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
- [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-… internet-drafts
- Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222… Magnus Westerlund
- Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222… DRAGE, Keith (Keith)
- Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222… Dan Wing
- Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222… DRAGE, Keith (Keith)
- Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222… Timothy B. Terriberry
- Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222… Kevin Gross
- Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222… Ali C. Begen (abegen)
- Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222… Kevin Gross