Speaking as an individual: You'd think this wouldn't be controversial, but I'm not convinced that this sort of bureaucratic formatting rule is really the right solution to get IETF as a whole more focused on IPv6 and reinforcing the idea that IPv4 is now a legacy protocol. Yes, increasing exposure and familiarity with IPv6 addresses by using them more consistently is a good thing, and it seems harmless to suggest that we do this, but it's the word mandate that bothers me.
A mandate implies that there is some sort of recourse to force it to be changed if people don't comply, and a question of who enforces it - the IESG? The RFC editor? IDNITs check? The document shepherd? Making this a suggestion means that it is something that is enforced via people looking at drafts during reviews, WGLC, IETF LC, etc and asking, "is there any reason why these examples are IPv4?" and failing any acceptable justification, suggesting that they update the examples with the current protocol version. I think this is very similar to what happens when people use randomly chosen IP addresses or ASNs for examples instead of the proper documentation ones - someone points out that a change needs to be made, and we all move on. That might mean that it doesn't actually need to progress as an RFC, having served its purpose as an I-D to start the discussion. It's also possible that the right place for this is in the RFC style guide, though that's probably a longer discussion since as far as I can tell, the style guide does not currently have any recommendation about use of documentation addresses, no references to RFC 6890, etc. and so adding a discussion about which *type* of documentation addresses to use might be going too far. To the content of the document: >From a strict RFC2119 normative keyword interpretation, I'm don't think that MUST is the right word here, since you caveat that MUST with "unless..." MUST doesn't have exceptions. SHOULD and MAY do. So I think you probably want a "SHOULD... unless". And there's also the problem that 2119 words are, by strictest interpretation, intended to describe behavior that is required for interoperability, not "eat your vegetables" imperatives, and people tend to raise objections to their use in the latter way. Not saying that there aren't documents that use 2119 a little off-label, but the burden of justification is higher. Perhaps RFC 6919 is a better choice for your normative keywords? :-) Thanks, Wes On 4/6/16, 7:53 AM, "sunset4 on behalf of Andrei Robachevsky" <[email protected] on behalf of [email protected]> wrote: >Hi, > >I recently submitted an I-D >draft-robachevsky-mandating-use-of-ipv6-examples-00.txt, mandating use >of IPv6 in examples in RFCs. > >I was reading some pretty recent drafts and noticed that authors >continue using IPv4 in their examples. This is probably more convenient, >but is not really forward thinking. Also, the prevalence of IPv6 >examples will send a strong message that IPv4 is essentially a legacy >protocol. > >I wonder if this WG is interested in progressing this document as a WG >item. > >Thanks, > >Andrei > > >> Name:draft-robachevsky-mandating-use-of-ipv6-examples >> Revision:00 >> Title:Mandating use of IPv6 in examples >> Document date:2016-03-21 >> Group:Individual Submission >> Pages:3 >> URL: >>https://www.ietf.org/internet-drafts/draft-robachevsky-mandating-use-of-i >>pv6-examples-00.txt >> Status: >>https://datatracker.ietf.org/doc/draft-robachevsky-mandating-use-of-ipv6- >>examples/ >> Htmlized: >>https://tools.ietf.org/html/draft-robachevsky-mandating-use-of-ipv6-examp >>les-00 >> >> >> Abstract: >> IPv6 is a successor of the legacy IPv4 protocol. This document >> mandates use of IPv6 in examples provided in RFCs. > ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
