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

From: "Alia Atlas" <[email-masked]>
Date: Tue, 29 Nov 2016 14:24:59 -0800

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.

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 29 Nov 2016 16:46:11 -0600

On 29 Nov 2016, at 16:24, Alia Atlas wrote:

> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html

Hi Alia,

Did you find Alissa's suggested wording helpful?

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.

Thanks!

Ben.

---

From: Alia Atlas <[email-masked]>
Date: Tue, 29 Nov 2016 17:56:23 -0500

Hi Ben,

> Did you find Alissa's suggested wording helpful?

Not sufficiently....

> 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."

Regards,
Alia

---

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

> 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.)

Thanks!

Ben.