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

["DRAGE, Keith (Keith)" <[e-mail]>]

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

Keith

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:[e-mail]]
> Sent: 05 April 2011 18:58
> To: DRAGE, Keith (Keith); draft-ietf-avtext-multicast-acq-rtcp-
> [e-mail]
> Cc: [e-mail]
> Subject: RE: Comments on draft-ietf-avtext-multicast-acq-rtcp-xr-01 in
> preparation for pub request
> 
> Keith,
> 
> > -----Original Message-----
> > From: DRAGE, Keith (Keith) [mailto:[e-mail]]
> > Sent: Tuesday, April 05, 2011 12:25 PM
> > To: Ali C. Begen (abegen); draft-ietf-avtext-multicast-acq-rtcp-
> [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.
> 
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!

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

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

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

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

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.
> 
> I am not sure whether this will be clearer but I will look into it.
> 

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.

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




> >
> > 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.
> 
Please do. I like requirements in the active!


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


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


> 
> -acbegen
> 
> >
> > Regards
> >
> > Keith