No, it was much earlier than the time of this document, I think around 2006.
As I recall it, was not referring to nodes, but in general to “IETF work”.
May be got the idea wrong in my memory, and it was not an RFC, but an IESG rule something such as “omitting IPv6 support in a document without a reasonable explanation will not be accepted by IESG” ? Do we have this kind of “rules” ?
Saludos,
Jordi
-----Mensaje original-----
De: Lee Howard <***@asgard.org>
Responder a: <***@asgard.org>
Fecha: miércoles, 6 de abril de 2016, 11:08
Para: Jordi Palet Martinez <***@consulintel.es>, <***@ietf.org>
Asunto: Re: [sunset4] Mandating use of IPv6 in examples
>rfc6540?
>"IPv6 Support Required for All IP-Capable Nodes²
>
>Lee
>
>On 4/6/16, 6:33 PM, "sunset4 on behalf of JORDI PALET MARTINEZ"
><sunset4-***@ietf.org on behalf of ***@consulintel.es> wrote:
>
>>I recall there was a document, hopefully turned into RFC, a few years
>>ago, stating that any future work in IETF must support IPv6 unless
>>clearly is an IPv4-only protocol. But can¹t find that document
>>
>>If I¹m correct and that document exist, what about reviewing that one to
>>include also now the mandatory IPv6 examples ?
>>
>>Saludos,
>>Jordi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>-----Mensaje original-----
>>De: sunset4 <sunset4-***@ietf.org> en nombre de "George, Wes"
>><***@twcable.com>
>>Responder a: <***@twcable.com>
>>Fecha: miércoles, 6 de abril de 2016, 11:59
>>Para: Andrei Robachevsky <***@gmail.com>,
>>"***@ietf.org" <***@ietf.org>
>>Asunto: Re: [sunset4] Mandating use of IPv6 in examples
>>
>>>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"
>>><sunset4-***@ietf.org on behalf of ***@gmail.com>
>>>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-ipv
>>>>>6-
>>>>>examples/
>>>>> Htmlized:
>>>>>https://tools.ietf.org/html/draft-robachevsky-mandating-use-of-ipv6-exa
>>>>>mp
>>>>>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
>>>***@ietf.org
>>>https://www.ietf.org/mailman/listinfo/sunset4
>>>
>>
>>
>>_______________________________________________
>>sunset4 mailing list
>>***@ietf.org
>>https://www.ietf.org/mailman/listinfo/sunset4
>
>
>