Subject: [OPSAWG] RE: [OPS-AREA] comments ondraft-harrington-operations-and-management-00

From: "David Harrington" <[email-masked]>
Date: Wed, 12 Sep 2007 19:26:23 -0400

Hi Bert,

comments inline

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Friday, March 16, 2007 11:45 AM
> To: [email-masked]
> Subject: RE: [OPS-AREA] comments 
> ondraft-harrington-operations-and-management-00
> 
> - I wonder if we should discuss (at all) the use/need of COMPLIANCE
>   specifications. We know that we have tools in SMI for MIB modules,
>   but we also know that it is not easy to use and certainly the
>   sysORTable in the SNMPv2-MIB module seems not much/often used by
> agents
>   to report how they comply with a MIB module compliance.

I think a major issue with the sysORTable is that it is a pointer to
an external document that describes whether it conforms or not.

> 
>   Maybe the topic is not easy to discuss/describe in general. But if
>   we do include it, I think it should tend toward generic/genral 
>   aspects of it and not go in details about the SMI methods.

Are you suggesting MUST/SHOULD statements to refer to compliance
levels for management data models, such as MIB modules? For example,
the ENTITY-MIB has multiple levels of compliance, to better
accommodate what makes snese in certain hardware/software
architectures, and some MIB modules define compliance levels for
read-only implementations and for read-write implementations.

I think IEEE defines as part of the standard what MUST be supported to
claim compliance, even for their management objects.

I certainly think a manageability considerations discussion could say
that an implementation SHOULD support, for example, the
qBridgeCompliance2 level for the Q-BRIDGE-MIB to provide interoperable
management.

> 
> Bert
>   
> 
> _______________________________________________
> OPS-AREA mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ops-area
> 

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

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Sat, 15 Sep 2007 11:04:53 +0200

inline

Bert Wijnen  

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, September 13, 2007 1:26 AM
> To: Wijnen, Bert (Bert); [email-masked]
> >   agents to report how they comply with a MIB module compliance.
> 
> I think a major issue with the sysORTable is that it is a 
> pointer to an external document that describes whether it 
> conforms or not.
> 

I agree that that is an important factor.

> Are you suggesting MUST/SHOULD statements to refer to 
> compliance levels for management data models, such as MIB 
> modules? For example, the ENTITY-MIB has multiple levels of 
> compliance, to better accommodate what makes snese in certain 
> hardware/software architectures, and some MIB modules define 
> compliance levels for read-only implementations and for 
> read-write implementations.
> 

We are talking about "management consierations". Not about being very
explicit w.r.t. MUST/SHOULD. are we?

> I think IEEE defines as part of the standard what MUST be 
> supported to claim compliance, even for their management objects.
> 

They have a MIB MODULE with MODULE-COMPLIANCE(s).
They also have their PICS.

> I certainly think a manageability considerations discussion 
> could say that an implementation SHOULD support, for example, the
> qBridgeCompliance2 level for the Q-BRIDGE-MIB to provide 
> interoperable management.
> 

I guess so.... but I thought we were doing this document in order to
allow for people who do not do MIB for their protocols to still do
a discussion on how to manage their protocol. So giving examples
on how one can specify compliance using a MIB module seems not
the nost helpful in that case, is it?

Bert