Re: [YANG] new pyang errors

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.

>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