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

Alissa Cooper via Datatracker <noreply@ietf.org> Tue, 06 August 2019 15:59 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mmusic-ice-sip-sdp@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alissa Cooper <alissa@cooperw.in>
Message-ID: <156510716501.18086.1896150985239645556.idtracker@ietfa.amsl.com>
Date: Tue, 06 Aug 2019 08:59:25 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/EC2aOKKE7RumfXSWS3RDpDStTmU>
Subject: [MMUSIC] Alissa Cooper's Discuss on draft-ietf-mmusic-ice-sip-sdp-37: (with DISCUSS and COMMENT)

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/esg@ietf.org/iesg@ietf.org/

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

[MMUSIC] Alissa Cooper's Discuss on draft-ietf-mm… Alissa Cooper via Datatracker
Re: [MMUSIC] Alissa Cooper's Discuss on draft-iet… Christer Holmberg
Re: [MMUSIC] Alissa Cooper's Discuss on draft-iet… Roman Shpount