Subject: Re: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 (editorials)

From: Bo Burman <[email-masked]>
Date: Tue, 5 May 2015 16:09:56 +0000

Hi,

Please find my responses to your editorial comments inline below, starting a new thread to leave substantive comments in the original thread.
 
Cheers,
Bo

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: den 3 maj 2015 17:55
> To: [email-masked]; [email-masked]
> Subject: AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06
> 
> Hi,
> 
> Here's my AD Evaluation of draft-ietf-avtext-rtp-grouping-taxonomy-06.
> Nothing here is sufficient to delay the IETF last call, but I'd like to at least see a response to the subtsantive comments.
> 
> Thanks!
> 
> Ben.
> 
> ----------------
> 
> Substantive Comments:
> 
> -- I do not object to this being informational per se, but I wonder if people expect it to be normatively references by
> future standards track documents. Remember that a reference should be normative if it is needed to understand the
> dependent document. Terminology references often fall squarely into that category. If the answer is yes, has there been
> any considerations that this draft may need to be standards track?
> 
> -- Along the same lines, all the references informational. Could a reader be expected to understand this draft without
> reading _any_ of the references? I recognize this may not be important for an informational draft that is not a technical
> specification. But it may be more important if standards track docs normatively reference this doc.
> 
> 
> Nits and Editorial Comments:
> 
> -- Abstract: "... attempts to define..."
> 
> Is there a concern that it may not have succeeded?  :-)
[BoB] No :) I expect this text to be a remnant from early draft stages. Will re-formulate. Good catch.

> 
> -- Section 1, 1st sentence:
> 
> Do you think RTP terminology will continue to be confusing and inconsistent after this draft is published?
[BoB] No. Probably same reason as above. Will find a better formulation.

 Also, please
> expand RTP in the first use in the body. (In addition to the abstract.)
[BoB] OK. I also think it appropriate to add a reference to RFC 3550 here.

> 
> -- 2.1.2:
> 
> Do you consider the meaning of the term "Media" to be clear enough that it doesn't need a definition here?
[BoB] The very first sentence of 2.1 starts with "In the context of this memo, Media is...". Is that not sufficient? I think that is sufficiently clear.

> 
> I find it hard to parse the following sentence:
> 
> "This data is due to its periodical sampling, or at least being timed asynchronous events, some form of a stream of media
> data. "
[BoB] Maybe re-arranging the sentence makes it more clear: "This data is some form of stream of media data, due to its periodical sampling or as a set of timed asynchronous events"?

> 
> -- 2.1.2, 2nd bullet list entry:
> 
> s/support/supports
[BoB] OK

> 
> -- 2.1.4, first sentence
> 
> I find the sentence hard to parse:
[BoB] What about re-arranging it : "A Media Source is the logical source of a time progressing, digital media stream called a Source Stream, synchronized to a reference clock"?

> 
> -- 2.1.5
> 
> Was the "raw stream" not also time-progressing?
[BoB] Yes, but only implicitly as "in general changing over time", since there is no explicit time information connected to the raw stream.

> 
> -- 2.1.9, first bullet list entry:
> 
> I can't parse the sentence. Is there a missing word towards the end?
[BoB] Suggest re-formulating to "The Media Packetizer selects which Synchronization source(s) (SSRC) and RTP Sessions to use"

> 
> -- 2.1.18 "... alarm subsequent transformations ... "
> 
> Do you mean "alert"?
[BoB] Yes.

> 
> -- 2.2.3, first bullet list entry:
> 
> is the SIP URI example assumed to be an Address of Record? If so, it might be worth mentioning that, since a SIP URI
> could also point to a device, and a participant might have more than one.
[BoB] While the URI _can_ be an AOR, I think that Participant can just as well be identified by a specific device URI and still fulfil the other listed characteristics of a Participant. Therefore, and unless you have other concerns with this, I'd like to keep the URI "unspecific". A single AOR could be used to reach one out of potentially many Participants, but only one Participant would actually end up being the target of such addressing, even if it is reached through one or more indirections. If multiple "entities" actually answer to the addressing and are all included into the conference, I'd prefer to define them as a "distributed Participant" consisting of multiple Endpoints belonging to the same address.

> 
> -- 3.7, last paragraph, 2nd sentence:
> 
> Sentence is convoluted and hard to read. Please consider splitting it into multiple simpler sentences.
[BoB] What about simplifying it slightly to " When using different RTP Sessions (MRMT), a single RTP Stream per Media Encoder, and a single Media Source in each RTP Session, common SSRC and CNAMEs can be used to identify the common Media Source"? The removed text (that different RTP Sessions imply different Media Transports) should already be clear from other text in the draft.

> 
> -- 3.8, first paragraph, 2nd sentence:
> 
> Convoluted sentence.
[BoB] OK. Will split.

> -- 3.9, last paragraph:
> Convoluted sentence.
[BoB] OK. Will split.

> 
> -- 3.10, last paragaph, last sentence:
> 
> Convoluted sentence.
[BoB] OK, will re-formulate.

> 
> -- 3.11, last paragraph : "This requires to either use..."
> 
> Missing noun?  ("This requires XXX to use either", or "This requires the use of either...")
[BoB] The latter. Will change.

> 
> 3.13, first paragraph, last sentence:
> 
> I can’t parse the sentence—is there a word missing? (i.e. “… and smaller number of flow based…”)?
> 
[BoB] I think you found an appropriate missing word. Thanks.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 12 May 2015 15:40:34 -0500

Hi, more comments inline. I will delete sections that do not seem to 
need further discussion.

On 5 May 2015, at 11:09, Bo Burman wrote:

[...]

> [BoB] The very first sentence of 2.1 starts with "In the context of 
> this memo, Media is...". Is that not sufficient? I think that is 
> sufficiently clear.
>

Oops, I forgot that was there by the time I got to 2.1.2. It's fine like 
it is.

>> "This data is due to its periodical sampling, or at least being timed 
>> asynchronous events, some form of a stream of media
>> data. "
> [BoB] Maybe re-arranging the sentence makes it more clear: "This data 
> is some form of stream of media data, due to its periodical sampling 
> or as a set of timed asynchronous events"?

I'm still not following it. Do you mean something to the effect of "This 
stream is considered 'Media', because it includes data that is 
periodically sampled, or made up of a set of timed asynchronous 
events."?

[...]

> [BoB] What about re-arranging it : "A Media Source is the logical 
> source of a time progressing, digital media stream called a Source 
> Stream, synchronized to a reference clock"?

The ordering of the clauses is still confusing. How about"

"A Media Source is the logical source of a time progressing digital 
media stream synchronized to a reference clock. This stream is called a 
"Source Stream".

> [BoB] Yes, but only implicitly as "in general changing over time", 
> since there is no explicit time information connected to the raw 
> stream.

I read "time-progressing" to mean exactly "changing over time". The rest 
of the sentence talks about clock-synchronization, so maybe the term 
"time-progressing" could be dropped?

> [BoB] Suggest re-formulating to "The Media Packetizer selects which 
> Synchronization source(s) (SSRC) and RTP Sessions to use"

That's better, thanks.
[...]

>> is the SIP URI example assumed to be an Address of Record? If so, it 
>> might be worth mentioning that, since a SIP URI
> [BoB] While the URI _can_ be an AOR, I think that Participant can just 
> as well be identified by a specific device URI and still fulfil the 
> other listed characteristics of a Participant. Therefore, and unless 
> you have other concerns with this, I'd like to keep the URI 
> "unspecific". A single AOR could be used to reach one out of 
> potentially many Participants, but only one Participant would actually 
> end up being the target of such addressing, even if it is reached 
> through one or more indirections. If multiple "entities" actually 
> answer to the addressing and are all included into the conference, I'd 
> prefer to define them as a "distributed Participant" consisting of 
> multiple Endpoints belonging to the same address.

If I have a human with more than one device, is the participant the 
human, or a device? If the answer is "the human", then only an AoR would 
seem to support the property of "reachable by a single address". Or does 
"reachable by a single address" mean you _can_ reach the participant 
with a single address (and no more information), not that the 
participant is _only_ reachable by a single address?

> [BoB] What about simplifying it slightly to " When using different RTP 
> Sessions (MRMT), a single RTP Stream per Media Encoder, and a single 
> Media Source in each RTP Session, common SSRC and CNAMEs can be used 
> to identify the common Media Source"? The removed text (that different 
> RTP Sessions imply different Media Transports) should already be clear 
> from other text in the draft.

That helps, thanks.

[...]

---

From: Bo Burman <[email-masked]>
Date: Wed, 13 May 2015 13:37:15 +0000

Hi, my responses inline.
Cheers,
Bo

> Sent: den 12 maj 2015 22:41
> To: Bo Burman
> Cc: [email-masked]; [email-masked]
> Subject: Re: AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06 (editorials)
> 
> Hi, more comments inline. I will delete sections that do not seem to need further discussion.
> 
> Oops, I forgot that was there by the time I got to 2.1.2. It's fine like it is.
[BoB] OK

> >> asynchronous events, some form of a stream of media data. "
> I'm still not following it. Do you mean something to the effect of "This stream is considered 'Media', because it includes
> data that is periodically sampled, or made up of a set of timed asynchronous events."?
[BoB] Yes. I'll happily adopt that formulation if it is more clear.

> "A Media Source is the logical source of a time progressing digital media stream synchronized to a reference clock. This
> stream is called a "Source Stream".
[BoB] Good!

> "time-progressing" could be dropped?
[BoB] I have no problem with that.

> participant is _only_ reachable by a single address?
[BoB] For the scope of "Participant", I mean that you _can_ reach the participant with a single _signaling_ address (and no more information). I say "signaling" here, because a single signaling address could encompass several other addresses in another address space, like different media IP addresses and ports.

Quoting the bullet text in the draft, for reference:
"A single signaling-addressable entity, using an application-specific signaling address space, for example a SIP URI."

A human user could possess several different devices that he or she could potentially use to participate in a "Conference". I however expect a single instance of actual participation to include a choice of which device to use that particular time. While the chosen device can be addressed by an AOR, it can very likely also be addressed by the device-specific address.

The participant is _defined_ to be a _single_ entity in the signaling address space by that bullet text, such that if you would have to use several different addresses, they would represent different participants. There's an intentional fuzziness here, both because it becomes problematic to make a very precise definition, and I also don't think it has to be better defined to be able to constructively use the term "participant".

Let me try to provide an example; assume a human user being addressed by a single AOR and choosing to answer a single call at _several different_ devices. Are those devices (all representing a single human user, and AOR) to be considered a single or multiple participants in the conference? It should be clear that each device can in turn make use of several media (non-signaling) addresses, and I expect that each device is also (in addition to the AOR) addressable by a device-specific signaling address (connected to the AOR). If the "application" only deals with AOR addresses, all of the devices are (with the definition above) part of the same participant. If the "application" instead deals with SIP URIs, each device is a participant in the conference (with that same definition), and the fact that they all convey media to and from the same human user is a secondary aspect. Any devices belonging to that same AOR, but that are not connected to the conference are of course not participants in it.

I think that the existing text is still correct, although I admit that it might be a bit minimalistic. What clarifications do you think we need to add to properly reflect what I said above, without being that verbose? I welcome your text proposals!