Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 09 October 2013 22:46 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9500521E81E5 for <mmusic@ietfa.amsl.com>; Wed, 9 Oct 2013 15:46:21 -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=[AWL=0.000, 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 Wwfv5qXYkSvi for <mmusic@ietfa.amsl.com>; Wed, 9 Oct 2013 15:46:16 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8691621E81C2 for <mmusic@ietf.org>; Wed, 9 Oct 2013 15:46:16 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r99MkCFC023142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Oct 2013 17:46:13 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r99MkBIg004921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 Oct 2013 00:46:11 +0200
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.239]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 10 Oct 2013 00:46:11 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "Flemming Andreasen (fandreas)" <fandreas@cisco.com>
Thread-Topic: [MMUSIC] Updating iana SDP parameter registries in 4566bis
Thread-Index: AQHOxTKpzKqfPZ+ZVkCM/v/rnUVHr5nsulIAgAA7+6A=
Date: Wed, 09 Oct 2013 22:46:11 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B0B40BA@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <20130701185623.25213.31890.idtracker@ietfa.amsl.com> <523AEC68.5050005@nteczone.com> <5252109C.7020609@cisco.com> <5252F4B7.4070303@alum.mit.edu> <5255C3FE.7010602@cisco.com> <C15918F2FCDA0243A7C919DA7C4BE9940E6FDE58@xmb-aln-x01.cisco.com>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE9940E6FDE58@xmb-aln-x01.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.41]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "<mmusic@ietf.org>" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Oct 2013 22:46:21 -0000

IANA registrations are a set of change requests to IANA to change things.

If the change has already been done, there is probably no absolute necessity to repeat them.

As an example, if RFCxxxxbis replaced RFCxxxx and made no new IANA registrations issues, it would be perfectly appropriate to refer to RFC xxxx has having performed the IANA actions.

Obviously at some point it may be appropriate to document a cumulative history, particularly where the IANA instructions are unclear at some point. However I would not regard it as the prime focus of RFC 4566bis to update the IANA registrations in this regard.

If the need for an IANA registration is clear despite the absence of a specific IANA registration section, just request it. Otherwise more action is required.

Keith

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Ali C. Begen (abegen)
> Sent: 09 October 2013 22:04
> To: Flemming Andreasen (fandreas)
> Cc: <mmusic@ietf.org>; Paul Kyzivat
> Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis
> 
> 
> On Oct 9, 2013, at 2:00 PM, Flemming Andreasen <fandreas@cisco.com> wrote:
> 
> >
> > On 10/7/13 1:51 PM, Paul Kyzivat wrote:
> >> Changing the topic because I'm hijacking the thread.
> >>
> >> On 10/6/13 9:38 PM, Flemming Andreasen wrote:
> >>> Hi Christian
> >>>
> >>> We had a thread on this particular issue about a year ago. See
> >>>
> >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09599.html
> >>>
> >>> and the conclusion in
> >>>
> >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg09621.html
> >>
> >> Thanks for remembering!
> >>
> >> In that mail I suggested that 4566bis take on updating the format of
> the IANA registries to reflect the dependency between addrtype and nettype.
> >>
> >> There are also other ways that the iana registries of SDP parameters
> are deficient. (Notably the registration of att-field names at
> session/media/source level.)
> >>
> >> How do we go about updating 4566bis to improve the iana registries?
> >
> > I think we ask Ali to make sure it is covered as part of 4566bis
> (possibly with some mailing list discussion first if you believe that is
> needed). If there are specific text suggestions, then all the better.
> 
> So, in the bis document, we can try to make it clearer but are we supposed
> to do a whole registry update as well? And certainly, the discussion will
> be a lot easier with some text proposals...
> 
> 
> >
> > Thanks
> >
> > -- Flemming
> >
> >>
> >>    Thanks,
> >>    Paul
> >>
> >>> I hope this addresses your concern as it relates to -cs draft.
> >>>
> >>> Thanks
> >>>
> >>> -- Flemming
> >>>
> >>>
> >>> On 9/19/13 8:22 AM, Christian Groves wrote:
> >>>> FYI, I was looking at the IANA registry for SDP parameters (
> >>>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml)
> >>>> and noticed that there was a registration for addrtype E164 linked to
> >>>> this CS draft.
> >>>>
> >>>> There's a problem that there's already an addrtype E164 in RFC3108.
> >>>> This earlier usage of E164 should have been registered with IANA but
> >>>> seems to have been missed. To complicate things the format of the
> >>>> RFC3108 E164 addrtype is different to the one in the CS draft.
> >>>>
> >>>> I've already raised this with IANA but I thought it would be worth
> >>>> mentioning in MMUSIC.
> >>>>
> >>>> Christian
> >>>>
> >>>>
> >>>> On 2/07/2013 4:56 AM, The IESG wrote:
> >>>>> The IESG has approved the following document:
> >>>>> - 'Session Description Protocol (SDP) Extension For Setting Audio
> and
> >>>>>    Video Media Streams Over Circuit-Switched Bearers In The Public
> >>>>>    Switched Telephone Network (PSTN)'
> >>>>>   (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard
> >>>>>
> >>>>> This document is the product of the Multiparty Multimedia Session
> >>>>> Control
> >>>>> Working Group.
> >>>>>
> >>>>> The IESG contact persons are Gonzalo Camarillo and Richard Barnes.
> >>>>>
> >>>>> A URL of this Internet Draft is:
> >>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> *Technical Summary
> >>>>> *
> >>>>>
> >>>>> The document describes use cases, requirements, and protocol
> extensions
> >>>>> for using the Session Description Protocol (SDP) Offer/Answer model
> for
> >>>>> establishing audio and video media streams over circuit-switched
> bearers
> >>>>> in the Publich Switched Telephone Network (PSTN)
> >>>>>
> >>>>> *Working Group Summary
> >>>>> *
> >>>>>
> >>>>> The WG had some discussion around the format to use for E.164
> numbers
> >>>>> and whether to align this with the existing definition in RFC 3108.
> The
> >>>>> RFC 3108 definition was seen as deficient and the WG agreed it was
> >>>>> better to align with relevant parts of the tel URI format defined in
> RFC
> >>>>> 3966, not least since SDP address types are defined in the context
> of a
> >>>>> particular network type, and hence RFC 3108 compatibility is not a
> >>>>> concern (the implication is that the "E164" address type may differ
> >>>>> between network types in SDP).
> >>>>>
> >>>>> *Document Quality
> >>>>> *
> >>>>>
> >>>>> There are currently no known implementations of the draft, however
> the
> >>>>> draft is a dependency for 3GPP, so future implementations are
> expected.
> >>>>>
> >>>>> The document has received good overall review in the WG, some of
> which
> >>>>> resulted in changes to the detailed specification. The document has
> been
> >>>>> reviewed in detail several times, including of the last few versions.
> >>>>> The major contributors to these as well as earlier discussions are
> >>>>> listed in the Acknowledgements section of the document.
> >>>>>
> >>>>>
> >>>>> *Personnel
> >>>>> *
> >>>>>
> >>>>> Document Shepherd: Flemming Andreasen
> >>>>> Responsible AD: Gonzalo Camarillo
> >>>>> _______________________________________________
> >>>>> mmusic mailing list
> >>>>> mmusic@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/mmusic
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> mmusic mailing list
> >>>> mmusic@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/mmusic
> >>>> .
> >>>>
> >>>
> >>> _______________________________________________
> >>> mmusic mailing list
> >>> mmusic@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/mmusic
> >>>
> >>
> >> _______________________________________________
> >> mmusic mailing list
> >> mmusic@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >> .
> >>
> >
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic