Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values

[Christian Groves <[e-mail]>]

I would agree with Flemming here. I think leniency is required as it 
does predate RFC4566. The parameters are in an RFC and it was a product 
of the MMUSIC WG so I would argue the "specification required" aspect is 
met. What information is 'missing'? I think its more of a case that the 
information is there but just not in a 'nice' format.

Strictly speaking even "draft-ietf-mmusic-sdp-cs" doesn't meet the 
requirements of RFC4566 section 8.2.8 because it doesn't provide the 
"long-form-name", "contact information" and a one paragraph purpose of 
the name in the RFC as required. Yet there's a registration for this??

So if we hold RFC3108 to the same standard then all the information we 
need is:

RFC3108
--------
1.  Registration of a new "nettype" value

    Type            SDP Name                     Reference
    ----            ------------------           ---------
    nettype         ATM                          [RFC3108]

2. Registration of new "addrtype" value

    Type            SDP Name                     Reference
    ----            ------------------           ---------
    addrtype        E164                         [RFC3108]

    Note: RFC 3108 defines the "E164" addrtype in the context of the
    "ATM" nettype only.

3. Registration of new "addrtype" value

    Type            SDP Name                     Reference
    ----            ------------------           ---------
    addrtype        NSAP                         [RFC3108]

    Note: RFC 3108 defines the "NSAP" addrtype in the context of the
    "ATM" nettype only.

4. Registration of new "addrtype" value

    Type            SDP Name                     Reference
    ----            ------------------           ---------
    addrtype        GWID                         [RFC3108]

    Note: RFC 3108 defines the "GWID" addrtype in the context of the
    "ATM" nettype only.


There's also another RFC that I'm aware of that defines a nettype and 
addrtype that would need to be registered also. RFC2848 was a product of 
the PINT WG. The relevant registrations are below:

RFC2848
-------
1.  Registration of a new "nettype" value

    Type            SDP Name                     Reference
    ----            ------------------           ---------
    nettype         TN                           [RFC2848]

2. Registration of new "addrtype" value

    Type            SDP Name                     Reference
    ----            ------------------           ---------
    addrtype        RFC2543                      [RFC2848]

    Note: RFC 2848 defines the "RFC2543" addrtype in the context of the
    "TN" nettype only.


Regards, Christian

On 10/10/2013 7:59 AM, Flemming Andreasen wrote:
>
> On 10/9/13 12:19 PM, Paul Kyzivat wrote:
>> On 10/7/13 6:46 PM, Christian Groves wrote:
>>> Hello Paul,
>>>
>>> Is a process needed to create an errata? Wouldn't the fact that they
>>> appear in standards track RFCs be enough to include them in the SDP
>>> registry based on the SDP directorates (i.e. expert review)
>>> recommendation? I agree its not ideal that these older RFCs didn't
>>> include an IANA considerations section but I think that rather than
>>> spending lots of cycles on this that the SDP directorate could just
>>> request IANA to register them to avoid any future overlap issues.
>>
>> Unfortunately there are rules. The rules for a particular IANA 
>> registry are defined when the registry is created. If you check in 
>> the registry, it points to RFC4566. Section 8.2.4 of RFC4566 says 
>> that additions to this registry must follow the "Specification 
>> Required" policy defined in RFC2434. And the specification must 
>> include a particular set of information. (That would typically be in 
>> an IANA considerations section.)
>>
>> At the moment all we have is RFC3108, and it doesn't have an IANA 
>> considerations section at all. It certainly doesn't give the info 
>> needed for an addition to that registry.
>>
>> IIUC, an errata to 3108 wouldn't, on its own, be sufficient either. I 
>> think we will need a new RFC that does it. This should probably be an 
>> update to 3108. An errata is perhaps a formal way to trigger that.
>>
> Having previously communicated with one of the RFC 3108 authors on 
> this, I would ask for leniency here, not least considering that RFC 
> 3108 predates RFC 4566. In other words, I'd argue that we should 
> simply add the missing registrations.
>
> Thanks
>
> -- Flemming
>
>
>
>>     Thanks,
>>     Paul
>>
>>> Regards, Christian
>>>
>>> On 8/10/2013 4:44 AM, Paul Kyzivat wrote:
>>>> On 10/6/13 11:28 PM, Christian Groves wrote:
>>>>> Hello Flemming,
>>>>>
>>>>> Thanks for pointing out that thread. If Paul as one of the SDP
>>>>> directorate is OK with it then I don't have any issue with the -cs
>>>>> draft.
>>>>>
>>>>> I think though that the addresstype and nettype from RFC3108 still 
>>>>> needs
>>>>> to be picked up by the IANA registry.
>>>>
>>>> I agree. I'm not sure what the best way to accomplish that is.
>>>> Perhaps an errata to 3108, pointing out that it fails to register its
>>>> new nettype and addrtypes with IANA would start the process. Or is
>>>> there a better way?
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>>> Regards, Christian
>>>>>
>>>>> On 7/10/2013 12: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
>>>>>>
>>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> 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
>