Re: comments on draft-ietf-netconf-prot-09

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> IMO we can't write a super-detailed elements of procedure without knowing
> many or all the problems areas, i.e., same input on 2 boxes that supposedly
> support the same data model produce different sets of <rpc-error> elements.
> We need real data from real implementations, indicating interoperability 
> problems.

I was more thinking of errors in the protocol, not data-model related
errors.  As an example, I have to produce some error message if
someone tries to get-config the candidate configuration, if my
implementation does not support it.  Maybe operation-not-supported?
Maybe unknown-element?  Maybe your intention is that it doesn't really
matter and that it's up to the implementation.  I'm just saying that
some guidelines would help.

> Side bar:  We need a monitoring module for NETCONF, especially in
> the early days, to debug the protocol.  I'm working on a set of counters
> (rpcs-rcvd, rpc-replies-sent, rpc-parse-errors, bad-hello-msgs-received, 
> etc.).
> I would really appreciate your input (and all fellow implementors) on this
> initial set of counters. 

Are these supposed to be readable through netconf, i.e. like a
SNMPv2-MIB for SNMP?  How will you specify these objects?  Using
netconfmodel's guidelines?


> >  4.  I understand the separation between the protocol and the
> >      underlying application data model.  But wouldn't it make sense
> >      to state when the result of an operation depends on the data
> >      model?  It's not trivial to understand how the edit-config
> >      operation is supposed to be used without knowledge of the data
> >      model.  For example, the first example in 7.2 is 
> >
> >          Set the MTU to 1500 on an interface named "Ethernet0/0" in
> >          the running configuration:
> >
> >            <interface>
> >              <name>Ethernet0/0</name>
> >              <mtu>1500</mtu>
> >            </interface>
> >
> >      In this example, the manager has to know that the <name> of an
> >      interface is used as a key (or index) by the agent.  If the same
> >      command was issued to an agent which had the <mtu> as key (not
> >      very realistic of course), the result had been quite different!
> >
> >      In fact, does the 'merge' operation make sense at all unless the
> >      manager knows which element(s) are used as key/index?  And if
> >      there are no keys, does 'merge' mean anything?
> >
> >      Again, I understand that the draft defines the protocol and not
> >      the model, but I think it would be helpful to at least make a
> >      note of the problem, and that this has to be solved by
> >      implementations (and/or the netconf modelling effort).  
> >  
> >
> 
> How much should a manager application be able to do without knowledge
> of the underlying networking technology being managed?  How much can
> it do without even loading the domain-specific schema?

I think it's reasonable that the manager loads the domain-specific
schema in order to do useful work.

> In your example, it seems the manager has no schema loaded,
> or you have a schema but you want a standard way to identify instances.

Well, yes I would like that, but that wasn't my point - I just think
it would be helpful if the document mentioned that the semantics of
the edit-config operation is dependant on the data model.  Unlike the
other operations.

I have another comment which I forgot yesterday.  I think the text
about the startup and running configurations could be improved.  I did
not understand what a startup configuration was until I searched the
archives and found a good explanation.


/martin


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>