Subject: LC summary for draft-ietf-opsawg-operations-and-management

From: "David Harrington" <[email-masked]>
Date: Tue, 23 Jun 2009 16:51:03 -0400

Hi,

Here is a summary of Last Call comments:

1) Cullen Jennings told chairs to pay attention; 
[dbh: no action required.]

2) Henning Schulzrinne concerned about slowing approvals, and applying
to new protocols and extensions.
[dbh: added text about the different needs for new protocols and
extensions]

3) Bernard Aboba concerned that IETF should focus on making successful
protocols, and Management Considerations may be an unnecessary
requirement. 
[dbh: this document went to great lengths to say that it was NOT
prescribing a Management Considerations requirement. sigh]
Management support is seldom a show-stopper. Wants differentiation of
need with new protocol versus existing protocols. 
[dbh: added text about the different needs for new protocols and
extensions]

4) IANA - no problem
[dbh: no action required.]

5) Miguel Garcia - GEN-ART + editorial 
[dbh: all comments fixed]

6) Sam Hartman - objects to BCP
* It does not reflect practices across significant areas of the IETF
	interoperable mgmt not required for all protocols
	document focuses on networking devices; document should be
scoped.
	[dbh: removed "primary" goal]
	[dbh: I added some text to "Designing for OPS and Management"
in the Introduction that talks about the traditional approach of using
MIB modules for networking devices, and that emerging technologies
have caused a change to IETF technologies and atrategy, and management
requirements.]
* It does not provide clear, actionable guidelines
	normative requirements vs "might want to consider"
[dbh: added text about "when appropriate," a data model might be
used.]
* It is not sufficiently clear to be understood outside the O&M area.
	fails to make distinctions (ops vs mgmt; config vs other mgmt)
	document organization and discussions jumbled.
[dbh: removed the use of "operations model". It is unclear what the
"model" part refers to. Changed text to discuss operations, and
deployment, etc.]
[dbh: I moved the counter discussion, which was probably the most
jarring context change. I modified a few other places, but some
specific suggestions for changes might be helpful. YMMV]
[dbh: I removed discussions of data and control planes, and tried to
make the discussion general enough to also include services.]

7) Eliot Lear - Informational, not BCP
	section 3.2 needs more applicability discussion
	[dbh: I added some text to "Designing for OPS and Management"
in the Introduction that talks about the traditional approach of using
MIB modules for networking devices, and that emerging technologies
have caused a change to IETF technologies and atrategy, and management
requirements.]
[dbh: changed primary gola from interoperability to "the 
primary goal is the ability to roll out new useful functions and 
services in a way in which they can be managed in a scalable manner, 
where one has understood the network impact (as part of total cost of
operations) for that service."]
	
8) SM - does not scale well for BCP
[dbh: no action required.]

9) Sam (in discussion with Dan) - this document does not indicate that

	a WG can decide "no management is fine".
[dbh: section 4.2 is very clear on that point]

10) Eliot Lear - need applicability scope
	needs to be be smaller document
[dbh: not something I think we can accomplish without a rewrite and
consensus on whether to keep each detail. WG consensus was to not do a
rewrite at this time.]

11) Eric Rosen - opposes BCP status 
[dbh: no action required.]

12) Randy Presuhn - Thinks document is important; prefers
Informational to BCP.
[dbh: no action required.]

13) Joel Halpern - discussion on OPS guidelines versus requirement
[dbh: no action required.]

14) Andy Bierman - discussion of OPS guidelines versus requirement
[dbh: no action required.]

15) Tom Petch - Thinks abstract should be changed. I do not understand
his point well enough to take action, and, as he points out, the
document says it is not trying to solve the problem he raises.
[dbh: no action taken.]

draft-ietf-opsawg-operations-and-management-08 has been posted.

David Harrington
[email-masked]
[email-masked]
[email-masked]

---

From: Eric Rosen <[email-masked]>
Date: Wed, 24 Jun 2009 16:40:50 -0400

Looking through your summary of the LC comments, it appears that there is
considerable sentiment to publish this document as Informational rather than
as a BCP.  Yet the new revision still says "Intended Status: BCP".  

> prescribing a Management Considerations requirement. sigh]

If this document were to proceed as a BCP, the following text could be
interpreted by an AD as license to require a "Management Considerations"
section:

   "Any decision to make a Management Considerations section a mandatory
   publication requirement for IETF documents is the responsibility of
   the IESG, or specific area directors, or working groups, and this
   document avoids recommending any mandatory publication requirements."

Since assigning responsibilities to the IESG is presumably out of scope of
this document, why not shorten this sentence to:
 
        "This document avoids recommending any mandatory publication
        requirements"

---

From: SM <[email-masked]>
Date: Wed, 24 Jun 2009 15:35:04 -0700

Hi David,
>prescribing a Management Considerations requirement. sigh]

The problem is not about what your document is not prescribing.  It 
is about how it may be used.  In Section 1:

   "This document provides guidelines to help protocol designers and
    working groups consider the operations and management functionality
    for their new IETF protocol or protocol extension at an earlier phase."

In an Informational document, guidelines provide guidance.  In a BCP 
document, it can be read as "the IETF community agrees to adopt these 
guidelines".  In Section 1.2:

   "This document does not impose a solution, or imply that a formal data
    model is needed, or imply that using a specific management protocol
    is mandatory."

The catch is in the following sentence:

The IESG could come up with such a requirement for the IETF Stream if 
this document is published as a BCP.

In Section 1.3:

   "The IESG policy to require working groups to write a MIB module to
    provide manageability for new protocols is being replaced by a policy
    that is more open to using a variety of management protocols and data
    models designed to achieve different goals."

The insistence on BCP could be seen as a way to set the stage for that.

>         "This document avoids recommending any mandatory publication

I suggest a slight change to the proposed sentence:

   This document does not recommend any mandatory publication requirements

I also suggest publishing the document as Informational.

Regards,
-sm

---

From: "Tom.Petch" <[email-masked]>
Date: Sat, 27 Jun 2009 11:46:07 +0200

+1

Tom Petch

----- Original Message ----- 
From: "SM" <[email-masked]>
To: "David Harrington" <[email-masked]>; "IETF Discussion" <[email-masked]>
Cc: "Romascanu, Dan (Dan)" <[email-masked]>; <[email-masked]>
Sent: Thursday, June 25, 2009 12:35 AM
Subject: Re: LC summary for draft-ietf-opsawg-operations-and-management

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 27 Jun 2009 08:16:53 -0700

> this document is published as a BCP.

In practical terms, the IESG could come up with that requirement whether this 
document is BCP or not.  Language such as you quoted does not "enable" an IESG 
action; it merely reminds the reader where a particular authority rests.  So the 
concern you raise is a non-sequitor.

More importantly, what is the purpose of having a consensus process for a 
document that has no status reflecting a consensus, particularly when that 
document seeks to alter behavior?

The term guidance means giving direction.  That's not merely informative.  It 
is, by definition, directive.  The IETF's labels for documents that are 
directive are standards track and BCP.

Normative labels (stds trk & bcp) are particularly helpful when the community 
needs to adjust its sense of priorities, to do things it probably should have 
doing all along, but hasn't.  The danger of a normative label, for non-protocol 
documents, is that they can be taken as casting things into Procrustean 
concrete. This draft has language that is reasonable cautious of such 
over-application, although this does require the reader to pay attention to the 
words that are actually written in the document...

If the job of this document were merely to provide a reference about some 
issues, Informational would make sense.  But it has a more directive intent than 
that.  It seeks to get specification writers to include considerations and 
material that has been notably lacking in IETF development work.

That's not merely informational.  It is, by definition, stating a really good -- 
probably even a Best -- current practice for developing specifications.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: SM <[email-masked]>
Date: Sun, 28 Jun 2009 16:47:21 -0700

Hi Dave,

I'll mention that my previous message was to explain to the author of 
the draft my point of view.  Some of the content of this message is 
not directed at you.

At 08:16 27-06-2009, Dave CROCKER wrote:
>In practical terms, the IESG could come up with that requirement 
>whether this document is BCP or not.  Language such as you quoted 
>does not "enable" an IESG action; it merely
>  reminds the reader where a particular authority rests.  So the 
> concern you raise is a

I agree with the basics of what you said.

Most of the references in the ID-Checklist are BCPs.  For example, 
Security Considerations are covered in BCP 72 and IANA Considerations 
in BCP 26.  There's also BCP 32 which has been used in arguments 
about an unrelated Internet-Draft.

There isn't anything explicitly written in the draft that prescribes 
a Management Considerations requirement.  One of the comments on the 
Last-Call mentioned that "Section 1 provides a potential 
justification for imposing such a requirement".  This draft does not 
target Operations and Management Area WG documents only.  The target 
is documents from all areas.  The question the different areas could 
answer is whether it is current practice to have management 
interoperability as part of interoperability.

>More importantly, what is the purpose of having a consensus process 
>for a document that has no status reflecting a consensus, 
>particularly when that document seeks to alter behavior?

The consensus process here is on a document with BCP as the intended status.

I'll read your question as what is the purpose of having a consensus 
process for a document with Informational status.  I think that even 
those documents do seek to alter behavior directly or 
indirectly.  The purpose of a consensus process is that it can 
facilitate conflict resolution.

>Normative labels (stds trk & bcp) are particularly helpful when the 
>community needs to adjust its sense of priorities, to do things it 
>probably should have doing all along, but hasn't.  The danger of a 
>normative label, for non-protocol documents, is that they can be 
>taken as casting things into Procrustean concrete. This draft has 
>language that is reasonable cautious of such over-application, 
>although this does require the reader to pay attention to the words 
>that are actually written in the document...

On the whole, I agree with you there.

>If the job of this document were merely to provide a reference about 
>some issues, Informational would make sense.  But it has a more 
>directive intent than that.  It seeks to get specification writers 
>to include considerations and material that has been notably lacking 
>in IETF development work.
>
>That's not merely informational.  It is, by definition, stating a 
>really good -- probably even a Best -- current practice for 
>developing specifications.

There is currently a Secdir review for Internet-Drafts.  If 
operations and management considerations are included, the documents 
will need an Opsdir review and a mandatory Management Considerations section.

Regards,
-sm

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 29 Jun 2009 12:24:05 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> 
> operations and management considerations are included, the 
> documents will need an Opsdir review and a mandatory 
> Management Considerations section.
> 

Just to clarify - there is an OPS-Dir review process in place now for
Internet-Drafts as well, but no requirement for a mandatory operations
and management considerations section.

Dan