Subject: [OPSAWG] draft-ietf-opsawg-operations-and-management-00.txt

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 21 Sep 2007 16:40:49 +0200

I have read the document and here are some minor comments:

1. the document is quite long. I know this is an easy comment as a 
   reader and no so easy to address as an editor.
   but we should realize that WG members who need to read this
   as preparation for their protocol-to-be-developed will be 
   less inclined to do so when the document is too long.

2. Section 4.3.1
 
      [DISCUSS:: 'control plane' and 'data plane' are such slippery
       terms that I think they need to be defined.]

   I don't think we need to define them We are not giving any hard
   recommendations/requirements, just guidelines on how to think 
   about these management aspects. In that context, I don't think
   we need to be precise. So we can avoid many long discussions
   to try to agree on an exact (or at least acceptable) definition.

3. Section 5.1 starts off with
      SNMP [RFC3410] is a Full Standard 
   Well, RFC3410 is Informational. I know that SNMP (Specifically
SNMPv3)
   is at IETF Full Standard level. But people who quickly check the 
   rfc-index for RFC3410 might get confused.

4. Section 6.5

     IPsec Security Policy IPsec Action MIB
     [I-D.ietf-ipsp-ipsecaction-mib] defines a MIB module for
     configuration of an IPsec action within the IPsec security policy
     database (SPD).  [TODO: this is not yet a PS, and has dependencies
on
     a dead document?]

     IPsec Security Policy IKE Action MIB [I-D.ietf-ipsp-ikeaction-mib]
     defines a MIB module for configuration of an Internet Key Exchange
     (IKE) [RFC4306] action within the IPsec security policy database
     (SPD).  [TODO: this is not yet a PS, and has dependencies on a dead
     document?]

   These 2 MIB modules have been back and forth between MIB-doctor
review
   and new revision for many (3-4) years now (cycles are around a year
   at least). As far as I can tell, I do not see them making much (if
   any progress). SO I think we should not discuss them here at all.

Bert Wijnen 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Thursday, September 20, 2007 5:00 PM
To: [email-masked]
Subject: [OPS-AREA] FW:
I-DACTION:draft-ietf-opsawg-operations-and-management-00.txt 

The Guidelines for operations and management of new protocols document
was submitted as OPSAWG I-D. Please use the OPSAWG list for comments and
discussions. 

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 19, 2007 10:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-opsawg-operations-and-management-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Operations and Management Area Working
Group Working Group of the IETF.

	Title		: Guidelines for Considering Operations and
Management of New Protocols
	Author(s)	: D. Harrington
	Filename	:
draft-ietf-opsawg-operations-and-management-00.txt
	Pages		: 37
	Date		: 2007-9-19

   New protocols or protocol extensions are best designed with due
   consideration of operations and management issues related to the
   protocol.  Retrofitting operations and management recommendations to
   protocols is sub-optimal.  The purpose of this document is to provide
   guidance to authors of protocol documents about aspects to consider
   related to the operations and management that should be considered
   for inclusion in documents defining requirements or functionality of
   new protocols or protocol extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsawg-operations-and-man
agement-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then "get
draft-ietf-opsawg-operations-and-management-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE
/internet-drafts/draft-ietf-opsawg-operations-and-management-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/opsawg

---

From: "David Harrington" <[email-masked]>
Date: Fri, 21 Sep 2007 12:12:08 -0400

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Friday, September 21, 2007 10:41 AM
> To: [email-masked]
> Subject: [OPSAWG] draft-ietf-opsawg-operations-and-management-00.txt

>    less inclined to do so when the document is too long.

I agree. there is a lot of redundancy and the document tries to cover
more ground than I think is reasonable; we need consensus on what can
be removed, and what can be combined into more concise text.

Hopefully when we are done, we have a reasonably concise guidelines.
One approach to making it easier for people to use this is to provide
an appendix with a checklist, much like RFC4181, with the explanations
and reasoning for each checklist item described in the main document.

dbh