Analysis of the 64-bit Boundary in IPv6 Addressing
RFC 7421

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

Alissa Cooper Yes

Comment (2014-10-29 for -07)
No email
send info
This is a nice document, thanks for taking the time to write it.

= Section 1 =
"The bits in the IID have no meaning and the entire identifier should
   be treated as an opaque value [RFC7136]."

I understand what this means based on RFC7136, but it seems like it would be a little more clear to re-use the language from that document directly, e.g., 

"The bits in the IID may have significance only in the process of deriving the IID and once it is derived the entire identifier should be treated as an opaque value [RFC7136]."

= Section 4.5 =
This is probably not worth mentioning in the draft, but I'll write it down since the thought occurred to me: it's conceivable to argue that there could be a privacy benefit of shortening the IID, if it became so short that a hardware address could not be embedded in it. This benefit is quite obviously outweighed by the drawbacks you already describe in this section I think, but just food for thought.

(Brian Haberman) Yes

(Ted Lemon) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Richard Barnes) No Objection

(Benoît Claise) No Objection

(Adrian Farrel) No Objection

Comment (2014-10-29 for -07)
No email
send info
Section 4.2

   o  Router implementations: Router implementors might interpret IETF
      standards such as [RFC6164] and [RFC7136] to indicate that

Maybe avoid any accidental confusion by using "specifications" rather
than "standards"

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Kathleen Moriarty) No Objection

Comment (2014-10-29 for -07)
No email
send info
The SecDir review looks good, thank you for your work on the draft.  
https://www.ietf.org/mail-archive/web/secdir/current/msg05118.html

(Martin Stiemerling) No Objection