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

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Tue, 9 Jan 2007 15:39:01 +0200

> -----Original Message-----
> From: Andy Bierman [mailto:[email-masked]] 
> The real issue is "what problem are you trying to solve"?
> 
> Is this supposed to be a mechanism to manipulate XML/MIB data 
> (derived from SMI-based schema) with NETCONF operations, or 
> is it a mechanism to tunnel SNMP protocol operations through 
> the NETCONF protocol?
> 
> I think it is supposed to be the former, and therefore 
> several decisions have to be made (e.g., how to move 
> RowStatus and StorageType data to NETCONF operations, how to 
> encode INDEX clauses, how to deal with data in different contexts).
> MaxRepetitions and even GetNext/GetBulk operations are not 
> relevant to NETCONF.
> 

This is coming close to a discussion that we should have sooner or later
about what will be the operational model in networks that run NETCONF
and how other protocols fit in this model. I believe that we vaguely
agree that the model will be multi-protocol, but there are yet many
aspects of what kind of data models support each, and if a common data
model will support only data or also protocol operations. To some extent
I believe that this proposal adopts the later approach, which is
probably necessary in a transitional phase, but not necessarily long
term. 

> We need a standard which specifies the details of "smidump 
> --format=xsd", and not much else (ignoring VACM for the 
> moment ;-).  Ideally, there would not need to even be an 
> <snmp-data> wrapper, and <ifTable> could be just another data 
> model in just another namespace, and not be treated special.
> This is probably not possible though, without moving the 
> <snmp-data> attributes to the RPC method as parameters.
> 
> 

Dan

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

---

From: Ma Yuzhi <[email-masked]>
Date: Wed, 10 Jan 2007 11:05:06 +0800

Hi, 

                                                                  smidump
Transitional Phase:  SMIv1/v2 MIB ---------------------> XSD MIB
 
\
 
\
 
\   
Long term target:
-------------> New MIB for multi-protocol

Base on the above assumption, here are some considerations:
1. If the XSD MIB and New MIB are quite distinct from each other, then there
maybe need another transition which is a terrible thing.
2. Is it necessary to keep the compatibility (just like SMIv1 and SMIv2 MIB)
between these two MIBs?  Is this a possibility work?
3. Maybe a more powerful tool "smidump++" could help us to  achieve middle
term target which can keep balance between above targets. 

Thanks 
Yuzhi

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: Tuesday, January 09, 2007 9:39 PM
> To: Andy Bierman; Li Yan
> Cc: [email-masked]
> Subject: RE: [NGO] comments on draft-li-ngo-access-mib-00
> 
> 
> 
>  
>  
> 
> > From: Andy Bierman [mailto:[email-masked]] The real issue is 
> > "what problem are you trying to solve"?
> > 
> > Is this supposed to be a mechanism to manipulate XML/MIB 
> data (derived 
> > from SMI-based schema) with NETCONF operations, or is it a 
> mechanism 
> > to tunnel SNMP protocol operations through the NETCONF protocol?
> > 
> > I think it is supposed to be the former, and therefore several 
> > decisions have to be made (e.g., how to move RowStatus and 
> StorageType 
> > data to NETCONF operations, how to encode INDEX clauses, 
> how to deal 
> > with data in different contexts).
> relevant to 
> > NETCONF.
> This is coming close to a discussion that we should have 
> sooner or later about what will be the operational model in 
> networks that run NETCONF and how other protocols fit in this 
> model. I believe that we vaguely agree that the model will be 
> multi-protocol, but there are yet many aspects of what kind 
> of data models support each, and if a common data model will 
> support only data or also protocol operations. To some extent 
> I believe that this proposal adopts the later approach, which 
> is probably necessary in a transitional phase, but not 
> necessarily long term. 
> 
> moment ;-).  
> > Ideally, there would not need to even be an <snmp-data> 
> wrapper, and 
> > <ifTable> could be just another data model in just another 
> namespace, 
> > and not be treated special.
> <snmp-data> 
> > attributes to the RPC method as parameters.
> > 
> > 
> 
> Dan
> 
> 
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 09 Jan 2007 20:06:29 -0800

> term target which can keep balance between above targets. 

I'm not sure we have much consensus on what the "New MIB" looks like,
or that the "MIB" is even the focus of the new programmatic interface.

We should keep hammering on the Interfaces MIB examples, because that
is one of the most important feature of an NE device.

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?

The smidump++ program can't figure out how to make these sorts of changes.
As a transition mechanism, the existing smidump translation is good enough
for "direct" access with the NETCONF protocol.

As for the edit-config operation attribute, I have always said it is
a data model specific matter whether all of the enumerations were supported.
It would be ideal if these operations were always supported the same way
on every object, but some data models (e.g., CLI and SNMP transition data models)
do not use those operations, and "merge" is always assumed instead.
(Not pretty but it works.)

Note that if the default-operation is left alone (default is 'merge'),
then the complete absence of the 'operation' attribute in the
<config> element will have the same (correct) outcome.

For the transition model, the standard operations can be used
(without the operation attribute), and RowStatus used to
create and delete rows.

> Yuzhi

Andy

---

From: Ma Yuzhi <[email-masked]>
Date: Wed, 10 Jan 2007 12:04:19 +0800

Hi,

Sorry,the chart of previous email have some problems, I convert it to HTML
formal 

                                      smidump 

Transitional Phase:  SMIv1/v2 MIB ---------------------> XSD MIB
                                                              \
                                                               \
                                                                \   
Long term target:                         -------------> New MIB for
multi-protocol

Thanks
Yuzhi

> From: Ma Yuzhi [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2007 11:05 AM
> To: 'Romascanu, Dan (Dan)'; 'Andy Bierman'
> Cc: [email-masked]
>     smidump Transitional Phase:  SMIv1/v2 MIB
> ---------------------> XSD MIB
> 
> \
> 
> \
> 
> \  
> Long term target:
> 1. If the XSD MIB and New MIB are quite distinct from each
> other, then there maybe need another transition which is a
> terrible thing.
> 2. Is it necessary to keep the compatibility (just like SMIv1
> and SMIv2 MIB) between these two MIBs?  Is this a possibility work?
> 3. Maybe a more powerful tool "smidump++" could help us to 
> achieve middle term target which can keep balance between
> above targets.
>
> Thanks
> Yuzhi
>
> > This is coming close to a discussion that we should have sooner or
> > later about what will be the operational model in networks that run
> > NETCONF and how other protocols fit in this model. I
> believe that we
> > vaguely agree that the model will be multi-protocol, but
> there are yet
> > many aspects of what kind of data models support each, and
> if a common
> > data model will support only data or also protocol
> operations. To some
> > extent I believe that this proposal adopts the later
> approach, which
> > is probably necessary in a transitional phase, but not necessarily
> > long term.
> >