Re: [YANG] new pyang errors

Phil Shafer píše v Čt 24. 01. 2008 v 10:49 -0500:
> 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;
>     }

An implementation may include this leaf or not. In the latter case it
doesn't exist at all, no default is defined. Hence the device must be
able to live without any MTU value available (this is of course
impossible for Ethernet). If the mtu leaf exists in an implementation,
it has to start with the default value of 1500, unless and until a
client changes it (which may or may not be possible).

> 
> and:
> 
>     leaf mtu {
>         type uint;
>         default 1500;
>         mandatory true;
>     }

Here every implementation conformant to this data model must have this
leaf. The interpretation of the default statement is as above.

In my interpretation the mandatory/optional and default concepts are
orthogonal. The former relates to the structure (leaf must or needn't
exist) whereas the latter to the value.
> 
> 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.

I understand what you are saying but I don't like it because it
introduces yet another meaning of validity with respect to a YANG data
model. We already had three:

1. validity of NETCONF PDUs
2. validity of entire configurations
3. managed device behaviour (e.g., must set the defaults)

Your view of mandatory brings another one:

4. client behaviour (must set mandatory parameters)

Each of these views differs in some aspects from the others. I would
myself prefer to concentrate on 2 and try to infer what it means for 1.

>  
> >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.

If it doesn't exist because the data modeller decided the leaf is
optional, I have to be able to live without it. If it is mandatory, then
I must be able to get it from the device via get-config
(modulo :with-defaults).

> 
> 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?

I'd be happy with items 2 and 1 above.

> 
> 
> >> 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:

In some cases this mapping is automatic, some cases are defined in the
YANG draft and some are not clear yet (to me at least).

> 
>      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.

In my view of mandatory the factory default configuration must be (and
is) valid. In your view, if I understand it correctly, it is not valid
till the client sets the mandatory parameters.

> 
> >> 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.

No, since it's optional (but of course lada:optional != phil:optional).
Both the device and manager can live without full names being in the
database.

> 
> 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.

Again, my model: if a parameter is optional then the client cannot be
surprised if it is not in the configuration obtained by get-config and
attempts to set it are ignored or return a warning.

> 
> 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.

I fully agree, we only differ in the interpretation of a YANG statement.
The confusion is due to an interplay between mandatory/optional and
defaults. As I said, I treat them as orthogonal and actually don't need
the defaults at all. I'd also say my interpretation is in accord with
section 7.6.4 of the YANG draft.

> 
> >(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;
>         }
>     }
> }

Actually I had this in mind, but it doesn't matter:
users {
  user {
         login admin;
         uid 0;
  }
}

The point is that both admin and uid values are read-only.

> 
> We should note that YANG does not cover factory-default configs.  But
> factory-default configs should follow the rules in the YANG data model.

Yes, factory default config should be valid.

Cheers, Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

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