Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
RFC 6222

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

(Robert Sparks) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Adrian Farrel) No Objection

Comment (2011-01-05 for -)
No email
send info
Support Stewart's Discuss since we have observed "clone" equipment with identical MAC addresses in the past. Also, I believe that some h/w exists with configurable MAC addresses.

---

Abstract
s/these/those/

(David Harrington) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

(Alexey Melnikov) No Objection

Comment (2010-12-25 for -)
No email
send info
5.  Procedure to Generate a Unique Identifier

   2.  Obtain an EUI-64 identifier from the system running this

I think this needs an Informative reference to a document which explains what is EUI-64.

       algorithm.  If an EUI-64 does not exist, one can be created from
       a 48-bit MAC address as specified in [RFC4291].  If an EUI-64
       cannot be obtained or created, a suitably unique identifier,
       local to the node, should be used (e.g., system serial number).

(Tim Polk) No Objection

Comment (2011-01-06 for -)
No email
send info
I support Sean's discuss: hard-coding SHA-1 is unnecessary and counterproductive.  There is no reason that all 
clients need to use the same secure hash algorithm, IMHO.  (For example, two clients using SHA-256 and SHA-512
are no more likely to generate a collision than two clients using SHA-256.)  I suggest "compute a message digest
using a secure hash function (e.g., SHA-256)" would provide the right level of detail for section 5.

A short paragraph should also be added to the security considerations section with appropriate references.  (I think
Sean's discuss has the right list.)

I would also note that the algorithm in section 5 does not *guarantee* uniqueness.  I think your odds of a collision
are one in 2**48 (but check with a real mathematician!).  I note this since the Requirements section states "It is
believed that obtaining uniqueness is an important property ..."

Section 4.2, third bullet:

"After performing the procedure, the significant 96 bits are used ..."

Please specify "most significant" or "least significant"; the latter would be consistent with the preceding bullet.

(Dan Romascanu) No Objection

Comment (2011-01-04 for -)
No email
send info
1. 
>    After obtaining a identifier by doing (a) or (b),
      the least significant 48 bits are converted to the standard colon-
      separated hexadecimal format, e.g., "00:23:32:af:9b:aa", resulting
      in a 17-octet printable string representation.

It would be good to provide a reference for this 'standard ... format'. RFC 5342 uses a different notation, so arguably there is more than one format used in RFCs. 

2. Also from 5342 - here is a reference for EUI-64 which could be added (also answers the COMMENT from Alexey)

[EUI-64]  IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
             Registration Authority", <http://standards.ieee.org/
             regauth/oui/tutorials/EUI64.html>, March 1997.

(Peter Saint-Andre) (was Discuss) No Objection

(Sean Turner) (was Discuss) No Objection