Subject: [Pce] Murray Kucherawy's No Objection on draft-ietf-pce-association-policy-15: (with COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Tue, 19 Jan 2021 23:52:23 -0800

Murray Kucherawy has entered the following ballot position for
draft-ietf-pce-association-policy-15: 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-pce-association-policy/

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

The use of BCP 14 language in Sections 9.1 and 9.2 seems awkward, since it
appears to be discussing operator-facing features of an implementation rather
than interoperability concerns.  See, in particular, Section 6 of RFC 2119.

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Wed, 20 Jan 2021 19:50:56 +0000

Hi Murray,

Thanks for your comment! As an operator, this is my fav question to reply😊

Use of BCP 14 language for a manageability section has long been a practice in our pce documents and other documents (of my groups). We learned from our previous (famous on manageability) AD how important this section was to include.

Some pointers:

RFC5706 (an ops document (2009)) section 3.1 provides a great description on why management interoperability needs to be considered just as important as protocol interoperability. Without management interoperability, one will not have protocol interoperability.

RFC6123 (our famous AD (2011)) "Inclusion of Manageability Sections in PCE Working Group Drafts"

BCP14 language was used in the manageability section of RFC5440, the original PCEP protocol definition RFC.

I'd recommend all Areas to seriously consider RFC5706 recommendations. Adrian and others had hoped to have it on the same level as the attention given to the Security section. And I see Warren often making note of the missing information. YANG does help, but there is a real risk to not include general recommendations in the original protocol specification (especially for vendors still hammering away on CLI).

Thanks!
Deborah

-----Original Message-----
From: iesg <[email-masked]> On Behalf Of Murray Kucherawy via Datatracker
Sent: Wednesday, January 20, 2021 2:52 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Hariharan Ananthakrishnan <[email-masked]>
Subject: Murray Kucherawy's No Objection on draft-ietf-pce-association-policy-15: (with COMMENT)

Please refer to https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!BhdT!3k8TAUIlAYWnSZPKQDDwXstUDsX4rjmnzNMWr8te166VvTz5u7w2Y6zVGVOeGg$ 
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-pce-association-policy/__;!!BhdT!3k8TAUIlAYWnSZPKQDDwXstUDsX4rjmnzNMWr8te166VvTz5u7w2Y6zj3SGYbw$

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 20 Jan 2021 20:36:56 -0800

On Wed, Jan 20, 2021 at 11:51 AM BRUNGARD, DEBORAH A <[email-masked]> wrote:

> Use of BCP 14 language for a manageability section has long been a
> practice in our pce documents and other documents (of my groups). We
> learned from our previous (famous on manageability) AD how important this
> section was to include.
>
> Some pointers:
>
> RFC5706 (an ops document (2009)) section 3.1 provides a great description
> on why management interoperability needs to be considered just as important
> as protocol interoperability. Without management interoperability, one will
> not have protocol interoperability.
>
> I'd recommend all Areas to seriously consider RFC5706 recommendations.
> Adrian and others had hoped to have it on the same level as the attention
> given to the Security section. And I see Warren often making note of the
> missing information. YANG does help, but there is a real risk to not
> include general recommendations in the original protocol specification
> (especially for vendors still hammering away on CLI).
>

Hi Deborah,

Thanks for this context.  I hadn't encountered this sort of use of BCP 14
language this way before which is why I was puzzled.

I'm looking at RFC 5706 and it specifically avoids BCP 14 key words,
perhaps to avoid exactly the thing that caught my attention.  But yes, it
was an interesting perspective.

-MSK