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

Hi,

Where did we end up with this?

Thanks!

Ben.

On 9 Jun 2016, at 16:07, Christer Holmberg wrote:

> (As co-chair)
>
> ACK!
>
> Regards,
>
> Christer
>
> Sent from my Windows Phone
> ________________________________
> From: Ben Campbell<mailto:ben@nostrum.com>
> Sent: ‎10/‎06/‎2016 00:04
> To: Lorenzo Miniero<mailto:lorenzo@meetecho.com>
> Cc: 
> draft-ietf-straw-b2bua-rtcp.all@ietf.org<mailto:draft-ietf-straw-b2bua-rtcp.all@ietf.org>; 
> straw@ietf.org<mailto:straw@ietf.org>; Christer 
> Holmberg<mailto:christer.holmberg@ericsson.com>
> 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.
>
> On 9 Jun 2016, at 15:51, Ben Campbell wrote:
>
> 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" ben@nostrum.com<mailto:ben@nostrum.com> 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.

> _______________________________________________
> straw mailing list
> straw@ietf.org
> https://www.ietf.org/mailman/listinfo/straw