Subject: [mpls] Mirja Kühlewind's No Objection on draft-ietf-mpls-egress-protection-framework-06: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Fri, 05 Jul 2019 08:54:13 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mpls-egress-protection-framework-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-mpls-egress-protection-framework/

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

I recommend to use the exact boilerplate text from RFC8174:
      "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here."

Editorial comments:

1) I recommend to either move the requirement section to the appendix or
rephrase this section to outline features of the final framework instead of
stating requirements.

2) section 5.2: "The mechanisms SHOULD be reasonably fast"
Alvaro also commented on this sentence, however, I think the resolution here is
to not use normatively language because that is not needed.

---

From: Yimin Shen <[email-masked]>
Date: Fri, 12 Jul 2019 14:05:57 +0000

Hi Mirja,

Thanks very much for your review and comments! 

Please see inline below for the changes we plan to make accordingly.

Thanks,

-- Yimin

    
    
    Editorial comments:

[yshen] We don't strong opinion on this. We are simply following the common style of many existing RFCs. Will leave it to the editor.

[yshen] Yes, will replace the normative language (MAY/SHOULD/MUST) in this section with may/should/must.