Re: [MMUSIC] Alexey Melnikov's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

[Christer Holmberg <[e-mail]>]

Hi,

I suggest to simply remove the sentence - or at least most of it.

Because, I do think it's important to say that one must ignore name/value pairs that one does not understand.

Something like:

"The grammar allows for new name/value pairs to be added at the end of the attribute.
An implementation MUST ignore any name/value pairs it doesn't understand."

Regards,

Christer

Lähettäjä: Alexey Melnikov <[e-mail]>
Lähetetty: tiistai 6. elokuuta 2019 12.28
Vastaanottaja: Roman Shpount <[e-mail]>; Christer Holmberg <[e-mail]>
Kopio: The IESG <[e-mail]>; Flemming Andreasen <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Aihe: Re: [MMUSIC] Alexey Melnikov's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

Hi,

On Mon, Aug 5, 2019, at 9:44 PM, Roman Shpount wrote:
On Mon, Aug 5, 2019 at 8:54 AM Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
> In 4.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.

Does it really mandate a registry?

The syntax says:

        candidate-types       = "host" / "srflx" / "prflx" / "relay" / token

There are other SDP attributes (and SIP header fields etc) that allow extensions ("token", in this case), without a registry.

I think Alexey is talking about  extension-att-name/extension-att-value in candidate-attribute definition.

Yes.

Such as "tcptype active", "generation 0", and "network-id 2" in the following ICE candidate example generated by Chrome:

a=candidate:1943319340 1 tcp 1518214911 10.7.18.148 9 typ host tcptype active generation 0 network-id 2

Note that this was already in RFC 5245.

I agree this how it was already defined in RFC 5245. I did ask the group if this required an additional IANA registry since it is currently impossible to determine where these extensions are defined. For instance, I have no idea in which RFC  "generation 0" is defined. The fact that we are not changing the current definition was the main reason new IANA registry for candidate extensions was not established.
This is exactly my point.

If the WG doesn't want to establish a new registry, then the sentence I quoted above must be removed, as it doesn't mean anything outside of IANA Considerations. In particular, if IESG is to approve an extension, how would implementors be able to find it, if IANA registry is not used? (Arguably, you can say that you still want to limit extensions to IETF stream, in that case the sentence still need to be reworded to something like: "Such extensions MUST be made in an IETF stream RFC and the assignments MUST contain the specific extension and a reference to the document defining the usage of the extension.")

We will need to run this by mmusic group if we want to change this.

Best Regards,
Alexey