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

["Alexey Melnikov" <[e-mail]>]

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