Summary: Needs a YES.
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
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.
I had the same question Alissa had, about stable addresses. Thanks for engaging with her - that conversation seems to be going the right direction.
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?
I agree with the concerns that this should not be a BCP and question the process path for this draft.
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).
Agree with Alvaro and Barry on concerns.