Reviewer: Eric Vyncke Review result: Serious issue Document reviewed: draft-ietf-tram-stun-pmtud-10 Hi, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft proposes two specific methods (Simple & Complex) for a UDP/STUN based Packetization Layer Path MTU Discovery (RFC 4821) but sending probes of increasing sizes and detecting errors or loss. Please note that I am not a STUN expert. I found the document sometimes a little unclear. I see several serious issues: 1) This draft does not address IPv6 at all (while STUN RFC 5389 has IPv6 parts). Section 4.1 DF does not exist in IPv6 ! 4.1.3 there is no ‘fragmentation needed’ in IPv6 but well ‘Packet too big’ (same issues apply for section 4.2) 2) Little is said on how to address section 4.1.1 “Client knows that the Server supports the protocols before sending the probes.” Is there a *fallback mechanism* when the Client wrongly assumed that the Server supports this specification? 3) Is this only a one-way path MTU detection? What about asymmetric routing where packets from Server to Client take a different path (hence a different path MTU)? Or is I misread the draft, then I would suggest to rename client/server to initiator/responder ? There are also a couple of minor issues: 1) How will this protocol be supported/affected if there is a (awful) middle-box (NAT, Firewall) inspecting the STUN payload? 2) The draft is unclear whether the Simple method has to be executed before transmitted data UDP packets 3) What about a mcast “Server”? The draft should at least mention that the Server must by unicast/anycast 4) Section 4.2.5 How is the checksum computed? I hope that this will help to produce a better document because a solid specification will be helpful. Regards -éric