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:
- If I wish to add a new DHCPv4 option as well as a similar
DHCPv6 iption, would that contravene the intent of this
document?
- 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:ietf-announce-bounces@xxxxxxxx] On Behalf Of The
IESG
Sent: 28 September 2017 14:26
To: IETF-Announce
Cc: sunset4-chairs@xxxxxxxx; draft-ietf-sunset4-ipv6-ietf@xxxxxxxx;
sunset4@xxxxxxxx; terry.manderson@xxxxxxxxx
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
ietf@xxxxxxxx mailing lists by 2017-10-12. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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 - )