IPv4 Service Continuity Prefix
RFC 7335

Note: This ballot was opened for revision 03 and is now closed.

(Joel Jaeggli) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Benoît Claise) No Objection

Comment (2014-06-23 for -03)
No email
send info
   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?

Alissa Cooper No Objection

Comment (2014-06-19 for -03)
No email
send info
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.

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2014-06-21 for -03)
No email
send info
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.

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

Barry Leiba No Objection

Comment (2014-06-16 for -03)
No email
send info
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?

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2014-06-24 for -03)
No email
send info
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.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection