Subject: [AVTCORE] AD Evaluation draft-ietf-avtcore-rfc5285-bis-08

From: "Ben Campbell" <[email-masked]>
Date: Sat, 25 Mar 2017 11:56:28 -0500

(Apologies, somehow I accidentally pasted some PDF attachements, which 
made the email quite huge. Here's a version without the attachments.)

Hi,

This is my AD evaluation of draft-ietf-avtcore-rfc5285-bis-08. These are 
mostly editorial, but I'd like to resolve at least the substantive 
comments prior to IETF last call.

Thanks!

Ben.

- Substantive:

-- 6, paragraph 3, "... unless the
    transmitter has some (out of band) knowledge..."
Why bother with that exception? It seems like the negotiation is easy 
enough. If people write code assuming that out-of-band knowledge will be 
available, interoperability will suffer.

-- 9, 2nd paragraph:

3264 does not require integrity protection to be _used_, just _provided_ 
(read: MUST implement). Does this mean to promote that to "MUST use"? If 
so, please be clear that this is a new requirement.

But from a practical perspective, do you believe people will really 
follow a "MUST use"? Is it a MUST (BUT WE KNOW YOU WON”T) [RFC6919] ?

- Editorial:

-- 3, third paragraph:

This changes the "... mechanism may be available..." from the original 
to "... mechanism can be available...". I think "may be" is more correct 
here.

-- 4.1.1, first paragraph, first sentence:
This is a statement of principle, and as such shouldn't use 2119 
keywords.

-- 4.1.2, 2nd paragraph: s/len/length  ; or "len field"  (2 occurances)

-- 4.1.2, 3rd paragraph, sentence starting with "Only the extension..."

“Only…MUST” constructs are ambiguous. The can be interpreted to 
say the MUST only applies to the matching set, and the rest are 
undefined. Please recast as “MUST NOT ”. (Note that this construct 
appears elsewhere in the draft, but I think the other occurrences are in 
the original text. I don't expect this update to fix those.)

--- "A transmitter MAY be aware...": That's a statement of fact; the MAY 
should not be capitalized.

-- 4.2, first sentence, first paragraph: The REQUIRED seems to be 
talking about an external requirement from RTP. If so, it should not be 
normative here.

-- 7, 11th paragraph, "Local identifiers in the valid range inclusive in 
an offer or answer
    MUST NOT be used more than once per media section"

The MUST NOT was not capitalized in 5285, probably because it was the 
4th time the requirement was mentioned :-). I don't think it needs to be 
promoted here.

-- 9, 1st paragraph: I don’t think this is an appropriate use of a 
2119 MUST. (It wasn’t capitalized in the original.)

---

From: Roni Even <[email-masked]>
Date: Sun, 26 Mar 2017 19:07:58 +0000

Ben,
See inline
Roni
> available, interoperability will suffer.
[Roni Even] We need it since RFC3264 is not the only usage. For example for declarative SDP there is no negotiation
> follow a "MUST use"? Is it a MUST (BUT WE KNOW YOU WON”T) [RFC6919] ?
[Roni Even] I am OK with changing it to" MUST be implemented"
> to "... mechanism can be available...". I think "may be" is more correct
[Roni Even] OK
> This is a statement of principle, and as such shouldn't use 2119
[Roni Even] OK, is changing to lower case enough? I can add a sentence to section 2 that normative language is written in capital letters in the document.
> -- 4.1.2, 2nd paragraph: s/len/length  ; or "len field"  (2 occurances)
[Roni Even] OK
> the original text. I don't expect this update to fix those.)
[Roni Even] The text says that only one byte or two byte rtp header extensions MUST be used in an RTP packet. I am not sure what is confusing here?
> should not be capitalized.
[Roni Even]OK
> talking about an external requirement from RTP. If so, it should not be
[Roni Even]OK
> 4th time the requirement was mentioned :-). I don't think it needs to be
[Roni Even]OK
> 2119 MUST. (It wasn’t capitalized in the original.)
[Roni Even]OK