Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-l3vpn-mvpn-spmsi-joins-01.txt

Re: [Full-disclosure] IPv6 security myths

Michael, > For instance, a reason to create a new network "zone" is because we > don't provide printers with decent access control lists (authorization), > instead, we make them wide open and then throw WPA on the wireless so > that it's "secure", and then assume if you've authenticated, you are >

Re: what is the problem bis

For which Working Groups does the current system work? It is completely failing for every one that I have been involved in. The distinction between DRAFT standard and Internet STANDARD seems completely arbitrary as far as I can see. We might as well replace the final step of the process with thro

Re: cell sim card recommendations

Yes, you could only get sim card other than rent a a new phone. let me try to classify 3 operators 1) China Mobile: 2G: GSM/GPRS/EDGE, 3G: TDSCDMA 2) China Unicom: 2G: GSM/GPRS/EDGE, 3G:WCDMA 3) China Telcom: 2G: CDMA, 3G:CDMA 2000 1XEVDO If you would like to get 3G capability, I would recommend

cell sim card recommendations

Nihao, The Beijing event info includes a reference to getting a sim card at the airport: Some references I've seen elsewhere on the net suggest perhaps getting a China Mobile card in town at a store. (For example, much cheaper.) What none of

Re: Beijing hotel Nikko close to Shangri-La?

could anyone copy the map to me ? this website is not reachable for me. I have been there several days before, the direct road is only for bike, I have observed there for a while and it seems nobody walking beside the major road. For pedestian, you may have to cross several over-road bridges whic

Fwd: [rfc-i] Transitional RFC Editor recommendations published in draft-kowack-rfc-editor-model-v2

I'd like to make sure that all of you are aware that draft-kowack-rfc-editor-model-v2 was posted. Discussion of it will take place on the rfc-inter...@rfc-editor.org mail list. If you have an interest in the RFC Editor model, please review the document and participate in the discussion on that li

Re: draft-housley-two-maturity-levels

Tony, if I understood what you wrote, you are saying that the change we need is really for the IESG to step back from reviewing documents before they go to PS. This task would be delegated to the ADs (and directorates). This could even mean eliminating IETF LCs on documents going to PS? The

Re: draft-housley-two-maturity-levels

If it is still possible to get code points issued on an Informational or Experimental RFC and the bar for those documents is not raised, I don't see the problem. Original -> Current -> 2 step Proposed -> Informational / Experimental ->Informational / Experimental Draft -> Proposed -> Proposed

Re: [Full-disclosure] IPv6 security myths

> "Dave" == Dave CROCKER writes: >> The major*security* advantage of IPv6 is that it removes 90% of >> complexity of IPv4 networks that results from layers of NAT, and >> then series of port-forwards through them. Dave> That's an operational hope, not a technical or operation

RE: draft-housley-two-maturity-levels

Phillip Hallam-Baker wrote: > All that is being proposed here is a modest change that brings > out documented practices in line with the actual practice. > Documenting actual practice is usually a necessary step before > attempting a change. This does not document actual practice, it documents

RE: draft-housley-two-maturity-levels

I will let James speak to most of your points, but I did talk to him as he exited that session, and he was very clear at that point this was the AD for that WG not the chair, and there was no misunderstanding. While I trust this is not an official policy, I look at that event as a leading indicat

Re: draft-housley-two-maturity-levels

I think that Phillip and I have agreed to disagree Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: draft-housley-two-maturity-levels

There is a difference between a proposal that does not fix the problems that you consider important and a proposal that does not fix any important problems at all. All that is being proposed here is a modest change that brings out documented practices in line with the actual practice. Documenting

Re: draft-housley-two-maturity-levels

Phillip politely says > I think this is nonsense. > We have been discussing this for over a decade. Time for debate is up. It is > time to make a decision. since I see no reason to think that the proposed changes will do anything at all to address any of the problems that I, and others, have bro

Re: draft-housley-two-maturity-levels

I think this is nonsense. We have been discussing this for over a decade. Time for debate is up. It is time to make a decision. If the best argument that can be made in favor of the current situation is that we need to discuss the situation for a decade or two more then I take that as an admissi

Re: draft-housley-two-maturity-levels

Tony Hain wrote: > > Did you miss James Polk's comment yesterday? The IESG is already changing > their ways!! They now require 2 independent implementations for a personal > I-D to become a WG draft. Though I'd rather steer clear of this fray, I must question this. I'm quite certain the

Re: [Full-disclosure] IPv6 security myths

> "David" == David Morris writes: >> Partly. I also expect "VPN" use to get reduced, since 90% of VPNs >> are really just remote-access systems necessary due to NAT, not >> security. David> In my experince, VPNs are used for secure connections between David> two private n

Re: draft-housley-two-maturity-levels

+1 Ship it, its ready. On Mon, Oct 25, 2010 at 8:35 PM, Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > On 2010-10-26 13:22, Barry Leiba wrote: > >> I'd like to hear from the community about pushing forward with this > >> proposal or dropping it. > > > > I see disagreement with the pro

Re: [Full-disclosure] IPv6 security myths

> "Fred" == Fred Baker writes: Fred> By the way, I don't buy the assertion that the PKI has to be Fred> global; if it did have to be global, I suspect one would have Fred> come into existence. Quite a number of ideas and protocols have suffered because of the lack of such a thing

Re: [Full-disclosure] IPv6 security myths

Michael Richardson wrote: > The major *security* advantage of IPv6 is that it removes 90% of > complexity of IPv4 networks that results from layers of NAT, and then > series of port-forwards through them. See page 13 of the slide of Gont stating: Ironically, NAT66 is one of the most freq

Re: [Full-disclosure] IPv6 security myths

Michael, > The major *security* advantage of IPv6 is that it removes 90% of > complexity of IPv4 networks that results from layers of NAT, and then > series of port-forwards through them. You seem to be assuming that there will not be middle-boxes with IPv6. -- NAT64, for example, doesn't seem to

Re: Fwd: [Full-disclosure] IPv6 security myths

Fernando Gont wrote: > IPsec is a > "SHOULD" (rather than a "MUST") in the latest node-reqs-bis document Too late, too little. > [] >> For the end to end security, only the end systems requiring the >> security are required to deploy mechanisms for the security, >> which means it is not nece

Re: [Full-disclosure] IPv6 security myths

On Tue, 26 Oct 2010, Michael Richardson wrote: > Partly. I also expect "VPN" use to get reduced, since 90% of VPNs are > really just remote-access systems necessary due to NAT, not security. In my experince, VPNs are used for secure connections between two private networks ... the existance of

Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC

> "Ralph" == Ralph Droms writes: Ralph> Combining an excellent suggestion from Donald and Avygdor's Ralph> clarification as to the official status of this document, I Ralph> suggest an RFC Editor note to add the following text as a new Ralph> last paragraph in the Introduction

Re: [Full-disclosure] IPv6 security myths

> "Fernando" == Fernando Gont writes: >> How it happened? --- Ever heard of NAT? At the time IPsec >> through nat did not widely exist, and even implementations that >> figured out udp had the problem that the cert often included a >> 1918 address which didn't match the packe

Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC

Hi Ralph - Exactly what I was getting at. But a slight change in the wording you suggested to make things clear. Instead as the first paragraph of the abstract or as an RFC editor note I suggest: "This document is not an official submission on behalf of the ANSI C12.19 and C12.22 working gr

Re: [Full-disclosure] IPv6 security myths

On Oct 26, 2010, at 14:18, Fernando Gont wrote: > > Sorry, but I don't follow. If the problem with widespread deployment of > IPsec was NAT traversal, why didn't we see widespread IPsec deployment > (for the general case) e.g. once RFC 3948 was published? RFC 3498 really only made a variant of tu

Re: [Full-disclosure] IPv6 security myths

On 10/26/2010 3:05 PM, Michael Richardson wrote: The major*security* advantage of IPv6 is that it removes 90% of complexity of IPv4 networks that results from layers of NAT, and then series of port-forwards through them. That's an operational hope, not a technical or operational fact. It i

Re: draft-housley-two-maturity-levels

> "Andrew" == Andrew Sullivan writes: >> I'm not in love with the 3 maturity levels, especially when I was >> asked by an AD during Maastricht to provide proof of 2 >> independent implementations just to have an ID I was presenting >> be considered to become a WG item. >>

Re: what is the problem bis

> "Eliot" == Eliot Lear writes: >> The downside of Russ's draft is that it is possible that after >> approving it we might find that nothing changes: Protocol >> specifications still stay at Proposed Standard; The IESG still >> takes a lot of time in approving a request to pub

Re: [Full-disclosure] IPv6 security myths

> "Fred" == Fred Baker writes: Fred> I'm not a security guru, and will step aside instantly if Fred> someone with those credentials says I'm wrong. However, from Fred> my perspective, the assertion that IPv6 had any security Fred> properties that differed from IPv4 *at*all* ha

Re: what is the problem bis

On Oct 26, 2010, at 2:39 PM, Dave CROCKER wrote: > I'm a fan of reducing down to 2 levels, too. But it has nothing to > do with how overblown the effort to get to Proposed is. (Well, I feel like we already have a 2-level system. What's the practical difference between Proposed and full Standard

Re: [Full-disclosure] IPv6 security myths

On Oct 25, 2010, at 5:46 AM, Masataka Ohta wrote: > Sabahattin Gucukoglu wrote: > >> In the interest of fair and balanced discussion. > > It is of course that, merely because IPv6 makes IPsec mandatory, > IPv6 can not be more secure than IPv4. > > But, the real problem of IPsec is that it expe

Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC

Combining an excellent suggestion from Donald and Avygdor's clarification as to the official status of this document, I suggest an RFC Editor note to add the following text as a new last paragraph in the Introduction: This document was created by technical experts of the ANSI C12.22 and ANSI

Re: [Full-disclosure] IPv6 security myths

Hi, Fred, > I'm not a security guru, and will step aside instantly if someone > with those credentials says I'm wrong. However, from my perspective, > the assertion that IPv6 had any security properties that differed > from IPv4 *at*all* has never made any sense. It is essentially a > marketing cl

Re: what is the problem bis

Hi - > From: "Phillip Hallam-Baker" > To: "Scott O. Bradner" > Cc: > Sent: Tuesday, October 26, 2010 12:24 PM > Subject: Re: what is the problem bis ... > Most of the documents to reach STANDARD status in recent years have been > SNMP documents. But even though SNMP has its uses, deployment and

Re: [Full-disclosure] IPv6 security myths

Hi, Tony, >> I have a feeling the idea that IPv6 add something to security might >> be linked back to the IPsec focus real early on in the IPv6 era, >> like years and years ago. Why it happen or how, I don't really >> know. > > How it happened? --- Ever heard of NAT? At the time IPsec through >

RE: [Full-disclosure] IPv6 security myths

Roger Jørgensen wrote: > Sent: Tuesday, October 26, 2010 1:53 PM > To: Fred Baker; IETF Discussion > Subject: Re: [Full-disclosure] IPv6 security myths > > On Tue, Oct 26, 2010 at 10:39 PM, Fred Baker wrote: > > > In the scope of things, wh does having one of out of the many needed > tools make

RE: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC

One simple question: Is this document an official and approved submission on behalf of the ANSI C12.22 and ANSI C12.19 working groups? The specific language in the IESG record (in the working group summary) is "This document was created by technical experts of the ANSI C12.22 and ANSI C12.

RE: draft-housley-two-maturity-levels

Scott O. Bradner wrote: > ... > the only way that could happen is if the IESG were to change their ways > a lot > and permit less complete documents to be published as PS Did you miss James Polk's comment yesterday? The IESG is already changing their ways!! They now require 2 independent implement

Re: [Full-disclosure] IPv6 security myths

On Tue, Oct 26, 2010 at 10:39 PM, Fred Baker wrote: > In the scope of things, wh does having one of out of the many needed tools > make > IPv6 different than IPv4, especially given that the indicated tool is present > in both > IPv4 and IPv6 implementations? > > Scratch-a-my-head. I don't see i

Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC

If there is something in the IESG write-up that is needed to understand the nature of a document, that material should also appear in the document. Most people looking at RFCs probably don't even know that an IESG write-up might exist or where to find it and even those who do know about the IESG wr

Re: [Full-disclosure] IPv6 security myths

I'm not a security guru, and will step aside instantly if someone with those credentials says I'm wrong. However, from my perspective, the assertion that IPv6 had any security properties that differed from IPv4 *at*all* has never made any sense. It is essentially a marketing claim, and - well, w

Re: what is the problem bis

On Oct 26, 2010, at 2:27 PM, Ross Callon wrote: > In my opinion the fact that this very simple and straightforward change draws > such heavy debate is a disincentive to anyone who would propose other > additional changes. Often the reason that "simple and straightforward changes" draw such he

Re: what is the problem bis

On Oct 26, 2010, at 1:54 PM, Dave CROCKER wrote: > Working groups take too long. The IESG often takes too long and ADs often > raise unexpected and possibly even arbitrary barriers. We have moved to an > enormously heavyweight model. Timeliness is almost never a factor. > > Nothing gets bett

Re: WG Review: Keys In DNS (kidns)

"Jeffrey A. Williams" writes: >>I object to that limitation. I believe it is important that any >>solution in this space supports different certificates for different >>ports/protocols on the same host. > > Whynot have both. One being a shared cert as acceptable and the > option of one for ea

Re: what is the problem bis

On Oct 26, 2010, at 12:32 PM, Ross Callon wrote: > I don't think that anyone is claiming that the two-maturity-levels draft > solves every problem. This draft should not discourage you or anyone else > from offering additional proposals to solve the problems that you are > mentioning in your em

Re: what is the problem bis

On Oct 26, 2010, at 2:39 PM, Dave CROCKER wrote: > I'm a fan of reducing down to 2 levels, too. But it has nothing to do with > how > overblown the effort to get to Proposed is. (Well, there's some pretty > simple > psych logic that says that it could actually make the barrier to Proposed >

Re: what is the problem bis

On Oct 26, 2010, at 12:08 PM, Scott O. Bradner wrote: > Seems to me that the issue of how the IETF can be better at producing > just what the community needs just when the community needs it is more > important than maturity warning labels. agreed, though we should be careful to not confuse "what

RE: what is the problem bis

--On Tuesday, October 26, 2010 14:27 -0400 Ross Callon wrote: > This is where I disagree with you. The simple change that Russ > has proposed is not what is taking away from discussion of the > actual barriers. What is taking attention away from discussion > of the actual barriers is the length

Re: WG Review: Keys In DNS (kidns)

I believe the KIDNS charter is generally good and I support forming this WG to work on this topic, however I have one important concern: > Specify mechanisms and techniques that allow Internet applications to > establish cryptographically secured communications by using information > distributed t

Re: draft-housley-two-maturity-levels

On Mon, Oct 25, 2010 at 11:36 AM, Russ Housley wrote: > I'd like to hear from the community about pushing forward with this > proposal or dropping it. > > At least one other proposal was raised.  My reading of this mail list is > that the proposal in draft-housley-two-maturity-levels has more supp

Re: what is the problem bis

The problem with the current, failed process is that there is absolutely no correlation between the standards status of a protocol and adoption. Most of the documents to reach STANDARD status in recent years have been SNMP documents. But even though SNMP has its uses, deployment and use hardly com

Re: what is the problem? (was Re: draft-housley-two-maturity-levels)

On Oct 26, 2010, at 10:19 AM, Phillip Hallam-Baker wrote: > Action > > We should adopt Russ's proposal: Axe the DRAFT status and automatically > promote all DRAFT status documents to STANDARD status. This can be done > formally by changing the process or the IESG can just agree to a convention

Re: what is the problem bis

--On Tuesday, October 26, 2010 10:54 -0700 Dave CROCKER wrote: > On 10/26/2010 9:32 AM, Ross Callon wrote: >> There are two problems that Russ's draft may very well solve: >> One issue with our current system is that there is no >> incentive to go from Proposed Standard to Draft Standard >> (si

Re: what is the problem bis

On 10/26/2010 11:27 AM, Ross Callon wrote: What is taking attention away from discussion of the actual barriers is the lengthy debate about Russ's proposed change. Here's where the term 'opportunity cost' applies: Taking action that does not achieve what is desired consumes energy and

Re: draft-housley-two-maturity-levels

Barry coments > Scott, I'm confused about one thing you say: >You seem to be saying that we have to carefully deliberate, consider > many factors, and be serious if we want to *change* the basic rules... > but that it's OK to *ignore* the basic rules and do whatever we want, > with no deliberation

Re: WG Review: Keys In DNS (kidns)

Howdy, The charter below has the following text: "The group may also create documents that describe how protocol entities can discover and validate these bindings in the execution of specific applications. This work would be done in coordination with the IETF Working Groups responsible for the pr

RE: what is the problem bis

Regarding your comment: > Working groups take too long. The IESG often takes too long and ADs often > raise > unexpected and possibly even arbitrary barriers. We have moved to an > enormously > heavyweight model. Timeliness is almost never a factor. In general I think that there is a lot o

Re: what is the problem bis

On 10/26/2010 9:32 AM, Ross Callon wrote: There are two problems that Russ's draft may very well solve: One issue with our current system is that there is no incentive to go from Proposed Standard to Draft Standard (since you are only going from one "intermediate state" short of full standard t

Re: what is the problem bis

On 10/26/2010 9:13 AM, Marshall Eubanks wrote: Would the first step be to try and get some statistics, to see how many of those ~ 200 standards fall into class 1-6 ? Sure would be nice to have a place for noting the basic data. What if someone created a wiki... [1] d/ [1] http://trac.to

Re: what is the problem bis

On 10/26/2010 9:08 AM, Scott O. Bradner wrote: while we are the topic of problems No Scott the problem is that the IETF is not a lobbyist organization and your blocking the standardization of anything based on whether the Internet "needs it or not" makes your IETF the controller of what gets

Re: draft-housley-two-maturity-levels

On Oct 26, 2010, at 8:41 AM, Scott O. Bradner wrote: > I think it is better to not fiddle, even if the current documents > do not paint an accurate picture, I think we need to be serious > when changing our basic rules. +1 ___ Ietf mailing list Ietf@ie

Re: what is the problem? (was Re: draft-housley-two-maturity-levels)

I think that many of us already know the problem(s) we want to solve here and have done since before NEWTRK was chartered. The core problem in my view is that the current IETF process is not and cannot be understood by non-participants because the theory is not and has never been followed. As a

Re: what is the problem bis

Ross, On 10/26/10 6:32 PM, Ross Callon wrote: > The downside of Russ's draft is that it is possible that after approving it > we might find that nothing changes: Protocol specifications still stay at > Proposed Standard; The IESG still takes a lot of time in approving a request > to publish a p

Re: draft-housley-two-maturity-levels

James M. Polk wrote: > > I'm not in love with the 3 maturity levels, especially when I was > asked by an AD during Maastricht to provide proof of 2 independent > implementations just to have an ID I was presenting be considered to > become a WG item. > > That bar is just WAY too high. Were yo

Re: draft-housley-two-maturity-levels

Scott, I'm confused about one thing you say: On Tue, Oct 26, 2010 at 8:41 AM, Scott O. Bradner wrote: > I think the community should only change its processes with careful > deliberation > taking into account the interplay of the different factors ... > I think it is better to not fiddle, even i

RE: Call for Community Feedback on Willing Nominees

Hi Tom, Take another look. The open positions are there and listed with the current incumbent, 1 IAOC slot, 8 IESG slots with the area right after the incumbents name, and 6 IAB slots. < I assume that the people listed are vacating their current positions and so, if we knew what those pos

RE: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 TransportOver IP' to Informational RFC

Dear Nikos, I believe that you appropriately addressed the comment and I are in complete agreement with your remarks. I'd would also like to point out that Mr. St. Johns' concerns are also addressed on the IETF data tracker for this RFC (http://datatracker.ietf.org/doc/draft-c1222-transport-

Re: draft-housley-two-maturity-levels

I support advancing this document to BCP and making these process changes.The changes will simplify advancement of standards-track documents and be a good step in the right direction. Please do seek a sponsor for this draft. Yours, Ran Atkinson _

Gen-ART last call review of draft-ietf-emu-eaptunnel-req-08

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-emu-eaptunnel-req-08 Re

Re: draft-iab-dns-applications - clarification re: Send-N

While I understand that there are a number of interesting questions about the DNS in play in the industry today, the subject of the iab-dns-applications draft is the dividing line between application functionality and the domain name system. Its target audience is the application protocol desig

Re: draft-iab-dns-applications - clarification re: Send-N

I refer to any past, present or future version of the charter that departs from the assumption that the DNS is the right protocol to address a set of discrete problems that includes the candidate drafts of the original E2MD BoF. As I read the version you point to below, for example, it does sug

RE: what is the problem bis

I don't think that anyone is claiming that the two-maturity-levels draft solves every problem. This draft should not discourage you or anyone else from offering additional proposals to solve the problems that you are mentioning in your email below. There are two problems that Russ's draft may

Re: what is the problem bis

On Oct 26, 2010, at 12:08 PM, Scott O. Bradner wrote: > while we are the topic of problems > > Russ basically proposes too change the maturity warning label on IETF > standard track RFCs -- remove baby before folding carriage -- this > hardly seems like our biggest problem > > The IETF publishe

Re: draft-housley-two-maturity-levels

On Mon, Oct 25, 2010 at 10:37:03PM -0500, James M. Polk wrote: > I'm not in love with the 3 maturity levels, especially when I was asked > by an AD during Maastricht to provide proof of 2 independent > implementations just to have an ID I was presenting be considered to > become a WG item. > >

what is the problem bis

while we are the topic of problems Russ basically proposes too change the maturity warning label on IETF standard track RFCs -- remove baby before folding carriage -- this hardly seems like our biggest problem The IETF publishes a lot of standards track RFCs each year. Mostly these are PS (186 i

Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 Transport Over IP' to Informational RFC

Hi Nikos - Unfortunately, [0] isn't a great reference to try and make this point: 1) It was published 20 years ago when we all of this was still in flux. 2) It's an algorithm description for crypto that's useful in certain situations, not a protocol (e.g. we've got multiple digital signature al

Re: draft-housley-two-maturity-levels

> "Scott" == Scott O Bradner writes: >> The known problem is it takes well over four years to get anything >> published. Scott> ... >> What I *am* hoping is that with two, clearly defined maturity levels, we >> can go back to publishing Proposed Standards in about a year

Re: draft-housley-two-maturity-levels

exec summary, but comments inline: I am in favour of two maturity levels. > "James" == James M Polk writes: James> At 09:44 PM 10/25/2010, John Levine wrote: >> >I am happy to agree to what the draft currently says. We've sliced >> >and diced this many times over the years, and t

Re: draft-housley-two-maturity-levels

Eric Burger wrote: > > The known problem is it takes well over four years to get anything > published. We've actually been making progress on that, at least for the part where the IESG is involved. Russ's draft _would_ reduce one issue: where a reference should be Normative but hasn't bee

Re: draft-housley-two-maturity-levels

On 26.10.2010 16:31, Dave CROCKER wrote: ... This seems to be the core idea driving support for this specification. Unfortunately, there is nothing in the proposed change that will affect this goal. The idea seems to be that "simplifying" the later part of the labeling model will somehow cause

Re: draft-housley-two-maturity-levels

On 10/26/2010 3:11 AM, Eric Burger wrote: What I*am* hoping is that with two, clearly defined maturity levels, we can go back to publishing Proposed Standards in about a year, This seems to be the core idea driving support for this specification. Unfortunately, there is nothing in the prop

Re: Fwd: [Full-disclosure] IPv6 security myths

Hi, Masataka, >> In the interest of fair and balanced discussion. > > It is of course that, merely because IPv6 makes IPsec mandatory, > IPv6 can not be more secure than IPv4. That was indeed the point of that slide. -- that aside, IPsec is a "SHOULD" (rather than a "MUST") in the latest node-re

what is the problem? (was Re: draft-housley-two-maturity-levels)

some more thoughts first figure out what problem you are trying to solve is the problem: 1/ that the 3 step standards track described in RFC 226 and its predecessors does not describe what happens most of the time? 2/ (as Eric says) that it takes too long to get to the first stage 3/ too much

Re: draft-housley-two-maturity-levels

Russ asks > Just to clarify, do you think that it would be better to document "one > step" or do you think that the community should not spend time on this > topic at all? I think the community should only change its processes with careful deliberation taking into account the interplay of the di

Re: draft-housley-two-maturity-levels

Scott: Just to clarify, do you think that it would be better to document "one step" or do you think that the community should not spend time on this topic at all? On 10/25/2010 10:48 PM, Scott O. Bradner wrote: > >> I'd like to hear from the community about pushing forward with this >> proposal

Re: draft-housley-two-maturity-levels

> The known problem is it takes well over four years to get anything > published. ... > What I *am* hoping is that with two, clearly defined maturity levels, we > can go back to publishing Proposed Standards in about a year the only way that could happen is if the IESG were to change their ways

Re: draft-housley-two-maturity-levels

The known problem is it takes well over four years to get anything published. I am experiencing in one never-ending saga the logical conclusion of the logic: since Proposed Standard is the new Draft Standard, and since the IESG has to make sure any proposal is beyond bullet-proof, the industry h

Re: Document Action: 'ANSI C12.22, IEEE 1703 and MC12.22 Transport Over IP' to Informational RFC

On Mon, Oct 25, 2010 at 7:39 PM, Michael StJohns wrote: > Hi - > I'm confused about this approval. > As I read the draft and the approval comments, this document is an > independent submission describing how to do C12.22 over IP.  But the document > is without context for "who does this" typical

Re: Beijing hotel Nikko close to Shangri-La?

Hi Alex, You wrote: > Thank you for guidance, I've put Shangri-La and Nikko on a google map: > >http://ow.ly/2ZpEh > > I hope they're correct. They are correct if you pick the "plan" view" the "satelite" view has a horizontal offset of about 500 meters. Regards, Huub. --

Re: Beijing hotel Nikko close to Shangri-La?

Thank you for guidance, I've put Shangri-La and Nikko on a google map: http://ow.ly/2ZpEh I hope they're correct. Alex Le 25/10/2010 18:29, Worley, Dale R (Dale) a écrit : > > From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behal

Re: draft-housley-two-maturity-levels

Although I do sort of also agree with Scott, I think it is one step in the right direction. So please seen a sponsor and get it published. Bert On 10/26/10 4:48 AM, Scott O. Bradner wrote: I'd like to hear from the community about pushing forward with this proposal or dropping it I do not thin