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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 10 Jan 2007 20:18:23 +0200

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> Sent: Wednesday, January 10, 2007 7:57 PM
> To: Romascanu, Dan (Dan)
> Cc: Ma Yuzhi; [email-masked]
> Subject: Re: [NGO] comments on draft-li-ngo-access-mib-00
> 
> Romascanu, Dan (Dan) wrote:
> > 
> >  
> >  
> > 
> >> -----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.
> 
> 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
> 

So, in your view, what should the IETF do next? 

- do work on the 'a combination of common standard parameters, standard
verbs'? and/or
- provide guidance and example to vendors about how to 'do the
groundwork by creating new models that utilize this approach'? or
- none of the above? 

Dan

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

---

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

Hi Dan,

> groundwork by creating new models that utilize this approach'? or

1) Finish, publish, and use draft-romascanu-netconf-datatypes-xx,
    so we can converge on encodings for IETF-related data types.

2) Standardize a direct encoding of SMIv2 modules, based on
    the output of smidump --format=xsd.  The application of
    NETCONF verbs to this data is helpful, but not critical.
    (E.g., if we have a simpleType or element definition for 'ifMtu',
    then it can be used by reference anywhere we want -- like an
    RPC parameter, a new data model, or a notification.)

3) Explore (by design team or individual I-D) the creation of a
    NETCONF management interface for the Interface MIB modules
    and possibly the REMOPS-MIB module as well.  Interfaces are
    important and special in that they have their own config section
    (i.e., each interface instance effectively has a nested <config> sub-root).
    The output would be verbs and data models, and hopefully some implementation experience,
    which could then be considered for standardization.  It is possible
    that multiple teams and solution approaches would need to be considered.

Andy