Re: [Gen-art] 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: gen-art@ietfa.amsl.com
Delivered-To: gen-art@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/gen-art/IE7BiL3Sl02CwtbEP7gPzjuoi4U>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-avtcore-multiplex-guidelines-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-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