Subject: Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10

From: "Ben Campbell" <[email-masked]>
Date: Thu, 09 Jun 2016 15:51:41 -0500

Hi,

Comments to your email inline. I removed sections that don't seem to 
need further discussion. I will send any comments about the new draft 
revision separately.

Thanks!

Ben.

On 31 May 2016, at 6:12, Lorenzo Miniero wrote:

> On Fri, 27 May 2016 17:17:35 -0500
> "Ben Campbell" <[email-masked]> wrote:

[...]

>
>
> Hello again, Ben,
>
> I just posted a new version of the document (an announcement should 
> get
> to the ML soon) that tries to address most, if not all, of your 
> points.
> You can find some additional comments inline on the parts I haven't
> addressed yet (or I only partly addressed), for one reason or another.
> To make this more readable, I snipped the parts that I already
> integrated.
>
>
>>
>> * The intended status is proposed standard. Do people really expect
>> b2bua vendors to implement the rules in this draft? Do they expect
>> existing b2bua implementations to be updated?
>>
>
>
> I already answered to this in my previous mail, but just to reinstate,
> I'll leave the decision to WG and chairs/ADs as to what the intended
> status should be. I personally would keep it a proposed standard, but
> again wouldn't object to a BCP, if needed.
>

Let's leave this as PS for now, but realize that may change at some 
point as we go forward. As far as getting the WG's opinion goes, it 
might be worth it to send a separate email to the list about this one 
question. Otherwise people may miss it buried in the rest of the review 
comments.

>
>>
>> * Section 3, last paragraph - This paragraph seems to argue that the
>> fact that
>>    existing b2buas do not follow specs is a reason to create more
>> specs. That seems
>>    questionable.
>>
>
>
> Fair point. I haven't changed that part in the doc yet, as I wanted to
> be sure I'd get it right, first. Do you think it would be ok to say
> something along the lines of "due to the mixed nature of B2BUAs, they
> sometimes can't or won't implement all specifications, so they should
> at least do this"?

I think that logic is reasonable.

[...]

>
>
>>
>> * Section 4
>>     * Last paragraph, 2nd to last sentence - If you think people will
>> really pay attention,
>>       then this might be a good place for a MUST or SHOULD
>>
>
>
> Do you mean where we say "behaviour is unspecified and discouraged"? 
> Or
> more in general about the fact that a B2BUA can only follow the
> guidelines when it has access to editing fields without breaking
> hashes? Not sure which MUST or SHOULD we might add there, considering
> that, if the media the B2BUA is encrypted, it can't possibly edit RTP
> related information without disrupting the communication, which in
> turn means no RTCP editing will be needed/possible either.
>
> Do you think a "B2BUAs MUST NOT modify RTP/RTCP data if media is
> encrypted" to be enough, in case?

In retrospect, I wrote that comment without thinking about it in context 
of b2bua-dtls-srtp. Since you already reference that draft, I withdraw 
that comment. No change is really needed.

>
>>
>>      * Third paragraph:
>>          * "It SHOULD NOT, though, blindly forward all SDP
>> attributes,"
>> - Isn’t
>>            the idea that it should forward any attributes that it
>> doesn’t
>>            have a specific reason not to forward? (i.e. default to
>> forwarding?)
>>
>
>
> The issue here is the reason not to forward itself. In order to figure
> out whether an attribute can be forwarded or not, the B2BUA must have
> some knowledge of it and of its impact. What I wanted to highlight in
> that sentence is that there are attributes that, if left where they 
> are
> by a B2BUA unaware of their purpose, can actually cause issues. Just
> think, for instance, of 'rtcp' attribute that is explained in the 
> text,
> or other attributes supporting features a B2BUA may not support 
> itself.
>

Aren't those attributes that the b2bua must, by definition, know about 
and have a "specific reason" not to forward.

> Of course, as you point out there could be reasons to actually keep
> attributes you don't know about in there, e.g., because they advertize
> support for an end-to-end feature the B2BUA doesn't need to worry
> about. Besides, the attributes that can cause issues are probably not
> that many anyway.

Right. One of the big issues with b2buas is that they tend to make SIP 
networks brittle to new features. I think we need to discourage that as 
much as possible. I realize we can't write guidance on how to handle a 
"foo" attribute that works in all cases of "foo", but we can at least 
err on the side of letting things through.

>
> I'll think about a way to make this clearer in the next for next
> version.

Okay.

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 09 Jun 2016 16:04:11 -0500

I did a quick scan of the new revision, and I think it's addressed most 
of my editorial concerns. I encourage the chairs to re-request 
publication as soon as the authors address the one or two outstanding 
items mentioned below.

Thanks!

Ben.

On 9 Jun 2016, at 15:51, Ben Campbell wrote:

> question. Otherwise people may miss it buried in the rest of the 
> review comments.
>
>
>>
>>>
> In retrospect, I wrote that comment without thinking about it in 
> context of b2bua-dtls-srtp. Since you already reference that draft, I 
> withdraw that comment. No change is really needed.
>
>>
>>>
>>>      * Third paragraph:
> networks brittle to new features. I think we need to discourage that 
> as much as possible. I realize we can't write guidance on how to 
> handle a "foo" attribute that works in all cases of "foo", but we can 
> at least err on the side of letting things through.
>
>
>
>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 9 Jun 2016 21:07:35 +0000

(As co-chair)

ACK!

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Ben Campbell<mailto:[email-masked]>
Sent: ‎10/‎06/‎2016 00:04
To: Lorenzo Miniero<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Christer Holmberg<mailto:[email-masked]>
Subject: Re: [straw] Review of draft-ietf-straw-b2bua-rtcp-10

I did a quick scan of the new revision, and I think it's addressed most of my editorial concerns. I encourage the chairs to re-request publication as soon as the authors address the one or two outstanding items mentioned below.

Thanks!

Ben.

Hi,

Comments to your email inline. I removed sections that don't seem to need further discussion. I will send any comments about the new draft revision separately.

Thanks!

Ben.

On Fri, 27 May 2016 17:17:35 -0500
"Ben Campbell" [email-masked]<mailto:[email-masked]> wrote:

[...]

Hello again, Ben,

I just posted a new version of the document (an announcement should get
to the ML soon) that tries to address most, if not all, of your points.
You can find some additional comments inline on the parts I haven't
addressed yet (or I only partly addressed), for one reason or another.
To make this more readable, I snipped the parts that I already
integrated.

  *   The intended status is proposed standard. Do people really expect b2bua vendors to implement the rules in this draft? Do they expect existing b2bua implementations to be updated?

Let's leave this as PS for now, but realize that may change at some point as we go forward. As far as getting the WG's opinion goes, it might be worth it to send a separate email to the list about this one question. Otherwise people may miss it buried in the rest of the review comments.

  *   Section 3, last paragraph - This paragraph seems to argue that the fact that existing b2buas do not follow specs is a reason to create more specs. That seems questionable.

[...]

  *   Section 4
     *   Last paragraph, 2nd to last sentence - If you think people will really pay attention, then this might be a good place for a MUST or SHOULD

Do you mean where we say "behaviour is unspecified and discouraged"? Or

In retrospect, I wrote that comment without thinking about it in context of b2bua-dtls-srtp. Since you already reference that draft, I withdraw that comment. No change is really needed.

 * Third paragraph:

attributes,"
- Isn’t

The issue here is the reason not to forward itself. In order to figure
out whether an attribute can be forwarded or not, the B2BUA must have
some knowledge of it and of its impact. What I wanted to highlight in
that sentence is that there are attributes that, if left where they are
by a B2BUA unaware of their purpose, can actually cause issues. Just
think, for instance, of 'rtcp' attribute that is explained in the text,
or other attributes supporting features a B2BUA may not support itself.

Aren't those attributes that the b2bua must, by definition, know about and have a "specific reason" not to forward.

Right. One of the big issues with b2buas is that they tend to make SIP networks brittle to new features. I think we need to discourage that as much as possible. I realize we can't write guidance on how to handle a "foo" attribute that works in all cases of "foo", but we can at least err on the side of letting things through.

Okay.

---

From: Lorenzo Miniero <[email-masked]>
Date: Fri, 10 Jun 2016 12:29:30 +0200

On Thu, 09 Jun 2016 15:51:41 -0500

> need further discussion. I will send any comments about the new draft 

Hello Ben,

thanks for the additional comments! I just pushed a new version of the
document that addresses the final points of the discussion.

I'll also send a new mail to the list shortly to foster discussion on
the "standards track vs BCP" scope for the document, as you suggested.

Thanks,
Lorenzo

> > addressed yet (or I only partly addressed), for one reason or
> > another. To make this more readable, I snipped the parts that I
> > already integrated.
> >
> >  
> >>
> > I already answered to this in my previous mail, but just to
> > reinstate, I'll leave the decision to WG and chairs/ADs as to what
> > the intended status should be. I personally would keep it a
> > proposed standard, but again wouldn't object to a BCP, if needed.
> >  
> 
> >> * Section 3, last paragraph - This paragraph seems to argue that
> >> the fact that
> > Fair point. I haven't changed that part in the doc yet, as I wanted
> > to be sure I'd get it right, first. Do you think it would be ok to
> > say something along the lines of "due to the mixed nature of
> > B2BUAs, they sometimes can't or won't implement all specifications,
> > so they should at least do this"?  
> 
> >>     * Last paragraph, 2nd to last sentence - If you think people
> >> will really pay attention,
> > hashes? Not sure which MUST or SHOULD we might add there,
> > considering that, if the media the B2BUA is encrypted, it can't
> > possibly edit RTP related information without disrupting the
> > communication, which in turn means no RTCP editing will be
> > needed/possible either.
> >
> > The issue here is the reason not to forward itself. In order to
> > figure out whether an attribute can be forwarded or not, the B2BUA
> > must have some knowledge of it and of its impact. What I wanted to
> > highlight in that sentence is that there are attributes that, if
> > left where they are
> Aren't those attributes that the b2bua must, by definition, know
> about and have a "specific reason" not to forward.
> 
> > attributes you don't know about in there, e.g., because they
> > advertize support for an end-to-end feature the B2BUA doesn't need
> > to worry about. Besides, the attributes that can cause issues are
> > probably not that many anyway.  
> 
> Right. One of the big issues with b2buas is that they tend to make
> SIP networks brittle to new features. I think we need to discourage
> that as much as possible. I realize we can't write guidance on how to