IPv4 Service Continuity Prefix
draft-ietf-v6ops-clatip-04
Yes
(Joel Jaeggli)
No Objection
(Alia Atlas)
(Brian Haberman)
(Jari Arkko)
(Martin Stiemerling)
(Pete Resnick)
(Spencer Dawkins)
(Stephen Farrell)
(Ted Lemon)
Note: This ballot was opened for revision 03 and is now closed.
Joel Jaeggli Former IESG member
Yes
Yes
(for -03)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-06-21 for -03)
Unknown
I have no objection to the publication of this document. Thanks to the shepherd for noting that softwire had seen the I-D. It would have been good to say why that WG decided not to take this on.
Alia Atlas Former IESG member
No Objection
No Objection
(for -03)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2014-06-19 for -03)
Unknown
I was wondering the same thing as Barry about the caution against overlapping addresses, although I thought for awhile and failed to come up with a scenario in which having multiple solutions configured on the same address would actually create a vulnerability as opposed to just being broken.
Barry Leiba Former IESG member
No Objection
No Objection
(2014-06-16 for -03)
Unknown
Some non-blocking comments: To the document shepherd: Thanks, Fred, for being clear about the uncertainty of the correct document status for this. This AD, at least, sees no issue with an Informational RFC "updating" a Standards Track one, and thinks this would be fine as Informational. That said, I don't object to Standards Track, and one can certainly say that it's specifying the standard for use of 192.0.0.0/29. So I'll let other ADs argue about this if they want: the status is currently Standards Track, and that's fine with me. I'll note that the "updates" tag at the top is done wrong (it should be "Updates: 6333 (if approved)", with no brackets and no "RFC"). The RFC Editor will handle that, but if the authors happen to put out a revised I-D for other reasons, they might fix that while they're at it. I wonder why it's felt that this updates 6333, and that it doesn't update 6877. It seems to me that the same argument applies to both: you want people implementing either one to be aware that the other might use the same address block, so you want readers of both RFCs to be aware of this change. This is specifying an address range that 6877 is expected to use. The Security Considerations say there's nothing to say, but the paragraph right before that says, "It is important that a host never enable 2 active IPv4 continuity solutions simultaneously in a way that would cause a node to have overlapping address from 192.0.0.0/29." Isn't that a security consideration?
Benoît Claise Former IESG member
No Objection
No Objection
(2014-06-23 for -03)
Unknown
To avoid conflicts with any other network that may communicate with the CLAT or other IPv6 transition solution, a locally unique IPv4 address must be assigned. Maybe I'm wrong, but the sentence above seems to contradict the one below. It is important that a host never enable 2 active IPv4 continuity solutions simultaneously in a way that would cause a node to have overlapping address from 192.0.0.0/29. Also, don't you need a MUST and MUST NOT, respectively, in the two paragraphs?
Brian Haberman Former IESG member
No Objection
No Objection
(for -03)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -03)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-06-24 for -03)
Unknown
Thanks for addressing Barry's comment on the Security Considerations question. I'm fine with that just being an operational consideration and that it won't work.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -03)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -03)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -03)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(for -03)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(for -03)
Unknown