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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 11 August 2020 13:45 UTC

Return-Path: <christer.holmberg@ericsson.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 73EA03A1088; Tue, 11 Aug 2020 06:45:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 HyvbLmPqTxpb; Tue, 11 Aug 2020 06:45:26 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10064.outbound.protection.outlook.com [40.107.1.64]) (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 E5E943A1087; Tue, 11 Aug 2020 06:45:25 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=foSK04WyEQ/J1lovCvEHd7FU9svFRjr/guw7vcS3ZNLmtNd8goW7hH8ESCdhNuW140PNdnfk0QsvbcTVkdu5AoubWngv+5o/HosdmDwyMPQx0JfUxl+ziQ+CO+JOau1FVtpsevjR4/c2LT/Rb6pgUpBLU5dXcL3MVHB46Fcc7yTTIOK5tm4bmP2fO0Fl39gij5x5vlyFG/Cr7j94jAQCELpZEVDnji0ZMLOg+HAq3uQUFHSceLOpGCVoxTtpCzOYg+JjQwMAtL/WQqdKPfQFSI0F89vNsez1aNlywSI+fgw3Egn3BuLtLXXtEWWdRzBXHGEhSO/9eteB0qdvccn3HA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kuSMBNeJi/bowH+/RydvyNt5+ePzP0yDAzvDLYUEXGM=; b=fR9m2SPtkfBJHnEhctUW02LSgub4/Wb+17fh9C4Xqa/3s05C4XG4RFZfuABHOE87UbSDQYuBCsDxlgG3gHmCywH4BpTgM67pIHWryUhPNDO35uiip3iR6z/AYZFfNVEEXPw1WbqTUYYA9eqSWyLCMqv9iUrJnw2uPSbMAcTrvR95DRdwIx62G4Qmx7CImYUIvd5d/HRlmtzeVqHFrZpVGgbQvn3vzWbYPV5uZtn9DLSrri9X6VAcAe8p8DILQYXLJPfAts/zTeH4xLDgGoT2ubrz87uOUH+fZPqYRtwWl8a0l+3DR9xNNSsnudZSqfdpPj1oEBQo0JsgR3mFP2/ETg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kuSMBNeJi/bowH+/RydvyNt5+ePzP0yDAzvDLYUEXGM=; b=b53malxFFoQdHzBYrJuZCaHLbPBBpmIojPkXfJ3Q4/sBaLbVPHMbGmWf55+9cweVMSg0EwjL5yIc9bGomfgenepajyF4h3iVhHHCnA4xve8sNpKfEY0H5zUkrh3vYQE73l+7XMpA0h8zw8hUU61qoeFBxZ8kl0G8nTrKw+o/y5k=
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com (2603:10a6:208:4c::18) by AM0PR07MB5538.eurprd07.prod.outlook.com (2603:10a6:208:105::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.8; Tue, 11 Aug 2020 13:45:23 +0000
Received: from AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::187b:7fe6:cc5a:eb00]) by AM0PR07MB3860.eurprd07.prod.outlook.com ([fe80::187b:7fe6:cc5a:eb00%5]) with mapi id 15.20.3283.015; Tue, 11 Aug 2020 13:45:23 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-mmusic-msrp-usage-data-channel@ietf.org" <draft-ietf-mmusic-msrp-usage-data-channel@ietf.org>, "mmusic-chairs@ietf.org" <mmusic-chairs@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>, Bo Burman <bo.burman@ericsson.com>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-mmusic-msrp-usage-data-channel-23: (with COMMENT)
Thread-Index: AQHWb3nP/dHQtg7skUG2Svi92Yq6Iakyb8GQ
Date: Tue, 11 Aug 2020 13:45:23 +0000
Message-ID: <AM0PR07MB3860DF85941EBD0053D7E22293450@AM0PR07MB3860.eurprd07.prod.outlook.com>
References: <159710718800.15102.2700846398441924868@ietfa.amsl.com>
In-Reply-To: <159710718800.15102.2700846398441924868@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [188.127.223.154]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9d540073-c72b-4930-758d-08d83dfccbe8
x-ms-traffictypediagnostic: AM0PR07MB5538:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM0PR07MB55384F6658CAD0CD2C5ABF8393450@AM0PR07MB5538.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: A9nZAh6VogBpyzHnl6vIxDLoc3NoDFcFJEtM/+DHNUttSxkSTQobJez7078lzPIOWqik7gn0/nQcCNvu8w9IodmHGD0D8tvjQTIHcNKYAH8z8x/fAm68BvSNIRYVpzfRgB9SD1bBQtl4Zbvkw5PN1TXlAE2iJZShnwfSRruVFB/Bbht/NQGY+icwksDYVHmiGMMEHLT34yx5CRKJW62elhbxk3ZSaGeq2JzSQIE6OHfKb/JQVyCERWxswd1px6tP1/qOiT+d/w1rSiHkF4QdruuLy40RTQELg/IT6ksTebronyxf07qvsu+5GjwZ6kkdZ6JiQdHuzfBMA97t4pEIbw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3860.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(136003)(39860400002)(366004)(346002)(71200400001)(86362001)(4326008)(64756008)(66446008)(6506007)(83380400001)(76116006)(52536014)(66556008)(66946007)(26005)(478600001)(44832011)(110136005)(107886003)(54906003)(66476007)(7696005)(9686003)(186003)(55016002)(8676002)(2906002)(5660300002)(8936002)(33656002)(316002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: PClfOCzQu1EvWhxnAouWX9DCVnDlp5vMyCwgAjKtFJbZx8QHidBocj017IXYzQd+jdBTiBhIkgLdoUAINKsxHHgLHBayjVzegCAdFAsPjd7xEwJuryS0SgBjjYCfTHbknEpjsGQJ/1ewYUbP3BqQBvgn3x4dqmBVHOepQmLwImlLWUDa7uSXcBX2lunZWmQQKkoMR8I567hC9KoKjOuxh5r/XEwnPoHcuzU2kNrCfZqhN2PbrKcKKa70qBiA5rfZ+l2IysG/hdroIiGNxAJjFfcJmrpAHspH0coTVmxUsrla6PrgKlhQ9KcPGWFVw1y0Rk4VBmWWmZ+Jzf6TuNEVoQtd9Ehbq2yeK3Br2Evg1IA9tx1yrJSGLgw9lawI/zyXPlkjS712MesmcZG0KEH0Zi27YiI6EmMeimpb2A98A09rlE9BvYK2kVRL00DmadN81symObc0ffAg7RKJhkVz7+emaS6mK6/C6ux5rijyC6dUqK26/7eqfI7RWHO0WT4K0ldmdj7MplxoTsSkecwFMZihq0IJfC6CU/ohl/j3+nXJpqOEr97hhsr8ygNlhr/o1w4VA0vsV6lZQdj4/te8xwXJbG0p65vVLNgJRM4hbN2uL4UpxU30g9GcgVZ1Jt09jevWIvP8FcrI0nQkhzxEWA==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR07MB3860.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9d540073-c72b-4930-758d-08d83dfccbe8
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 13:45:23.3808 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: NYheMaQyIjYxOmU9DOlTmfmu/1MklXQVMOLq1a8HLfuSFpWt8nt5MQIFhu8U8SGFjSFW++jxK2cVgmzrW8Acih8ZkAbyVRzDJrxrREmw2R8=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5538
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/DlSxE81lzk3D87KE3GbJ4wv5Asg>
Subject: Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-msrp-usage-data-channel-23: (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, 11 Aug 2020 13:45:28 -0000

Hi Benjamin,

Thank You for the review! Please see inline.

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

Section 4.4

>   An offerer and answerer SHALL include a dcsa attribute for each of
>   the following MSRP-specific SDP attributes:
>
>   o  defined in [RFC4975]: "path".
>
>   o  defined in [RFC6714]: "msrp-cema".
>
>   o  defined in [RFC6135]: "setup".  See Section 4.5
>
> Some discussion of why "msrp-cema" and "setup" are mandatory for all MSRP data-channel usage (noting that neither RFC 6714 nor RFC 6135 has an "Updates:" relationship to RFC 4975, 
> which might suggest that they are independent extensions) might be helpful.  I see strong "MUST always include an explicit a=setup attribute" in RFC 6135, with some justification, but
> RFC 6714 is only using language like "attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension", which suggests that the extension is seen as an optional
> thing.  (Is the CEMA requirement just to allow transparent use of a gateway to a non-data-channel peer?  I guess the IANA considerations mention "the routing of MSRP messages transported
> on a data channel is more similar to the MSRP CEMA mechanism than the legacy MSRP routing mechanism", which is reasonably compelling.)

Section 4.4 does mention CEMA:

   "The MSRP data channel is established using the SDP offer/answer procedures defined
   in [I-D.ietf-mmusic-data-channel-sdpneg], and the MSRP messages are then transported on that data channel.
   This is different from legacy MSRP [RFC4975] but similar to MSRP CEMA [RFC6714].

I guess I could enhance that, and say something like:

   "The MSRP data channel is established using the SDP offer/answer procedures defined
   in [I-D.ietf-mmusic-data-channel-sdpneg], and the MSRP messages are then transported on that data channel.
   This is different from legacy MSRP [RFC4975] but similar to MSRP CEMA [RFC6714]. Because of this, a dcsa embedded
   "msrp-cema" attribute is mandated for MSRP sessions over data channels.


I think Section 4.5 covers "setup":

   "As described in Section 4.4, the usage of a dsca embedded setup
   attribute is mandated for MSRP sessions over data channels.  It is
   used to negotiate which MSRP session endpoint assumes the active role
   as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]."

(Note to self: Quotes shall be added to setup: s/setup/"setup")

---


Section 4.8

> [obligatory griping about IPv4, SHA-1,

I will change it to IPv6.

> date two years in the past, etc.]

A reminder of how long we have been working with the draft... :)

I will update that date.

> Is there value in showing a corresponding SDP answer?

Well, at least it doesn't hurt, so I can add an SDP answer :)

>Do we want to say anything about backslash-wrapping of long lines for readability (and/or reference draft-ietf-netmod-artwork-folding)?

I can do that.

---

Section 5.4

>   message.  Therefore all sent MSRP chunks including the MSRP chunk
>   header SHALL have lengths of less than or equal to the value of the
>   peer's "a=max-message-size" attribute, which is associated with the
>   data channel's SCTP association.
>
> nit: perhaps the "including the MSRP chunk header" is better off being applied to the lengths that are less than the message-size rather than being indicated as a type of chunk.

RFC 4975 describes what an MSRP chunk is, so I suggest to remove "including the MSRP chunk header" part.

NEW:

    "Therefore all sent MSRP chunks SHALL have lengths of less than or equal to the value of the
     peer's "a=max-message-size" attribute, which is associated with the
     data channel's SCTP association."

---

Section 8

>   Note that discussion in [RFC4975] on MSRP message attribution to
>   remote identities applies to data channel transport.
>
> nit: the phrase "message attribution" does not appear in RFC 4975, though I do see just a single usage of "attribution" in Section 14.5 "Other Security Concerns", which seems 
> ike it matches up to what's being discussed here.  Would a section reference in RFC 4975 help the reader to locate the intended discussion?

I can add a section reference.

NEW:

     "Note that discussion in Section 14.5 of [RFC4975] on MSRP message attribution to
      remote identities applies to data channel transport."

----

Section 9.3

>   +-----------------------+-------------------------------------------+
>   | Contact name:         | IESG                                      |
>   | Contact email:        | iesg@ietf.org                             |
>   | Attribute name:       | file-date                                 |
>   | Usage level:          | dcsa(msrp)                                |
>   | Purpose:              | Indicate a date related to the file in an |
>   |                       | MSRP file transfer negotiation.           |
>   | Reference:            | RFCXXXX                                   |
>   +-----------------------+-------------------------------------------+
>
> nit(?): should this be "one or more dates"?

Yes. Will fix as suggested.

---

Section 12.1

>draft-ietf-rtcweb-data-protocols appears unreferenced other than the changelog (which presumably is not normative, though I expect the RFC Editor to just remove it entirely during publication).

Yes, the change logs will be removed.

>We don't actually cite draft-ietf-mmusic-sctp-sdp anywhere that looks like a normative manner, though the changelog says that this is normative for use of the a=max-message-size attribute lines, so maybe another citation or two is in order?

First, draft-ietf-mmusic-sctp-sdp is already indirectly a normative reference, via the normative reference to draft-ietf-mmusic-data-channel-sdpneg.

Second, I could add a reference to draft-ietf-mmusic-sctp-sdp in Section 5.4:

   "SHALL have lengths of less than or equal to the value of the peer's "a=max-message-size" attribute [I-D.ietf-mmusic-sctp-sdp]"

(Note to self: s/"a=max-message-size attribute"/max-message-size attribute)

>RFC 7977 is only mentioned in the Introduction as a thing that MSRP was previously specified for, which hardly seems normative.

Well, RFC 7977 does define the WebSocket subprotocol value ('msrp'), which we also use for the MSRP data channel.

---

Regards,

Christer