Re: [sunset4] Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on IPv4) to Proposed Standard

[Eliot Lear <[e-mail]>]

Hi Lee and others,

I agree with Adrian and would go a bit further.  The abstract seems to
contradict the content.  That needs correcting, one way or the other. 
This reader in particular is confused as to the document's intent.  And
so, I have these questions:

 1. If I wish to add a new DHCPv4 option as well as a similar DHCPv6
    iption, would that contravene the intent of this document?
 2. If I wish to add a field that would permit IPv4 addresses and IPv6
    addresses, would that contravene the intent of this document?

Let us presume for purposes of answering these questions that we are
talking about non-security and non-transitional work.

I also have a comment about the charter of sunset4 with regard to this
document.  I was expecting to see a gap analysis first, and I wasn't
particularly expecting a policy statement from this WG.

I share the sentiment of the abstract, but I also share the concerns
that Stewart raised.  If there is a demand for IPv4 improvements, and
the IETF won't satisfy it, others will fill that vacuum.  That sort of
problem has posed a substantial amount of work for the IAB, the IESG,
ISOC, and the IETF Trust in the past.

Thanks,

Eliot


On 9/28/17 8:29 PM, Adrian Farrel wrote:
> The underlying intent of this document may be well intentioned, but the execution is lacking. As currently presented I strongly oppose it's publication as an IETF RFC.
>
> 1. The document title is (wilfully?) melodramatic and is in conflict with the content of the document. This document specifically lists circumstances under which the authors think that the IETF should continue to work on IPv4. Using this document title will do nothing more than cause confusion, panic, and result in the kind of "land grab" that others have worried about. Can the title please be changed to reflect the actual content of the document.
>
> 2. The Abstract is at odds with the content of the document. The Abstract says:
>>   The IETF will stop working on IPv4, except where needed to mitigate
>>   documented security issues, to facilitate the transition to IPv6, or
>>   to enable IPv4 decommissioning.
> ...but Section 1 adds to this list the very important point that 
>>  Until the time when IPv4 is no longer in
>>  wide use and/or declared historic, the IETF needs to continue to
>>  update IPv4-only protocols and features for vital operational or
>>  security issues.  "Vital" means "necessary for successfully operating
>>  IPv4 networks."  
> ...The Abstract must give an accurate account of what the document says. This could be achieved by saying less ("This document describes the IETF's approach to new work on IPv4 and IPv4-only protocols") or more (by setting out the full list of cases as described in Section 1).
>
> 3. The bullet list in Section 1 concludes with:
>>    New IETF work must function completely on IPv6-only nodes and
>>    networks.
> ...This is ambiguous after the previous bullets. I believe that either there is some special meaning of "New" intended here (different from in previous bullets) or this is meant to read something like:
> |  All new IETF work must be capable of functioning in IPv6-only networks.
>
> 4. The IANA Considerations section attempts a commentary that is probably unhelpful. It might be helpful to replace this with a "standard" Null IANA section as that will be clearer and is entirely consistent with the ask (which is null).
>
> 5. You might consider adding some statement about documentation of examples in new RFCs (idnits already drops a strong hint, but most authors chose to ignore it). It might be too strong to require non-documentation of IPv4 examples, but inclusion of IPv6 examples whenever there is an IPv4 example sounds like a good idea "unless there is a good and documented reason why not."
>
> And lastly, just to check...
> Suppose I have a protocol that runs in a private network using a private address space, and suppose that that network currently uses IPv4. Take as an example a network that uses management or control protocol running between the routers and separate from the traffic carried over the network. 
> My reading of this I-D is that those protocols can be enhanced and features added provided that those additions are also made such that the protocols would work perfectly in an IPv6-only network.
> If it is not the intention that I should be able to make this reading, then words should be changed.
>
> Thanks,
> Adrian
>
>
>
>
>> -----Original Message-----
>> From: IETF-Announce [mailto:[e-mail]] On Behalf Of The
>> IESG
>> Sent: 28 September 2017 14:26
>> To: IETF-Announce
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Last Call: <draft-ietf-sunset4-ipv6-ietf-01.txt> (IETF: End Work on IPv4)
>> to Proposed Standard
>>
>>
>> The IESG has received a request from the Sunsetting IPv4 WG (sunset4) to
>> consider the following document: - 'IETF: End Work on IPv4'
>>   <draft-ietf-sunset4-ipv6-ietf-01.txt> as Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits final
>> comments on this action. Please send substantive comments to the
>> [e-mail] mailing lists by 2017-10-12. Exceptionally, comments may be
>> sent to [e-mail] instead. In either case, please retain the beginning of
>> the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>    The IETF will stop working on IPv4, except where needed to mitigate
>>    documented security issues, to facilitate the transition to IPv6, or
>>    to enable IPv4 decommissioning.
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-ietf-sunset4-ipv6-ietf/ballot/
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>>
>> The document contains these normative downward references.
>> See RFC 3967 for additional information:
>>     draft-george-ipv6-support: IPv6 Support Within IETF work (None - )
>>
>
>