[MMUSIC] Benjamin Kaduk's Discuss on draft-ietf-mmusic-ice-sip-sdp-38: (with DISCUSS and COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 09 August 2019 18:38 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7991200EC; Fri, 9 Aug 2019 11:38:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk 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
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156537593203.15838.12286824910808417510.idtracker@ietfa.amsl.com>
Date: Fri, 09 Aug 2019 11:38:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/jMkeoxmk475VO2Lgmt6IQWB8B3o>
Subject: [MMUSIC] Benjamin Kaduk's Discuss on draft-ietf-mmusic-ice-sip-sdp-38: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Aug 2019 18:39:03 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mmusic-ice-sip-sdp-38: 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:
----------------------------------------------------------------------

A fairly minor point, but the example in Section 5.6 is not compliant
with the ABNF for the ice-options production, which uses SP to separate
different ice-option-tag values; the example uses a comma.


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

Thank you for addressing most of my comments from the -37!  A few
still remain, below.

Can you remind me why the discussion of an additional three-second
waiting period for SIP with forking was removed from (now-) Section 7?

Do we have anywhere a definition of what it means to "indicate ICE
support in an SDP offer/answer"?  (As distinct from ice2 support.)  I remember
some discussion about containing a ufrag/password being enough, but that
doesn't seem to have ended up in the document.

Section 4.2.2

Aren't "rtcp attribute SHOULD be included" and "rtcp attribute MAY be
omitted" just duplicating existing normative requirements from previous
specifications (which thus would not need new normative language here)?
I think we talked about how this is slightly different from some of the previous
relevant specifications, so calling out any differences here might be worthwhile.

Section 5.1

I appreciate that IP address privacy is mentioned here.  (It might
be good in the security considerations, too.)

Section 9

I think this top-level section would be a great place to reiterate that
the SDP and ICE security considerations apply, since we are using both
of them in combination.  Specifically, the IP Address Privacy concerns
are only briefly mentioned elsewhere in the document, and could be worth
reiterating.