Subject: [ippm] Murray Kucherawy's Discuss on draft-ietf-ippm-capacity-metric-method-06: (with DISCUSS and COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Wed, 24 Feb 2021 23:46:26 -0800

Murray Kucherawy has entered the following ballot position for
draft-ietf-ippm-capacity-metric-method-06: Discuss

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-ippm-capacity-metric-method/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Several of the SHOULDs in this document are giving me trouble.  There are two
main categories, one in particular I'd like to discuss:

As described in RFC 2119, we typically use this sort of language to describe
interoperability or security concerns.  How are the SHOULDs in Section 9
related to interoperability or security?  Rather, they seem to be describing
issues of presentation.  Or is this another instance of the "operational
advice" exception that's come up on other operational advice documents?

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

Similar to my DISCUSS POINT:

Since a SHOULD leaves an implementer with a choice, it's preferable to see
prose explaining why one might deviate from the SHOULD advice.  Thus, the
SHOULDs in Sections 5.3 and 6.3 leave me wondering under what circumstances an
implementer might legitimately choose to do something else.  If there are none,
should it be a MUST?