Subject: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-iana-dscp-registry-06: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 06 Jun 2018 03:46:40 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tsvwg-iana-dscp-registry-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 06 Jun 2018 13:40:15 +0100

Thanks for this feedback and for recording your ballot position. Some 
responses below.

Gorry

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-iana-dscp-registry/
I don't know of one. My co-authors and I wrote a paper on observed 
marking behaviour, but not specifically on security considerations.
> nit: Figure 2 does not show the registry *contents*, but rather the
Corect, caption will be changed to:
/The new registry assignment policy is shown in Figure 2./
> Does/should this requirement go away when Pool 1 is completely
I think that would still be OK stand, people should justify a request 
for a specific DSCP value, Pool 3 codepoints are more precious in some 
ways than Pool 1 - because they can have specific properties when deployed.

Gorry

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 7 Jun 2018 08:06:11 -0500

> marking behaviour, but not specifically on security considerations.

Hmm, that might still be useful as an informative reference -- is
there a public version of it I could read?

> ways than Pool 1 - because they can have specific properties when deployed.

Okay, that works for me.

Thanks,

Benjamin