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

Magnus Westerlund <> Wed, 24 April 2019 12:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE5F312006E; Wed, 24 Apr 2019 05:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 OmVjRut2klXR; Wed, 24 Apr 2019 05:33:07 -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 A4619120045; Wed, 24 Apr 2019 05:33:06 -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=IQDklVFxFFPYIiYzQNUkDVGyikI28H7+DTLbofIw6aY=; b=SlOdof0GKf1u4pkBi+FHG9JT23QGT8fc4LRC43aK4rjKzGMs9pHAcvHGMvXVUykic9qX6VsUhOEOzhhuodidKGjWeIc0f4PjrmrEekQRljkYR3AhPfzGCDYPSWiSDKDQJZ1hPDi7vbIROceK+Ihe5Qsf6HMV5QTlRFxkBQ8Fg8M=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.11; Wed, 24 Apr 2019 12:33:03 +0000
Received: from ([fe80::b161:fb77:e4ea:4723]) by ([fe80::b161:fb77:e4ea:4723%3]) with mapi id 15.20.1856.004; Wed, 24 Apr 2019 12:33:03 +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: Wed, 24 Apr 2019 12:33:03 +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: 1b91bf82-b581-43f5-b206-08d6c8b0feb5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600141)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:HE1PR0701MB2955;
x-ms-traffictypediagnostic: HE1PR0701MB2955:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 00179089FD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(136003)(39860400002)(396003)(376002)(51744003)(189003)(199004)(256004)(68736007)(6116002)(3846002)(53936002)(55016002)(76176011)(7696005)(5024004)(7736002)(316002)(14444005)(74316002)(73956011)(91956017)(71200400001)(66476007)(66946007)(76116006)(66446008)(64756008)(14454004)(66556008)(71190400001)(66066001)(8676002)(8936002)(99286004)(54906003)(81156014)(81166006)(186003)(53546011)(6506007)(606006)(5660300002)(229853002)(486006)(446003)(6436002)(44832011)(33656002)(4326008)(6916009)(476003)(86362001)(6306002)(6246003)(478600001)(966005)(9686003)(54896002)(236005)(102836004)(26005)(52536014)(97736004)(25786009)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2955;; 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: m/u4068UXd2iwhhAtIlTcq2ykLKQT+yumOzmz/yV3juA8BGhsmQe/AGiSeSFFSe0LgvuvLBVGIYteK/1n5J7a9chITopz9cFCxPNmhJzN3s3v7+y7aY37NOUvo7jxRo4fn0pGvk5cO1UAjcLqblRO9Ko2IOH9qcNrL6C84ukHXF4Ef9/w5yegr0PaLGH3nbODv5ymQfJpN7Efitg1UDO6lQnHb5cJEDPSitBSaDXn+q/7eXnEgf49KgDGCTOCFP/c4FCjtqsU9kRhoI0F3gUGkG7DuoS5uKXPcw64JoymZ7XAstR7+mWLQrkU0bjZj81KxNTpZq4AvwxzInT0H+ithkS24N7XPC/It7PKLI6azPCmrxXIfBhfleouY2uPX+py52SSihKKUkMbX5rPLvADTH/jH0NlBpX/pIxA2/fsKg=
Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB25224217CCDB07858F009223953C0HE1PR0701MB2522_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1b91bf82-b581-43f5-b206-08d6c8b0feb5
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 12:33:03.1232 (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: HE1PR0701MB2955
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: Wed, 24 Apr 2019 12:33:11 -0000


Good, I will implement the changes.



On 2019-04-19 16:19, Vijay Gurbani wrote:
Magnus: Thank you for your time looking at my review.

More inline; I will cut the extraneous text below and retain the text that provides context.

On Thu, Apr 18, 2019 at 3:07 AM Magnus Westerlund <<>> wrote:

> - 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 ...".

Sounds good.

>   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

I will leave it to your sound editorial judgement above. Personally, I think artifact is fine as it denotes a by product of a particular human endeavour (multimedia protocol design).  But I am fine with "aspects" as well, as you suggest.  Certainly, both these choices are better than the original wording.

> - 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.

Great, thanks.

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

Sounds good.  Thanks again for your time.


- vijay


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:<>