Ballot for draft-ietf-tsvwg-iana-dscp-registry
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
I am supporting Alissa's question.
The only question this raises for me is whether there are widespread experimental uses of Pool 3 codepoints. If so, will the people using those will be aware of this change, or is the likely impact of collisions not viewed as terribly problematic, or both?
- The use of 2119/8174 keywords seem unneeded for this document. As far as I can tell, there's just a MAY that talks about IANA behavior. - Please define "bleaching".
Is there a good reference already for the security considerations of bleaching the TOS field? That's not really the main point of this document, so I don't want to make you write something from scratch, but since we mention the issue in passing it might be nice to have a reference if one exists. Section 3 The new registry contents are shown in Figure 2. nit: Figure 2 does not show the registry *contents*, but rather the assignment policies. Section 5 The Registration Procedure for use of Pool 3 is "Standards Action" [RFC8126]. IANA is expected to normally make assignments from Pool 1, until this Pool is exhausted, but MAY make assignments from Pool 3 where the format of the codepoint has properties that are needed for a specific PHB. The required characteristics for choosing the DSCP value MUST be explained in the IANA considerations of the document that requests any assignment from Pool 3 Does/should this requirement go away when Pool 1 is completely allocated?
Hello, Alissa's question also came to my mind, so I support her COMMENT. Twice in the document you give a definition to "Standards Action", but it is not strictly identical to the one of 8126. Citing RFC 8126 should be sufficient.