Session Traversal Utilities for NAT (STUN) Message Handling for SIP Back-to-Back User Agents (B2BUAs)
draft-ietf-straw-b2bua-stun-08

-- Section 1 --

   For these
   and other reasons, B2BUAs were already being used by SIP domains for
   other SIP and media-related purposes began to use proprietary
   mechanisms to enable SIP devices behind NATs to communicate across
   the NAT.

I can't parse that sentence.  The "began" doesn't seem to be the right part of speech, or maybr the second "for" is wrong.  Something, anyway.

Update: the author has provided good replacement text:
NEW:
For these reasons, B2BUAs were being used by SIP domains for
SIP and media-related purposes. These B2BUAs use proprietary
mechanisms to enable SIP devices behind NATs to communicate across
the NAT.
END

Thanks for addressing Nevil Brownlee's OPS-DIR feedback.

Regards, Benoit

I just finished reading this draft and agree with the SecDir review assessment that this draft does not add additional security considerations.  The SecDir reviewer had some good points on the abstract and introduction that I do think would be helpful to improve the readability of the draft and would like you to consider these updates.

https://www.ietf.org/mail-archive/web/secdir/current/msg05687.html

No objection, but a couple of places where the text seemed rough:

In this text:

   For these
   and other reasons, B2BUAs were already being used by SIP domains for
   other SIP and media-related purposes began to use proprietary
   mechanisms to enable SIP devices behind NATs to communicate across
   the NAT.
   
Does this sentence parse?

In this text:

   The most commonly used approach to solve these issues is
   "restricted-latching", whereby the B2BUA will not latch to any
   packets from a source public IP address other than the one the SIP UA
   uses for SIP signaling.
   
Is the phrase "will not latch to" clear to the intended reader? The sentence is defining a type of latching, but there's not a description of what latching means in the general sense. The following section says terms are defined in https://tools.ietf.org/html/rfc7092, but I didn't see "latch" in a quick text search over there. Is the reference to https://tools.ietf.org/html/rfc7362 earlier in the paragraph also to the description of "latching"?

In this text:

   o  A B2BUA that acts as a simple media relay effectively unaware of
      anything that is transported and only modifies the transport
      header (could be UDP/IP) of the media packets.

   o  A B2BUA that performs a media-aware role.  It inspects and
      potentially modifies RTP or RTP Control Protocol (RTCP) headers;
      but it does not modify the payload of RTP/RTCP.

   o  A B2BUA that performs a media-termination role and operates at the
      media payload layer, such as RTP/RTCP payload (e.g., a
      transcoder).

   When such a B2BUA operating on a media plane is involved in a session
   between two endpoints performing ICE, then it MUST follow the
   behavior described in Section 4.
   
I"m reading "such a B2BUA" as a reference to the third bullet, but it would be clearer to me if both places used the same terms ("operates at the media payload layer" vs. "operating on a media plane").

- 4.2, but maybe also elsewhere: should such a b2bua be
REQUIRED to announce itself as a b2bua that forces itself
into the media stream in some manner? Or more broadly, if we
are now (for the 1st time?) standardising b2bua behaviours,
then ought we mandate that such entities make their
prescence or even some flavour of their functionality known
in-band?  Even if we do not mandate such behaviour,
shouldn't we at least define how a b2bua that wants to be
visible ought do that? (And if we have done the above
already, or discussed and discarded the above already, then
great, and that shows how much I know:-)