Subject: [tram] Adam Roach's No Objection on draft-ietf-tram-stun-pmtud-13: (with COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Tue, 24 Sep 2019 17:03:03 -0700

Adam Roach has entered the following ballot position for
draft-ietf-tram-stun-pmtud-13: 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-tram-stun-pmtud/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing my DISCUSS. I'm keeping the one substantive comment
below, as it is still applicable to the -13 version of the document.

In the general case, STUN servers aren't aware of the signaling protocol that is
in use. For example, when a TURN server is use with RTP and RTCP with a session
set up via SIP, there is no requirement that the TURN server itself have any
inherent knowledge of SIP or RTP or RTCP. From that perspective, the following
text in section 4.2 is a bit confusing and/or problematic:

   Some application layer protocols may already have a way of
   identifying each individual UDP packet, in which case these
   identifiers SHOULD be used in the IDENTIFIERS attribute of the Report
   Response.

It seems odd that I would have to teach my TURN server about the protocols I'm
using it with just so that it can identify the packets.

This behavior, combined with the requirement that all behavior be symmetrical
("As a result of the fact that all endpoints implementing this specification
are both clients and servers") leads me to believe that perhaps the use cases
that drove this mechanism are tightly scoped to direct peer-to-peer uses of ICE,
while the other common uses of STUN (e.g., public TURN servers used for
symmetric NAT traversal) were given no consideration. If that was intentional,
then I think the abstract and introduction need to clearly describe the
scenarios the mechanism was defined for; and, more importantly, clarify that it
does not work for the general case, including STUN servers used for NAT
traversal.

I suspect that, once this mechanism begins to be deployed, the foregoing
limitations will cause operational difficulties, which may in turn suggest
changes to the mechanism that is currently defined.