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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf