I have several comments on this draft. But first, this is a big improvement since the last version I reviewed, so kudos to the authors. A couple of these refer to issues in the document that need to be resolved before it can move forward, but you probably already know what they are. The rest are not showstoppers. It could also use a quick editorial pass, which I'm happy to do for you separately if you like. - Section 3, bullet 7: LTMP -> LMTP - Section 4.1 contains a reference to "esmtp-values" which looks like an ABNF terminal, but it's not explained. Did you mean an ABNF terminal, or did you mean something about ESMTP parameters? - Section 4.2, bullet 2: "Section 6" should probably be in parentheses, probably preceded by "see" - There's a bunch of TBDs that still need to be resolved before this document moves forward (X.7.TBD3 as an enhanced status code, for example) - Section 4.2 makes reference to "the Minimize condition" but the document doesn't otherwise define it - Section 4.3 says "For example, once an MTA accepts a message, the MTA MUST NOT change a (syntactically valid) priority value if the MTA doesn't support it." There seems to be a chicken-and-egg going on here: If the MTA doesn't support the extension, how can it know not to change the priority outbound? - There are lots of SHOULDs in here that might benefit from example situations in which one might deviate from the normative statement containing the SHOULD. - Section 5 and Section 5.1 use "not required", "should", and "may" where RFC2119 is cited earlier. Should they be in all-caps, or should other language be selected? - Section 5: "Irrespectively on" -> "Irrespective of" - Section 5: "fine grainer control" -> "finer-grained control" - Section 5.1 makes reference to "the work-in-progress effort extension to RSVP that prioritizes reservations." This should include a citation even if it references an I-D that's not published yet. - Section 9: "it is advised that all or none of them SHOULD support the PRIORITY extension" sounds awfully mushy. I suggest dropping the SHOULD, and rather say something like "it is advised that either all of them support the PRIORITY extension, or none do". - Section 10 should be resolved before the document advances. - Section 11: Why use "PRI" and not "priority"? The existing set of Received clause names are lowercase words, so it seems strange to deviate. - Appendix A: Can STANAG 4406 be listed in the Informative References? - Appendix D: "This appendix and its subsections are informative." I think that (a) any appendix is informative, because normative text doesn't belong in an appendix; and (b) the normative stuff uses RFC2119 language and this doesn't. Thus, I think this sentence should be removed. (I know I've lost this argument before, but I'll make another stand here anyway.) -MSK _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf