Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite
RFC 7785

Summary: Has enough positions to pass.

Terry Manderson Yes

Deborah Brungard No Objection

Ben Campbell (was Discuss) No Objection

Comment (2015-12-09)
No email
send info
I'm clearing the discuss because this went to the ISE.

-- 1, 2nd to last paragraph:
I'm a little confused by the statement that the privacy-related requirements are out of scope, since there is a recently-added privacy considerations section. Is the "out of scope" assertion still accurate?  (If so, it seems a shame not to at least have some discussion about why it would be out of scope.)

Nits:

--1, first paragraph: "...derive IPv6 addresses out of that prefix."
s/out of/from
Please expand "DS-Lite" on first mention in the body (independently from the expansion in the abstract.)

-- 2, first paragraph: "...hosts serviced by a B4 element are overlapping across multiple CPEs..."
s/are overlapping/overlap

Alissa Cooper No Objection

Comment (2015-08-18 for -09)
No email
send info
How was the 56-bit default chosen?

Section 6 says "This document does not nullify the privacy effects that may motivate the use of non-stable IPv6 prefixes." It does incentivize the use of stable prefixes though, right? Perhaps the quoted words were carefully chosen to elide that, but it seems worth noting in the same paragraph somewhere. Use of RFC 7217 or RFC 4941 doesn't have the same impact if your prefix never changes.

Spencer Dawkins No Objection

Comment (2015-08-19 for -09)
No email
send info
I had the same question Alissa had, about stable addresses. Thanks for engaging with her - that conversation seems to be going the right direction.

(Barry Leiba) No Objection

Comment (2015-08-19 for -09)
No email
send info
I have no issue with this document itself, but I have a process concern that right on the edge of a DISCUSS.  It's very much related to Álvaro's comment, and it's a meta-issue for IESG discussion:

It bothers me more than a little that we're not bothering with an external (unbiased) document shepherd here.  While that is the prerogative of the responsible AD, it's disturbing because of some omissions in the shepherd writeup.  For one, the "working group summary" and "document quality" sections are meant to tell us about the discussion that went on with respect to the document (even if it wasn't in a working group), and there's nothing there.  The response to question 9 is particularly worrisome; the question asks how solid the consensus is of the interested community, and the response is simply that the question isn't applicable because there's no working group.  Yet there is still an interested community, the document is aiming at BCP, and I expect some assurance that there *is* solid consensus here.  I get nothing.

When I search the mailing list archives, I see almost no discussion of the document.  Other than from the authors, the only comments I see are from Tiru Reddy, and there's not very much there.  And then we have the Gen-ART and SecDir reviews during last call.  What leads us to believe, in good conscience, that there really is IETF consensus here?  Was there substantive review and discussion that I'm not seeing?  If so, where?

(Kathleen Moriarty) No Objection

Comment (2015-08-19 for -09)
No email
send info
I agree with the concerns that this should not be a BCP and question the process path for this draft.

Alvaro Retana No Objection

Comment (2015-08-19 for -09)
No email
send info
I am not opposed to the publication of this document.  It is well written and clear.

I do have one point that I want to discuss (lower case)..maybe mostly for my own education.

The intended status of this document is BCP.  I’m wondering, why isn’t it a WG document?  It seems to me that the softwire charter includes this content ("DS-Lite…operational specification”), but I couldn’t find anything in the archives about this decision.  In fact, I found little discussion from the WG on the document, and nothing related to adoption (but I may have missed it).

"BCPs are meant to express community consensus” [rfc2026], but there’s very little (if any) community discussion.

I don’t think there’s any reason why this document can’t be AD-sponsored, which is why this comment is not a DISCUSS.  But it just seems odd to me that we’re publishing a BCP with almost no discussion/deliberation (that I can find).

(Alia Atlas) (was No Objection) No Record

Comment (2015-08-19 for -09)
No email
send info
Agree with Alvaro and Barry on concerns.

Ignas Bagdonas No Record

Benjamin Kaduk No Record

Suresh Krishnan No Record

Warren Kumari No Record

Mirja Kühlewind No Record

Alexey Melnikov No Record

Eric Rescorla No Record

Adam Roach No Record

Martin Vigoureux No Record