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
- [MMUSIC] Benjamin Kaduk's No Objection on draft-i… Benjamin Kaduk via Datatracker
- Re: [MMUSIC] Benjamin Kaduk's No Objection on dra… Christer Holmberg