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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 10 July 2013 14:11 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DEA21F9F13 for <avt@ietfa.amsl.com>; Wed, 10 Jul 2013 07:11:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilHJboqOlvor for <avt@ietfa.amsl.com>; Wed, 10 Jul 2013 07:11:50 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7537D21F9AEE for <avt@ietf.org>; Wed, 10 Jul 2013 07:11:50 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r6AEBhqM010882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Jul 2013 09:11:45 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id r6AEBhJ5018151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jul 2013 16:11:43 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.194]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 10 Jul 2013 16:11:43 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Dan Wing <dwing@cisco.com>
Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt
Thread-Index: AQHOfRNJWkFGIrKCkEarOElRktFoVpld9FNQ
Date: Wed, 10 Jul 2013 14:11:42 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B067E6C@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <20130708212917.31411.52919.idtracker@ietfa.amsl.com> <51DBC578.9000306@ericsson.com> <949EF20990823C4C85C18D59AA11AD8B0675B2@FR712WXCHMBA11.zeu.alcatel-lucent.com> <24BEECDC-9FE6-4FBE-85F9-2ACBF9887591@cisco.com>
In-Reply-To: <24BEECDC-9FE6-4FBE-85F9-2ACBF9887591@cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2013 14:11:55 -0000

If that applies then I agree.

I might suggest an informative statement indicating that the maximum length is fixed by RFC 3550.

Keith

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> Sent: 10 July 2013 03:15
> To: DRAGE, Keith (Keith)
> Cc: Magnus Westerlund; avt@ietf.org
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-05.txt
> 
> 
> On Jul 9, 2013, at 8:38 AM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-
> lucent.com> 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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of
> >> Magnus Westerlund
> >> Sent: 09 July 2013 09:11
> >> To: avt@ietf.org
> >> 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, internet-drafts@ietf.org 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
> >>> avt@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/avt
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Magnus Westerlund
> >>
> >> ----------------------------------------------------------------------
> >> Multimedia Technologies, Ericsson Research EAB/TVM
> >> ----------------------------------------------------------------------
> >> Ericsson AB                | Phone  +46 10 7148287
> >> Färögatan 6                | Mobile +46 73 0949079
> >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> >> ----------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Audio/Video Transport Core Maintenance
> >> avt@ietf.org
> >> https://www.ietf.org/mailman/listinfo/avt
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt