Re: [Gen-art] Genart last call review of draft-ietf-avtcore-multiplex-guidelines-08

Magnus Westerlund <> Thu, 18 April 2019 08:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75F4612024F; Thu, 18 Apr 2019 01:07:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aPsM82ZOnE81; Thu, 18 Apr 2019 01:07:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9071D120311; Thu, 18 Apr 2019 01:07:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=879iUiOqvHHG/KHTIjF/pjBX80rv0a+QAcKw86B+2ys=; b=fopDrTLaevqlG4lNpXnS9Uk6XIhPcMwFpAIjD/wmI3o2Fc8QOcoSsVDRY5JgSp99+YoagfXWTz93vThJ4Ph6qD8iVQ2zb8Fl20K13AA9uxYm7ODhQT3Vhk7oJux+MWj5MHoSR7nKoXQ1LAAGSe/42H95uNS6O32+2/W97DGDgkA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.9; Thu, 18 Apr 2019 08:06:57 +0000
Received: from ([fe80::b161:fb77:e4ea:4723]) by ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1813.009; Thu, 18 Apr 2019 08:06:57 +0000
From: Magnus Westerlund <>
To: Vijay Gurbani <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: Genart last call review of draft-ietf-avtcore-multiplex-guidelines-08
Thread-Index: AQHU85zMpYD8bRn2cUeCw7CxAd4Abw==
Date: Thu, 18 Apr 2019 08:06:57 +0000
Message-ID: <>
References: <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 225ed5c0-b05f-4aa2-6a1c-08d6c3d4d40f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2473;
x-ms-traffictypediagnostic: HE1PR0701MB2473:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0011612A55
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(366004)(346002)(39860400002)(396003)(51914003)(51444003)(189003)(199004)(8676002)(25786009)(7696005)(74316002)(6506007)(6116002)(26005)(256004)(76176011)(186003)(305945005)(5024004)(14444005)(102836004)(486006)(2501003)(446003)(71190400001)(7736002)(476003)(6436002)(44832011)(99286004)(2906002)(71200400001)(110136005)(478600001)(229853002)(52536014)(53936002)(81156014)(5660300002)(53546011)(9686003)(97736004)(6306002)(966005)(68736007)(55016002)(66066001)(14454004)(81166006)(316002)(33656002)(54906003)(8936002)(4326008)(3846002)(6246003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2473;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: GPzqLVDWhW0Xt6o2yEuPS7q56Q54B/o8h9qdVQ5Xo1MDoKJJcmvjEkoa4jecG6hRt9ioiPKzcJDZNeNdLsccWNwUvLGX46R+rJq7XXqcH1o9kR68qKqlfQL7dQTw6erYcp3Ba0yu3vgs2iKQWZO3MFSo1XHxjydrQRnIPb3zCcHGQyBDAshmpa7glQpctC484UpPi+3jDgu58POuhSU2KScwUqXPSqgG/aFv9Ms6exubjs1IQmGlkDIB8rNJlZ1KBF/dPorWbU7I+6puzTzjq6A93lbmrse9RaxV2fRgFnbY09uR7G2WBXMUMRW39K0lo9wMMbB6Q8WwNQLTkAULq5zcY6zVxr+5glMqu2b3qYdEgeYronGqqtDLrlYSbVy4cW/LBOr5SROPXJsx74iJreV4eeBiM2eANjIpE1QCUMo=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 225ed5c0-b05f-4aa2-6a1c-08d6c3d4d40f
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2019 08:06:57.5835 (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-Transport-CrossTenantHeadersStamped: HE1PR0701MB2473
Archived-At: <>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-avtcore-multiplex-guidelines-08
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Apr 2019 08:07:06 -0000

Hi Vijay,

Thanks for the review.

On 2019-04-15 17:06, Vijay Gurbani via Datatracker wrote:
> Reviewer: Vijay Gurbani
> Review result: Ready with Issues
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-avtcore-multiplex-guidelines-??
> Reviewer: Vijay K. Gurbani
> Review Date: 2019-04-15
> IETF LC End Date: 2019-04-10
> IESG Telechat date: Not scheduled for a telechat
> Summary: Ready for informational with some minor issues that should be looked at, and some nits.
> Major issues: 0
> Minor issues: 3
> Nits/editorial comments: various
> - Minor:
> - S3.2.1, third paragraph: Here, is the assumption that the "single endpoint"
>   has multiple network attachments, each with its own IP address?  If so,
>   perhaps it is better to say so.  The text talks about multiple UDP flows being
>   identified by their UDP source port and destination IP address, however, if
>   the "single endpoint" has only one network attachment, isn't the port number
>   enough to identify the flows?  I know it can get arbitrarily complex if
>   multiple IP addresses are bound to the single network attachment point, etc.,
>   however, the intent of this document is to reduce ambiguity around RTP
>   multiplexing, so it is best that it lays out its assumptions in detail so as
>   to not add to the noise.

It is intended to generalize it so that it works in cases it has
multiple IP addresses. However, the main point is that traffic related
to one RTP session can flow across multiple UDP flows, independent if
there are one or more IP addresses involved.

I guess that last clarification could be added in a new sentence before
the one that starts with "Another example ...".

> - S3.2.4, first paragraph: We should not use the term "whatever" in a standards
>   document.  My suggestion would be to rewrite the offending sentences(s) as
>   follows:
>   OLD:
>   The term "format" here includes whatever can be described by out-of-band
>   signalling means.  In SDP, the term "format" includes media type, RTP
>   timestamp sampling rate, codec, codec configuration, payload format
>   configurations, and various robustness mechanisms such as redundant encodings
>   [RFC2198]. 
>   NEW:
>   The term "format" here includes any artifacts described by out-of-band
>   signalling means; in SDP, the term "format" includes media type, RTP
>   timestamp sampling rate, codec, codec configuration, payload format
>   configurations, and various robustness mechanisms such as redundant encodings
>   [RFC2198]. 

I agree that whatever is not the best term. However, I think artifact is
the wrong term. Looking for example at Merriam Webster's definition it
sounds wrong:


  The term "format" here includes those aspects described by out-of-band
  signalling means; in SDP, the term "format" includes media type, RTP
  timestamp sampling rate, codec, codec configuration, payload format
  configurations, and various robustness mechanisms such as redundant encodings

> - S4.1.1, first and second paragraphs: There is an overuse of "one" or "ones" in
>   this paragraph.  In different context, "one" may refer to a person or it may
>   refer to a way of enumerating or counting some things.  It is not clear what
>   is being referred to here by using "one".  For example, "where one want to
>   interconnect", here is it the one referring to one of the many applications?
>   Or is it referring to a user?

See your point. In some cases it is the user or a system designer.

The below nits we will go through and update the document.

> - Nits:
> - S1: s/implications that come from/implications arising from/
> - S1: I am not sure why it is worth highlighting that "The document will
>   highlight against as some usages being unsuitable, ..."  If it is worth
>   stating this, then perhaps it is also worth stating that the document will
>   also highlight usages that are suitable.  If on the other hand, the existing
>   text in the document is a warning to implementors who are using RTP in a way
>   not intended, then perhaps best to say that "The document will highlight
>   against some prevalent usages of RTP multiplexing as unsuitable, ..."
> - S2.2, second sentence: Perhaps best to include references for SIP and Jingle.
> - S3.1: Please expand FEC (Forward Error Correction) on first use.
> - S3.2.1: s/yet, RTP sessions must be possible to separate both across /yet, RTP
>   sessions must be separable across/
> - S3.2.1: s/media descriptions, for example used/media descriptions, for
>   example, to be used/
>   OR
>   s/media descriptions, for example used/media descriptions to be used/
> - S3.2.2, end of page 9: s/(and should not)/(and, indeed, should not)/
>   (Highlight that the existing usage is wrong).
> - S3.2.2, top of page 10: s/SSRC, so the new SSRC/SSRC, making the new SSRC/
> - S3.2.4, page 11: "at any time instant" ==> Do you mean "at any time instance"?
>   If so, there are a couple of occurrences of "time instant" in that paragraph
>   that should be changed.
> - S3.3, page 12: "If the stream transport ... or media adaptation."  This sounds
>   like a warning, if so, I would preface the sentence as follows: "Beware that
>   changing the stream transport characteristics..."  You will have to reword the
>   rest of the sentence appropriately.
> - S3.3, last paragraph: Is what is described in that paragraph okay?  Nothing
>   bad will happen, right?  The intent of this document is to reduce ambiguities
>   in RTP multiplexing, so if this paragraph does not result in an undesirable
>   outcome, then perhaps it makes sense to say so.  In its current form, the
>   paragraph is asserting a statement without providing any hints on whether or
>   not the statement is accurate.
> - S3.4.1, page 14: "As we saw in the discussion of RTP mixers, ..." => Perhaps
>   provide a reference to the RTP mixing section; I tried to find it, but was not
>   sure which section is being referenced here.
> - S3.4.1, page 14: s/we will discuss more below/we will discuss below/
> - S3.4.3: s/or resource consuming/or a drain on resources/
> - S3.4.4: s/see very heterogeneous/see heterogeneous/
> - S4.1.2: s/even if no participants/even if none of the participants/
> - S4.2.2, page 22: "... as some stack implementations." => Which "stack"?  RTP
>   stack or some other stack.  Please specify.
> - S4.3.1, first paragraph: The sentence, "At least unless ... achieve source
>   authentication." appears to be a fragment not tied to any of the succeeding or
>   preceding sentences.  Perhaps you may want to reword it, or make it part of
>   the neighbouring sentences.
> - S5.1 to S5.4: My advice would be to s/The Pros:/The advantages:/ and s/The
>   Cons:/The disadvantages:/
>   (Reason: Pros and Cons are more colloquial usage of the terms, in a standard
>   document it is better, at least in my opinion, to be more formal.)
> - S5.1: - s/that uses individual/that use individual/
>         - s/the RTP streams'/the RTP stream's/
> - S6, page 32: delete the extra line after "Use additional RTP sessions for
>   streams with different requirements:"
> - Appendix A: s/for most things/for most issues/
> - Appendix A: s/If one attempts to use Payload type multiplexing beyond its
>   defined usage, that has well known negative effects on RTP./Attempting to use
>   Payload type multiplexing beyond its defined usage has well known negative
>   effects on RTP./
>   (You may want to provide a reference to where such "well known negative
>   effects on RTP" are documented.)
> - Appendix B: s/it is hugely important/it is extremely important/
>   (Reason: "hugely" is a colloquial term.)
> - Appendix B, second paragraph: I think that this paragraph is important since
> it is asking WGs to do something specific at some time, and it is documenting
> the current behaviour that the WG should change.  As such, I would advise that
> the gravity of this be provided accordingly.  The suggested paragraph below can
> replace the existing paragraph (subject to your editorial discretion, of
> course):
>   We document salient issues here that need to be addressed by the WGs
>   that use some form of signaling to establish RTP sessions.  These
>   issues cannot simply be addressed by tweaking, extending, or profiling
>   RTP, but require a dedicated and indepth look at the signaling
>   primitives that set up the RTP sessions.
> - Appendix B.1:
>   - s/focused around/focused on/
>   - s/potentially useful to signal not only on/potentially useful beyond/


Magnus Westerlund 

Network Architecture & Protocols, Ericsson Research
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: