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

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Tue, 06 Aug 2019 08:47:41 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-mmusic-ice-sip-sdp-37: Yes

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Since RFC 5245 is already obsolete, this document cannot obsolete it I don't
think. RFC 8445 references this document, so readers of that document will be
able to find this one.

Section 2: Please use the precise boilerplate from RFC 8174.

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.

Section 8: Agree with Ben about adding references to ICE and SDP security
considerations.

Section 9.1.1: s/[email-masked]/[email-masked]/

Section 9.2: Further to Alexey's point, the minimal information necessary for
the registry to function should be collected and/or published.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Aug 2019 16:29:50 +0000

Hi Alissa,

Thank You for the review! Please see inline.

> Since RFC 5245 is already obsolete, this document cannot obsolete it I don't think. 
> RFC 8445 references this document, so readers of that document will be able to find this one.

Ok, we will remove the "obsolete" part.

---

> Section 2: Please use the precise boilerplate from RFC 8174.

Will do.

---

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

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

---

> Section 8: Agree with Ben about adding references to ICE and SDP security considerations.

Will do.

---

> Section 9.1.1: s/[email-masked]/[email-masked]/

Will fix.

---

> Section 9.2: Further to Alexey's point, the minimal information necessary for the registry to function should be collected and/or published.

I suggest to only keep the following:

   o  The ICE option identifier to be registered

   o  Short description of the ICE extension to which the option relates

   o  Reference(s) to the specification defining the ICE option and the
      related extensions

---

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 6 Aug 2019 12:47:52 -0400

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 <
[email-masked]> wrote:

> registration policies to extend
> 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.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Aug 2019 16:52:59 +0000

Hi,

I am fine with a registry if people think it’s needed.

Regards,

Christer

Lähettäjä: Roman Shpount <[email-masked]>
Lähetetty: tiistai 6. elokuuta 2019 19.48
Vastaanottaja: Christer Holmberg <[email-masked]>
Kopio: Alissa Cooper <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Aihe: Re: [MMUSIC] Alissa Cooper's Yes on draft-ietf-mmusic-ice-sip-sdp-37: (with COMMENT)

Hi Christer,

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

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

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