Subject: [Gen-art] A *new* batch of IETF LC reviews - 2013-11-08

From: "A. Jean Mahoney" <[email-masked]>
Date: Fri, 08 Nov 2013 09:32:39 -0800

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Brian Carpenter   2013-12-01   draft-moonesamy-ietf-conduct-3184bis-03

Christer Holmberg 2013-11-26   draft-ietf-cdni-requirements-12

Dan Romascanu     2013-11-19   draft-ietf-soc-load-control-event-package-10

David Black       2013-12-06   draft-bundesbank-eurosystem-namespace-02

Peter Yee *       2013-11-18   draft-ietf-geopriv-res-gw-lis-discovery-07

* 2nd LC

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Nov 2013 07:06:47 -0500

Document: draft-ietf-xrblock-rtcp-xr-qoe-12
     RTP Control Protocol (RTCP) Extended Report (XR) Blocks for
                        MOS Metric Reporting
Reviewer: Joel M. Halpern
Review Date: 12-November-2013
IETF LC End Date: 27-November-2013
IESG Telechat date: N/A

Summary: This document is nearly ready for publication as a Proposed 
Standard RFC

Major issues:

Moderate issues:
     In section 3.2.2 on Multi-Channel audio per SSRC Segment, the 
format description for the Calculation Algorithm ID (CAID) reads:
"The 8-bit ID is the local identifier of this segment in the range
1-255 inclusive."  I am pretty sure this is supposed to be an algorithm 
ID, not a segment index?

     The text in section 4.1 indicates that the number after "calg:" in 
the mapentry of the calgextmap is used as the ID in the CAID of the 
xrblock.  The packet format only allows 8 bits of value.  So why does 
the SDP format allow up to 5 digits?  Also, is there some reason that 
the special values 4095-4351 (in section 4.1) or 4096-4351 (in section 
4.2) are used rather than say equally invalid 512 through some 
appropriate upper bound still in 3 digits?

Minor issues:
     Please ensure that all acronyms are expanded on first use.  For 
example, QoE is not expanded.

     The notes in B.3 indicate that mostype was to be removed from the 
SDP grammar.  But it is still defined.  And section 4.2 still mentions 
it, even though it does not get referenced by the message format. 
Please finish removing it.  (also "most type")

Nits/editorial comments:

---

From: Joel Halpern <[email-masked]>
Date: Tue, 12 Nov 2013 07:12:02 -0500

Major issues:

Moderate issues:

Minor issues:

     The notes in B.3 indicate that mostype was to be removed from the 
SDP grammar.  But it is still defined.  And section 4.2 still mentions 
it, even though it does not get referenced by the message format. Please 
finish removing it.  (also "most type")

Nits/editorial comments:

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 12 Nov 2013 15:01:03 +0100

Hi Joel,

thanks for your review. I am responding to this email because the
address of the XRBLOCK list had a typo in the original email (I have
fixed it in this one). This message should make it to the list.

Authors, please look into this.

Cheers,

Gonzalo

On 12/11/2013 1:06 PM, Joel M. Halpern wrote:
>     In section 3.2.2 on Multi-Channel audio per SSRC Segment, the format
> description for the Calculation Algorithm ID (CAID) reads:

---

From: Alan Clark <[email-masked]>
Date: Tue, 12 Nov 2013 12:05:33 -0500

Hi Joel

Thanks for your comments.

(i) Section 1.4

Proposed change

    The MOS Metrics Report Block can be used in any application of RTP
    for which QoE measurement algorithms are defined.

to

    The MOS Metrics Report Block can be used in any application of RTP
    for which QoE (Quality of Experience) measurement algorithms are defined.

(ii) Section 3.2.2

Proposed change
"The 8-bit ID is the local identifier of this segment in the range 1-255 
inclusive"
to
"The 8-bit CAID is the session specific reference to the calculation 
algorithm and associated qualifiers indicated in SDP (see Section 4.1) 
and used to compute QoE scores for this segment"

(iii) Section 3.2.1

Proposed change
"The 8-bit CAID is the local identifier of calculation algorithm 
associated with this segment in the range 1-255 inclusive. "
to
"The 8-bit CAID is the session specific reference to the calculation 
algorithm and associated qualifiers indicated in SDP (see Section 4.1) 
and used to compute QoE scores for this segment"

(iv) Section 4.1

Proposed change

    mapentry =  "calg:" 1*5 DIGIT ["/" direction]
                           ;Values other than 4095~4351 are valid
to
   mapentry =  "calg:" 1*3 DIGIT ["/" direction]
                           ;Values other than 1..255 are valid

and remove

  mostype = "mostype=" ("e"; Estimated MOS [P.800.1]
                            /"s";subjective MOS [P.800.1]
                            /"o";objective MOS [P.800.1]
                            /non-ws-string)

We will see if there are additional comments and then update the draft

Regards

Alan Clark

On 11/12/13, 7:12 AM, Joel Halpern wrote:
> 1-255 inclusive."  I am pretty sure this is supposed to be an 
> algorithm ID, not a segment index?
>
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 Nov 2013 14:20:23 -0500

Thank you for your very fast and effective response Alan.  Those work 
for me.
Yours,
Joel

---

From: Qin Wu <[email-masked]>
Date: Wed, 13 Nov 2013 02:14:05 +0000

Hi, Alan:
Thank for quick response.  Here are additional changes I proposed.
Regarding section 4.1, I propose the following change:
OLD TEXT:
   mapentry =  "calg:" 1*5 DIGIT ["/" direction]
                          ;Values other than 4095~4351 are valid
NEW TEXT:
  mapentry =  "calg:" 1*3 DIGIT ["/" direction]
                          ;Values 1..255 are valid
OLD TEXT:
"
If the answerer wishes to reject a mosref attribute offered by the
offerer, it sets identifiers associated with segment extensions in
the answer to the value in the range 4096-4351.
"

NEW TEXT:
"
If the answerer wishes to reject a mosref attribute offered by the
offerer, it sets identifiers associated with segment extensions in
the answer to the value in the range 512-767.
"

OLD TEXT:
"
   If a party wishes to offer mutually exclusive alternatives, then
   multiple segment extensions with the same identifier in the
   (unusable) range 4096-4351 MAY be offered;
"
NEW TEXT:
"
   If a party wishes to offer mutually exclusive alternatives, then
   multiple segment extensions with the same identifier in the
   (unusable) range 512-767 MAY be offered;
"
OLD TEXT:
"
Similarly, if more segment extensions are offered than can be fit in
the valid range, identifiers in the range 4096-4351 MAY be offered;
"
NEW TEXT:
"
Similarly, if more segment extensions are offered than can be fit in
the valid range, identifiers in the range 512-767 MAY be offered;
"

OLD TEXT:
"
Note that the range 4096-4351 for these negotiation identifiers is
deliberately restricted to allow expansion of the range of valid
identifiers in future.
"
NEW TEXT:
"
Note that the range 512-767 for these negotiation identifiers is
deliberately restricted to allow expansion of the range of valid
identifiers in future.
"

Regards!
-Qin
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Clark
Sent: Wednesday, November 13, 2013 1:06 AM
To: Joel Halpern; A. Jean Mahoney; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [xrblock] [Gen-art] Review: draft-ietf-xrblock-rtcp-xr-qoe-12

Hi Joel

(i) Section 1.4

Proposed change

Proposed change
"The 8-bit ID is the local identifier of this segment in the range 1-255 inclusive"
to
"The 8-bit CAID is the session specific reference to the calculation algorithm and associated qualifiers indicated in SDP (see Section 4.1) and used to compute QoE scores for this segment"

(iii) Section 3.2.1

Proposed change
"The 8-bit CAID is the local identifier of calculation algorithm associated with this segment in the range 1-255 inclusive. "
to
"The 8-bit CAID is the session specific reference to the calculation algorithm and associated qualifiers indicated in SDP (see Section 4.1) and used to compute QoE scores for this segment"

(iv) Section 4.1

Proposed change

to

                           /non-ws-string)

Regards

Alan Clark

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq><http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Summary: This document is nearly ready for publication as a Proposed Standard RFC

Major issues:

Moderate issues:
    In section 3.2.2 on Multi-Channel audio per SSRC Segment, the format description for the Calculation Algorithm ID (CAID) reads:
"The 8-bit ID is the local identifier of this segment in the range
1-255 inclusive."  I am pretty sure this is supposed to be an algorithm ID, not a segment index?

    The text in section 4.1 indicates that the number after "calg:" in the mapentry of the calgextmap is used as the ID in the CAID of the xrblock.  The packet format only allows 8 bits of value.  So why does the SDP format allow up to 5 digits?  Also, is there some reason that the special values 4095-4351 (in section 4.1) or 4096-4351 (in section 4.2) are used rather than say equally invalid 512 through some appropriate upper bound still in 3 digits?

Minor issues:
    Please ensure that all acronyms are expanded on first use.  For example, QoE is not expanded.

    The notes in B.3 indicate that mostype was to be removed from the SDP grammar.  But it is still defined.  And section 4.2 still mentions it, even though it does not get referenced by the message format. Please finish removing it.  (also "most type")

Nits/editorial comments:
_______________________________________________
xrblock mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/xrblock

---

From: Alan Clark <[email-masked]>
Date: Wed, 13 Nov 2013 15:30:58 -0500

Hi Qin

The use of an out of range value within SDP to signal that you don't 
want to accept something does not seem to be within the spirit of SDP.  
The normal usage would be "I can do A, B, C" with an answer of "C".

In the case of QoE measurement - an RTP endpoint may incorporate one or 
more QoE algorithms that are used to estimate the user perceived quality 
of the received media stream. The offer should contain a subset of the 
QoE algorithms supported by the offeror and the answer should contain a 
subset of the QoE algorithms supported by the answerer; it is not 
necessary that the QoE algorithms in the Answer are a subset of those in 
the Offer (as the algorithms don't need to interoperate).  Unlike the 
case when negotiating a codec - it is not required that the two 
endpoints implement the same algorithm although there is some minor 
advantage if the two endpoints use the same algorithm if possible in 
order that QoE scores for the two directions are equivalently scaled.

I'd prefer to use SDP in the following way:

(i) Offer provides a list of one or more QoE algorithms that it 
supports, in the form of a map

(ii) Answer provides a list of one or more QoE algorithms that it 
supports, in the form of a map. If the Answerer supports one of the same 
algorithms that the Offer provides then the Answerer SHOULD answer with 
only that algorithm however MAY answer with more than one.

I'll work out the appropriate text changes to implement this unless 
there are strong technical reasons not to.

Regards

Alan

On 11/12/13, 9:14 PM, Qin Wu wrote:
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Alan Clark
> *Sent:* Wednesday, November 13, 2013 1:06 AM
> *To:* Joel Halpern; A. Jean Mahoney; [email-masked]; 
> [email-masked]; [email-masked]
> *Subject:* Re: [xrblock] [Gen-art] Review: 
> draft-ietf-xrblock-rtcp-xr-qoe-12
>
> Hi Joel
>
> 1-255 inclusive"
>     <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>         The text in section 4.1 indicates that the number after
>     "calg:" in the mapentry of the calgextmap is used as the ID in the
>     CAID of the xrblock.  The packet format only allows 8 bits of
>     value.  So why does the SDP format allow up to 5 digits?  Also, is
>     there some reason that the special values 4095-4351 (in section
>     4.1) or 4096-4351 (in section 4.2) are used rather than say
>     equally invalid 512 through some appropriate upper bound still in
>     3 digits?
>
>     Minor issues:
>         The notes in B.3 indicate that mostype was to be removed from
>     the SDP grammar.  But it is still defined.  And section 4.2 still
>     mentions it, even though it does not get referenced by the message
>     format. Please finish removing it.  (also "most type")
>
>     Nits/editorial comments:
>     [email-masked] <mailto:[email-masked]>

---

From: Qin Wu <[email-masked]>
Date: Thu, 14 Nov 2013 01:43:41 +0000

Hi, Alan:
I think the current text of draft-ietf-xrblock-rtcp-xr-qoe-12 has already supported (i),(ii).
In addition, we follow SDP usage example defined in section 5 and section 6 of RFC5285
use of an out of range value to indicate some exceptional cases.

If we don't use out of range to deal with failure, what else can we do?

Regards!
-Qin
From: Alan Clark [mailto:[email-masked]]
Sent: Thursday, November 14, 2013 4:31 AM
To: Qin Wu; Joel Halpern; A. Jean Mahoney; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [xrblock] [Gen-art] Review: draft-ietf-xrblock-rtcp-xr-qoe-12

Hi Qin

The use of an out of range value within SDP to signal that you don't want to accept something does not seem to be within the spirit of SDP.  The normal usage would be "I can do A, B, C" with an answer of "C".

In the case of QoE measurement - an RTP endpoint may incorporate one or more QoE algorithms that are used to estimate the user perceived quality of the received media stream. The offer should contain a subset of the QoE algorithms supported by the offeror and the answer should contain a subset of the QoE algorithms supported by the answerer; it is not necessary that the QoE algorithms in the Answer are a subset of those in the Offer (as the algorithms don't need to interoperate).  Unlike the case when negotiating a codec - it is not required that the two endpoints implement the same algorithm although there is some minor advantage if the two endpoints use the same algorithm if possible in order that QoE scores for the two directions are equivalently scaled.

(i) Offer provides a list of one or more QoE algorithms that it supports, in the form of a map

(ii) Answer provides a list of one or more QoE algorithms that it supports, in the form of a map. If the Answerer supports one of the same algorithms that the Offer provides then the Answerer SHOULD answer with only that algorithm however MAY answer with more than one.

I'll work out the appropriate text changes to implement this unless there are strong technical reasons not to.

Regards

Alan

NEW TEXT:
"

OLD TEXT:
"

OLD TEXT:
"

Regards!
-Qin
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Alan Clark
Sent: Wednesday, November 13, 2013 1:06 AM
To: Joel Halpern; A. Jean Mahoney; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [xrblock] [Gen-art] Review: draft-ietf-xrblock-rtcp-xr-qoe-12

Hi Joel

(i) Section 1.4

Proposed change

Proposed change

(iii) Section 3.2.1

Proposed change

(iv) Section 4.1

Proposed change

to

                           /non-ws-string)

Regards

Alan Clark

Major issues:

Moderate issues:

Minor issues:

Nits/editorial comments: