Subject: Re: [MMUSIC] Protocol Action: 'Session Description Protocol (SDP) Extension For Setting Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)' to Proposed Standard (draft-ietf-mmusic-sdp-cs-21.txt)

From: Richard Barnes <[email-masked]>
Date: Fri, 4 Oct 2013 10:36:15 -0400

Is this really a conflict?  In the "c=" line, the addrtype is scoped to
either the "ATM" or "E164" nettype, so it's clear which one is meant.  I
think the only thing to do here is just have both RFC 3108 and this
document as references in the registry.

--Richard

On Thu, Sep 19, 2013 at 8:22 AM, Christian Groves <
[email-masked]> wrote:

> FYI, I was looking at the IANA registry for SDP parameters (
> http://www.iana.org/**assignments/sdp-parameters/**sdp-parameters.xhtml<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/<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
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: Christian Groves <[email-masked]>
Date: Sun, 06 Oct 2013 21:41:15 +1100

Hello Richard,

I guess you mean the "ATM" or "PSTN" nettype? If you assume "c=" line 
scopes then in theory there's not an issue. However I'm not aware of any 
other parameters/values in that registry that are duplicated. This 
essential means no other SDP parameter/value is scoped to understand the 
syntax except E164.

Regards, Christian

On 5/10/2013 12:36 AM, Richard Barnes wrote:
> Is this really a conflict?  In the "c=" line, the addrtype is scoped 
> to either the "ATM" or "E164" nettype, so it's clear which one is 
> meant.  I think the only thing to do here is just have both RFC 3108 
> and this document as references in the registry.
>
> --Richard
>
>
> On Thu, Sep 19, 2013 at 8:22 AM, Christian Groves 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     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.
>
>            (draft-ietf-mmusic-sdp-cs-21.txt) as Proposed Standard
>
>         http://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-cs/
>
>
>
>
>         *Technical Summary
>         *
>
>         _______________________________________________
>         mmusic mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/mmusic
>
>
>     _______________________________________________
>     mmusic mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 06 Oct 2013 21:38:36 -0400

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:
> 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.
>
> .

---

From: Christian Groves <[email-masked]>
Date: Mon, 07 Oct 2013 14:28:41 +1100

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.

Regards, Christian

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 07 Oct 2013 10:34:20 -0400

On 10/6/13 11:28 PM, Christian Groves wrote:
> I think though that the addresstype and nettype from RFC3108 still 
> needs to be picked up by the IANA registry.
>
Agreed.

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Oct 2013 13:44:47 -0400

> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Oct 2013 13:51:51 -0400

Changing the topic because I'm hijacking the thread.

> 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?

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 08 Oct 2013 09:46:13 +1100

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.

Regards, Christian

On 8/10/2013 4:44 AM, Paul Kyzivat wrote:
> new nettype and addrtypes with IANA would start the process. Or is 
> there a better way?
>
>     Thanks,
>     Paul
>
>> Regards, Christian
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Oct 2013 12:19:51 -0400

> 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.

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 09 Oct 2013 16:59:19 -0400

On 10/9/13 12:19 PM, Paul Kyzivat wrote:
> 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.)
>
> considerations section at all. It certainly doesn't give the info 
> needed for an addition to that registry.
>
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

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 09 Oct 2013 17:00:46 -0400

On 10/7/13 1:51 PM, Paul Kyzivat wrote:
> 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 

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.

Thanks

-- Flemming

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 9 Oct 2013 21:04:20 +0000

On Oct 9, 2013, at 2:00 PM, Flemming Andreasen <[email-masked]> wrote:

>> 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.)
>> 
> 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...

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Oct 2013 18:28:30 -0400

> the missing registrations.

I wasn't trying to be pejorative - just commenting on what seems 
required to fix it.

We just need *some* RFC to do it. It could be 4566bis. But if it isn't 
one that explicitly updates 3108, then we should take care to instruct 
IANA to make the registry point to 3108.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 9 Oct 2013 22:46:11 +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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ali C. Begen (abegen)
> Sent: 09 October 2013 22:04
> To: Flemming Andreasen (fandreas)
> Cc: <[email-masked]>; Paul Kyzivat
> Subject: Re: [MMUSIC] Updating iana SDP parameter registries in 4566bis
> 
> 
> the IANA registries to reflect the dependency between addrtype and nettype.
> >>
> 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
> >>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 9 Oct 2013 22:47:38 +0000

We don't need an RFC to do it. We existed for years without an IANA registration section but still had IANA registrations.

My understanding of the current rule is that they need to exist, and give instructions on how to write them. This is to make their job easier and their output more efficient. There is nothing that says that IANA cannot address issues regarding missing material from reading the rest of the RFC. After all, the entire RFC has IETF consensus.

Keith

> Of Paul Kyzivat
> Sent: 09 October 2013 23:29
> To: Flemming Andreasen
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Updating SDP parameter registry with RFC3108 values
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 10 Oct 2013 10:36:51 +1100

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:
>> 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.)
>>
> 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
>>>

---

From: Christian Groves <[email-masked]>
Date: Thu, 10 Oct 2013 11:30:47 +1100

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Oct 2013 18:06:11 -0400

Christian,

In some sense this is not a problem. The constraints apply even though 
the iana registry doesn't show them. They can be discovered by following 
the references. But it is annoying and confusing.

We have a similar, but worse, problem with the registries for SDP 
attributes. They come in different types (session, media, and source), 
and the same attribute can support multiple types. But the registries 
treat them separately. And the templates used to register them aren't 
consistent with the registry formats. So I suggested that 4566bis take 
on updating these IANA registries.

In general, all the registries for SDP stuff probably need a good scrubbing.

	Thanks,
	Paul

On 10/9/13 8:30 PM, Christian Groves wrote:
>> 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
>>
>>>>>>>> better to align with relevant parts of the tel URI format
>>>>>>>> defined in
>>> RFC

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Oct 2013 18:12:06 -0400

> 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…

Certainly it is not the primary purpose of 4566bis.
But if it isn't done there, then we will need yet another RFC to do it.
4566bis seems like a good place to do it.

> 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.

Just request it *how*?
If IANA receives an email asking them to make a change, they won't be 
doing their job unless they consult the existing registry and check the 
rules for changes/additions. If the rules call for an rfc and a specific 
template, then they need an rfc with that template filled out.

Note that these templates often carry information that isn't captured in 
the registry itself - depending on the registry reference to the document.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Oct 2013 18:13:49 -0400

> My understanding of the current rule is that they need to exist, and give instructions on how to write them. This is to make their job easier and their output more efficient. There is nothing that…

Repeating what I just posted in another thread:

Just request it *how*?

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 11 Oct 2013 11:17:23 +1100

Hello Paul,

On 11/10/2013 9:13 AM, Paul Kyzivat wrote:
>> We don't need an RFC to do it. We existed for years without an IANA 
>> registration section but still had IANA registrations.
>>
>> My understanding of the current rule is that they need to exist, and 
>> give instructions on how to write them. This is to make their job 
>> easier and their output more efficient. There is nothing that says 
>> that IANA cannot address issues regarding missing material from 
>> reading the rest of the RFC. After all, the entire RFC has IETF 
>> consensus.
>
[CNG] Email? Surely if one of the MMUSIC chairs sends an email 
highlighting the situation that the original registrations were missed 
and point to the agreed standards tracks RFCs this can be considered. 
IANA works with experts all the time to manage these pages. If I find an 
error in the registry I'm responsible for its just a matter of sending 
an email indicating what the issue is.

> doing their job unless they consult the existing registry and check 
> the rules for changes/additions. If the rules call for an rfc and a 
> specific template, then they need an rfc with that template filled out.
[CNG] I think we need to recognise that what we are trying to do is fix 
an error not do a brand new registration.

> Note that these templates often carry information that isn't captured 
> in the registry itself - depending on the registry reference to the 
> document.
>
>     Thanks,
>     Paul
>
>> Keith
>>
>>>>> the
>>>> this,

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 11 Oct 2013 06:35:45 +0000

In regard to "how" just write an email or fill out the form on the IANA main page.

And it works in exactly the same way as when the material exists in the IANA considerations section but has not been correctly implemented by IANA. We don't have to go and write a new RFC in that case.

The IANA sections of RFCs are there to provide a convenient means for IANA to find the information they need, not the arbiter of whether the information can be included in a registry or not.

The arbiter of whether the information can be included in the registry or not is the registration policy of that registry. Even if the registration policy is RFC required, if it is somewhere else in the RFC, then IANA can still use that information. Regardless, all of this will take place in conjunction with the appropriate experts to ensure that a mistake does not occur. IANA consult on anything they are not sure of.

As for formatting of the information - we help them as much as possible with the IANA considerations section, but that is all it is "considerations". IANA have total flexibility in this area.

Keith

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 10 October 2013 23:14
> To: DRAGE, Keith (Keith)
> Cc: Flemming Andreasen; [email-masked]
> > We don't need an RFC to do it. We existed for years without 
> an IANA registration section but still had IANA registrations.
> >
> > My understanding of the current rule is that they need to 
> exist, and give instructions on how to write them. This is to 
> make their job easier and their output more efficient. There 
> is nothing that says that IANA cannot address issues 
> regarding missing material from reading the rest of the RFC. 
> After all, the entire RFC has IETF consensus.
> 
> If IANA receives an email asking them to make a change, they 
> won't be doing their job unless they consult the existing 
> registry and check the rules for changes/additions. If the 
> rules call for an rfc and a specific template, then they need 
> an rfc with that template filled out.
> 
> Note that these templates often carry information that isn't 
> captured in the registry itself - depending on the registry 
> reference to the document.
> 
> 	Thanks,
> 	Paul
> 
> > Keith
> >
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of Paul Kyzivat
> >>>>> 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.
> >>>>
> >>>> that additions to this registry must follow the 
> "Specification Required"
> >>>> 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.
> >>>>
> >> We just need *some* RFC to do it. It could be 4566bis. But if it 
> >> isn't one that explicitly updates 3108, then we should 
> take care to 
> >> instruct IANA to make the registry point to 3108.
> >>
> >> 	Thanks,
> >> 	Paul
> >>

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 11 Oct 2013 10:47:43 -0400

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:
> registration of an address type MUST specify a registered network 
> type, or be submitted along with a network type registration."
>
> information in another column "Registered network type" in the 
> addrtype table at SDP parameter registry.
>
>> 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
>>
>>> Behalf
>>>>>>>> for using the Session Description Protocol (SDP) Offer/Answer 
>>>>>>>> model
>>> for
>>>>>>>> and whether to align this with the existing definition in RFC 
>>>>>>>> 3108.
>>> The
>>>>>>>> resulted in changes to the detailed specification. The document 
>>>>>>>> has
>>> been

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Oct 2013 12:49:23 -0400

> The arbiter of whether the information can be included in the registry or not is the registration policy of that registry. Even if the registration policy is RFC required, if it is somewhere else i…

Note that 4566 says that registrations nettype, addrtype, ... contain:

    o  contact name, email address, and telephone number

    o  name being registered (as it will appear in SDP)

    o  long-form name in English

    o  type of name ("media", "proto", "fmt", "bwtype", "nettype", or
       "addrtype")

    o  a one-paragraph explanation of the purpose of the registered name

    o  a reference to the specification for the registered name (this
       will typically be an RFC number)

But the actual registries don't contain all this information. They 
depend upon the referenced RFC to contain it. If the RFC doesn't contain 
all this information, then an after the fact registration is incomplete.

In this case, the only questionable piece is the contact. Perhaps it is 
sufficient to consider the author info in the RFC to substitute for 
this. (This contact info is at best dubious. It tends to get stale 
before anybody needs it.)

> As for formatting of the information - we help them as much as possible with the IANA considerations section, but that is all it is "considerations". IANA have total flexibility in this area.

Do they? If IANA considerations request creation of two registries named 
X & Y, and lists the fields to be included in each, is IANA free to 
create one combined registry named XY? I really don't know.

I understand that the IANA registries started out as very informal 
things. As we get more of them, and depend upon them more, it becomes 
important to get more formal about the way they are handled. That has 
happened, to an extent. But not uniformly. It is good if we can clean 
things up as we discover past informality or evolution has made things 
troublesome.

I must say that I am troubled that 4566 does not make the registration 
of new network or address types mandatory. ("New network(address) types 
... *may* be registered with IANA") The current situation almost tripped 
over this. If new ones aren't registered, then how is someone who wants 
to define a new one to know if the chosen name is already taken.

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 11 Oct 2013 16:56:34 -0400

On 10/11/13 12:49 PM, Paul Kyzivat wrote:
> of new network or address types mandatory. ("New network(address) 
> types ... *may* be registered with IANA") The current situation almost 
> tripped over this. If new ones aren't registered, then how is someone 
> who wants to define a new one to know if the chosen name is already 
> taken.
>
Fair point; want to start a new thread on this ?

-- Flemming

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Oct 2013 20:03:21 -0400

> Fair point; want to start a new thread on this ?

Does this require a thread of its own?
I'm thinking this is just part of a more general task to clean up the 
IANA registries for SDP. (Probably as part of 4566bis.)

But I hesitate to kick of a discussion now that might be active.
I am swamped in another context right now.

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 13 Oct 2013 19:56:21 -0400

> Does this require a thread of its own?
It's buried so deep in this thread that I thought it would be a good 
idea, however I have asked Ali to make sure he tracks it as part of the 
4566bis update.

Thanks

-- Flemming