A handful of comments. Perhaps Section 12 of any -04 version can update it's 'open issue' list to reflect what's below and anything else on the table? And are we content that the other things listed currently in section 12 have been answered?
Can we say anything stronger for MLDv2 support? It is frustrating to be in a campus deployment where one notable vendor continues to not provide this - encouragement would be welcome. What about CGA/SeND support? I can't see any reference to this currently. Should there be? It's often waved as the answer to make rogue RAs 'go away', so perhaps we should. There's a couple of newish RA-related RFCs out that may be relevant, though one is experimental: RFC 5006 (perhaps relevant in 6.2.2 of the node requirements draft) and RFC 5075. Was there agreement or not to list various IPv6-over-Foo documents? There's now also RFC 5121. Tim On Mon, Jul 20, 2009 at 04:25:40PM -0400, Thomas Narten wrote: > Hi. > > I've posted a revised version of the node requirments ID. This > document had stalled for a while and I volunteered to help move it > along. Wish me/us luck! > > The new -03 version has only fairly minor changes relative to > -02. Specifically, they were (IMO) editorial cleanups that were no > brainers. A summary of the changes appears below. > > Over the next few days, I will post some additional messages with > specific issues that still need to be resolved. The document will also > be discussed in Stockholm. > > They include: > > - proper status of this document (info vs. BCP) and whether this > document can update any existing RFC > > - Security recommendation. It clearly needs tweaking/updating, but > the fundamental one surrounds the current MUST for IPSec/ESP, MAY > for AH, and SHOULD for some (unspecified) key management. > > - DHCP and stateless autoconf. This document is probably not the > right place to discuss the M&O bits, but IMO this document should > say more about DHCP vs. stateless and the issues surrounding when > to implement one or the other. Not to mandate them. Actually, that > raises an intersting point. This document (and RFC 4294) mandate > (MUST) that hosts implement stateless autoconfiguration. This > despite that this document is only informational, and no where in > standards track RFCs is stateless autoconf mandated. This takes us > back to the question of what the scope of this document should be. > > If anyone has any other issues they think the document should address, > please speak up. > > Thomas > > John Loughney says: > > > >section 5.1, last paragraph. Shouldn't the doc reference RFC > > >5095 and deprecation of RH0? suggest: > > > > > > An IPv6 node MUST be able to process these headers. An exception is=20 > > >Routing Header type 0 (RH0) which is deprecated by [RFC 5095] due to=20 > > >security concerns, and which MUST be treated as an unrecognized routing=20 > > >type. > > > > Issue 7. I think this would be good to add. > > tn: done (and added reference) > > > >5.2 - should RFC 5175 - extensions to RA flags - be included? > > > > Issue 8: This would be good to add as well. > > tn: done. > > > >5.3.1 - would it be redundant to mention the default MTU defined in=20 > > >2460, e.g. "The rules in RFC 2460 MUST be followed for default minimum=20 > > >MTU size of 1280, packet fragmentation and reassembly." > > > > Issue 9: This seems good to add. > > tn: done. see replacement text > > > >6.1 - A6 records: is NOT RECOMMENDED strong enough? =20 > > >"conventional wisdom" is that A6 has been deprecated, while > > >3363 makes it experimental. Perhaps the node requirements should say=20 > > >SHOULD NOT implement A6. > > > > I didn't give this an issue, as I think this is according to 2119 language. > > tn: no change. "NOT RECOMMENDED" is equivalent to "SHOULD NOT". > > > >7.1.1 - typo - update ref in title to 4213 > > > > Issue 10: I think this should be fixed. > > tn: Done, but it causes the line to wrap. > > > >8. - update ref to RFC 3776 to add RFC 4877 as well. (updates 3776 for > > >4301 architecture) > > > > Issue 11: Yup, this should be fixed. > > tn: done. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -- Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
