Re: [YANG] new pyang errors

Phil Shafer píše v St 23. 01. 2008 v 15:58 -0500:
> Ladislav Lhotka writes:
> >My definition of mandatory: mandatory configuration parameters are those
> >that are essential for device or protocol operation. It doesn't matter
> >whether they are set by the user/application, supplied from non-volatile
> >memory or perhaps even hardwired.
> 
> Why would you need or want to mark is as mandatory if the value
> is hardwired?  What are you trying to say by calling a parameter
> "mandatory" and who are you trying to say it to?

Example: there are many devices out there that have fixed Ethernet MTU
value (1500). Such a device can certainly use a DM that specifies MTU as
mandatory. It will just fill in this slot with the hardwired value and
report a run-time error if a client tries to change it.  

> 
> If the application need do nothing with such hardwired parameters,
> why does it need to distinquish them?

The application needs to know what the value is (as in the case of MTU).
I don't want to rely on out-of-band resources. We also have get-config,
not only edit-config.

> 
> If the device need to nothing <ditto>?

<ditto>

> 
> YANG defines constraints on the XML that passes between the client and
> server.  Nearly every statement in a YANG module defines a rule which
> that XML must follow, both during protocol operations and the valid
> configuration being built.

I don't agree. YANG models mostly define constraints on the entire
content of the config datastore, less so on the XML PDUs.

> 
> Mandatory is such a constraint, and should be an indication to the
> NETCONF client application that it needs to do something explicit
> to satisfy this constraint.  If the mandatory parameter isn't set,
> the configuration isn't valid.

I disagree again: this would mean you cannot change the factory default
configuration part by part. Should the factory default configuration be
marked invalid until the client application touches all mandatory
values?

> 
> If we allow this mandatory constraint to be satisfied via mechanisms
> that do not involve the client and server, why have it?  How is the
> application to discern the difference between a real constraint and
> a parameter that the fairy god mother daemon fills in?

The mandatory/optional property should be specified by the data modeller
and not depend on the way how it is implemented in different devices.
Example: in an authentication database DM, the login, uid and password
are mandatory while full-name is optional. IMO this DM is perfectly
usable also by devices that either
(i) don't implement the full-name slot, or even
(ii) allow only one user - so, login=admin and uid=0 are effectively
hardwired.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang