Subject: Re: [avtext] AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07 (more pre-LC comments)

From: Bo Burman <[email-masked]>
Date: Fri, 3 Jul 2015 14:25:01 +0000

Hi Ben,

Again, thank you for good comments!

There is already an ongoing thread on partial support configuration that seems to converge, and I recently posted my answers to LC and editorial comments. With this mail, I start yet another thread, dealing with the so far unhandled pre-IETF Last Call issues. I will strip out the issues below that are handled elsewhere. For the rest, please see inline.

I will soon send out a new revision of the draft that includes all updates that I have suggested so far.

Cheers,
Bo

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: den 16 juni 2015 05:19
> To: [email-masked]; [email-masked]
> Subject: AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07
> 
> Hi,
> 
> Here's my AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07. I've broken it down between things I'd like to see
> discussed prior to IETF last call, things I think can be worked in parallel to the last call, and things that are just editorial.
> 
> Thanks!
> 
> Ben.
> 
> *** Things to discuss before IETF Last Call:
> 
> -- Partial Support Configuration
> 

[BoB] <snip> (handled in separate thread; will add clarifying text to describe interoperability of different "config")

> 
> -- "Available PauseID"
> 
> I find the specification of "Available PauseID" to be very confusing.
> Section 8.1 (third paragraph) seems to say that the PauseID in the PAUSE request should be taken from the most
> recently received PAUSED indication. But the next paragraph says the value from PAUSED should be incremented by
> one.
[BoB] I agree that this needs clarification. What PauseID to use in PAUSE is _implicitly_ 'indicated' by most recently PAUSED, but this has to be combined with the fact that "available" PauseID was updated (incremented by one in modulo arithmetic) when the stream was resumed (when entering playing state, which obviously should have happened after last PAUSED was received). If the stream was _not_ resumed after last PAUSED was received, the stream is still paused, and "available" PauseID is the same as in PAUSED. A PAUSE with the same PauseID as in a received PAUSED is superfluous while the stream is still paused and will be ignored (which is described further down in the text).

> 
> I think the confusion comes from two things. First, the name "Available PauseID" is a confusing choice. To me, "available"
> means I can use it.
> But if I understand correctly, I can't use that one for a "new" PAUSE request. Perhaps a better term would be "Current
> PauseID". That would make more sense if I refer to the "current" value to act on a current pause (or most recent)
> condition, and then have the concept of a "next" PauseID which would be the current one plus 1.
[BoB] I think this is a good proposal. I will update the text to consistently use "current" instead of "available". I think "valid" is also used as a synonym in some places, and I will replace that too. In the spirit of that, I think that describing "smaller" and "larger" could be confusing when dealing with PauseID modulo arithmetic, so I suggest to instead use "past" and "future", which I also think is in line with using "current".

> 
> I also think it would help to have one section that describes
> (non-normatively) all the semantics of PauseID early in section 5 (before the concept is first referenced.)
[BoB] Again, I think this is a good idea. I suggest to add that as a new section 5.2. I may then also move some text on PauseID from other sections there. Since text in 5.x is explicitly non-normative, I also suggest to gather some normative statements on PauseID ahead of 8.1, describing it before the rest of the message details.

> 
> -- 2.2: Are the definitions in the RTP Taxonomy document necessary to understand/implement this draft? If so, this
> should be a normative reference, which we would need to call out in the last call. (I'm not saying they are required to
> understand this one--I'm not sure one way or
> another.)
[BoB] I would not say that RTP Taxonomy is necessary. RFC3550 (which is a normative reference) concepts should be sufficient, understanding what an RTP stream is, that there is one sender of it and potentially multiple receivers. Understanding RTP Taxonomy could of course help, especially if the implementer has some particular "media stream layout" in mind, but as said, I don't think it is necessary.

> 
> -- 5.3, 3rd paragraph:
> 
> Does this mean the stream receiver may see a PAUSED indication prior to the stream actually being paused? (That is, see
> a paused indication, but continue to receive the stream?) I don't think that's the intent, but seeing this after the
> paragraphs on the PAUSED indication makes me wonder.
[BoB] No, that is not the intent. PAUSED is only sent when the stream is actually paused, when no more RTP packets are sent. What are the PAUSED paragraphs that make you wonder? If they make you wonder, it suggests the text should be improved.

> 
> *** Things that can be treated as part of IETF Last Call:
> 
[BoB] <snip> (handled in separate thread)

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 30 Jul 2015 10:45:05 -0500

Hi Bo,

I apologize for the slow response. Somehow I managed to miss your 
message until during the IETF week, and then it got caught in the crazy.

I've done a brief scan of version 08. I plan to follow up with a more 
detailed read, and may or may not have additional comments. But in any 
case, I don't see a reason to further delay the IETF last call. I will 
invoke it shortly.

Thanks!

Ben.

On 3 Jul 2015, at 9:25, Bo Burman wrote:

> There is already an ongoing thread on partial support configuration 
> that seems to converge, and I recently posted my answers to LC and 
> editorial comments. With this mail, I start yet another thread, 
> dealing with the so far unhandled pre-IETF Last Call issues. I will 
> strip out the issues below that are handled elsewhere. For the rest, 
> please see inline.
>
>> Here's my AD Evaluation of draft-ietf-avtext-rtp-stream-pause-07. 
>> I've broken it down between things I'd like to see
>> discussed prior to IETF last call, things I think can be worked in 
>> parallel to the last call, and things that are just editorial.
>>
>> Thanks!
>>
>> Ben.
>>
> [BoB] <snip> (handled in separate thread; will add clarifying text to 
> describe interoperability of different "config")
>
>>
>> -- "Available PauseID"
>>
>> Section 8.1 (third paragraph) seems to say that the PauseID in the 
>> PAUSE request should be taken from the most
>> recently received PAUSED indication. But the next paragraph says the 
>> value from PAUSED should be incremented by
>> one.
> [BoB] I agree that this needs clarification. What PauseID to use in 
> PAUSE is _implicitly_ 'indicated' by most recently PAUSED, but this 
> has to be combined with the fact that "available" PauseID was updated 
> (incremented by one in modulo arithmetic) when the stream was resumed 
> (when entering playing state, which obviously should have happened 
> after last PAUSED was received). If the stream was _not_ resumed after 
> last PAUSED was received, the stream is still paused, and "available" 
> PauseID is the same as in PAUSED. A PAUSE with the same PauseID as in 
> a received PAUSED is superfluous while the stream is still paused and 
> will be ignored (which is described further down in the text).
>
>>
>> I think the confusion comes from two things. First, the name 
>> "Available PauseID" is a confusing choice. To me, "available"
>> means I can use it.
>> But if I understand correctly, I can't use that one for a "new" PAUSE 
>> request. Perhaps a better term would be "Current
>> PauseID". That would make more sense if I refer to the "current" 
>> value to act on a current pause (or most recent)
> [BoB] I think this is a good proposal. I will update the text to 
> consistently use "current" instead of "available". I think "valid" is 
> also used as a synonym in some places, and I will replace that too. In 
> the spirit of that, I think that describing "smaller" and "larger" 
> could be confusing when dealing with PauseID modulo arithmetic, so I 
> suggest to instead use "past" and "future", which I also think is in 
> line with using "current".
>
>>
>> (non-normatively) all the semantics of PauseID early in section 5 
>> (before the concept is first referenced.)
> [BoB] Again, I think this is a good idea. I suggest to add that as a 
> new section 5.2. I may then also move some text on PauseID from other 
> sections there. Since text in 5.x is explicitly non-normative, I also 
> suggest to gather some normative statements on PauseID ahead of 8.1, 
> describing it before the rest of the message details.
>
>>
>> -- 2.2: Are the definitions in the RTP Taxonomy document necessary to 
>> understand/implement this draft? If so, this
>> should be a normative reference, which we would need to call out in 
>> the last call. (I'm not saying they are required to
> [BoB] I would not say that RTP Taxonomy is necessary. RFC3550 (which 
> is a normative reference) concepts should be sufficient, understanding 
> what an RTP stream is, that there is one sender of it and potentially 
> multiple receivers. Understanding RTP Taxonomy could of course help, 
> especially if the implementer has some particular "media stream 
> layout" in mind, but as said, I don't think it is necessary.
>
>>
>> -- 5.3, 3rd paragraph:
>>
>> Does this mean the stream receiver may see a PAUSED indication prior 
>> to the stream actually being paused? (That is, see
>> a paused indication, but continue to receive the stream?) I don't 
>> think that's the intent, but seeing this after the
> [BoB] No, that is not the intent. PAUSED is only sent when the stream 
> is actually paused, when no more RTP packets are sent. What are the 
> PAUSED paragraphs that make you wonder? If they make you wonder, it 
> suggests the text should be improved.
>
>>