Re: [avtext] Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request

["Ali C. Begen (abegen)" <[e-mail]>]

Keith,

> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:[e-mail]]
> Sent: Tuesday, April 05, 2011 12:25 PM
> To: Ali C. Begen (abegen); [e-mail]
> Cc: [e-mail]
> Subject: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request
> 
> I've done a detailed review of this document before sending for publication request. I'd appreciate it if you could address the
> following in a new version. By all means ask questions about any of the comments. I don't believe any of these make a
> technical change to the document, but they should make it clearer.

> 1)      General. There are a number of instances where SHALL is used in the document. This means exactly the same as
> "MUST" and it would be more consistent to use "MUST" throughout.

Then, why did 2119 define "SHALL"? I prefer "SHALL" over "MUST" in certain scenarios. This is a writing style preference.
 
> 2)      Abstract.
> 
>    In most RTP-based multicast applications, the RTP source sends inter-
>    related data.  Due to this interdependency, randomly joining RTP
>    receivers usually cannot start consuming the multicast data right
>    after they join the session.  Thus, they often experience a random
>    acquisition delay.  An RTP receiver may use one ore more different
>    approaches to achieve rapid acquisition.  Yet, due to various
>    factors, performance of the rapid acquisition methods usually varies.
>    Furthermore, in some cases the RTP receiver may (or may have to) do a
>    simple multicast join.  For quality reporting, monitoring and
>    diagnostics purposes, it is important to collect detailed information
>    from the RTP receivers about their acquisition and presentation
>    experiences.  This document addresses this issue by defining a new
>    report block type, called Multicast Acquisition (MA) Report Block,
>    within the framework of RTP Control Protocol (RTCP) Extended Reports
>    (XR) (RFC 3611).  This document also defines the necessary signaling
>    of the new MA report block type in the Session Description Protocol
>    (SDP).
> 
> Replace two instances of "may" by "can" and an instance of "may have to" by "be compelled to", to avoid usage of RFC 2119
> like language (even though lower case)

I think you are paying unnecessary attention here and in other paragraphs you noted. Using such keywords in abstract or intro before 2119 usage is introduced is absolutely fine - as noted by IESG in my earlier documents. Again, this is pure writing style issue. 

> 5)      Section 3. Definition of Primary Multicast Session.
> 
>    (Primary) Multicast Session:  The multicast session to which RTP
>    receivers can join at a random point in time.
> 
> I interpret the parenthesis round "primary" to indicate that some instances of the term appear without the word "primary"
> but still mean "primary". I'm not convinced that is the case. Anyway, remove the parenthesis and check the rest of the
> document for instances where "primary" should now be inserted.

This is consistent with our definitions and terms used in the RAMS spec. I'd rather keep the same to be consistent.
 
> 6)      Section 3. Definition of Primary Multicast (RTP) Streams
> 
>    Primary Multicast (RTP) Streams:  The RTP stream(s) carried in the
>    primary multicast RTP session.
> 
> I cannot find this term used within the document. If it does not appear, delete it. If the something in the document means
> this, then apply the defined term to it.

Good catch. Should remove it.
 
> 7)      Section 4. 2nd paragraph.
> 
>    The optional extensions that are defined in this document are
>    primarily developed for the method presented in
>    [I-D.ietf-avt-rapid-acquisition-for-rtp].  Other methods that provide
>    rapid acquisition MAY define their own extensions to be used in the
>    MA report block.
> 
> I don't think this merits RFC 2119 language and certainly not "MAY" which defines an option. I think "can" is sufficient here.
> Other methods are outside the scope of this document.

"can" is fine here.
 
> 8)      Section 4. 4th paragraph.
> 
>    The MA report block is better to be sent after all the necessary
>    information is collected and computed.  Partial reporting is
>    generally not useful as it may not give the full picture of the
>    multicast acquisition, and causes additional complexity in terms of
>    report block matching and correlation.  The MA report block SHOULD
>    only be sent as a part of an RTCP compound packet, and it is sent in
>    the primary multicast session.
> 
> I had some trouble parsing the 1st sentence, and I believe it is better reworded as below.
> 
>    It is better to send the MA report block after all the necessary
>    information is collected and computed.  Partial reporting is
>    generally not useful as it cannot give the full picture of the
>    multicast acquisition, and causes additional complexity in terms of
>    report block matching and correlation.  The MA report block SHOULD
>    only be sent as a part of an RTCP compound packet, and it is sent in
>    the primary multicast session.

Rewording looks better. Thanks.
 
> Secondly, for the "SHOULD" usage, it is normal to provide additional text identify use cases under which the "SHOULD" might
> or might not be deviated from. Otherwise implementors will trat it as a straight option and we may as well have written
> "MAY". What do we really mean here? How do we check conformance?

There is no conformance check here. As Magnus suggested, we added this text to clarify that this report block was sent as a part of the compound packet. I don't see any reason why anybody would do it differently. But, even if they do, no big deal, nothing will break and the world will not collapse. Any proper RTP implementation has to follow certain rules anyway, which we don't need to repeat here.
 
> 9)      Section 4. 5th paragraph
> 
>    The reliability of the MA report block is not any more essential than
>    other report blocks or types.  If desired, the report block could be
>    repeated for redundancy purposes while respecting to the RTCP
>    scheduling algorithms.
> 
> Again I had some trouble parsing this. I suggest the following:
> 
>    The need for reliability of the MA report block is no greater than
>    other report blocks or types.  If desired, the report block could be
>    repeated for redundancy purposes while respecting to the RTCP
>    scheduling algorithms.

OK.
 
> 10)     Section 4.1. Status
> 
>       This document defines several status codes and registers them with
>       IANA in Section 7.5.  If a new vendor-neutral status code will be
>       defined, it MUST be registered with IANA through the guidelines
>       specified in Section 7.5.  If the new status code is intended to
>       be used privately by a vendor, there is no need for IANA
>       management.  Instead, the vendor MUST use the private extension
>       mechanism (Section 4.2.2) to convey its message and MUST indicate
>       this by putting zero in the Status field.
> 
> The above text contains two requirements on the vendor. Firstly I am not a great fan of hiding these requirements in a coding
> section.

I can't think of any other (and better) place to define them.
 
> Secondly the first of these is also repeated in section 4.2 so we should delete one of them anyway.

Will remove the one in 4.2.1.
 
> Finally the last paragraph is a combination of a vendor requirement and an implementation requirement. These have to be
> split. For the first half ("the vendor MUST use the private extension mechanism (Section 4.2.2) to convey its message), I am
> not sure how one would demonstrate conformance so I would suggest we have a sentence more like:
> 
>         "Section 4.2.2 defines how a vendor defines and uses private extension mechanisms to convey its message."

OK.
 
> For the second half, I would suggest a sentence of the form:
> 
>         "To indicate a private extension mechanism, the RTP receiver MUST set the Status field to zero."

OK.
 
> 11)     Section 4.1. Rsvd
> 
>    o  Rsvd. (16 bits):  This field SHALL be set to 0 and ignored on
>       reception.
> 
> Two separate requirements here and write in the active.
> 
>         The RTP receiver MUST set this bit to "0". The recipient MUST ignore this bit when received.

OK.
 
> However I note that RFC 3611 uses the following text for similar bits, which could be an alternative:
> 
>          This field is reserved for future definition.  In the absence
>          of such definition, the bits in this field MUST be set to zero
>          and MUST be ignored by the receiver.
> 
> 12)     Section 4.1.1.
> 
> I would suggest splitting this subsection into two. The first would cover the paragraphs relating to someone writing a new MA
> method, and should be titled something like "defining new MA methods". The second would be the remaining material and
> should be entitled something like "use of status codes". The reason for this is that the conformers to the statements are
> completely different.

I am not sure whether this will be clearer but I will look into it.
 
> 13)     Section 4.1.1, 1st paragraph
> 
>    Different MA methods usually use different status codes, although
>    some status codes (e.g., a code indicating that multicast join has
>    failed) may apply to more than one MA method.  However, the status
>    code reported in the base report MUST always be within the scope of
>    the particular MA method specified in the MA Method field.
> 
> Change "may" to "can". Delete the "However" as superfluous.

OK

> 14)     Section 4.1.1, second paragraph.
> 
>    In certain MA methods, the RTP receiver may generate a status code
>    for its multicast acquisition attempt, or may be told by another
>    network element or RTP endpoint what the current status is via a
>    response code.  In such cases, the RTP receiver MAY report the value
>    of the received response code as its status code if the response code
>    has a higher priority.  It is RECOMMENDED that each MA method
>    outlines the rules pertaining to its response and status codes so
>    that RTP receiver implementations can determine what to report in any
>    given scenario.  Below, we provide these rules for the RAMS method
>    described in [I-D.ietf-avt-rapid-acquisition-for-rtp].
> 
> Change "may" to "can" twice.

OK.
 
> As regards the "RECOMMENDED", this is equivalent to "SHOULD" and presumably should be assessed by any review before
> making the IANA registration. However you give no guidance as to what should be checked here. Do we make the IANA
> registration anyway. If so, I would argue that the RFC 2119 language is superfluous, and give the language more in the form
> of descriptive guidance.

Ok. I will just say "each MA methods needs ..."
 
> 15)     Section 4.1.1, third paragraph
> 
>    Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines
>    several response codes for its MA method.  The 1xx and 2xx-level
>    response codes are informational and success response codes,
>    respectively.  If the RTP receiver receives a 1xx or 2xx-level
>    response code, it MUST use one of the 1xxx-level status codes defined
>    in Section 7.5 of this document.  The RTP receiver may also receive a
>    4xx or 5xx-level response code (indicating receiver-side and server-
>    side errors, respectively).  In that case, the RTP receiver MUST use
>    the response code as its status code.  In other words, the 4xx and
>    5xx-level response codes have a higher priority than the 1xxx-level
>    status codes.  The 5xx-level response codes have a higher priority
>    than the 4xx-level response codes and MUST be reported in the base
>    report in case the RTP receiver receives both 4xx and 5xx-level
>    response codes (in different RAMS-I messages) during the same RAMS
>    session.
> 
> I would suggest some minor rewording as follows:
> 
>    Section 12.6 of [I-D.ietf-avt-rapid-acquisition-for-rtp] defines
>    several response codes for its MA method.  The 1xx and 2xx-level
>    response codes are informational and success response codes,
>    respectively.  If the RTP receiver receives a 1xx or 2xx-level
>    response code, then the RTP receiver MUST use one of the 1xxx-level status codes defined
>    in Section 7.5 of this document.  If the RTP receiver receives a
>    4xx or 5xx-level response code (indicating receiver-side and server-
>    side errors, respectively), then the RTP receiver MUST use
>    the response code as its status code.  In other words, the 4xx and
>    5xx-level response codes have a higher priority than the 1xxx-level
>    status codes.  The 5xx-level response codes have a higher priority
>    than the 4xx-level response codes and MUST be reported in the base
>    report in case the RTP receiver receives both 4xx and 5xx-level
>    response codes (in different RAMS-I messages) during the same RAMS
>    session.
> 
> However not sure the final sentence correctly expresses what should be conformed to. Presumably we have to select one and
> only one response code when multiple are reported. Does this sentence clearly specify which one is selected. Can there be
> multiple 4xx responses?

Yes, you select one (as the last sentence indicates). The sentence says 5xx has higher priority over 4xx. There cannot be multiple 4xx responses in the same RAMS session AFAICT.
 
> 16)     Section 4.2, 1st paragraph:
> 
>    To improve the reporting scope, it might be desirable to define new
>    fields in the MA report block.  Such fields MUST be encoded as TLV
>    elements as described below and sketched in Figure 2:
> 
> Not sure this statement merits RFC 2119 language, and indeed I'm not clear if this is a requirement on the definer of the
> extension, or on the implementor of the extension.

Better said "such fields are to be encoded ...". The requirement was mentioned earlier.

> 
> 17)     Section 4.2, 1st paragraph, length
> 
>    o  Length:  A two-octet field that indicates the length (in octets)
>       of the TLV element excluding the Type and Length fields, and the
>       8-bit Reserved field between them.  Note that this length does not
>       include any padding that is required for alignment.
> 
> Change "required" to "needed".

Ok.
 
> 18)     Section 4.2, 2nd paragraph and 3rd paragraphs:
> 
>    In the extensions, the Reserved field SHALL be set to zero and
>    ignored on reception.  If a TLV element does not fall on a 32-bit
>    boundary, the last word MUST be padded to the boundary using further
>    bits set to zero.
> 
>    In the MA report block, any vendor-neutral or private extension MUST
>    be placed after the base report.
> 
> Again I am not clear whether this is a requirement on the definer of the extension, or on the implementor of the extension.

On the implementor. The place of the extension has nothing to do with its definition. We could make it active sentence and clarify it.
 
> 19)     Section 4.2.1, 2nd paragraph, 1st bullet:
> 
>    o  RTP Seqnum of the First Multicast Packet (16 bits):  TLV element
>       that specifies the RTP sequence number of the first multicast
>       packet received for the primary multicast stream.  If the
>       multicast join was successful, this element MUST exist.  If no
>       multicast packet has been received, this element SHALL NOT exist.
> 
> I assume the RFC 2119 language is a requirement on the implementation of the RTP receiver. Please make this clear.
> 
> Note this comment also applies to many of the subsequent bullets. Please review.

OK.
 
> 20)     Section 4.2.2, 1st paragraph:
> 
>    It is desirable to allow vendors to use private extensions in TLV
>    format.  For interoperability, such extensions MUST NOT collide with
>    each other.
> 
> I don't believe I can assess conformance to such a statement unless I know the scope of the uniqueness required. I suspect
> this is something that should not use RFC 2119 language in the first place.

I can simply remove the second sentence since by definition extensions will not collide between vendors. But if a vendor is naïve enough to use the same type for different extensions, it is their problem.
 
> 21)     Section 4.2.2, 3rd paragraph:
> 
>    The structure that MUST be used for the private extensions is
>    depicted in Figure 3.  Here, the private enterprise numbers are used
>    from http://www.iana.org/assignments/enterprise-numbers.  This will
>    ensure the uniqueness of the private extensions and avoid any
>    collision.
> 
> Again I am not clear whether this is a requirement on the definer of the extension, or on the implementor of the extension.

Will make this clear, too.
 
> 22)     Section 5.
> 
> I believe there is a construct in ABNF that allows an existing production to be extended using "/="
> 
> I'm guessing here, but I think you are extending the following production from RFC 3611:
> 
>      xr-format = pkt-loss-rle
>                / pkt-dup-rle
>                / pkt-rcpt-times
>                / rcvr-rtt
>                / stat-summary
>                / voip-metrics
>                / format-ext
> 
> In which case I would expect to see something like
> 
>      xr-format /= multicast-acq-ext
> 
>      multicast-acq-ext = "multicast-acq"
> 
> along with a reference to RFC 3611 for the original production.

I copied this part from RFC 5725 directly, I was suggested to write it that way and it looked correct to me. Unless it is wrong, I wanna keep it that way.
 
> 23)     Section 6. 2nd paragraph
> 
>    The information contained in MA reports could be stolen as any other
>    RTCP reports if proper protection mechanism(s) are not in place.  If
>    desired, similar to other RTCP XR reports, the MA reports MAY be
>    protected by using Secure RTP (SRTP) and Secure RTP Control Protocol
>    (SRTCP) [RFC3711].
> 
> Used with "MAY" I believe RFC 3711 becomes a normative reference. Currently it is only informative.

Will move it to the normative part.
 
> 24)     Section 6. 3rd paragraph
> 
>    Using the MA reports to provide feedback into the acquisition of the
>    multicast streams can introduce possible additional security
>    implications.  If a forged or otherwise modified MA report is
>    received for an earlier acquisition attempt, invalid data may be used
>    as input in later rapid acquisition attempts.  For example,
>    incorrectly small SFGMP join times could cause the unicast burst to
>    be too short, leading to gaps in sequence numbers in the approach
>    discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp].  Additionally,
>    forged reports could give the appearance that rapid acquisition is
>    performing correctly, when it is in fact failing, or vice versa.
>    However, the MA reports are believed not to introduce any additional
>    risks from a confidentiality viewpoint.
> 
> Change "may" to "can".
> 
Ok.
 
> 25)     Section 7. 1st paragraph
> 
>    The following contact information shall be used for all registrations
>    in this document:
> 
> Change to
> 
>    The following contact information is provided for all registrations
>    in this document:

Ok.
 
> 26)     Section 7.4. Final bullet
> 
>    o  A detailed description of what the new Status code describes and
>       how it shall be interpreted.
> 
> Reword to:
> 
>    o  A detailed description of what the new Status code describes and
>       how it is interpreted.
> 
> Same change also to Section 7.5 final bullet.

Ok.
 
> 27)     Normative references.
> 
> RFC 5226 is not a normative reference. Move to informative references section.

Moved (FYI, both are acceptable to IESG AFAICT).

-acbegen
 
> 
> Regards
> 
> Keith