Re: [MMUSIC] Alissa Cooper's Yes on draft-ietf-mmusic-ice-sip-sdp-37: (with COMMENT)

[Roman Shpount <[e-mail]>]

Hi Christer,

I agree with most of your comments except the ones regarding the ICE
candidate extenstion registry.

On Tue, Aug 6, 2019 at 12:30 PM Christer Holmberg <
[e-mail]> wrote:

> > Section 4.1: It's not clear why IESG Approval is included as one of the
> registration policies to extend
> > the candidate attribute. Does the WG anticipate cases where IETF Review
> will not be appropriate?
> > And I agree with Alexey that a registry needs to be defined in the IANA
> Considerations section.
>
> My suggestion (I think Alexey also gave it as an option) is to remove the
> text about the process for defining new name/value pairs, and only say that
> unsupported name/value pairs are discarded.
>

This would be the only place where this document allows future extensions
elements without establishing a IANA registry. I would prefer to avoid this.

No one has ever brought an extension suggestion to IETF, AFAIK.
>

This is actually incorrect.

RFC 6544 defines "tcptype" candidate extension attribute (
https://tools.ietf.org/html/rfc6544#section-4.5)
Draft thatcher-ice-network-cost tried to define network-cost and network-id
(https://tools.ietf.org/html/draft-thatcher-ice-network-cost-01#section-4),
but expired.
Somebody defined "generation" extension. I cannot find the relevant
document. If only we had a registry...

Here is an example of ICE candidate generated by Chrome 76 using all of
those extensions:

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

In any case, as an ICE stack implementer I would really love to have IANA
registry for those extensions. If procedural burden of this is not too
high, the benefits of having a single reference location for future
extensions cannot be underestimated.

Best Regards,
_____________
Roman Shpount