Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)

"Roni Even (A)" <roni.even@huawei.com> Tue, 23 April 2019 12:47 UTC

Return-Path: <roni.even@huawei.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE5A120167; Tue, 23 Apr 2019 05:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJ6pIt3YqpUp; Tue, 23 Apr 2019 05:47:19 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFAB12015F; Tue, 23 Apr 2019 05:47:18 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 6489CA5E49A64D750C04; Tue, 23 Apr 2019 13:47:16 +0100 (IST)
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 23 Apr 2019 13:47:15 +0100
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 23 Apr 2019 13:47:15 +0100
Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 23 Apr 2019 13:47:15 +0100
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.138]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0415.000; Tue, 23 Apr 2019 20:47:10 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-mmusic-data-channel-sdpneg@ietf.org" <draft-ietf-mmusic-data-channel-sdpneg@ietf.org>, Bo Burman <bo.burman@ericsson.com>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)
Thread-Index: AQHU8BG0WtMoUIs+/0m9N797VxlBlqZJspdA
Date: Tue, 23 Apr 2019 12:47:10 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CDD817@dggemm526-mbx.china.huawei.com>
References: <155495118561.22741.226184336926630062.idtracker@ietfa.amsl.com>
In-Reply-To: <155495118561.22741.226184336926630062.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.102]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/ldPtRntqnqHtzL3uWLc50G85jh4>
Subject: Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Tue, 23 Apr 2019 12:47:22 -0000

Hi,
Thanks for the review, see inline
Roni

-----Original Message-----
From: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] 
Sent: Thursday, April 11, 2019 5:53 AM
To: The IESG
Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org; Bo Burman; mmusic-chairs@ietf.org; bo.burman@ericsson.com; mmusic@ietf.org
Subject: Benjamin Kaduk's No Objection on draft-ietf-mmusic-data-channel-sdpneg-25: (with COMMENT)

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mmusic-data-channel-sdpneg-25: No Objection

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-data-channel-sdpneg/



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

Section 4

   The mechanism in this document only applies to the Session
   Description Protocol (SDP) [I-D.ietf-mmusic-rfc4566bis] when used
   together with the SDP offer/answer mechanism [RFC3264].  Declarative
   usage of SDP is out of scope of this document, and is thus undefined.

nit: this text doesn't actually scope itself to "this mechanism" or the RTCWeb data channel, and seems to be saying that all declarative SDP is undefined, globally.

RE: change to " Declarative  usage of SDP is out of scope for this document, and is thus undefined."

Section 5.1.7

                                The ordered parameter is optional and
   takes two values: "true" for ordered and "false" for unordered
   delivery with "true" as the default value.  Any other value is
   ignored and default "ordered=true" is assumed.  [...]

This seems to be saying that offers or answers that do not conform to the ABNF will be special-cased as being ignored (instead of rejected) when they appear where ordering-value should appear.  It's not clear to me why we need a special case here, since in Section 8 we explicitly say that peers MUST close the relevant data channel when such error cases occur.

RE: this statement only applies to the ordered parameter, I am not sure why you think it is for any parameter.

Section 5.1.8

If we chase links to draft-ietf-rtcweb-data-channel we find that larger values indicate higher priority.  Do we want to short-circuit that and say so explicitly here?

RE: I prefer to keep the link since otherwise any change in the rtcweb document will require a change here.

Section 5.2

                                                                   Each
   of these attributes is represented by one new attribute line, and it
   includes the contents of a media-level SDP attribute already defined
   for use with this (sub)protocol in another IETF (Internet Engineering
   Task Force) document.  [...]

Do we need to limit the data-channel subprotocols to those specified by the IETF?  Or is it just the media-level SDP attributes that we are trying to maintain change control over?

RE: it is just the SDP attributes, this is the dcsa section. Sub protocols are specified for dcmap

   The detailed offer/answer procedures for the dcsa attribute are
   dependent on the associated sub-protocol.  If no offer/answer
   procedures exist for the sub-protocol when used outside of the dcsa
   attribute, no specification is needed for use with dcsa.  The IANA
   registration procedures for the WebSocket Subprotocol Name Registry
   (Section 9.1) do not strictly require a specification of the offer/
   answer procedures for the sub-protocol when used with dcsa.  If the
   sub-protocol has defined offer/answer procedures when used outside of
   dcsa, such a specification is encouraged to ensure interoperability.
   If the sub-protocol has defined offer/answer procedures when used
   outside of dcsa, but no specification exists for the offer/answer
   procedures for the sub-protocol when used with dcsa, implementations
   SHOULD assume the use of the default values for all otherwise-
   negotiable and applicable sub-protocol parameters.

I'm not entirely sure I understand what this paragraph is trying to say.
The first sentence is clear, but the second sentence seems to be saying that if there are no O/A procedures for a given subprotocol outside the datachannel, it's just a free for all and I can use it in the data channel and make up my own procedures for using the dcsa attribute.
I understand that IANA doesn't require a specification for the subprotocol when allocating the subprotocol name, but that just means that there may not be a specification available whether or not I want to use it with dcsa -- the IANA registry doesn't care directly about use with dcsa.  If a subprotocol has defined O/A procedures outside of dcsa, doesn't that basically mean there's a specification?  Why do we need to go out of our way to encourage a specification in that case (and is it a specification of the O/A semantics when the subprotocol is used outside dcsa or with dcsa)?  In the last sentence, I think we're talking about using defaults for parameters that are not explicitly negotiated using dcsa, but we don't actually say that.

RE- Since subprotocols can be registered with IANA on FCFS we cannot assume that there will be a document that will address the offer answer but we would like to encourage it.

Section 5.2.1

                                               Note however that not all
   SDP attributes are suitable as a "a=dcsa:" parameter.  IANA SDP
   parameters contains the lists of IANA (Internet Assigned Numbers
   Authority) registered session and media level or media level only SDP
   attributes.

Am I supposed to infer that these are the attributes that are suitable for a=dcsa: parameters?

RE: added the following text to this section:

" SDP attributes that are only defined for use at the
   dcsa usage level, SHALL use the dcsa usage level when registering the
   attribute.  If existing media attributes are used in a datachannel
   subprotocol specific way, then a new dcsa usage level
   MUST be defined for the existing media attribute.  Where the SDP
  attribute is applicable to a particular subprotocol/s this SHALL also
   be registered by indicating the applicable subprotocol identifiers
   (see https://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-34#section-8.5) along with the dcsa usage level.
"
Note that rfc4566bis changes the registration table in IANA

   As opposed to the data channel "a=dcmap:" attribute parameters, these
   parameters are subject to offer/answer negotiation following the
   procedures defined in the subprotocol specific documents.

I am not sure where we really say that the a=dcmap: parameters are not subject to O/A negotiation.

RE: see section 6.4 , dcmap is either accepted as is or rejected.

Section 6.1

   SCTP stream identifiers associated with data channels that have been
   negotiated using DCEP MUST NOT be included in SDP offers and answers.

This sentence appears as a dedicated paragraph and is duplicated at the end of the previous paragraph; presumably we only need one copy thereof...

RE: yes, thanks

Section 6.2

                                         If an SDP answer contains both
   of these parameters then the offerer MUST treat the associated SDP
   offer/answer failed.

nit: "as failed", I think.

RE: OK

Section 6.4

We only mention that the dcmap-stream-id, max-retr, and max-time values need to match the offer, leaving the ordering/subprotocol/label/priority
to be omitted because they are conveyed at the SCTP layer?  Perhaps we should state explicitly that they need to be absent...

RE: they can be different in each direction

Section 6.6

Do we want to say anything about the appropriate response to receiving changed values for the SDP attributes/attribute values is to close the corresponding data channel?

RE: Added text in the -26 version about this being application dependent

Section 6.6.1

It seems like the second bullet point only makes sense after the first has completed, as the tsvart reviewer noted?  Specifically, the "; or"
at the end of the first bullet point doesn't seem to make much sense.

RE: after the data channel is reset you can use a new data channel with a new dcmap value 

Section 9.3

               If existing media attributes are used in a datachannel
   subprotocol specific way (Section 5.2.1), then a new dcsa usage level
   MUST be defined for the existing media attribute.  [...]

I'm not entirely sure that I understand what this means, though I'm not really an expert in SDP.

RE: this section was removed see my comment on section 5.2.1

Appendix A.1

I'm not sure that I know what "glare situations" are; is there a reasonable reference to include?

RE: this is an offer/answer term in RFC3264 and known to anyone who is doing offer/answer (I can add a reference to RFC3264)

   Which set of stream identifiers is owned by which endpoint is
   determined by convention or other means.

(specific to the application?)

      Note:For data channels negotiated via different protocol from
      DCEP, no convention is defined by default.

That seems a bit misleading, since Section 6.1 says that the even/odd split applies to the SDP O/A negotiation case.

RE: this is true and the note says that for non DCEP you need to specify the convention which is done in section 6.1