Hi Brian, Please see inline.
Cheers, Julien -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian E Carpenter Sent: mardi 26 février 2008 12:46 To: Ed Jankiewicz Cc: Brian Haberman; [email protected] Subject: Re: the role of the node "requirements" document On 2008-02-27 05:36, Ed Jankiewicz wrote: > (full disclosure - I am one of the editors of the DoD IPv6 Profiles > document - but comments are my own as an individual) > > 1. Can we discuss the normative level of the revised Node > Requirements document? My preference would be that it is a standards > track or BCP ultimately, to give firm definition of what an IPv6 node MUST do. > Another INFORMATIONAL document like RFC4294 is merely a helpful > annotated bibliography, but that may be all we can accomplish in a > reasonable timeframe, all in all it doesn't make a big difference. I think we have a lot of experience of failure in this area in the IETF (and OSI profiles also failed), so I predict that if we try to reach consensus on this as a standards-track or BCP document, we will fail again. As we often say, in the end it's the market that decides, and each implementor chooses what to do for their particular part of the market. I think our job is to publish clear and consistent specifications. In the present case, they may well say things like If you choose to implement IPsec, here are the RFCs that you MUST/SHOULD/MAY implement. If you choose to implement an IGP, here are the RFCs that you MAY implement. and so on, for things that are not part of the bare minimum. [JA]I like a lot this approach. It allows more solution specific SDOs to say what they take, and fits very fine with our 6lowpan effort to identify the "bare minimum". > > 2. I don't expect (nor believe it appropriate) that this revision > will satisfy all the needs of either NIST or DoD for defining "IPv6 Capable" > for our client organizations. Of course not. A requirement spec for an RFP is not the same thing as a generic implementation requirement spec. > That being said, several folks are > already reviewing the three drafts side by side, to help ensure that > the Node Requirements accurately defines the requirements that apply > to ALL > IPv6 nodes for ALL deployments. It may need to define a bare minimum but in addition it certainly needs to list a whole bunch of options. > The editors of the DoD and NIST > documents should concentrate on the delta from that baseline for > specific US Government and DoD requirements and deployments. As should anyone else in the RFP business. > > 3. Specifically with respect to IPsec and IKEv2, regardless of the > "settlement" of that debate years ago, there are still valid questions > about which requirements apply to ALL IPv6 nodes. I hope this > revision of the Node Requirements can reiterate the commitment to > IPsec, but if it does not, DoD (and NIST) can certainly state stronger > and more specific requirements in our documents. DoD in particular > answers to a higher authority on security and cryptographic > requirements, and will probably require things that a small office or home > user would never need. Exactly right, IMHO. Brian C > > A prior message in this thread (from Jeremy Duncan) included pointers > to the NIST and DoD profiles drafts, feel free to send any > questions/comments to the editors off-list. Some of the differences > are worth discussing on this list to see if there is consensus for > changes to the Node Requirements draft. Additional work will need to > be done by the editors of both the DoD and NIST drafts to address the > specific needs of our clients that don't apply to everyone. > > Hemant Singh (shemant) wrote: >> Brian, >> >> Indeed, I know that RFC4294 is INFORMATIONAL. I got confused because >> I see the new node-req-bis draft URL snipped below to be on Standards >> Track. >> >> http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01.t >> xt >> >> Sorry, if I am missing some IETF process. I was expecting the bis >> draft above to be INFORMATIONAL as well. >> >> Thanks. >> >> Best Regards. >> >> Hemant >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >> Of Brian Haberman >> Sent: Tuesday, February 26, 2008 9:27 AM >> To: [email protected] >> Subject: Re: the role of the node "requirements" document >> >> Hemant, >> Take a look at the category for RFC 4294 at >> http://tools.ietf.org/html/rfc4294. It is Informational and no >> discussion has occurred to change that classification for this update. >> >> Regards, >> Brian >> >> >> Hemant Singh (shemant) wrote: >> >>> Pekka, >>> >>> The node requirement draft as I read it from >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-node-req-bis-01. >>> tx >>> t >>> >>> is on Standards Track. Did I miss anything because you think this >>> node >>> >> >>> requirement doc is an INFORMATIONAL draft? >>> >>> As for IPSec and IPv6, indeed it is true that IPSec is mandatory for >>> IPv6, unlike IPv4. If one wants an RFC reference that says IPSec is >>> mandatory for IPv6, please refer to RFC 2401 or RFC 4301 (Security >>> Architecture for the Internet Protocol). Snipped from the RFC's is >>> section 10 shown below between square brackets. >>> >>> [10. Conformance Requirements >>> >>> All IPv4 systems that claim to implement IPsec MUST comply with all >>> requirements of the Security Architecture document. All IPv6 >>> >> systems >> >>> MUST comply with all requirements of the Security Architecture >>> document.] >>> >>> I totally appreciate Alain's concern for cable modem devices with >>> limited memory for IPv6 but the problem is that IPv6 community >>> decided >>> >> >>> as far back as 1998 with RFC 2401 that IPSec is mandatory for IPv6. >>> Cable IPv6 standards came much later. We will have to see what >>> common ground can be met to address Alain's concern. >>> >>> Hemant >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >>> Of Pekka Savola >>> Sent: Tuesday, February 26, 2008 5:05 AM >>> To: Alain Durand >>> Cc: [EMAIL PROTECTED]; [email protected]; Fred Baker (fred) >>> Subject: the role of the node "requirements" document >>> >>> On Tue, 26 Feb 2008, Alain Durand wrote: >>> >>>> The problem is that some of those devices have really limited >>>> memory and they already do (too?) many things, so there is no room left... >>>> Some vendors had to go back at their code and spend a lot of time >>>> and >>>> >> >>>> effort to clean things up to make room for the very basic IPv6 >>>> code, >>>> >>> so every kb count. >>> >>>> The whole idea of asking them to do extra efforts to implement a >>>> functionality that is not needed and that will introduce bugs & >>>> instability is not very appealing. >>>> >>>> Again, this last argument applies also to devices that do not have >>>> memory >>>> problems: if I do not need functionality X, I'd rather like not to >>>> have it implemented as it will lower the operational risks. >>>> >>> I think this discussion somewhat misses the point because some folks >>> feel informational roadmap documents have more weight than they >>> actually do (according to IETF procedures, or even in practice in >>> >> vendors' >> >>> feature planning). (E.g., there was similar discussion about >>> RFC4614.) >>> >>> The node requirements document, despite its misleading title, is >>> INFORMATIONAL. It does not represent IETF consensus, so even if the >>> document would say every IPv6 node MUST implement IPsec, it would >>> mean >>> >> >>> basically nothing. >>> >>> Where is a Standards Track or BCP document that says IPsec is >>> >> mandatory? >> >>> If vendors need to make tradeoffs of what they implement or don't >>> implement, that's their call. They can't call that product to be >>> "RFC4294 compliant", "RFC4301 compliant", claim it supports IPsec, >>> or claim it's "RFCxxxx" compliant (where xxxx corresponds to an RFC >>> number which mandates IPsec). That's all. >>> >>> The product also might not get IPv6 ready logo certifications and >>> such, but that's not IETF's business anyway. >>> >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> [email protected] >> Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: http://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
