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

[Flemming Andreasen <[e-mail]>]

The chairs are basically working with the ADs and IANA to make such a 
change and to register the missing nettype and addrtype from RFC 2848 
(PINT) and 3108 (ATM). My understanding is that it's not a problem to 
fix these with IANA, unless anybody in the WG has an issue with doing so 
(in which case you should let us know).

Thanks

-- Flemming


On 10/9/13 8:30 PM, Christian Groves wrote:
> 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
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>