Re: [AVTCORE] Genart last call review of draft-ietf-avtcore-multiplex-guidelines-08
Vijay Gurbani <vijay.gurbani@gmail.com> Fri, 19 April 2019 14:19 UTC
Return-Path: <vijay.gurbani@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EA812015C; Fri, 19 Apr 2019 07:19:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 geHaI6RcUscO; Fri, 19 Apr 2019 07:19:39 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C9E120108; Fri, 19 Apr 2019 07:19:39 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id i13so4515175edf.11; Fri, 19 Apr 2019 07:19:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W37FLdqQfvtQg/2iVYxGaBjBkOfK7fIz97ooC5YU0T8=; b=kS2+qD5JvXIqPK5FtmflZeL2HSGA40vvLyXB2ZLRJtij4SsDFvBuxHLcxxKmtJKdWv Y1sBxF9j1Et+2fhi7DGaNlwtFUVsJk21jjqcek+H/bgneOg9k5TH9XObG71dtLWmpIBq /8ioDFnNOFsToLGykfCzDTzzsVG8SV1DNLs7AMqaE772tp83LEeRFCPKC+9xvjB9kAbC nSuuukR0c/xXLQj1lWdyslt4JM6o3pbOFHoV4GinpUhtGrK/b0PcEAlh5nZBr07X1KBh ZYSCFrTbceTBVIkOjsZP46N390TZ0D6jGrxRYmsorkm3S08IBl3EsZOnggCtJDeKQuGC OXfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W37FLdqQfvtQg/2iVYxGaBjBkOfK7fIz97ooC5YU0T8=; b=SpKjeRE8+JIIxFd8vxnD0BsPz36jAo5zYkIPH/0ruMfF/iibMngsSwZhz08+JMouSS Y+HFjzVjDQUDoRIbPZAPgyL3BM0i10QwnI/dqeLZeEmoWZ3XVsYNLGZdVONVK0OPokef cgYfQtGs84xz4L3ColT6ibLdXkpzkoKeavPVr/Mk3zkpg44D36fVCAfhAyg3tKvyVBYI jNA3oYAOQWtTeb/kir/wIjjanSa7AwS6A5T2imI2zNQdQC85hN8Z8MXYl6RtyC9ydmKL MKswTSN3Ybdfs0SIdigZzLk2XmUEtZfbiVyaSMl1KsFncHt3c3grsysIn8LjIY/2Ckfd wfDQ==
X-Gm-Message-State: APjAAAWKasx2BesXgaSi8VZkJUELikjqmmRPSbiSoM6fXYvz/+LSOyXg msJ3xpNjz2eUSnfelIwg7koXul3rVaRbej/rXG4=
X-Google-Smtp-Source: APXvYqz6NEclSR9mlXBAmVEXYEkPh0JTXSMI1H5C7IAuXgnSu4gIYuPFWz08hLamzb0ZQqGc7fo9YFWnDCjh4PQeHjY=
X-Received: by 2002:aa7:d755:: with SMTP id a21mr2627257eds.165.1555683577697; Fri, 19 Apr 2019 07:19:37 -0700 (PDT)
MIME-Version: 1.0
References: <155534077715.10819.12652723852940605606@ietfa.amsl.com> <HE1PR0701MB252252B89A8E849A4DB8DD6595260@HE1PR0701MB2522.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0701MB252252B89A8E849A4DB8DD6595260@HE1PR0701MB2522.eurprd07.prod.outlook.com>
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Fri, 19 Apr 2019 09:21:22 -0500
Message-ID: <CAMMTW_LyqsfEzVME2va_WY7DrLU5_SCDOoKe0QwgcnpofN=7yg@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-avtcore-multiplex-guidelines.all@ietf.org" <draft-ietf-avtcore-multiplex-guidelines.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "avt@ietf.org" <avt@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000081d320586e2cf5b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/Qv1URUAVPbJJF48VOyM8CRJCKfU>
Subject: Re: [AVTCORE] Genart last call review of draft-ietf-avtcore-multiplex-guidelines-08
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Apr 2019 14:19:42 -0000
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 < magnus.westerlund@ericsson.com> 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: > > https://www.merriam-webster.com/dictionary/artifact > > maybe > > NEW: > 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 > [RFC2198]. > 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. Cheers, - vijay
- [AVTCORE] Genart last call review of draft-ietf-a… Vijay Gurbani via Datatracker
- Re: [AVTCORE] Genart last call review of draft-ie… Magnus Westerlund
- Re: [AVTCORE] Genart last call review of draft-ie… Vijay Gurbani
- Re: [AVTCORE] Genart last call review of draft-ie… Magnus Westerlund