I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.   This document provides syntax for specifying a port within a URI for an IPv6 link-local address. I find no security-specific issues with this draft, but I do think the clarity of the draft could be improved a lot, and also, I think that the draft allows options of what is or is not allowed, which could cause confusion for a human using this, since some strings will work sometimes.  I think it would be better to lock down what is and is not allowed.    I'm not fond of the term "zone identifier" (I had to do some Internet searching to figure out what it was). It would only take a sentence to explain it in this draft.  Admittedly, not many people will be reading this draft out of context (like me).   An example of where the wording is needlessly hard to read, and where I think the rule should be a MUST:   " A SHOULD contain only ASCII characters classified    in RFC 3986 as "unreserved", which conveniently excludes "]" in order    to simplify parsing."   That wording could mean that ] is reserved or it could mean that it is not reserved. Turns out (by referring to RFC 3986) "]" is actually reserved. And also, with my preference for specifying mandatory behavior rather than recommendation... perhaps saying something like   " A  MUST NOT contain ASCII characters classified    in RFC 3986 as "reserved".  The character  "]" is reserved, so MUST NOT   be used in the zone ID.     --------- Again,     "The rules in [ RFC5952 ] SHOULD be applied in producing URIs." Why not MUST be applied?   ---------- "we recommend that URI parsers accept bare "%" signs...make it easy for a user to copy and paste a string..."   again, I'd think it would be better to specify what parsers MUST do, rather than saying some parsers can be more lenient, so that the same string will create the same behavior regardless of the implementation parsing it.   --------- similarly   "To limit this risk, implementations SHOULD NOT allow use of this    format except for well-defined usages such as sending to link local    addresses under prefix fe80::/10."   I'd think it would be better to say MUST NOT, and also, to specify what it should do if it receives such a thing.   Radia