[RTG-DIR] RtgDir review: draft-ietf-sunset4-ipv6-ietf-01

[Ron Bonica <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document:  draft-ietf-sunset4-ipv6-ietf-01
Reviewer: Ron Bonica
Review Date: 10/6/2017
IETF LC End Date: 10/12/2017 
Intended Status: Standards Track

Summary: 

I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.

Comments:

Major Issues:

1) If published, would this draft prevent work like RFC 6864? Given that the majority of Internet traffic still runs over IPv4, is that a good idea?

2) I cannot parse Section 1, Bullet 2. The problem may be that the terms "IPv4-only protocol" and "IPv4-only feature" are undefined. The use of negatives in the second sentence doesn't help. I think that the author is trying to say, "it is OK to add an IPv4 feature so long as you add the equivalent IPv6 feature". But which of the following examples are covered:

a)  it is OK to add a feature to OSPFv2, so long as you add the equivalent feature to OSPFv3
b)  it is OK to add an new ICMPv4 message, so long as you add the equivalent ICMPv6 message
c) it is OK to add a new IPv4 Option, so long as you add the equivalent IPv6 option

I think that a) and b) are reasonable, while c) is not. But I can't glean this from the draft.

3) I cannot parse Section 1, Bullet 4 because the term IPv4 extension technology is undefined. Does this mean that RFC 791 cannot be updated? Or does it mean more than this

4) Does this document represent a departure from current IETF policy? If so, how? If not, why is it needed.

5) The title of this document offers shock value. Once we resolve the ambiguity in the document, and once we answer the question above, we should decide whether the title delivers the right message to the industry.


Minor Issues:

None

Nits:

None