Subject: [OPSAWG] Fwd: Re: I-D ACTION:draft-harrington-operations-and-management-01.txt

From: HarringtonDavid 73653 <[email-masked]>
Date: Mon, 23 Jul 2007 09:35:06 -0400

Subject: Re: I-D ACTION:draft-harrington-operations-and-management-01.txt
From: Brian E Carpenter <[email-masked]>
To: [email-masked]
Cc: Dan Romascanu <[email-masked]>, Ron Bonica <[email-masked]>
Date: Sun, 22 Jul 2007 23:11:10 +0200

Dave,

I'm not sure where this is being discussed, so feel free to forward
these comments, or not, as you feel useful.

One general point I thought was missing was some discussion of which
protocols need O&M considerations more than others. (For example,
I can imagine being much more concerned to instrument the server end
of a client/server protocol.)

 > 3.  Operational Considerations
...
 > Operations and manageability considerations should focus on on-the-
 > wire interoperability, and not constrain implementation decisions.

I don't understand this, and the more often I read it the less
I understand it. The first half (on-the-wire interop) really doesn't
mean anything specific to me for O&M, and the second half seems
directly in conflict with other guidelines such as defining default
values for config parameters.

If it means "focus on externally observable behaviors" that would be
fine, but then say so ;-)

 > 4.  Management Considerations
...
 > Getting everybody to agree on a certain syntax and the protocol
 > associated with that has proven to be difficult.  So management
 > systems tend to speak whatever the boxes support, whether the IETF
 > likes this or not.  The IETF is moving from support for a single
 > management data modeling language and a single management protocol
 > towards support for multiple management protocols and multiple data
 > models suited to different purposes.

This seems to be the place to mention that other SDOs (e.g. DMTF, TMF)
also define management mechanisms and that these mechanisms may be
more suitable than IETF mechanisms in some cases.

 > 4.2.1.  Liveness Detection and Monitoring
 >
 > Liveness detection and monitoring applies both to the control plane
 > and the data plane.

'control plane' and 'data plane' are such slippery terms that I think
they need to be defined.

 > 4.3.  Configuration Management
 >
...
 > It is highly desirable that text processing tools such as diff, and
 > version management tools such as RCS or CVS or SVN, can be used to
 > process configurations.  This approach simplifies comparing the
 > current operational state to the initial configuration.

If we are including XML config in the scope, simple text diffs are
basically useless and more sophisticated tools are needed to make
any useful comparison of versions.

 > 5.  Existing Protocols
...
 > We want to avoid seeming to impose a solution by putting in place
 > a strict terminology - for example implying that a formal data model,
 > or even using a management protocol is mandatory.  If a WG considers
 > that its technology can be managed solely by using proprietary CLIs,
 > and no structured or standardzied data model needs to be in place,
 > this should be fine, but this is a requirement that needs to be
 > explicit in their manageability section,

Consistency issue: later you say that there is no required section.

 > 6.4.  Performance Management

You could mention the IPPM and BMWG work.

 > 7.  Documentation Guidelines
...
 > Making a Management Considerations section a mandatory publication
 > requirement is the responsibility of the IESG, or specific area
 > directors, or working groups, and this document avoids recommending
 > any mandatory publication requirements.

Good. You might also comment that for a complex protocol, a completely
separate draft on O&M might be appropriate. Or even a completely
separate WG.

Hope this helps.

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

---

From: "David Harrington" <[email-masked]>
Date: Mon, 23 Jul 2007 11:12:24 -0500

I'm not sure my earlier forward of Brian's comments will be readable,
so I am resending.

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

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Sunday, July 22, 2007 4:11 PM
To: [email-masked]
Cc: Dan Romascanu; Ron Bonica
Subject: Re: I-D
ACTION:draft-harrington-operations-and-management-01.txt

Dave,

...

...

...

...

...

Hope this helps.

    Brian

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Jul 2007 10:07:25 +0200

Comments from Brian Carpenter. 

Regards,

Dan

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Wednesday, July 25, 2007 12:33 AM
To: [email-masked]
Cc: Romascanu, Dan (Dan); Ron Bonica
Subject: Re: I-D

Dave,

It's very likely you didn't see this before, due to a bad address.
Feel free to forward if desired.

One general point I thought was missing was some discussion of which
protocols need O&M considerations more than others. (For example, I can
imagine being much more concerned to instrument the server end of a
client/server protocol.)

...
> wire interoperability, and not constrain implementation decisions.

I don't understand this, and the more often I read it the less I
understand it. The first half (on-the-wire interop) really doesn't mean
anything specific to me for O&M, and the second half seems directly in
conflict with other guidelines such as defining default values for
config parameters.

...

This seems to be the place to mention that other SDOs (e.g. DMTF, TMF)
also define management mechanisms and that these mechanisms may be more
suitable than IETF mechanisms in some cases.

...

If we are including XML config in the scope, simple text diffs are
basically useless and more sophisticated tools are needed to make any
useful comparison of versions.

...
> We want to avoid seeming to impose a solution by putting in place a 
> strict terminology - for example implying that a formal data model, or

> even using a management protocol is mandatory.  If a WG considers that

> its technology can be managed solely by using proprietary CLIs, and no

> structured or standardzied data model needs to be in place, this 
> should be fine, but this is a requirement that needs to be explicit in

> their manageability section,

...

Hope this helps.

    Brian