Subject: [OPS-AREA] FW: I-D ACTION:draft-ietf-opsawg-operations-and-management-00.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 20 Sep 2007 16:59:44 +0200

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.
_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 20 Sep 2007 23:15:58 +0100

Hi Dave,

Some thoughts...

The last sentence of the abstract is a bit convoluted. Suggest:
OLD
   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.
NEW
   The purpose of this document is to provide guidance to authors of
   documents that define requirements or functionality of new protocols
   or that define protocol extensions. The guidance is about aspects
   related to operations and management that should be considered for
   inclusion.
===
Introduction. First paragraph.
First sentence rightly refers to new protocols or protocol extensions.
Last sentence refers only to new protocols.
===
   [DISCUSS - This document seems to be just as concerned with the
   protocol designer's "mind-set" and the protocol development process
   as it is with the protocol as a finished product.  While we all agree
   that it would be a good thing to imprint operational sensitivities
   into the consciousness of the protocol developer, I do not think that
   this is a practical goal.  The best that we can do is to set forth a
   list of objective criteria by which a protocol designer can evaluate
   whether the protocol that he/she has developed is manageable.]
I think this point is worth crystalising in the text. But we shoud also
give some guidance about things to include/exclude in order to achieve
the goal of being manageable.
===
   [DISCUSS: - the document may attempt to cover too much ground.  Maybe
   it will develop into a framework document, supported by documents of
   the following sort: . what makes a MIB usable? . how much protocol
   state information needs to be exposed and how? . how much performance
   information needs to be exposed and how?]
Certainly too much detail will render the document unreadable by all but
the management geeks (who we assume are already the converted in this
matter. Better to be short and pithy with pointers to more information
on specific topics in different places.
In fact, a good piece of the docment seems to be about the philosophy
underlying the giving of guidance. maybe that should be separated from
the guidance itself and the philosophy underlying the guidance.
My feeling is that, at 37 pages, it is already unlikely to be read by
many people. That may be unfortunate, but it fact. I think you have to
get your base document down to around 15 pages.
===
   Experiments
   to require such sections have had a mixed reaction from protocol
   developers.
Not for inclusion in the I-D, but have you any details of negative
reactions to such experiments?
===
Section 4 (maybe 4.1?)
It might be interesting to consider extensibility. For example, a MIB
module structure that is open to future protocol extensions or to
proprietary extensions provide greater manageability.
===
Section 4.3.1
   [DISCUSS:: 'control plane' and 'data plane' are such slippery terms
   that I think they need to be defined.]
Probably, this being mainly an IP-centric world, you could use:
- control protocol fault
- data forwarding fault
===
Sections 4.6, 6.5, and 9
I find the subtly of difference between 4.6 and 6.5 hard. Could the
sections reference each other for some clarification?
I think section 9 should at least reference 4.6 and 6.5.
But we also need to consider security vulnerabilities introduced by
management techniques. For example, if you cannot configure a router, it
is hard to make it do bad things. For example, OAM techniques can be
used to swamp the forwarding plane achieving a DoS attack.
===

Hope this is useful.

Cheers,
Adrian