Session Initiation Protocol Event Package for Voice Quality Reporting
draft-ietf-sipping-rtcp-summary-13

Unclear on the use use of references within the ABNF comments.
Sometimes they are used, and sometimes not.
Suspect that (as per MIB Modules) they should not be used.

Wonder if the Proto Writeup should be updated. This would certainly have caught Alexey's issues with the ABNF.

[Updated as per draft-ietf-sipping-rtcp-summary-10.txt]

The document shepherd/sponsoring AD should rerun
<http://tools.ietf.org/tools/bap/abnf.cgi> on the ABNF from this document.


       ; SignalLevel will normally be a negative value
       ; the absence of the negative sign indicates a positive value

I think "." is missing at the end of the previous line.

       ; where the signal level is negative, the sign MUST be
       ; included.This metric applies to the speech signal decoded
       ; from the received packet stream.

       SignalLevel = "SL" EQUAL (["-"] 1*2DIGIT)



       RLQEstAlg = "RLQEstAlg" EQUAL word ; "P.564", or other

Some pointer where P.564 is defined would be good hear.


4.6.2.2.  Timestamps

   Following SIP and other IETF convention, timestamps are provided in
   Coordinated Universal Time (UTC) using the ABNF format provided in
   RFC 3339 [7].

ABNF for timestamps allows for timezones, so it would be good to mention
in the ABNF section that timezones other than "Z" are not allowed.



4.6.2.11.2.  RLQEstAlg

   This field provides a text name for the algorithm used to estimate
   ListeningQualityR.

Is there an IANA registry for such algorithms, or does this field
contain free form text?

4.6.2.11.4.  RCQEstAlg

   This field provides a text name for the algorithm used to estimate
   ConversationalQualityR.

As above.

4.6.2.11.6.  ExtRInEstAlg

   This field provides a text name for the algorithm used to estimate
   ExternalR-In.

As above.

4.6.2.11.8.  ExtROutEstAlg

   This field provides a text name for the algorithm used to estimate
   ExternalR-Out.  Conversion of RFC3611 reported MOS scores for use in
   reporting MOS-LQ and MOS-CQ MUST be performed by dividing the RFC3611
   reported value by 10 if this value is less than or equal to 50 or
   omitting the MOS-xQ parameter if the RFC3611 reported value is 127
   (which indicates unavailable).

All but the first sentence don't seem to belong to this section.

4.6.2.11.11.  MOSCQEstAlg

   This field provides a text name for the algorithm used to estimate
   MOS-CQ.

Is there an IANA registry for such algorithms, or does this field
contain free form text?

Agree w/ above comments that doc needs a spin

1. Section 4.4 talks about subscription duration but not about when to cancel a subscription (by either the reporter or the collector); for example, it might be appropriate to recommend cancelling the subscription when the voice session had ended?

2. The RemoteID "bill@elpmaxe.org" does not conform to RFC 2606.

3. The references to draft-ietf-sipping-config-framework and RFC 5389 appear to be informative, not normative.

  Some of the comments in the Gen-ART Review by Scott Brim were
  not addressed.  Please consider them.

  In Secrion 3.4 (Overload Avoidance) has small editorial issues

  - Typo: "MUST send a 503 Service Unavailable or other 5xx esponse"

  - "on these responses and respect the retry after time interval."
    Perhaps it should say "Retry-After."

In 4.2.6.10, the specifications for both Round Trip Delay and End System Delay end with

"This parameter does no require any conversion."

Perhaps "no" should be "not" in both cases?