[AVTCORE] AD review: draft-ietf-avtcore-ecn-for-rtp-06

[Robert Sparks <[e-mail]>]

Summary: Ready for IETF LC with minor issues to address during LC. Watch 
for the IETF LC announcement shortly.

Chairs/shepherd: Please request a review from the SDP directorate.

Please treat these as LC comments:

*) ietf-avt-rtp-no-op is very expired. Are there plans to progress it? 
If not, can you point to something else?

*) Section 5.2's definition of "Block Length" has a bug. This length is 
counting 32-bit words. "not a multiple of five octets" does not make 
sense. It should simply be "not a multiple of five". It might also help 
to say "The number of 32-bit words in the report block" instead of "The 
length of the report block" as the first sentence of the definition?

*) In section 5.1, why is this sentence using 2119: "Thus handling of 
wrapping of these counters MUST be supported".  It's not clear what "be 
supported" means, so it's hard to know what the MUST is constraining.
Is this anything more than a implementation consideration saying "don't 
write code that will crash when
the counter overflows"?

*) Section 7.3.3 paragraph 2. Given this MUST, was the intent to require 
that any such "other reactions"
only be deployed if they were standardized? In the IETF? Can this be 
clarified?

*) In section 10.6, What name are you asking IANA to put in the 
attribute registry? It's not obvious when
reading section 7.2.2. Do you want that to be "ECN", or would it be 
better if it were "ECN-CHECK"?

*) Why isn't the reference to RFC4566 (SDP) normative?

Nits:

Section 1 paragraph 2 first sentence: "is getting attention" will not 
age well.
Section 7.2.2 last paragraph: "SHALL be discard"->"SHALL be discarded"
Section 7.4 first paragraph: How do you reduce an assumption? Should 
this say "The probability this assumption is correct" is reduced?
Section 7.4.1 3rd paragraph: "then the two possible"->"then two possible"
Section 11 first "Denial of service" section: "sender disable the 
usage"->"sender disables the usage"