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

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

Alissa Cooper has entered the following ballot position for
draft-ietf-mmusic-ice-sip-sdp-37: 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:
----------------------------------------------------------------------

Apologies for multiple ballot emails, wrapped up a bit too soon the first time.

I'm confused about Section 7. The mechanisms in RFC 4091 and RFC 4092 were
deprecated in RFC 5245, and this is mentioned in RFC 8445. Why does this
specification then need to additionally normatively recommend the use of ICE
for dual-stack scenarios? This could be interpreted as saying that ANAT is an
alternative option for this use case, but it shouldn't be according to RFC 8445.

----------------------------------------------------------------------
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:36:51 +0000

Hi Alissa,

I didn't see the second ballot email, where you had added a DISCUSS. I will address that in this reply :)

> I'm confused about Section 7. The mechanisms in RFC 4091 and RFC 4092 were deprecated
> in RFC 5245, and this is mentioned in RFC 8445. Why does this specification then need to 
> additionally normatively recommend the use of ICE for dual-stack scenarios? This could be 
> interpreted as saying that ANAT is an alternative option for this use case, but it shouldn't be 
> according to RFC 8445.

You are right. My suggestion is to remove Section 7.

Regards,

Christer

---

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

Hi Alissa,

I agree with what Christer said :)
_____________
Roman Shpount

On Tue, Aug 6, 2019 at 12:37 PM Christer Holmberg <
[email-masked]> wrote:

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>