Skip to main content

Recommendations for Prefix Binding in the Context of Softwire Dual-Stack Lite
draft-vinapamula-softwire-dslite-prefix-binding-12

Yes

(Terry Manderson)

No Objection

(Deborah Brungard)

No Record

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
John Scudder
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Warren Kumari
Zaheduzzaman Sarker
Éric Vyncke

Summary: Needs a YES.

Deb Cooley
No Record
Erik Kline
No Record
Francesca Palombini
No Record
Gunter Van de Velde
No Record
Jim Guichard
No Record
John Scudder
No Record
Mahesh Jethanandani
No Record
Murray Kucherawy
No Record
Orie Steele
No Record
Paul Wouters
No Record
Roman Danyliw
No Record
Warren Kumari
No Record
Zaheduzzaman Sarker
No Record
Éric Vyncke
No Record
Terry Manderson Former IESG member
Yes
Yes (for -09) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (2015-08-18 for -09) Unknown
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.
Alvaro Retana Former IESG member
No Objection
No Objection (2015-08-19 for -09) Unknown
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).
Barry Leiba Former IESG member
No Objection
No Objection (2015-08-19 for -09) Unknown
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?
Ben Campbell Former IESG member
(was Discuss) No Objection
No Objection (2015-12-09) Unknown
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
Deborah Brungard Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-08-19 for -09) Unknown
I agree with the concerns that this should not be a BCP and question the process path for this draft.
Spencer Dawkins Former IESG member
No Objection
No Objection (2015-08-19 for -09) Unknown
I had the same question Alissa had, about stable addresses. Thanks for engaging with her - that conversation seems to be going the right direction.
Alia Atlas Former IESG member
(was No Objection) No Record
No Record (2015-08-19 for -09) Unknown
Agree with Alvaro and Barry on concerns.