Re: [netmod] review of draft-ietf-netmod-interfaces-cfg-04

[Martin Bjorklund <[e-mail]>]

Hi,

"Alexander Clemm (alex)" <[e-mail]> wrote:
> Hello Martin,
> 
> thank you for your response - some replies below, <ALEX> delineated
> 
> Thanks
> --- Alex
> 
> ...
> 
> 
> > p7 - ifPromiscuousode not mapped because not a configuration object.
> > Agree with this in spirit, but neither is ifIndex, yet it is included.
> > It might be good to add a comment why to keep ifIndex (important for
> > mappings, want it persisted between reboots, etc etc) 
> 
> Actually, ifIndex is not included in the configuration model - it is
> included as a non-config object, in order to facilitate the mapping.
> This document does not assume anything about if/how ifIndex is
> persistent between reboots.
> 
> 
> <ALEX> 
> 
> My comment pertained to the reason that is given for not including
> ifPromiscousMode.

It is writable in the MIB, but does not represent configuration.
Hence it is not included.

ifIndex is not writable in the MIB, so the reason for not including
ifPromiscousMode does not apply to ifIndex.

Do you have a suggestion for some text to make this more clear?

> > p10 - leaf name "A device MAY restrict the allowed values for this
> > leaf...."  It would be good to provide a section that provides clear
> > instructions/ recommendations how to provide such restrictions.  (An
> > implementation will have to be clear on what those restrictions are,
> as
> > ultimately they will need to be validated.)  Section 3.1 could be
> > expanded for this purpose, which already talks about how to augment
> this
> > for interface type specific data.  
> 
> The current text says:
> 
>            Such an implementation MAY restrict the allowed values
>            for this leaf so that it matches the restrictions of
>            ifName.";
>         reference
>           "RFC 2863: The Interfaces Group MIB - ifName";
> 
> This really just refers the reader to the ifName definition (which
> leads to RFC 2579 DisplayString, which in turn references RFC 854).  I
> would prefer to not duplicate this text, but keep the reference.
> 
> 
> <ALEX> 
> 
> The text given in the leaf description makes sense and clearly is all
> that can be specified here.  My comment pertains to the product that now
> wants to implement that.  This implementation may very well (as
> specified here) restrict the allowed values.  How and where are these
> restrictions to be expressed?  One way is to not express these at all.
> In that case, some validation above and beyond what is specified in the
> YANG module needs to occur

Yes, this is the current situation.

> and the rules for that validation are not
> obvious from the YANG module itself.

Correct.  The YANG module doesn't have any formal restriction, but it
allows implementations to restrict values according to the rules of a
DisplayString.

> An alternative would consist in
> introducing an augmentation that defines these additional
> constraints.

Unfortunately, this isn't really possible with standard YANG.  You
cannot add constraints via augmentations.


> I believe the usefulness of the document would be improved if it could
> provide some guidance on how to do that instead of leaving it up to
> readers of the document to figure it out for themselves; it would make
> the spec easier to use and show implementers how the value of YANG-based
> validation can still be derived.  
> 
> </ALEX>


> 
> 
> .....
> 
> > As a side note, if the purpose of this is to turn on or off an
> > interface, have you considered defining this as an RPC?
> 
> No, this is a persistently stored configuration object, so it should
> not be modelled as an RPC.
> 
> <ALEX>
> 
> I understand this is MODELED as a persistently stored configuration
> object, but it doesn't have to be that.  You can also interpret this
> simply as an action.  Just as a consideration, with regards to the
> Netconf-light discussion, if you force people to replace the entire
> configuration each time they plan to enable or disable a single
> interface will seem awkward - just my 2 cents.
> 
> </ALEX> 

I agree with Juergens comment on this one.  If we start to add RPCs to
change some config params, where do we stop?  NETCONF is by design
"document-oriented" (see Juergen's expired
http://tools.ietf.org/id/draft-schoenw-sming-lessons-01.txt) and we
should not change that.


/martin