Re: [YANG] new pyang errors

Phil Shafer wrote:
> Ladislav Lhotka writes:
>> 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.  
> 
> We're crosstalking on the meaning of mandatory again.  My question
> is what's the difference between:
> 
>     leaf mtu {
>         type uint;
>         default 1500;
>         mandatory false;
>     }
> 
> and:
> 
>     leaf mtu {
>         type uint;
>         default 1500;
>         mandatory true;
>     }
> 
> What am I adding by having mandatory set to true?  What
> is the mandatory flag adding?  In my view of "mandatory", the
> mandatory flag means the client must set this, but the server
> has a default which should be used for this, so I'm not seeing
> why the client should be forced to send the server information
> the server already knows.
>  

IMO this overlap between 'default' and 'mandatory' is not relevant.
If mandatory=false, then the default is ignored in the agent.
In your interpretation, mandatory=true causes the agent to
ignore the default.

Your view of mandatory is inconsistent with the rest of YANG,
which (correctly) focuses on the description of valid NETCONF configuration
databases, not the PDUs.  When focusing on the config, what
difference does it make if the manager explicitly sets the mtu to 1500,
or if the agent sets it to 1500 by default?  The data model should describe
what a valid mtu leaf looks like in the config, and nothing more.

Andy

>> 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.
> 
> The application _has_ to rely on meta data to find the value
> for leafs in objects that don't exist.  Even with the :with-defaults
> capability, you won't see defaults for stuff that doesn't exist.
> 
> A YANG module defines a data model.  The client and server agree to
> abide by the constraints and meanings defined in that data model.
> Applications can read this model and understand the data that is
> being manipulated.  The YANG module is by definition out-of-band,
> since it's metadata.
> 
> If you don't want out-of-band resources, what's your interest in
> YANG?  How do you see this helping you?
> 
> 
>>> 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.
> 
> In defining what's valid in the datastore, we implicitly define
> what's valid in the XML.  If the model says:
> 
>      leaf mtu {
>          type uint {
>              range 576..8192;
>          }
>      }
> 
> then you cannot send xml that looks like:
> 
>     <mtu/>
>     <mtu>hot-dog</mtu>
>     <mtu>10</mtu>
>     <mtu>infinitiy minus 3 </mtu>
>     <mtu><maybe>not</maybe></mtu>
> 
>>> 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?
> 
> I don't follow your argument here.  If the factory default config
> for a box doesn't follow the rules defined in the data models
> supported by that box, then there's a bug somewhere.  The data model
> defines what's valid config, so if you don't follow the rules, you
> don't have valid config.  If a parameter is tagged as mandatory
> in the model, it must appear in the factory-shipped config.
> 
>>> 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.
> 
> Completely agree with you, but I don't see a conflict between your
> point and mine.
> 
>> 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
> 
> Here I completely and strongly disagree.  A data model defines how
> data works.  If you tell a client that your support this data model
> and you don't implement "full-name", your telling a fib.  Customers
> will catch you and bludgeon you about the head and shoulders.
> 
> A data model is a contract.  A client application should have faith
> that you are abiding by that contract.  YANG doesn't have a compliance
> mechanism to allow you to avoid parts of the contract, but does
> have "augment" to allow you to extend the contract with additional
> information if required.  But if your box doesn't have a place to
> put "full-name", it shouldn't be advertising the capability for
> that data model.
> 
> We're looking to build strong and binding underpinning for future
> data models and the applications that rely on them.  If a box
> doesn't abide by a data model that it advertises, it's a bug.
> 
>> (ii) allow only one user - so, login=admin and uid=0 are effectively
>> hardwired.
> 
> Then your factory default config should look like:
> 
> system {
>     login {
>         user admin {
>             uid 0;
>         }
>     }
> }
> 
> We should note that YANG does not cover factory-default configs.  But
> factory-default configs should follow the rules in the YANG data model.
> 
> Thanks,
>  Phil
> 
> 
> _______________________________________________
> YANG mailing list
> YANG@ietf.org
> https://www1.ietf.org/mailman/listinfo/yang
> 
> 

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