--On Thursday, August 29, 2013 12:43 -0400 Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote: >> In Section 2: >> >> 'a. The code points must be from a space designated as >> "Specification Required" (where an RFC will be used as the >> stable reference), "RFC Required", "IETF Review", or >> "Standards Action".' >> >> I suggest not having the comment (where) and leaving it to >> RFC 5226 to define "Specification Required". > > Yes, except that's not what this means. > > I tripped over the same text, and I suggest rephrasing it this > way: > > NEW > The code points must be from a space designated as > "Specification Required" (in cases where an RFC will be > used as the stable reference), "RFC Required", "IETF > Review", or "Standards Action". Barry, that leaves me even more confused because it seems to essentially promote "Specification Required" into "RFC Required" by allowing only those specifications published as RFCs. Perhaps, given that this is about Standards Track code points, that is just what is wanted. If so the intent would be a lot more clear if the text went a step further and said: NEWER: The code points must normally be from a space designated as "RFC Required", "IETF Review", or "Standards Action". In addition, code points from the "Specification Required" are allowed if the specification will be published as an RFC. There is still a small procedural problem here, which is that IANA is asking that someone guarantee RFC publication of a document (or its successor) that may not be complete. There is no way to make that guarantee. In particular, the guarantee of Section 2 (c) without constraining the actions that IETF LC can reasonably consider. As I have argued earlier today in another context, language that suggests really strong justification for the tradeoff may be acceptable, but a guarantee to IANA by the WG Chairs and relevant ADs, or even the full IESG, that constrains a Last Call is not. Section 3.2 begins to examine that issue, but probably doesn't go quite far enough, especially in the light of the "four conditions" of Section 2. It would probably be appropriate to identify those conditions as part of good-faith beliefs. It might even be reasonable to require at least part of tee "what if things change" analysis that Section 3.2 calls for after the decision is made to be included in the request for early allocation. Requiring that analysis would also provide a small additional safeguard against the scenarios discussed in the Security Considerations section. Incidentally, while I'm nit-picking about wording, the last sentence of Section 3.3 has an unfortunate dependency on a form of the verb "to expire". Language more similar to that used for RFCs might be more appropriate, e.g., that the beginning of IESG Review (or issuance of an IETF Last Call) suspends the expiration date until either an RFC is published or the IESG or authors withdraws the document. best, john