Re: Genart last call review of draft-ietf-avtcore-multiplex-guidelines-08

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Good, I will implement the changes.

Cheers

Magnus

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 <magnus.westerlund@xxxxxxxxxxxx> 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


-- 

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: magnus.westerlund@xxxxxxxxxxxx
----------------------------------------------------------------------

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux