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

[Christian Groves <[e-mail]>]

Isn't this just the manner in which IANA formats their registry? Both 
RFC2327 and RFC4566 both have text along the lines of "An address type 
is only meaningful in the context of a network type, and any 
registration of an address type MUST specify a registered network type, 
or be submitted along with a network type registration."

Given that as part of the registration the applicable nettype must 
already have been given. Isn't all we need is for IANA to reflect this 
information in another column "Registered network type" in the addrtype 
table at SDP parameter registry.

Type       SDP Name     Registered Nettype   Reference
addrtype     IP4              IN             [RFC4566]
addrtype     IP6              IN             [RFC4566]
addrtype     E164             PSTN [RFC-ietf-mmusic-sdp-cs-21]
etc.


Regards, Christian

On 10/10/2013 9:46 AM, DRAGE, Keith (Keith) wrote:
> 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: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Ali C. Begen (abegen)
>> Sent: 09 October 2013 22:04
>> To: Flemming Andreasen (fandreas)
>> Cc: <[e-mail]>; Paul Kyzivat
>> Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis
>>
>>
>> On Oct 9, 2013, at 2:00 PM, Flemming Andreasen <[e-mail]> 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
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>
>>>>>> _______________________________________________
>>>>>> mmusic mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>> .
>>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>> .
>>>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>