Issues with Dual Stack IPv6 on by Default
draft-ietf-v6ops-v6onbydefault-03
Discuss
Yes
(David Kessens)
No Objection
(Alex Zinin)
(Bert Wijnen)
(Margaret Cullen)
(Scott Hollenbeck)
(Steven Bellovin)
(Ted Hardie)
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
Thomas Narten Former IESG member
Discuss
Discuss
[Treat as non-blocking comment]
(2004-05-27)
Unknown
This document really needs an "applicability" paragraph or two at the beginning saying something like: This document discusses in detail some issues related to .... The IPv6 WG has addressed these (or is addressing?) them in the following way... The suggestions in this document are just possible approaches for discussion and are not recommended solutions; see the other relevant documents for the recommended approaches." Or something like that. I don't have an issue with publishing the contents of the document essentially as is, but I think it would be good to include context about what the IETF is doing about these problems. Readers should not be misled into thinking they should implement the recommendations in the document.
David Kessens Former IESG member
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
(2004-05-27)
Unknown
Reviewed by Spencer Dawkins, Gen-ART Issues found in review: - I'm a little confused about why 2.3.1.1 talks about aborting TCP connections that are in SYN-RECEIVED state. The problem statement said "no IPv6 router" - how did the SYN get to the host in the first place? The discussion makes perfect sense to me if it's limited to SYN-SENT. - Section 2.1 talks about "rules" out of the blue, with no reference given explicitly. I THINK it's referring to the rules from Section 6 of [ADDRSEL], but that's not obvious to the semi-initiated. - No reference is given for the assertion that "Many TCP implementations behave this way" in 2.3.1.1, or for the "work in progress" described at the end of 2.3.3. So, you ask, is fixing these items enough? I sympathize with the authors, but they are being forced to handwave on firewalling and NATing because we don't have BCPs on how to firewall, and this doesn't help them to be clear or complete. That's not a problem the authors can fix in this document. But from one end of the document to the other, this problem complicates life - 3.3 talks about firewalls that don't enforce the same policy for IPv4 and IPv6, but where do we set the expectation that firewalls should, or don't have to, enforce the same policy? We do have RFC 2979, but it's Informational, does not contain the ASCII string "v6", and talks about what firewalls do, not how to operate firewalled networks. Sigh. But maybe this document will be good enough for an Informational RFC. Sigh.
Margaret Cullen Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2004-05-26)
Unknown
Delete appendix B and appendic C prior to publication as an RFC.
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Steven Bellovin Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown