Re: WG last call on draft-ietf-disman-remops-mib-v2-01.txt

Hi -

As a technical contributor...

> From: "Eduardo Cardona" <[email protected]>
> To: "Juergen Quittek" <[email protected]>; "Randy Presuhn" <[email protected]>; <[email protected]>
> Cc: "Ipcdn List (E-mail)" <[email protected]>
> Sent: Monday, April 26, 2004 7:16 AM
> Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt
...
>   - Is it agreed to add such clauses, that definitely require
>     less funtionality to be implemented?
>
>   - what is the preferred procedure for columnar objects that
>     are not required for minimal compliancy?  We can either
>     allow them to be missing completely.  But this would result
>     in non-consecutive numbering of the remaining objects in
>     the minimal tables.  Or we require them to be implemented
>     as read-only indicating that the feature that they would
>     serve in full compliancy is not supported.
>
> <edo>
> I understand the desire of having normalized process and applications
> that may tune themselves by just reading static values (read-write with
> read-only compliances) as a subset of the full module compliance
>
> It is also understood that some vendors later may complain of 'static'
> requirements as a waist of resources in terms of memory and code. Just
> my note in the disjunctive of the implementer vs the  manager
> approaches.

Since a management application needs to be prepared for missing
rows, missing columns, and "holes" in tables ANYWAY (due to access
control), I think there would be value of read-only compliance is limited
except in the case where there would actually be useful information to read.

> I always though the AGENT-CAPABILLITIES is the best tool for minimize
> devices implementations plus adding a robust layer in the manager side
> to create the vendor, compliance/specific "what if cases", but not very
> used I guess by current tools.

AGENT-CAPABILITIES isn't useful for stating conformance requirements;
it's just a way of saying what a particular implementation can do.

> We Will be ok with the disman group decision in this matter,
>
> </edo>
...

Ok, but we do appreciate ipcdn's input.  We need to be sure the end
result meets their needs.

Randy