Subject: [AVTCORE] Alexey Melnikov's No Objection on draft-ietf-avtcore-rfc5285-bis-12: (with COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Tue, 20 Jun 2017 10:01:23 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-avtcore-rfc5285-bis-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In general this is a well written document, but I have a small list of issues
that you should consider fixing:

In Section 5:

   When SDP signaling is used for the RTP session, it is the presence of
   the 'extmap' attribute(s) that is diagnostic that this style of
   header extensions is used, not the magic number indicated above.

You lost me here. Which magic number do you mean here?

In Section 7:

   If an extension is marked as "sendonly" and the answerer desires to
   receive it, the extension MUST be marked as "recvonly" in the SDP
   answer.  An answerer that has no desire to receive the extension or
   does not understand the extension SHOULD remove it from the SDP
   answer.

Why is this not a MUST?

   If an extension is marked as "recvonly" and the answerer desires to
   send it, the extension MUST be marked as "sendonly" in the SDP
   answer.  An answerer that has no desire to, or is unable to, send the
   extension SHOULD remove it from the SDP answer.

As above.

In Section 9:

   In order to prevent DOS attacks, for
   example, by changing the header extension integrity protection SHOULD
   be used.

I can't parse this sentence.

---

From: Roni Even <[email-masked]>
Date: Wed, 21 Jun 2017 05:23:29 +0000

> -----Original Message-----
> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: יום ג 20 יוני 2017 20:01
> To: The IESG
> Cc: [email-masked]; Magnus Westerlund; avtcore-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Alexey Melnikov's No Objection on draft-ietf-avtcore-rfc5285-bis-
> 12: (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> In general this is a well written document, but I have a small list of issues that
> you should consider fixing:
> 
> In Section 5:
> 
[Roni Even] This is "the defined by profile" part of the header extension (rfc3550) specified above as "BEDE" or "100"
This text was in RFC5285 which this document will replace.  I can clarify
", not the magic number ("BEDE" or "100") indicated above"

>    does not understand the extension SHOULD remove it from the SDP
[Roni Even] This text was already in RFC5285. 
>    extension SHOULD remove it from the SDP answer.
[Roni Even] This text was already in RFC5285.
> I can't parse this sentence.
[Roni Even] thanks, will  " In order to prevent DOS attacks, for
   example, by changing the header extension, integrity protection SHOULD
   be used." work better?

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Jun 2017 10:36:52 +0100

Hi Roni,

> On 21 Jun 2017, at 06:23, Roni Even <[email-masked]> wrote:

This is clearer, thank you.

> [Roni Even] This text was already in RFC5285. 

This is not an excuse :-).

Let me rephrase: what are the possible reasons to violate the SHOULD? Leaving this as SHOULD is fine, but adding some examples on reasons to violate it would be much better.

As above.
>   example, by changing the header extension, integrity protection SHOULD

I think it is a bit better. Is this saying "In order to prevent DOS attacks, integrity protection SHOULD be used." and that "by changing the header extension" is one way to do the DOS?

---

From: Roni Even <[email-masked]>
Date: Wed, 21 Jun 2017 11:40:58 +0000

Hi,
These two comments from IESG review ask to change the SHOULD to MUST. Any reason why it is a SHOULD , when does a receiver keep the extension in the SDP.

Thanks
Roni

In general this is a well written document, but I have a small list of issues that you should consider fixing:

In Section 7:

Why is this not a MUST?

As above.

---

From: David Singer <[email-masked]>
Date: Wed, 21 Jun 2017 09:07:36 -0400

> On Jun 20, 2017, at 13:01 , Alexey Melnikov <[email-masked]> wrote:
> 

The one in the RTP packet header

> I can't parse this sentence.

looks like a missing comma

 In order to prevent DOS attacks, for example, by changing the header extension, integrity protection SHOULD
  be used.

David Singer
Manager, Software Standards, Apple Inc.

---

From: Roni Even <[email-masked]>
Date: Thu, 22 Jun 2017 08:30:01 +0000

Hi Alexey ,
Just answering with the open issue from section 7

Reading these two paragraphs I can see the cases for not removing,  I think that the logic is not complete and suggest the following
 
   answer.   An answerer MAY want to respond that he supports the extension and may use it in the future will mark the extension as "inactive"

To clarify: If the answerer is able to send this extension if and when the current offerer change his directionality

 If an extension is marked as "recvonly" and the answerer desires to
   send it, the extension MUST be marked as "sendonly" in the SDP
   answer.  An answerer that has no desire to, or is unable to, send the
   extension SHOULD remove it from the SDP answer. An answerer may want to respond that he support this extension and may send in the future or will be able to receive by marking the extension as "inactive"

Roni

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Jun 2017 10:05:35 +0100

Hi Roni,
This is much better, thank you!

On Thu, Jun 22, 2017, at 09:30 AM, Roni Even wrote:
> Reading these two paragraphs I can see the cases for not removing,  I
> think that the logic is not complete and suggest the following
>  
>    answer.   An answerer MAY want to respond that he supports the
>    extension and may use it in the future will mark the extension as
>    "inactive"
> 
> To clarify: If the answerer is able to send this extension if and when
> the current offerer change his directionality
> 
>   
>    extension SHOULD remove it from the SDP answer. An answerer may want
>    to respond that he support this extension and may send in the future
>    or will be able to receive by marking the extension as "inactive"
> 
> Roni