Subject: [MMUSIC] Alexey Melnikov's Discuss on draft-ietf-mmusic-ice-sip-sdp-38: (with DISCUSS)

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Fri, 09 Aug 2019 07:41:02 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-mmusic-ice-sip-sdp-38: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-ice-sip-sdp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a fine document and I only found a few minor things that should be easy
to fix.

Thank you for addressing my comments. Unfortunately it doesn't look like my
DISCUSS point was addressed yet. Also, your IANA change introduced another
issue.

1) In 5.1:

   The candidate attribute can itself be extended.  The grammar allows
   for new name/value pairs to be added at the end of the attribute.

   Such extensions MUST be made through IETF Review or IESG Approval
   [RFC8126] and the assignments MUST contain the specific extension and
   a reference to the document defining the usage of the extension.

This is effectively creating a new registry, but this information is not
present in the IANA Considerations section. So you need to do one of the
following:

a) Remove the last sentence
b) Reword it to only talk about IETF stream documents for defining extensions
(IESG can't really do what you ask, unless you have an IANA registry
established for these.) c) Move this text to the IANA considerations and update
it to properly define a new IANA registry.

2) In 10.2:

You removed the following text:

   o  Name, Email, and Address of a contact person for the registration

   o  Organization or individuals having the change control

I think removing (postal) Address is a good thing. However the rest of this is
still needed, as IANA uses this information to decide whether a
person/organization is allowed to update an existing registry entry. So please
consider adding it back or explain why this information is not needed for a
registry where external organizations can add value (without publishing an RFC).

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2019 15:22:28 +0000

Hi Alexey,

>This is a fine document and I only found a few minor things that should be easy to fix.
>
>Thank you for addressing my comments. Unfortunately it doesn't look like my DISCUSS point was addressed yet. 

Correct. There was a slight misunderstanding between the authors. It seems like Suhas thought all issues had been addressed in my pull requests, which was not the case. Sorry for the confusion.

>Also, your IANA change introduced another issue.
>
>1) In 5.1:
>
> This is effectively creating a new registry, but this information is not present in the IANA Considerations section. 
> So you need to do one of the
> following:
>
> b) Reword it to only talk about IETF stream documents for defining extensions (IESG can't really do what you ask, 
> unless you have an IANA registry established for these.) 
> c) Move this text to the IANA considerations and update it to properly define a new IANA registry.

Our plan is to go for option c), and create a new IANA registry. We will create a pull request, and verify that the WG is ok with it.

---

> I think removing (postal) Address is a good thing. However the rest of this is still needed, as IANA uses 
> this information to decide whether a person/organization is allowed to update an existing registry entry. 
> may be closed down. The authors of the RFC may have moved on. etc
>
> So please consider adding it back or explain why this information is not needed for a registry where external 
> organizations can add value (without publishing an RFC).

The text already says that "Specification Required" applies to new entries.

I am not aware of another registry where we would define entry-specific rules. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 11 Aug 2019 09:34:21 +0000

Hi Alexey,

    > Our plan is to go for option c), and create a new IANA registry. We will create a pull request, and verify that the WG is ok with it.
    
The following pull requests creates a new IANA registry:

https://github.com/suhasHere/ice-sip-sdp/pull/19

    ---
    
    > I am not aware of another registry where we would define entry-specific rules. 
    
    Let me know if you still have issues with this. Maybe I misunderstood your issue :)

    Regards,
    
    Christer

---

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 12 Aug 2019 14:11:31 +0100

Hi Christer,

On Sun, Aug 11, 2019, at 10:34 AM, Christer Holmberg wrote:
>     >> I think removing (postal) Address is a good thing. However the 
> rest of this is still needed, as IANA uses 
>     >> this information to decide whether a person/organization is 
> allowed to update an existing registry entry. 
>     >> So please consider adding it back or explain why this 
> information is not needed for a registry where external 

Yes, I still have an issue with this change. The document is now lacking information needed for IANA to complete registrations.

When I originally asked about need for "Address", all I wanted was removal of "Address", not removal of the 2 sentences around it.

Thank you,
Alexey

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Aug 2019 13:45:32 +0000

Hi,

    > When I originally asked about need for "Address", all I wanted was removal of "Address", not removal of the 2 sentences around it.

    Yes.

    But, my comment regarding "Organization or individuals" was that I am not aware of any IANA registry where we indicate who
    is allowed to update an entry. Why do you think IANA needs that information?

    Regards,

    Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 13 Aug 2019 19:00:09 -0700

Hello Alexey

  We just submitted version 39. Could you please check if this addresses
your concerns

Thanks
Suhas

On Mon, Aug 12, 2019 at 2:53 PM Christer Holmberg <
[email-masked]> wrote:

>     > Yes, I still have an issue with this change. The document is now
> lacking information needed for IANA to complete registrations.
>     >
>     > When I originally asked about need for "Address", all I wanted was
> removal of "Address", not removal of the 2 sentences around it.
>
>     Yes.
>
>     But, my comment regarding "Organization or individuals" was that I am
> not aware of any IANA registry where we indicate who
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 14 Aug 2019 18:31:06 +0100

On Mon, Aug 12, 2019, at 2:45 PM, Christer Holmberg wrote:
>     > When I originally asked about need for "Address", all I wanted 
> was removal of "Address", not removal of the 2 sentences around it.
> 
>     Yes.
> 
>     But, my comment regarding "Organization or individuals" was that I 
> am not aware of any IANA registry where we indicate who

This is less of an issue for "Specification Required", but it is certainly an issue for "Expert Review" registries.

Consider the following scenario (it has happened several times in the past as far as I know):

At some point an item X is registered by [email-masked].  10 years later the person is no longer working for Organization Y. The person contacts IANA and attempt to change the registration from a new email address [email-masked]. If the registry doesn't say whether this was a personal registration (and thus the request should be approved, assuming IANA can prove that this is the same person) or for a company (in which case the change request should be denied and the contact email should be updated to another person representing Organization Y), then making changes/updates becomes difficult.

There were similar problems recently when a specification was originally developed by an organization and later on was taken as a work item in an SDO.

Anyway, if you want to make updates to registration easier, Contant and Change Controller should be included in an IANA registration template.

Best Regards,
Alexey

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Aug 2019 17:54:51 +0000

Hi,

> At some point an item X is registered by [email-masked].  10 years later the person is no longer working 
> for Organization Y. The person contacts IANA and attempt to change the registration from a new email address
> [email-masked]. If the registry doesn't say whether this was a personal registration (and thus the request 
> should be approved, assuming IANA can prove that this is the same person) or for a company (in which case 
> the change request should be denied and the contact email should be updated to another person representing 
> Organization Y), then making changes/updates becomes difficult.

Well, in case of "Specification Required" an individual can't just say that he/she wants to change something.

> Anyway, if you want to make updates to registration easier, Contant and Change Controller should be included in an IANA registration template.

To me this kind of "Change control" is something that should be discussed with a wider audience. Individual drafts should not make their own rules. Is there any registry that have these kind of change control rules?

In addition, there would need to be some guidance on what information to provide. For example, if IETF WG X defines an entry, I don't think the change control can be given to WG X, because WG X may not exist in 10 years. So, I assume the change control would be given to IESG?

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 14 Aug 2019 13:31:05 -0500

> To me this kind of "Change control" is something that should be discussed with a wider audience. Individual drafts should not make their own rules. Is there any registry that have these kind of cha…

It's not unheard of. See, e.g., the tables at 
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml

The problems that Alexey cites have caused real issues in the past. 
Given that this is an administrative issue rather than a technical one, 
I'm comfortable taking an executive decision to fix the text in an RFC 
Editor's note per Alexey's comment, and sending the document into the queue.

> In addition, there would need to be some guidance on what information to provide. For example, if IETF WG X defines an entry, I don't think the change control can be given to WG X, because WG X may…

Yes, that is what is generally done. The IESG typically ensures this 
during its review. As this is a pan-IANA issue, it's not generally 
treated as a special consideration on a table-by-table basis.

rfc4422.txt:      Owner/Change controller: IESG <[email-masked]>
rfc4505.txt:      Author/Change controller: IESG <[email-masked]>
rfc4616.txt:   Author/Change controller: IESG <[email-masked]>
rfc4642.txt:   o  Change Controller: IESG <[email-masked]>.
rfc4643.txt:   o  Change Controller: IESG <[email-masked]>.
rfc4643.txt:   o  Change Controller: IESG <[email-masked]>.
rfc4644.txt:   o  Change Controller: IESG <[email-masked]>.
rfc4752.txt:   Owner/Change controller:  [email-masked]
rfc5023.txt:   Author/Change controller:  IETF ([email-masked]) Internet 
Engineering
rfc5023.txt:   Author/Change controller:  IETF ([email-masked]) Internet 
Engineering
rfc5023.txt:   Author/Change controller:  IETF ([email-masked]) Internet 
Engineering
rfc5258.txt:       Owner/Change controller: [email-masked]
rfc5258.txt:       Owner/Change controller: [email-masked]
rfc5258.txt:       Owner/Change controller: [email-masked]
rfc5258.txt:       Owner/Change controller: [email-masked]
rfc5258.txt:       Owner/Change controller: [email-masked]
rfc5258.txt:       Owner/Change controller: [email-masked]
rfc5465.txt:   Owner/Change controller: [email-masked]
rfc5738.txt:       Owner/Change controller: [email-masked]
rfc5738.txt:       Owner/Change controller: [email-masked]
rfc5738.txt:       Owner/Change controller: [email-masked]
rfc5801.txt:     Owner/Change controller: [email-masked]
rfc5802.txt:   Owner/Change controller: IESG <[email-masked]>
rfc5802.txt:   Owner/Change controller: IESG <[email-masked]>
rfc5802.txt:   Owner/Change controller: IESG <[email-masked]>
rfc5819.txt:   Owner/Change controller: [email-masked]
rfc6030.txt:   Change controller:  The IESG <[email-masked]>
rfc6048.txt:   o  Change Controller: IESG <[email-masked]>.
rfc6066.txt:   Change controller: IESG <[email-masked]>
rfc6154.txt:   Owner/Change controller: [email-masked]
rfc6154.txt:   Owner/Change controller: [email-masked]
rfc6335.txt:           | Assignee           | IESG <[email-masked]>        |
rfc6335.txt:           | Assignee           | IESG <[email-masked]>        |
rfc6402.txt:   Assignee: [email-masked]
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6477.txt:   Author/change controller: IESG ([email-masked]) on behalf 
of the IETF
rfc6641.txt:   Assignee (REQUIRED)  IESG ([email-masked])
rfc6694.txt:      Author/Change controller: IESG <[email-masked]> (on 
behalf of the
rfc6694.txt:   o  Contact/change controller:  IESG <[email-masked]> (on 
behalf of the
rfc6717.txt:     Assignee:           IESG <[email-masked]>
rfc6733.txt:      Assignee:             IESG <[email-masked]>
rfc6758.txt:   Author/change controller: Alexey Melnikov / IESG 
([email-masked])
rfc6758.txt:   Author/change controller: Alexey Melnikov / IESG 
([email-masked])
rfc6764.txt:   Assignee:  IESG <[email-masked]>
rfc6764.txt:   Assignee:  IESG <[email-masked]>
rfc6764.txt:   Assignee:  IESG <[email-masked]>
rfc6764.txt:   Assignee:  IESG <[email-masked]>
rfc6787.txt:   Author/Change controller:  IESG, [email-masked]
rfc6940.txt:           | Change controller:         | IETF <[email-masked]> |
rfc6940.txt:   | Registration Owner          | IETF 
<[email-masked]>                |
rfc7030.txt:       Change controller: The IESG <[email-masked]>
rfc7055.txt:   Owner/Change controller:  [email-masked]
rfc7193.txt:   Change controller: The IESG <[email-masked]>
rfc7230.txt:   The change controller is: "IETF ([email-masked]) - Internet
rfc7232.txt:   The change controller is: "IETF ([email-masked]) - Internet
rfc7233.txt:   The change controller is: "IETF ([email-masked]) - Internet
rfc7233.txt:   The change controller is: "IETF ([email-masked]) - Internet
rfc7234.txt:   The change controller is: "IETF ([email-masked]) - Internet
rfc7235.txt:   The change controller is: "IETF ([email-masked]) - Internet
rfc7510.txt:      Assignee: IESG <[email-masked]>
rfc7510.txt:      Assignee: IESG <[email-masked]>
rfc7512.txt:      Author/Change Controller: IESG <[email-masked]>
rfc7532.txt:   Author/Change Controller:  IESG ([email-masked])
rfc7585.txt:      Assignee: IESG <[email-masked]>
rfc7589.txt:      Assignee:               IESG <[email-masked]>
rfc7639.txt:   Change Controller:  IETF ([email-masked]) - Internet 
Engineering Task
rfc7677.txt:      Owner/Change controller: IESG <[email-masked]>
rfc7677.txt:      Owner/Change controller: IESG <[email-masked]>
rfc7677.txt:      Owner/Change controller: IESG <[email-masked]>
rfc7677.txt:      Owner/Change controller: IESG <[email-masked]>
rfc7808.txt:   Assignee:  IESG <[email-masked]>
rfc7808.txt:   Assignee:  IESG <[email-masked]>
rfc7838.txt:   The change controller is: "IETF ([email-masked]) -- Internet
rfc7846.txt:   Change controller:  IESG ([email-masked])
rfc7852.txt:      Change controller: The IESG <[email-masked]>
rfc7852.txt:      Change controller: The IESG <[email-masked]>
rfc7852.txt:      Change controller: The IESG <[email-masked]>
rfc7852.txt:      Change controller: The IESG <[email-masked]>
rfc7852.txt:      Change controller: The IESG <[email-masked]>
rfc8030.txt:   The change controller is: "IETF ([email-masked]) - Internet
rfc8054.txt:      Owner/Change controller: IESG <[email-masked]>
rfc8054.txt:   o  Change Controller: IESG <[email-masked]>
rfc8071.txt:   Assignee:               IESG <[email-masked]>
rfc8071.txt:   Assignee:               IESG <[email-masked]>
rfc8071.txt:   Assignee:               IESG <[email-masked]>
rfc8086.txt:         Assignee: IESG <[email-masked]>
rfc8086.txt:         Assignee: IESG <[email-masked]>
rfc8226.txt:    Change controller: The IESG <[email-masked]>
rfc8314.txt:     Assignee: IESG <[email-masked]>
rfc8314.txt:     Assignee: IESG <[email-masked]>
rfc8314.txt:     Assignee: IESG <[email-masked]>
rfc8315.txt:      Owner/Change controller: IESG <[email-masked]>
rfc8315.txt:      Owner/Change controller: IESG <[email-masked]>
rfc8315.txt:      Owner/Change controller: IESG <[email-masked]>
rfc8315.txt:      Owner/Change controller: IESG <[email-masked]>
rfc8315.txt:      Owner/Change controller: IESG <[email-masked]>
rfc8315.txt:      Owner/Change controller: IESG <[email-masked]>
rfc8440.txt:   Owner/Change controller:  IESG <[email-masked]>
rfc8460.txt:   Change controller: Internet Engineering Task Force 
([email-masked]).
rfc8460.txt:   Change controller: Internet Engineering Task Force 
([email-masked]).
rfc8555.txt:   Change controller: IETF <[email-masked]>
rfc8572.txt:     Assignee:                IESG <[email-masked]>

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Aug 2019 19:12:47 +0000

Hi,

...

>>>> This is less of an issue for "Specification Required", but it is 
>>>> certainly an issue for "Expert Review" registries.
>>>>
>>>> At some point an item X is registered by [email-masked].  10 
>>>> years later the person is no longer working for Organization Y. The 
>>>> person contacts IANA and attempt to change the registration from a 
>>>> new email address [email-masked]. If the registry doesn't say 
>>>> whether this was a personal registration (and thus the request should 
>>>> be approved, assuming IANA can prove that this is the same person) or for a company (in which case the 
>>>> change request should be denied and the contact email should be updated to another person representing 
>>> There were similar problems recently when a specification was originally developed by an organization and
>>> later on was taken as a work item in an SDO.	 
>>
>>> Anyway, if you want to make updates to registration easier, Contant and Change Controller should be
>>> included in an IANA registration template.
>>> To me this kind of "Change control" is something that should be discussed with a wider audience. Individual
>>> drafts should not make their own rules. Is there any registry that have these kind of change control rules?
>>
>> It's not unheard of. See, e.g., the tables at https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml
>>
> Given that this is an administrative issue rather than a technical one, I'm comfortable taking an executive decision to fix the
> text in an RFC Editor's note per Alexey's comment, and sending the document into the queue.

There is still one PR, based on a few remaining issues raised by Alissa. Is it ok if we merge the PR, submit a -40 version, and the send it to the queue?

We can put back the "Organization or individuals having the change control" part in the draft at the same time, so you don' t need to do it.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 14 Aug 2019 14:14:24 -0500

> We can put back the "Organization or individuals having the change control" part in the draft at the same time, so you don' t need to do it.

I've already approved the document. If you point me to the PR, I'll 
append its changes to the RFC Editor's note.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 14 Aug 2019 19:20:13 +0000

Hi,

>I've already approved the document. If you point me to the PR, I'll append its changes to the RFC Editor's note.

https://github.com/suhasHere/ice-sip-sdp/pull/22

We also did a PR, just in case, that adds IPv6 addresses to the examples. Since there were different opinions on whether to include IPv6 examples,  I will let you use "executive power" to decide whether to use it or not :)

https://github.com/suhasHere/ice-sip-sdp/pull/23

Regards,

Christer