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

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 5 Apr 2011 18:25:03 +0200

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.

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)

   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 can 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 can (or be compelled 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).

3)      Section 1, 2nd paragraph

   In most RTP-based multicast applications such as the ones carrying
   video content, the RTP source sends inter-related data.
   Consequently, the RTP application may not be able to decode and
   present the data in an RTP packet before decoding one or more earlier
   RTP packets and/or before acquiring some Reference Information about
   the content itself.  Thus, RTP receivers that are randomly joining a
   multicast session often experience a random acquisition delay.  In
   order to reduce this delay, [I-D.ietf-avt-rapid-acquisition-for-rtp]
   proposes an approach where an auxiliary unicast RTP session is
   established between a retransmission server and the joining RTP
   receiver.  Over this unicast RTP session, the retransmission server
   provides the Reference Information, which is all the information the
   RTP receiver needs to rapidly acquire the multicast stream.  This
   method is referred to as the Rapid Acquisition of Multicast Sessions
   (RAMS).  However, depending on the variability in the Source
   Filtering Group Management Protocol (SFGMP) processing times,
   availability of network resources for rapid acquisition and nature of
   the RTP data, not all RTP receivers can acquire the multicast stream
   in the same amount of time.  The performance of rapid acquisition may
   vary not only for different RTP receivers but also over time.

Replace "may not be able to" with "cannot" and instance of "may" with "can" to avoid usage of RFC 2119 language.

   In most RTP-based multicast applications such as the ones carrying
   video content, the RTP source sends inter-related data.
   Consequently, the RTP application cannot decode and
   present the data in an RTP packet before decoding one or more earlier
   RTP packets and/or before acquiring some Reference Information about
   the content itself.  Thus, RTP receivers that are randomly joining a
   multicast session often experience a random acquisition delay.  In
   order to reduce this delay, [I-D.ietf-avt-rapid-acquisition-for-rtp]
   proposes an approach where an auxiliary unicast RTP session is
   established between a retransmission server and the joining RTP
   receiver.  Over this unicast RTP session, the retransmission server
   provides the Reference Information, which is all the information the
   RTP receiver needs to rapidly acquire the multicast stream.  This
   method is referred to as the Rapid Acquisition of Multicast Sessions
   (RAMS).  However, depending on the variability in the Source
   Filtering Group Management Protocol (SFGMP) processing times,
   availability of network resources for rapid acquisition and nature of
   the RTP data, not all RTP receivers can acquire the multicast stream
   in the same amount of time.  The performance of rapid acquisition can
   vary not only for different RTP receivers but also over time.

4)      Section 1, 3rd paragraph

   To increase the visibility of the multicast service provider into its
   network, to diagnose slow multicast acquisition issues and to collect
   the acquisition experiences of the RTP receivers, this document
   defines a new report block type, which is called Multicast
   Acquisition (MA) Report Block, within the framework of RTCP XR.  RTP
   receivers that are using the method described in
   [I-D.ietf-avt-rapid-acquisition-for-rtp] may use this report every
   time they join a new multicast RTP session.  RTP receivers that use a
   different method for rapid acquisition or those do not use any method
   but rather do a simple multicast join may also use this report to
   collect information.  This way, the multicast service provider can
   quantitatively compare the improvements achieved by different
   methods.

Replace two instances of "may" with "can".

   To increase the visibility of the multicast service provider into its
   network, to diagnose slow multicast acquisition issues and to collect
   the acquisition experiences of the RTP receivers, this document
   defines a new report block type, which is called Multicast
   Acquisition (MA) Report Block, within the framework of RTCP XR.  RTP
   receivers that are using the method described in
   [I-D.ietf-avt-rapid-acquisition-for-rtp] can use this report every
   time they join a new multicast RTP session.  RTP receivers that use a
   different method for rapid acquisition or those do not use any method
   but rather do a simple multicast join can also use this report to
   collect information.  This way, the multicast service provider can
   quantitatively compare the improvements achieved by different
   methods.

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.

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.

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.

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.

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?

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.

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.

Secondly the first of these is also repeated in section 4.2 so we should delete one of them anyway.

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."

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."

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.

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.

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.

   Different MA methods usually use different status codes, although
   some status codes (e.g., a code indicating that multicast join has
   failed) can apply to more than one MA method.  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.

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.

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.

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?

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.

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".

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.

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.

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.

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.

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.

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.

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".

   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 can 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.

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:

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.

27)     Normative references.

RFC 5226 is not a normative reference. Move to informative references section.

Regards

Keith

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 5 Apr 2011 10:58:03 -0700

Keith,

> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Tuesday, April 05, 2011 12:25 PM
> To: Ali C. Begen (abegen); [email-masked]
> Cc: [email-masked]
> 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.
 
> 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. 

> 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.
 
> this, then apply the defined term to it.

Good catch. Should remove it.
 
> 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.
 
>    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.
 
>    repeated for redundancy purposes while respecting to the RTCP

OK.
 
> The above text contains two requirements on the vendor. Firstly I am not a great fan of hiding these requirements in a coding

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:
> 

OK.
 
>         "To indicate a private extension mechanism, the RTP receiver MUST set the Status field to zero."

OK.
 
>         The RTP receiver MUST set this bit to "0". The recipient MUST ignore this bit when received.

OK.
 
> 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.
 
> Change "may" to "can". Delete the "However" as superfluous.

OK

> 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 ..."
 
> 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.
 
> 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.

> Change "required" to "needed".

Ok.
 
> 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.
 
> Note this comment also applies to many of the subsequent bullets. Please review.

OK.
 
> 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.
 
> 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.
 
> 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.
 
> Used with "MAY" I believe RFC 3711 becomes a normative reference. Currently it is only informative.

Will move it to the normative part.
 
>    risks from a confidentiality viewpoint.
Ok.
 
>    The following contact information is provided for all registrations

Ok.
 
> Same change also to Section 7.5 final bullet.

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

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

-acbegen

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 6 Apr 2011 16:06:28 +0200

See below and deleting the ones you already plan to fix.

Keith

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: 05 April 2011 18:58
> To: DRAGE, Keith (Keith); draft-ietf-avtext-multicast-acq-rtcp-
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in
> preparation for pub request
> 
> Keith,
> 
> > 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
> > 1)      General. There are a number of instances where SHALL is used in
> the document. This means exactly the same as
> Then, why did 2119 define "SHALL"? I prefer "SHALL" over "MUST" in certain
> scenarios. This is a writing style preference.
> 
Coming from SDOs that inherently used "shall" I prefer it as well. The reason for using "shall" as opposed to "must" in ISO, CEN, CENELEC and ETSI is that these standards have to be translated into other languages, and they have chosen modal auxiliary verbs that are readily translatable without error into other languages. The problem with "must" is the translation into the equivalent German.

I suspect the "SHALL" exists in RFC 2119 not to allow style, but to allow double publication of specifications from other SDOs as RFCs, without having to change all the word.

But my real complaint is not against the use of SHALL as opposed to MUST. It is the use of MUST in one sentence versus SHALL in the next sentence. Standards are not about the variability and richness of writing style. They are about using things consistently so if the reader gets the correct interpretation from one usage to the next. So if you changed everything to "SHALL" I would not have a problem - although other people might!

> > 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.
> 
This is not the most important comment for those sections that are recognized as purely informative. What I am trying to avoid with a lot of these changes is people asking later on "This doesn't have capital letters but was a requirement really meant".

> > 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
> 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.
> 

So we will remove the "SHOULD from the following sentence???

> >    the primary multicast session.

Becomes "The MA report block is only sent..."

> > 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.
> 

The key here is that I am trying to separate the requirements into separate sections that apply the specifier of a method from those applying to the implementation (the latter which can therefore be tested on an implementation). I don't really mind how such restructuring is done providing we get to that intent.

> > 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.
> 
OK, I think I understand. I think the text is still somewhat complex. How about if we  define a priority list as follows:

"If multiple response codes are received for the RAMS MA method, the RTP receiver MUST use only one response code, applying the following priority table, where the code with the highest entry in the table represents the response code that is used.

		5xx-level response codes
		4xx-level response codes
		1xx-level response codes
		2xx-level response codes"

> > Again I am not clear whether this is a requirement on the definer of the
> On the implementor. The place of the extension has nothing to do with its
> definition. We could make it active sentence and clarify it.
> 
Please do. I like requirements in the active!

> > I don't believe I can assess conformance to such a statement unless I
> know the scope of the uniqueness required. I suspect
> 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.
> 
OK.

> 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.
> 
I've seen comments on internet-drafts elsewhere making the same comment. I don't know how recent this construct is. The publication request process does ask the shepherd to verify the ABNF, and the only means of doing that is providing the construct I have identified, rather than the one in the current i-d.

I'll ask Gonzalo for his expections, as I'm not really an ABNF expert.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 6 Apr 2011 07:20:26 -0700

Two minor comments below.

> Becomes "The MA report block is only sent..."

Sure.
 
> OK, I think I understand. I think the text is still somewhat complex. How about if we  define a priority list as follows:

Actually, we realized that there won't be any case where the receiver gets both 4xx and 5xx responses. So, the sentence is removed.
 
I will replace all the SHALLs with a MUST just for you, Keith.

Expect the revision shortly.

-acbegen

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 6 Apr 2011 18:31:58 +0200

Thanks.

Just reviewing (again) the IANA section, and noticed the following.

Section 7.1.

7.1.  RTCP XR Block Type

   Type value 11 has been pre-registered with IANA for the "Multicast
   Acquisition Report Block" in the RTCP XR Block Type Registry.

This IANA action was already performed by the RAMS draft, and therefore there is no IANA action associated with this parameter. As such it is sensible not to include this section, unless you feel it is appropriate to add this draft as a reference in the existing IANA registry entry (in which case the section needs to be redrafted to say this).

Regards

Keith

> Sent: 06 April 2011 15:20
> > > > I had some trouble parsing the 1st sentence, and I believe it is
> better
> > > reworded as below.
> > > >
> > > >    response code, then the RTP receiver MUST use one of the 1xxx-
> level
> > > status codes defined
> > OK, I think I understand. I think the text is still somewhat complex.
> How about if we  define a priority list as follows:
> 
> Actually, we realized that there won't be any case where the receiver gets
> both 4xx and 5xx responses. So, the sentence is removed.
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 6 Apr 2011 09:37:13 -0700

> Sent: Wednesday, April 06, 2011 12:32 PM
> Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in preparation for pub request
> 
> Thanks.
> 
> This IANA action was already performed by the RAMS draft, and therefore there is no IANA action associated with this

No, it was not performed by the RAMS draft.  It was registered externally.

> parameter. As such it is sensible not to include this section, unless you feel it is appropriate to add this draft as a reference in
> the existing IANA registry entry (in which case the section needs to be redrafted to say this).

Until this becomes an RFC, we need to keep this text around to let people know what will be used for this XR block. If the RFC editor feels appropriate, she can remove the sentence at that time.

-acbegen

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 7 Apr 2011 11:19:12 +0200

Right OK, I get it now.

So the question I need to ask is whether section 7.1 instructs IANA clearly in how they need to change their registration tables from how they are now to what they should be once this internet draft is published as an RFC.

So essentially they need an instruction to replace the current reference associated with this registered value (which is a previous version of this draft under a different name) to the number of this RFC.

Regards

Keith

> Sent: 06 April 2011 17:37
> > This IANA action was already performed by the RAMS draft, and therefore
> there is no IANA action associated with this
> 
> > parameter. As such it is sensible not to include this section, unless
> you feel it is appropriate to add this draft as a reference in
> Until this becomes an RFC, we need to keep this text around to let people
> know what will be used for this XR block. If the RFC editor feels
> appropriate, she can remove the sentence at that time.
> 
> -acbegen
> 
> > Regards
> >
> > Keith
> >
> > > > > >    multicast acquisition, and causes additional complexity in
> terms
> > > of
> > > > > >    only be sent as a part of an RTCP compound packet, and it is
> sent
> > > in
> > > > > > or might not be deviated from. Otherwise implementors will trat
> it
> > > as a
> > > > > 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
> > > > > >    only be sent as a part of an RTCP compound packet, and it is
> sent
> > > in
> > > > > >    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
> > > > > > However not sure the final sentence correctly expresses what
> should
> > > be

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 7 Apr 2011 06:57:28 -0400

It turns out that iana is enough smart to make that change automatically. They did it before in rfc 5725. 

I think the text right now is quite adequate for it. 

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Apr 2011 13:59:02 +0200

Ali C. Begen (abegen) skrev 2011-04-07 12:57:
> It turns out that iana is enough smart to make that change
> automatically. They did it before in rfc 5725.
> 

One can formulate this so that it is clear that IANA is to update the
registration to now point to this document and transfer the change
control to IETF.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------