Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt

[Dan Wing <[e-mail]>]

On Jul 9, 2013, at 8:38 AM, "DRAGE, Keith (Keith)" <[e-mail]> wrote:

> No comment on removing option a), but later in the document I did note the sentence:
> 
> "This	value MUST be at least 96 bits and MAY be up to 512 bits."
> 
> To me "MAY defines an option, and therefore this appears to be stating that the upper limit is optional, whereas I believe you are stating:
> 
> "This	value MUST be at least 96 bits and MUST be less than 512 bits."

RFC4096 ("Randomness Requirements for Security") has as its longest output 512 bits, and that document is what we cite for generating the random value.  A value longer than 512 bits is permitted, and would not cause interoperability problems; it just needs to fit into the CNAME space, which has a maximum size of 255 octets of ASCII characters.  If there is need to specify the maximum length to conform to RFC3550's CNAME length limit, that maximum would be 255 octets * 3 / 4 = 191.25 octets (the 3/4 is to for binary to BASE64 encoding, the .25 octets gets into nuance of BASE64 encoding, I don't want to worry about BASE64 encoders).  But that is a limit of CNAME encoding in RFC3550.  I propose draft-ietf-avtcore-6222bis just say "The value MUST be at least 96 bits" and not worry about the maximum -- CNAME already has a maximum due to its 255 octet length.

-d



> 
> Regards
> 
> Keith
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Magnus Westerlund
>> Sent: 09 July 2013 09:11
>> To: [e-mail]
>> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt
>> 
>> WG,
>> 
>> This document has just been in IESG review and the authors has discussed
>> with the IESG. One discuss raised was the implications of the MAC based
>> generation of short-term persistent CNAMES. The conclusion in that
>> discussion was to remove that option and rely only on random names in
>> that case.
>> 
>> I wanted to inform the WG about this significant change and give you a
>> chance to react to this change before the document is approved. You will
>> have one week to react.
>> 
>> The details can be seen in this diff:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-05
>> 
>> 
>> Cheers
>> 
>> Magnus Westerlund
>> 
>> 
>> On 2013-07-08 23:29, [e-mail] wrote:
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>> This draft is a work item of the Audio/Video Transport Core Maintenance
>> Working Group of the IETF.
>>> 
>>> 	Title           : Guidelines for Choosing RTP Control Protocol
>> (RTCP) Canonical Names (CNAMEs)
>>> 	Author(s)       : Ali Begen
>>>                          Colin Perkins
>>>                          Dan Wing
>>>                          Eric Rescorla
>>> 	Filename        : draft-ietf-avtcore-6222bis-05.txt
>>> 	Pages           : 10
>>> 	Date            : 2013-07-08
>>> 
>>> Abstract:
>>>   The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
>>>   persistent transport-level identifier for an RTP endpoint.  While the
>>>   Synchronization Source (SSRC) identifier of an RTP endpoint may
>>>   change if a collision is detected or when the RTP application is
>>>   restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
>>>   endpoints can be uniquely identified and associated with their RTP
>>>   media streams.
>>> 
>>>   For proper functionality, RTCP CNAMEs should be unique within the
>>>   participants of an RTP session.  However, the existing guidelines for
>>>   choosing the RTCP CNAME provided in the RTP standard are insufficient
>>>   to achieve this uniqueness.  RFC 6222 was published to update those
>>>   guidelines to allow endpoints to choose unique RTCP CNAMEs.
>>>   Unfortunately, later investigations showed that some parts of the new
>>>   algorithms were unnecessarily complicated and/or ineffective.  This
>>>   document addresses these concerns and replaces RFC 6222.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-05
>>> 
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-05
>>> 
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/avt
>>> 
>>> 
>> 
>> 
>> --
>> 
>> Magnus Westerlund
>> 
>> ----------------------------------------------------------------------
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> ----------------------------------------------------------------------
>> Ericsson AB                | Phone  [phone]
>> Färögatan 6                | Mobile [phone]
>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>> ----------------------------------------------------------------------
>> 
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt