Re: [sunset4] Mandating use of IPv6 in examples

["George, Wes" <[e-mail]>]

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"
<[e-mail] on behalf of [e-mail]> 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.