Re: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Thu, 03 October 2019 12:10 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
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 766F912085F for <mmusic@ietfa.amsl.com>; Thu, 3 Oct 2019 05:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=omnitorab.onmicrosoft.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 io-_rXw9OI5W for <mmusic@ietfa.amsl.com>; Thu, 3 Oct 2019 05:10:38 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150103.outbound.protection.outlook.com [40.107.15.103]) (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 E0C6D120857 for <mmusic@ietf.org>; Thu, 3 Oct 2019 05:10:37 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fPuF8DU/CzXWxIc1ZDsw8daAla2TdUCM0lrrQ158nPPw5aqkT24YabSi6vDriNjc7EI/qa34NvQ4TFdptojAc+hq8qksTn3lOHGlPqS4IEXOaKh3MyQNEu/1MvhRRO/Ld3ThShrJud15RorUw2pE0fFzRdEYhTTBFVVzRl41IxHs295e5o+T/uv1fJ8PgK4ktqiAzT5bh9fD+oWNwFe8lS6r/j8sznUUqJwT3BvuDxEHDYbxl0zltGldB+NuSyvrNgxkKPyfCcKzWOtSzC1tk7QR9qohuy9PpjhxLMa4+7Uu2Uv1JCjTv/iUks0MHqq/A20QqZHweqHSYe3SofdckA==
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=9tifvC50OEO9Jw+k/DazlLG+Po1rO3WRqwUMfVy91Sg=; b=BOCfE5BZ0L8YJ+2NJqQa6ZSS0ZqNRCiB4m/lB44MIiBZ6vWSJopA4FVK3RODqOlS5fF1XuEdP5m6wLC97BFii62vTAeRLfdBUVaqJzCX3sghCjjEsOPcJwD8ga+TPlEF11HYEQnk86yZ3rBwPs1usIIYYCpvohaQYNFDbOadr9GRDoqYpr2KGHg+IbpcldmWXwhVB6WvxsB0AU9GACZ4yn0DfoxizBoCsSOHD9tm+ZbwhK4Kl2P/BNIlXknFHalyMq9TmFmOFoZNpyrUangjVu5okfsYQ67JcvYjh2ET5bm1XUk2HRRLY/kZyjnDEykCEDquEFMC2tO7rTjvqGpHtg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=omnitor.se; dmarc=pass action=none header.from=omnitor.se; dkim=pass header.d=omnitor.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=omnitorab.onmicrosoft.com; s=selector2-omnitorab-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9tifvC50OEO9Jw+k/DazlLG+Po1rO3WRqwUMfVy91Sg=; b=ZeepXVteBCfPAhAUg/79auET5WjT79I45fvUAfJi2zXF6+xQ0YIgiar3vTJ7DcAS7f680kYHC1R+FGjMmhIIKpLGpT/7bEyj6YTkamrgX4AUW7kBjMr4Ek/I+fOl9ruvGiQe7J+CNEMdkysTy22ziin7F9sQxAQDodGLEBDwqPM=
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (10.186.178.76) by VI1P193MB0253.EURP193.PROD.OUTLOOK.COM (10.175.183.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Thu, 3 Oct 2019 12:10:34 +0000
Received: from VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::ec96:d49e:287d:6c1]) by VI1P193MB0669.EURP193.PROD.OUTLOOK.COM ([fe80::ec96:d49e:287d:6c1%3]) with mapi id 15.20.2305.023; Thu, 3 Oct 2019 12:10:34 +0000
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Bo Burman <bo.burman=40ericsson.com@dmarc.ietf.org>, "mmusic (mmusic@ietf.org)" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06
Thread-Index: AdV5JBu3/7R1eFiwT0+abl8CWK3iFAArTgsAAAir1ID//98TgA==
Date: Thu, 03 Oct 2019 12:10:33 +0000
Message-ID: <d54b7de0-e846-24e0-fd91-df085f683cc8@omnitor.se>
References: <HE1PR07MB3259435390044A9DCE53123B8D9C0@HE1PR07MB3259.eurprd07.prod.outlook.com> <b4f3e9ca-ca62-c822-6991-87835c4cb6be@omnitor.se> <57665CB6-6668-4585-864D-16A02FBEF228@ericsson.com>
In-Reply-To: <57665CB6-6668-4585-864D-16A02FBEF228@ericsson.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: PR0P264CA0224.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1e::20) To VI1P193MB0669.EURP193.PROD.OUTLOOK.COM (2603:10a6:800:159::12)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunnar.hellstrom@omnitor.se;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [77.53.231.170]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 801cc348-6c5c-467f-811b-08d747fab148
x-ms-traffictypediagnostic: VI1P193MB0253:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <VI1P193MB025306792448E70F071F4035FB9F0@VI1P193MB0253.EURP193.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01792087B6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(39830400003)(376002)(396003)(199004)(189003)(8676002)(3846002)(6116002)(7736002)(26005)(2906002)(305945005)(31696002)(316002)(110136005)(76176011)(52116002)(186003)(31686004)(86362001)(6306002)(6506007)(386003)(6436002)(446003)(2616005)(6486002)(6512007)(476003)(85202003)(102836004)(229853002)(486006)(85182001)(6246003)(25786009)(81156014)(14454004)(561944003)(14444005)(966005)(508600001)(66066001)(71190400001)(71200400001)(36756003)(8936002)(66446008)(64756008)(66556008)(66476007)(66574012)(99286004)(5660300002)(81166006)(66946007)(256004)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1P193MB0253; H:VI1P193MB0669.EURP193.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: omnitor.se does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Aj0Fd2vtKWJZCGwMAk4CxnT0EW0LIjrIuUVMyr73S0aUwTqnFF0pMTlme9DxNNJGb4dNR2g0gIrWNeuz661p689PDl94H/p0W1XX6pFa64r2EmvfvwfjgMdwKUVRiFi4Cr23O1mZO9oTAk1lhA7iT4MAvgRGGOwozzRf8jOfUPjO97mq3tXZK/V09RjOsMg6jwmszYhKvZAL0rSPDMoxBIFAJzups0lcq5spvYMyN7Lc7xNAmMzrW0km6JeoHmixk4qOnPAp759rvO8J5Oy+YADCQTf1Zvj0Obrh5kQb6y4YLqiOM1oyP5+NM7bhmZ7IBwgyLUJir+b3hYi/JggmoVpIy58s0iPeD4KucHxATGudC5K4GupiXXIhGRoLHVmiZlbrmkusCFqeLTwRRGVmoSDqGJY+ukUEohxe86Yu/MJrNdBRkaW7eOx8Afgx+CFf7w7NrLohko5wopMAqr59sA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <45AF10CF257F5643A0D6D7557F250EE9@EURP193.PROD.OUTLOOK.COM>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: omnitor.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 801cc348-6c5c-467f-811b-08d747fab148
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2019 12:10:33.9660 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2df8b35f-363f-46b8-a0d1-ee9b1723225b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vaANGtVrWW82agW5G4kZXaaZbJfUjGr6vcIrCxI/hPRfklBSsWcdS6fngb1bRj8Yk30lT59zmJoWqiJInsTyDjDJ/8pvSlsllz/8SVql4Bs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P193MB0253
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/m7apkNQ626r8tUT2XZgwfB9Tl2c>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-t140-usage-data-channel-06
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: Thu, 03 Oct 2019 12:10:42 -0000

Hi Christer, please see responses inline,

Den 2019-10-03 kl. 13:08, skrev Christer Holmberg:
> Hi Gunnar,
>
> Thank You for the review! Please see inline.
>
>> I have reviewed draft-ietf-mmusic-t140-usage-data-channel-06 and find it to be in good shape, important and sufficient for its purpose. I see also that
>> further separate work is desirable for the multi-party considerations and the gateway considerations.
>>
>> I found some places where mainly editorial improvements can be made:
>>
>> 1. In 4.1, misspelling. "descripton" sb "description"
> Will be fixed.
>
>> 2. In 4.1 Note, misspelling "negotied" sb "negotiated"
> Will be fixed.
>
>> 3. In 1., line 4  the last informational reference in the paragraph should be to RFC 3550 instead of RFC 4103
> Will be fixed.
>
>> 4. In 3, delete "using the RTP timestamp". It is usually the sequence number that helps finding where data is missing.
> The sequence number is used to detect missing data, but the timestamp is used for data redundancy.
>
>     "The RTP header is followed by one or more redundant data block
>     headers: one for each redundant data block to be included.  Each of
>     these headers provides the timestamp offset and length of the
>     corresponding data block,"  (RFC 4103, Section 4.1)
{GH] Well, that is the coding of the redundancy data block, but not how 
loss is detected. I do not know any implementation that bothers about 
details in the RTP timestamp for detecting loss. Instead, the sequence 
numbers of the redundant parts can be evaluated by subtraction from the 
current RTP sequence number and then it is easy to detect if some data 
needs to be recovered from the redundant parts or if there is a 
irrecoverable gap in received sequence numbers. So, I sustain my 
proposal to delete "using the RTP timestamp".
>> 5. In 4.2, first line: "an SDP 'dcsa' attribute" s.b. "one or more SDP 'dcsa' attributes"
> Will be fixed.
>
>> 6. At the end of 4.2, add "section 6.7" because it is hard to find in sdpneg where it is specified how to handle unknown attributes (and the wording in 6.7 is confusing, but that is another matter)
> Will be fixed.
>
>> 7. In 4.2.3 delete the last sentence "An offerer and answerer MUST mark the direction of the text by sending a direction attribute inside 'dcsa' attribute."
>> This is superfluous information, and it can be misunderstood that the direction attribute always must be explicitly provided. (another solution could be to
>> improve the sentence by including when the direction must be included)
> I suggest to delete the last sentence.
[GH] good
>> 8. In 4.2.3.1.1 "both send or receive" s.b. "both send and receive"
> Will be fixed.
>
>> 9. In 4.2.3.1.2 all "MUST" sb changed to "SHOULD", because the last paragraph of 4.2.3.1.1 says that the answerer might not support
>> direction marking. It is then illogical to require that.
>>
>> 10. In 4.2.3.1.2 second paragraph. The wording about not indicating 'sendrecv' means implicit marking as sendrecv is a bit confusing and may
>> cause implementers to believe that they must always provide explicit marking of direction. A remedy might be to swap order between the two
>> sentences in the second paragraph and insert "(implicitly or explicitly)" after "sendrecv" to make the paragraph wording:
>> "If the answerer does not explicitly mark the data channel, a 'sendrecv' attribute inside a 'dcsa' attribute is implicitly applied. If the offerer
>> marked the data channel as sendrecv (implicitly or explicitly), the answerer SHOULD mark the data channel as sendrecv(implicitly or explicitly),
>> sendonly, recvonly or inactive with a 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute inside a 'dcsa' attribute. "
> I don't like the SHOULD. We define the procedures for an answerer that do support the procedures.
>
> The last paragraph of Section 4.2.3.1.1 already points out that the answerer may not support setting the direction attribute, and how the offerer handles it.
>
> Other than that, I am fine with your suggestion to change the ordering.
>
> Or, we could make it even shorter:
>
>     "If the offerer marked the data channel as sendrecv (implicitly or
>       explicitly), the answerer MUST mark the data channel as sendrecv
>       sendrecv (implicitly or explicitly), sendonly, recvonly or inactive with
>       a 'sendrecv', 'sendonly', 'recvonly' respective 'inactive' attribute inside
>       a 'dcsa' attribute."
[GH] accepted, ( but you have double sendrcv on lines 2-3 in your 
proposal above)
>
>> 11. In 4.3 Examples, some values are unusual and should be selected to be more natural:
>> The stream-id in the offer is very often even because it is most often the same party who takes the initiative to the SCTP association
>> who also sends the initial offer. Thus, change all stream-id in the examples from the odd 1 to e.g. the even 2
> Will fix.
>
>> Use different udp port numbers in the m-lines in the offers and corrsponding answers.
> Will fix.
>
>> Use different sctp port numbers in offers and corresponding answers.
> Will fix.
>
>> 12. In 5.2 Change the header to "5.2 Data Encoding, Sending and Receiving"
>> and insert last this important hint for interoperability.
>> "The T.140 coding details contain information on optional control codes intended for controlling the
>> presentation that may not be supported by the presentation level of the receiving application. The
>> receiving application MUST handle reception of such T.140 control codes properly (e.g. ignore them)
>> even if their effect on presentation is not supported."
> That is not data channel specific, is it? I assume it is already part of T.140, so we shall not specify new MUST requirements.
>
> With that, I suggest to not change the title.
[GH] Right, but it is an important reminder for interoperability between 
implementations. So, make it a NOTE instead and change the MUST to 
something suitable (needs to ?).
>> 13. In 6. Gateway considerations:
>> At the end of bullet point 4 add "in reception"
> I think "was lost in reception" sounds strange.  What about "was lost due to the data channel failure"?
[GH] I wanted to point out in what direction it was lost. In T.140 data 
channels, the sender has in fact better opportunity than the receiver to 
detect if something was lost. Bullet point 4 was intended to tell about 
data received on the T.140 data channel to be sent on the RTP stream. I 
want to insert a new bullet point (see 14) for when the gateway detects 
loss in sending in the T.140 data channel. Therefore it should be clear 
that bullet point 4 is for the reception case. What about "was lost when 
receiving from the T.140 data channel due to the data channel failure" ?
>
>> 14. In 6. Gateway considerations:
>> After bullet point 4, add one more bullet point:
>> "If the gateway detects that the T.140 data channel has failed and got torn down, once the data channel has been reestablished the
>> gateway SHOULD insert the T.140 missing text marker [T140ad1] in the data sent on the outgoing T.140 data channel if it detects or
>> suspects that data sent or to be sent on the T.140 data channel was lost during the failure. Data that may have been correctly
>> transmitted and received MUST not be repeated."
> I don't think we need the last sentence, because it is confusing. It is enough to say that the procedure is done if the gateway detects or suspects that data was lost.
[GH] Accepted
>
>> 15. In 6. Gateway considerations:
>> In the last bullet point, change MUST to SHOULD, because we say above that some implementations may not support
>> the direction attributes.
> We define the procedures for implementations that are compliant with the spec, and for such implementations it is a MUST.
>
> We can have text about implementations that don't support the procedures (as we have in section 4.2.3.1.1., when the answerer does not support the direction attributes), and how it impacts things, but we shall not modify the normative procedures because of that.
[GH]Accepted. The language you ask for is kind of already there, so I do 
not require anything more here.
>   
>
>> 16. In 7 Update to RFC 8373
>> Reference for RFC 8373 is missing
> Will fix.
>
>> 17. In 11.2 Informational references:
>> Add reference to RFC 3550 as indicated in point 3 above.
> Will fix.
>
>> I intend to provide these comments also as change proposals in GitHub.
> Ok.
>
> Regards,
>
> Christer

Regards

Gunnar

>
>
>
>
>
>
>
> Den 2019-10-02 kl. 15:25, skrev Bo Burman:
> Greetings MMUSIC ,
>
> This is to announce a 2 week WGLC on the draft:
>
>      https://protect2.fireeye.com/url?k=806502d9-dcecd8e4-80654242-0cc47ad93c0c-e10d1004cdda139e&q=1&u=https://www.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-06.txt
>
> as Proposed Standard. Please review and provide any comments you may have on the document by Wednesday, October 16, 2019. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.
>
> Thanks,
>
> /Bo
> (MMUSIC co-chair)
>   
>
>
> _______________________________________________
> mmusic mailing list
> mailto:mmusic@ietf.org
> https://protect2.fireeye.com/url?k=a6662b9d-faeff1a0-a6666b06-0cc47ad93c0c-f61b6b0757d55756&q=1&u=https://www.ietf.org/mailman/listinfo/mmusic
>
-- 

+ + + + + + + + + + + + + +

Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288