Skip to main content

IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
RFC 7600

Note: This ballot was opened for revision 08 and is now closed.

Ted Lemon Former IESG member
Yes (2014-12-15)
I'm adding this comment in response to some of the comments raised by Adrian and concurred with by several other ADs.   If it had been my personal choice, I would have proposed either publishing this document as Informational, or through the ISE.   However, the working group consensus was to publish this document as an Experimental document.   I would need a strong reason to push back on the working group consensus, and the best I could come up with is that it would somehow look better.   The allocation of an RFC number would not change, and the document would still get published.   So I see no point in going down that path.

As to the experimental status of the document, and "protecting the internet" from it, on the one hand the experimental status of the document does legitimately lead us to want to ask that question, but on the other hand I think the answer to that question is that there is no risk to the internet from this specification.   Like any A+P solution, it will be expensive to deploy, and will not be deployed broadly across the Internet in a way that requires end-to-end interoperation.

So the goal when considering interoperability and harm to the internet with this document should be "what harm will come if a host that is reachable over this technology attempts to connect to some arbitrary host on the internet that may or may not be using this technology (or some other A+P technology)."   The working group considered this technology at length and identified no such issues other than those currently documented, to which Adrian and the others have not raised specific objections.   This technology was a candidate for being chosen as the working group's proposed solution to the lightweight CGN problem.   It wasn't selected, but would have been a viable candidate.

Consequently, I conclude that no actionable point has been raised here.   I think it is unreasonable to ask the authors or the working group to attempt to come up with some pro forma list of issues from which the Internet need be protected when there are currently no such known issues, and when there is no stated reason to think that such issues exist or need to be addressed.

Were I to advise a working group on how to approach such a decision in the future, I would advise them not to follow the path that the working group followed in this case.   However, that is water under the bridge.   I therefore consider this particular issue to be closed.
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2014-10-30 for -09)
I discussed my Discuss with the responsible AD, and arrived at an understanding that the text in RFC 3315 for the registry is not as clear as it could have been.

Our agreement is that the allocation policy is meant to be:
   Standards Action
   Expert Review with guidance to the DE including that the
   allocation can be reclaimed if it turns out that the use of
   the codepoint is not successfully deployed.

This is obviously not what 3315 actually says, but I have cleared my Discuss on the understanding that some effort will be made to document this allocation policy, and an attempt will be made to get IETF consensus on this.


Just like draft-ietf-softwire-map-t, I don't specifically care to
object to the publication of this document and I don't feel strongly 
enough to abstain, but I do find it hard to understand why it is being
published even as experimental. It feels to me like a consolation prize
for not being the WG's selected solution. Maybe it would have been 
better to pursue publication either as an historic record of an idea
not adopted, or as an informational record of some existing
implementation and deployment. That way it would have been less
confusing to the market.

Anyway, given that it is positioned as an experimental RFC, I wish this
document explained why and how it is experimental in nature. It is not a
requirement to do this, but it would make a lot of sense.

- How is the Internet kept safe from the experiment?
- What feedback do you want from experimentation?
- How will you judge the success of the experiment?
- How do you plan to move the experiment to standards track?
Barry Leiba Former IESG member
No Objection
No Objection (2014-10-29 for -09)
I've had a quick look, and nothing stands out.  I trust my distinguished colleagues from Vermont and Maryland to duke it out.
Benoît Claise Former IESG member
No Objection
No Objection (2014-10-30 for -09)
Exactly like Adrian, I would like some more information on the Experimental
status. As examples:

I believe this should be common practice for experiemental RFCs.
Re-reading RFC 3933, and I don't see this.
Maybe an IESG statement ... ?
Jari Arkko Former IESG member
No Objection
No Objection (for -09)

Kathleen Moriarty Former IESG member
(was Discuss) No Objection
No Objection (2014-12-08)
Thanks for addressing the questions that came up through the SecDir review.  The new text looks good.
Brian Haberman Former IESG member
Abstain (2014-10-14 for -09)
I find it a dis-service to the community for the softwire WG to put forth multiple solutions that solve essentially the same problem (  I believe the confusion caused by a myriad of solutions in this space, regardless of whether they are Standards Track or Experimental, will adversely impact vendors, operators, and end-users.  My only hope is that this confusion will speed up the transition to IPv6-only operations within the affected networks.
Joel Jaeggli Former IESG member
Abstain (2014-10-30 for -09)
I don't see a lot of positive outcomes from advancing additional transition mechanisms I find myself altogether better off when I can avoid using any of them.
Martin Stiemerling Former IESG member
Abstain (2014-10-29 for -09)
I'm with Brian and Adrian on this draft: It is not clear to me why the softwire WG  is publishing this document. It could have been submitted via the ISE, if there is the desire to document the existence of a different approach.
Richard Barnes Former IESG member
Abstain (2014-10-30 for -09)
For the same reasons as Brian.