Subject: RE: [NGO] comments on draft-li-ngo-access-mib-00

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 10 Jan 2007 15:02:54 +0200

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> 
> IMO, the "new" Interfaces MIB would not strictly follow the IF*-MIB.
> For example, why split the ifTable and ifXTable? They are 
> only separate because they were created years apart.  Why not 
> use a real tree instead of the ifStackTable?  How about some 
> standard methods for interface services, like install, 
> uninstall, start, stop, restart, status, etc?  How about a 
> mechanism to determine what parameters are actually 
> configurable on a particular interface instance?
> 

Sure. Without these or most of these we would have missed one of the
principal reasons of doing NETCONF. 

Now, how do we get from here to there? It is allowed to rock the boat I
believe, but we cannot afford drying up the whole ocean. 

Dan

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 10 Jan 2007 09:57:09 -0800

> believe, but we cannot afford drying up the whole ocean. 

I'm not sure how your mixed metaphors map to standards-based configuration,
or if there is common understanding of the problem space.  IMO, the new API
has no need to support anything from the SNMP world except the ability to
reuse the semantics of SMI data types, some TEXTUAL-CONVENTIONs, and
perhaps some OBJECT-TYPE and NOTIFICATION-TYPE macros.

The data structures and RPC methods that use them should not be
constrained by how someone using SNMP would approach a solution.

IMO, special RPCs serve 3 critical functions, that SNMP can't touch:

1) Ability to extend the standard verb set (e.g., start, stop, reset, ping)

2) Ability to encapsulate complex and multi-step procedures, and hide
    variances in the low-level details (e.g. create-vlan, add-bgp-peer, create-loopback).
    If the agent provided these high-level procedures, the NMS would not
    have to manage the dozens or even 100s of little differences in PDU order,
    acceptable value sets, error-codes, etc., in order to provide the same
    high-level procedures across all devices.

3) Ability to model actions and a "Set PDU with a return value".
    RPCs allow one to say "I don't care what the values
    of index X or parameter Y are; just return the values you picked
    in the response."

I don't think the IETF would (or should) move in this direction
unless and until vendors do the groundwork by creating new models
that utilize this approach.

I am concerned that the Ultimate Goal (everybody uses the same exact
config-file/CLI/XML data models) is not going to be achievable,
and therefore <edit-config> will not have a lot of standards-based
configuration data to work on.  I do not think this is a show-stopper.

If we could agree on some high-level verbs (and their parameters),
then it is less problematic if the XML blob saved in the <config> element
is not the same every time for every agent.  Perhaps a combination
of common standard parameters, standard verbs, and vendor extensions
to both of them would be possible.  If writable standard MIB objects already
exist for a particular data model, then they should be used somehow,
but not necessarily in the same MIB table form.

> Dan

Andy