Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

From: Colin Perkins <[email-masked]>
Date: Tue, 11 Dec 2012 23:26:48 +0100

On 29 Nov 2012, at 13:51, Romascanu, Dan (Dan) wrote:
> This is a Working Group Last Call for http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-jb-02.txt.  
> 
> Please read and review this document, and send your comments, questions and concerns to the WG list before December 13, 2012. If you have no comments and you believe that the document is ready for submission to the IESG as a Standards Track document please send a short message as well to help us in determining the level of review and consensus. 

This looks to be in good shape. One minor comment: why is SHOULD used for the value to report if over-range or unknown values are received, rather than MUST?

Also, one question: there are many reserved values for the jb cfg. Do we need to define how new values are to be registered in an IANA Registry, or is the assumption that this draft is revised if new values are needed?

-- 
Colin Perkins
http://csperkins.org/

---

From: Qin Wu <[email-masked]>
Date: Wed, 12 Dec 2012 15:51:24 +0800

Hi,
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, December 12, 2012 6:26 AM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

> This looks to be in good shape. One minor comment: why is SHOULD used for the value to report if over-range or unknown values are received, rather than MUST?

[Qin]: I believe you are right, we should use MUST instead.

> Also, one question: there are many reserved values for the jb cfg. Do we need to define how new values are to be registered in an IANA Registry, or is the assumption that this draft is revised if n…

[Qin]:I am a little doubt about this. Do you have other values in mind besides the values for fixed jitter buffer method and adaptive jitter buffer method?
Also these values looks to me are just configuration parameters. They usually fixed upon they are set.
> 
> -- 
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Colin Perkins <[email-masked]>
Date: Wed, 12 Dec 2012 17:12:53 +0100

> [Qin]:I am a little doubt about this. Do you have other values in mind besides the values for fixed jitter buffer method and adaptive jitter buffer method?

I don't have any other values in mind, but I noted that this is a large, with few values assigned, so the question of how any future values are to be assigned naturally arises. 

> Also these values looks to me are just configuration parameters. They usually fixed upon they are set.

Sure.

-- 
Colin Perkins
http://csperkins.org/

---

From: Glen Zorn <[email-masked]>
Date: Thu, 13 Dec 2012 15:49:47 +0700

> [Qin]: I believe you are right, we should use MUST instead.

Yes.

>
>> Also, one question: there are many reserved values for the jb cfg. Do we need to define how new values are to be registered in an IANA Registry,

I think so, yes.

>> or is the assumption that this draft is revised if new values are needed?

A very poor idea, IMHO.

> Also these values looks to me are just configuration parameters. They usually fixed upon they are set.

If the meaning of values not defined in this draft is unknown what use 
are they?

...

---

From: Qin Wu <[email-masked]>
Date: Thu, 13 Dec 2012 17:45:38 +0800

> If the meaning of values not defined in this draft is unknown what use 

[Qin]: I think the problem is we don't know how many new values we need to add. The current two values we defined in the draft  
are used to distinct measurement results that are using different jitter buffer method.
If we don't have any new value to be defined, we don't need to resort to IANA Registry,
if we do have many new values that need to be defined, I think IANA Registry is the right approach.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 13 Dec 2012 11:01:24 +0100

On 13 Dec 2012, at 10:45, Qin Wu wrote:
>> If the meaning of values not defined in this draft is unknown what use are they?
> 
> [Qin]: I think the problem is we don't know how many new values we need to add. The current two values we defined in the draft are used to distinct measurement results that are using different jitter buffer method. If we don't have any new value to be defined, we don't need to resort to IANA Registry, if we do have many new values that need to be defined, I think IANA Registry is the right approach.

I disagree. If this is an expected extension point of the protocol, then you need an IANA registry. Otherwise, mark the bits as reserved, and let someone revise the RFC if they need to extend it.

-- 
Colin Perkins
http://csperkins.org/

---

From: Varun Singh <[email-masked]>
Date: Thu, 13 Dec 2012 12:01:22 +0200

> if we do have many new values that need to be defined, I think IANA Registry is the right approach.

[Varun]: IMO the two values are sufficient. One possible solution is
to reduce the "jb cfg" to 1-bit (0:fixed, 1:adaptive), because the
value in "jb cfg" tells the receiving endpoint that the "jitter buffer
maximum delay" is going to remain constant throughout the session or
will vary.

Regards,
Varun

-- 
http://www.netlab.tkk.fi/~varun/

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 Dec 2012 13:24:27 +0000

This document is in good shape, I have a couple of issues that need clarification: 

1. for all delay and water mark fields I see the following: 

>     If the measured value exceeds 0xFFFD, the value 0xFFFE SHOULD be
      reported to indicate an over-range measurement.  If the
      measurement is unavailable, the value 0xFFFF SHOULD be reported.

What are these SHOULD and not MUST? If there are exception cases please explain, if not s/SHOULD/MUST

2. in the jitter buffer maximum delay description the following sentence seems crippled: 

> In adaptive jitter buffer implementations,
      this value may dynamically.  

Something is missing here, please fix. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Romascanu, Dan (Dan)
> Sent: Thursday, November 29, 2012 2:52 PM
> To: [email-masked]
> Subject: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt
> 
> 
> Please read and review this document, and send your comments, questions
> and concerns to the WG list before December 13, 2012. If you have no
> comments and you believe that the document is ready for submission to
> the IESG as a Standards Track document please send a short message as
> well to help us in determining the level of review and consensus.
> 
> Thanks and Regards,
> 
> Dan
> 
> 
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 Dec 2012 13:31:25 +0000

A couple of more editorial issues: 

3. In the Reserved (rsv) bits description - please put the reference RFC6709 in brackets -> [RFC6709]

4. No [RFC2119] keywords are used in this memo, so please drop [RFC2119] from the list of references. 

Thanks and Regards,

Dan

> Sent: Thursday, December 13, 2012 3:24 PM
> To: [email-masked]
> > This is a Working Group Last Call for
> > http://www.ietf.org/id/draft-ietf-
> > xrblock-rtcp-xr-jb-02.txt.
> >
> > Please read and review this document, and send your comments,
> > questions and concerns to the WG list before December 13, 2012. If you
> > have no comments and you believe that the document is ready for
> > submission to the IESG as a Standards Track document please send a
> > short message as well to help us in determining the level of review
> and consensus.
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> >

---

From: Qin Wu <[email-masked]>
Date: Fri, 14 Dec 2012 08:51:45 +0800

----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 13, 2012 6:01 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

> I disagree. If this is an expected extension point of the protocol, then you need an IANA registry. Otherwise, mark the bits as reserved, and let someone revise the RFC if they need to extend it.

[Qin]: Okay, I see your point.

---

From: Qin Wu <[email-masked]>
Date: Fri, 14 Dec 2012 08:53:15 +0800

----- Original Message ----- 
From: "Varun Singh" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Colin Perkins" <[email-masked]>; <[email-masked]>
Sent: Thursday, December 13, 2012 6:01 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

> maximum delay" is going to remain constant throughout the session or

[Qin]: Sound good to me, I think Colin also proposed this as the secondary.

---

From: Qin Wu <[email-masked]>
Date: Fri, 14 Dec 2012 10:32:13 +0800

Hi,
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 13, 2012 9:24 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

> What are these SHOULD and not MUST? If there are exception cases please explain, if not s/SHOULD/MUST

[Qin]: It was brought up by Colin as well. Your point is taken. We will use "MUST".
> Something is missing here, please fix. 

[Qin]: Good catch, accepted. we will add "change" in beween which will be read as:
"this value may change dynamically"

---

From: Qin Wu <[email-masked]>
Date: Fri, 14 Dec 2012 10:38:29 +0800

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 13, 2012 9:31 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

> 3. In the Reserved (rsv) bits description - please put the reference RFC6709 in brackets -> [RFC6709]

[Qin]: Okay.
> 4. No [RFC2119] keywords are used in this memo, so please drop [RFC2119] from the list of references. 

[Qin]: We did use RFC229 keywork like "SHOULD" which will be replaced with "MUST" as you suggested.
Rather than  drop RFC2119,I believe we should add the same"standard language "  section in this memo as we
 did in the other recently published draft .