Subject: Re: [Netconf] [netmod] meaning of default

From: Balazs Lengyel <[email-masked]>
Date: Wed, 21 Oct 2009 18:02:24 +0200

Hello,
I have the feeling that we should make with-defaults MANDATORY for all nodes using YANG.
(Currently report-all is the only mode that is mandatory to support in with-defaults.)
Opinions?

Balazs

On 09/01/09 21:30, Phil Shafer wrote:
> Andy Bierman writes:
>> You want to force your way of thinking on everybody
>> else by insisting that your server does not need
>> to ever make the full data-set available to any client,
>> or to even let the client know what sort of 'server-pruning'
>> is being done.
>
> The current scheme in YANG allows the server to behave in any of
> the three styles listed in the with-defaults draft.  We have
> sufficient flexibility to allow you to work the way you want, and
> to allow others to work the way they work.  This is good.
>
> Thanks,
>   Phil
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: [email-masked]

---

From: Phil Shafer <[email-masked]>
Date: Wed, 21 Oct 2009 12:03:31 -0400

>(Currently report-all is the only mode that is mandatory to support in with-defaults.)

I disagree.  There's nothing in YANG that requires with-defaults.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 21 Oct 2009 09:41:41 -0700

> (Currently report-all is the only mode that is mandatory to support in

I was thinking that, until Phil explained to us
that a system-created node (not a YANG default)
is an explicit node.  Every defaults style MUST
return s-c leafs.

The leafs that can get left out are YANG defaults.
Here are some open issues that impact the reliability
of the meta-data the client needs to derive the proper defaults:
I think MUST implement with-defaults is a more user-friendly
solution than the following:

   * Agree that using revision statements is mandatory

   * Agree that the server MUST advertise all its modules in the <hello>

   * Agreed that import/include by revision SHOULD be used in vendor modules
     and MUST (+) be used in standard modules.

   + I am not convinced mandatory import-by-rev is a workable solution.
     I think it will lead to a rats-nest of version dependencies.
     Instead, YANG should specify that the most recent revision date supported
     by the server MUST be used if no revision-date is provided.

     E.g, A -> B -> C, but now A wants to import the new version of C,
     but also wants B to use the same version of C; otherwise
     typedefs/groupings in B are out-of-synch with those in A.

     If vendor(A) is not vendor(B), then updating B may be difficult
     or impossible.  In the IETF, it will mean republishing RFCs
     just to change 1 import-stmt, which could turn into a
     boiler-plate/process nightmare.

> Balazs

Andy