Subject: Re: [straw] Alia Atlas' No Objection on draft-ietf-straw-b2bua-rtcp-15: (with COMMENT)

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 1 Dec 2016 09:58:36 +0100

On Tue, 29 Nov 2016 16:59:53 -0600
"Ben Campbell" <[email-masked]> wrote:

> On 29 Nov 2016, at 16:56, Alia Atlas wrote:
> 
> > Hi Ben,
> >
> > On Tue, Nov 29, 2016 at 5:46 PM, Ben Campbell <[email-masked]>
> > wrote: 
> >> On 29 Nov 2016, at 16:24, Alia Atlas wrote:
> >>
> >> Alia Atlas has entered the following ballot position for  
> >>> draft-ietf-straw-b2bua-rtcp-15: 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-straw-b2bua-rtcp/
> >>>
> >>>
> >>>
> >>> ----------------------------------------------------------------------
> >>> COMMENT:
> >>> ----------------------------------------------------------------------
> >>>
> >>> I agree with Alissa that the set of attributes that fall into each
> >>> category is just not clear or fully specified.
> >>> I'm not sure about better wording - but at least indicating how to
> >>> categorize the different attributes (if listing them
> >>> all isn't reasonable) would help.  Describing the category as
> >>> "those that
> >>> cause issues"' is not helpful.
> >>>  
> >>
> >> Hi Alia,
> >>
> >> Did you find Alissa's suggested wording helpful?
> >>  
> >
> > Not sufficiently....
> >
> >  
> >> The problem is, these can't reasonably be enumerated. It's
> >> basically the
> >> set of any attributes that have implied assumptions that the 
> >> attribute
> >> describes the immediate peer.
> >>  
> >
> > Right, I gathered that the set of attributes was too large - but
> > your response starts to indicate the categories that could be used.
> >
> > I.e. instead of "Any other attributes known to the B2BUA to cause
> > call failures when forwarded SHOULD NOT be forwarded." perhaps
> > something like
> > (wildly out of my core expertise of course)
> >
> > "Some attributes have an implied assumption that the attribute 
> > describes
> > the immediate peer. A clear example of this is the 'rtcp'
> > attribute, which
> > describes the expected peer port. Other attributes might include the
> > immediate peer's IP address, preferred transport, etc. In general,
> > the guideline is to require rewriting of attributes that are
> > implicitly describing the immediate peer. If in doubt during
> > implementation, testing
> > to determine whether a call failure occurs should be done."  
> 
> That seems like a reasonable clarification, assuming the authors
> agree that the new first sentence adequately describes all the
> problematic attributes (that is, there are no attributes I have
> forgotten about that do not have that specific implication, but still
> break things.)
> 

Alia, Ben,

thanks for proposing fixes to the text! I agree this does clarify the
point we were trying to make, and significantly improves the paragraph.
I'll integrate this in the next version of the document.

Thanks!
Lorenzo

> Thanks!
> 
> Ben.
> 
> _______________________________________________
> straw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/straw