Subject: Re: [netmod] review of draft-ietf-netmod-rfc6020bis-08.txt

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 01 Nov 2015 22:12:20 +0900

Martin Bjorklund <[email-masked]> writes:
>
>> Sec. 1.1
>>    o  Made "when" and "if-feature" illegal on list keys, unless the
>>       parent is also conditional, and the condition matches the parent's
>>       condition.
>> 
>>   - This contradicts text in
>>    7.20.2:
>>    A leaf that is a list key MUST NOT have any "if-feature" statements.
>>    7.21.5:
>>    A leaf that is a list key MUST NOT have a "when" statement.
>> 
>>   - Which is correct?
>
> You're right, it seems this issue was never really resolved.
>
> See the thread:
> https://www.ietf.org/mail-archive/web/netmod/current/msg11537.html
>
> the last email on this issue is:
> https://www.ietf.org/mail-archive/web/netmod/current/msg11570.html
>
>>   - The 7.* MUST NOT text is not backward compatible with YANG 1.0
>>     I think the WG agreed on what the bullet in 1.1 says, not the
>>     new restrictions in 7.*
>
> In this email thread it was pointed out that this is very
> difficult to check for "when", and at least non-trivial for
> "if-feature".

Right, I think the consensus was it was an omission in 6020, and bug
fixes are permitted.

...

>> Sec. 5.7: Datastore Modification
>> 
>>   - This section is NETCONF specific for no apparent reason
>
> Ok.  I suggest s/NETCONF protocol messages/network management protocol
> messages/

I think it has nothing to do with YANG, except that such changes
shouldn't render the datastore invalid. There are inherent problems
connected to system-generated values though, e.g. what if the datastore
is locked in a NETCONF session? My proposal is to delete this section
altogether.

...

>> Sec. 7.10.3:  NETCONF <edit-config> Operations
>> 
>>  - Can these sections be changed to 'Configuration Datastore Edit
>>    Operations' and be generic so they focus on the contents of
>>    the datastore before and after the edit, without specifying
>>    <edit-config> as the edit operation
>
> Hmm, I think these sections are really edit-config-specific.  YANG
> Patch defines its own syntax, for example.

Agreed. I think enforcing the same NETCONF-like semantics for all users
of YANG is not good. Protocols that want something else will ignore such
statements - as RESTCONF did, and rightly so.

...

>>  - Para 1 says:
>>       If multiple "base" statements are present, the identity is derived
>>       from all of them.
>> 
>>    The draft does not say how this is done. It is not clear how
>>    a particular identity-stmt has multiple bases and how a server
>>    determines an identify is derived from multiple bases. Examples
>>    of a 'pass' and 'fail' for this test should be given.
>
> This section simply defines what "derived from" means.  An identity
> can be derived from zero, one or many other identites.

Yes, and sec. 9.10.2 specifies the permitted values for an identityref
type. IMO, everything is clear.

>
>> Sec. 7.21.5.  The when Statement
>> 
>>  bullet 3:
>>  - Altering the tree changes means that each when-stmt processes
>>    a different XML document.  IMO it is a bad idea to replace a
>>    node that is in the tree with a dummy node.  It is OK to create
>>    a temp dummy node as an implementation detail to decide if
>>    a when-stmt is true or not.
>
> We've discussed this at length on the ML.  I think the current text
> reflects WG consensus.  Without this text, it is not clear how to

Actually, when we put together this third bullet, I thought it would
only be used when there is no context node in the instance document. So
I agree with Andy here.

> interpret the theoretical corner case when the expression references
> nodes that are being augmented:
>
>    augment /... {
>      when "foo != 42";
>      leaf foo {
>        type int32;
>      }
>    }
>

It would be much better to exclude such references explicitly. In this
example, an instance of "foo" may actually exist with the value of "42"
- IMO this would be terribly confusing.

>> Sec. 8.1: Constraints on Data
>> 
>>  - bullets say constraint MUST be true, but this info should really
>>    be part of NETCONF, and should say what a NETCONF server should
>>    so when a constraint is false
>
> Do you want to make this text *more* NETCONF-specific?  The idea was
> that these conditions hold regardless of which protocol is used.

Right, validity of the data tree should be an absolute property,
independent of protocol or encoding.

...

>>  - what happens if a feature value is changed at boot-time or run-time,
>>    causing valid enumeration or bits values within a datastore to
>>    suddenly become invalid?  Changing the value set of a leaf or leaf-list
>>    with if-feature is very complicated and under-specified
>
> I think this is an implementation detail.  Some implementations don't
> even support enabling/disabling features.
>
> Compare with this situation:
>
>   leaf foo {
>     if-feature foo-feature;
>     ...
>   }
>
>   leaf my-i-i {
>     type instance-idnetifier;
>   }
>
> and then the datastore contains:
>
>    my-i-i = /foo
>
> Now suppose you disable 'foo-feature' in your server.  What happens to
> the datastore?

Right, there are also other ways for making the set of permitted values
of a type empty. Tools might emit a warning but that's all.

>> 
>> Sec. 9.10.5.  (Identityref) Usage Example
>> 
>>  - Add an example and use-case showing multiple base-stmts
>>    for an identityref
>
> I will try to come up with something simple.

In the example in Y13, the identityref could be

  type identityref {
    base share-alike;
    base non-commercial;
  }

and then the only permitted value would be CC-BY-NC-SA.

...

>
>> Sec. 10.3.1.  deref()
>> 
>>  - why is this XPath function needed?
>>    No use-cases are explained.
>>    The example given shows that deref(.) saves some extra typing
>>    from the previous line.  Not very interesting new feature.
>
> If the node is an instance-identifier, it is not possible to check the
> target node w/o deref().

Right, and evaluate() function in EXSLT does the same thing:

http://exslt.org/dyn/functions/evaluate/index.html

Maybe we could reuse its definition.

...

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Sun, 1 Nov 2015 09:09:08 -0800

> Right, I think the consensus was it was an omission in 6020, and bug
The issue never occurred to u during development of 6020.
It is OK to say MUST NOT for YANG 1.1, but maybe not for a YANG 1.1 module
importing a YANG 1.0 module.

Since we agree that the keys and parent cannot
have different conditions, is it OK to assume that the
when and if-feature-stmts on the keys can be ignored,
if they appear in a YANG 1.0 module?

...
> is locked in a NETCONF session? My proposal is to delete this section

The problem is that there needs to be a good definition of a datastore.
Instead there are just descriptions of XML after a NETCONF <edit-config>
operation.

> only be used when there is no context node in the instance document. So

I strongly object to any implementation details in the normative text.
One part of the draft says that XPath is completely conceptual and not
actually
required for implementation, but there is all this text that mandates how
when-stmt MUST be implemented.

Nobody is going to spend any resources to process XPath statements
to sort them by dependency.  That is a non-starter, especially for
a theoretical corner-case that is extremely unlikely.   We will solve this
problem in the tools, perhaps with a YANG extension (e.g. when-priority N;)
so vendors can force an evaluation order if the problem ever comes up.

> - IMO this would be terribly confusing.

Nobody does this because it is gibberish from an operational POV.
Perhaps standardized network management has been such an
elusive goal because we obsess over theory and ignore operational
experience so often.

> independent of protocol or encoding.

So how is the current text protocol independent?
Does this draft claim to support RESTCONF?
Does it need to say anything, or can protocol documents just
declare that YANG 1.1 applies to them?
That would be OK, except the NETCONF stuff needs to move
out of YANG somehow.

...
> > even support enabling/disabling features.

But some do support it and YANG does not say anything about
YANG features being frozen at boot-time.
That doesn't even help in the situation
where the features change across a reboot and the NV-saved config
is now invalid.

This is a major flaw in YANG not an implementation detail.
It is possible to change the value set such that existing values
become invalid, or such that the default-stmt for a leaf becomes invalid.

> > Now suppose you disable 'foo-feature' in your server.  What happens to

This is no different than just deleting a node without any if-feature.

The really broken part is the default-stmt can become invalid.

I agree the if-feature change can be treated like an internal
server datastore change, and error nodes will be pruned to adjust.
This works most of the time, and when it doesn't, it blows up
real good so the operator will fix it.

> of a type empty. Tools might emit a warning but that's all.

Are there existing ways to make the default-stmt invalid?

I agree that some corner-cases exist, like identityref.
Our server allows modules to be added or removed on the fly,
so the set of identities for a given identityref can change,
causing this same problem.

> Maybe we could reuse its definition.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 1 Nov 2015 12:11:03 -0800

On Fri, Oct 30, 2015 at 8:45 AM, Martin Bjorklund <[email-masked]> wrote:

> Hi Andy,

> >  - Should 'may' be 'MAY'?
>
> Actually, since the enitire section 4 is not marked as:
>
>    This non-normative section is intended to give a high-level overview
>    of YANG to first-time readers.
>
> I think we should remove all 2119-keywords from section 4.
>
>

OK

> > Sec. 5.6.4: para 2:
> >
> >    A server MUST NOT implement more than one revision of a module.
> >
> >  - IMO this should a SHOULD NOT or 'MUST NOT advertise' instead
> >    of MUST NOT implement
>
> There is an ongoing thread on this topic, the last msg is:
>
> https://www.ietf.org/mail-archive/web/netmod/current/msg14211.html
>
> The question in this msg is not yet answered.
>
> >    Example of possible exception:
> >     - rev N-1 has object needed by application
> >     - rev N has that object set to status 'obsolete' (and removed)
> >     - rev N also has other objects unrelated to the obsolete object
> >       but desired for the product feature set
>
> In this case revision N should be implemented.
>

but then the obsolete object is not allowed, right?

So the server has to advertise N-1.
Hopefully deviations can be constructed to represent the changes
from version N-1 to N, and the server will advertise the deviations.

>
> > Sec. 5.6.4:
> >   - para 4: the rules for populating the YANG library should probably be
> >     in the yang-library draft
> >   - the example on page 35 - 37 should probably be in the
> >     yang-library draft
>
> Maybe, but I think this document might seem under-specified unless we
> define these rules here.
>

Right, because you have to add a reference to the external document.
This is not that important since the library is only intended for
YANG modules.

>
> > Sec. 5.6.5.  Announcing Conformance Information in NETCONF
> >
> >   - This should really be in a NETCONF 1.2 spec
>
> Maybe, but we need to work with NETCONF 1.1 now.
>

So if there is a NETCONF 1.2 someday, does that mean we will
also have a YANG 1.n that moves the NETCONF specific text?
If so, then I don't have any concerns about NETCONF-specific YANG.

>
> >   - RESTCONF draft defines ietf-yang-library requirements for RESTCONF.
> >     Why should YANG 1.1 define NETCONF ietf-yang-library requirements?
>
> B/c this document defines both the language and the NETCONF mapping.
>
>
So we will do the same for NETCONF if there is a NETCONF 1.2 someday

> Ok.  I suggest s/NETCONF protocol messages/network management protocol

OK

>
> > Sec. 6.4.1: bullet 5
> >
> >    o  The set of variable bindings is empty.
> >
> >   - This is not true.  The NACM data model defines the USER variable.
> >     This text should say that YANG modules MAY define variable bindings
> >     associated with conformance for that module (like NACM does).
>
> No, the USER variable is only available in expressions of type
> nacm:node-instance-identifier.   It cannot be used in must/when
> expressions.
>

OK

I checked our code and we do not use any variable sets in must/when.
It is only select.

>
> > Sec. 6.4.1: XPath accessible tree
> >
> >   - I object to expanding the context of XPath evaluation for
> >     notification and rpc/input, rpc/output.  This is too complicated
> >     to implement and under-specified, resulting in poor interoperability.
>
> This is issue Y04, and it was discussed at the WG interim 2014-06-11.
>

I won't object but reality does not agree with your text.
Servers do not run XPath on their own output, so the XPath
is going to be enforced conceptually in the instrumentation.

Outside the server, there does not exist a tool that can reliably reproduce
the instance document to evaluate, that includes the config and operational
state
at the instant the notification or rpc/output was generated.
(As if that is well-defined either).

> >   - What is the justification for this expansion of complexity?
> >     An tool cannot reproduce the same result anymore for
> >     <rpc>, <rpc-reply> or <notification> offline validation.
>
> It couldn't do that earlier either, if there were leafrefs in the
> data.
>
> I agree with all your concerns below.  I would prefer Y04-01, but that
> would brake RFC 6643 :(
>
> Maybe we should consider doing this only for the 'path' statement.  It
> has the same set of issues of course.
>
> >  - Notification context expanded from notification message to message +
> >    running config + operational state;  When is the server supposed
> >    to gather and check all the data nodes? Event time? Buffer time?
> >    Send time? What if operational state or config changes while the
> >    notification is in the replay buffer?
> >
> >  - RPC input context expanded from input message to message +
> >    running config + operational state;  When is the server supposed
> >    to gather and check all the data nodes? Parse time? Buffer time?
> >    Invocation time?
> >
> >  - RPC output context expanded from input message to message +
> >    running config + operational state;  Is the server supposed to
> >    wait for operational state that may change as a result of the
> >    action or rpc being invoked?
> >
> >  - The expanded contexts for notification and rpc statements
> >    require coupling of the notification and RPC processing
> >    implementation components to the datastore and operational data.
> >    This is a big change from current NETCONF requirements.
> >    YANG should not be making any changes to NETCONF, but it does
> >    in several places, effectively creating a new undeclared
> >    version of the NETCONF protocol
> >
> >  - It is not clear if "action" and "notification" statements
> >    nested in the data tree are visible at all for XPath evaluation.
> >    (They MUST NOT be visible)
>
> Agree.  I think this is covered since the accessible tree is made up
> of data nodes, and action/notification are not data nodes.
>
> >  - NETCONF <get> and <get-config> "filter" element needs clarification
> >    wrt/ action and notification within the data tree
>
> Why?  These nodes are not part of the data tree (datastore).
>
>

RFC 5277 filters will be run against the top-node, which will be
the ancestor nodes, not <notification> or <my-event>,
Can nested notifications be filtered, and if so, how does it work?

>  - NETCONF and RESTCONF notifications "filter" element needs clarification
> >    wrt/ action and notification within the data tree
> >
> > Sec. 7.5.3: must: last para
> >
> >    Also note that the XPath expression is conceptually evaluated.  This
> >    means that an implementation does not have to use an XPath evaluator
> >    in the server.  How the evaluation is done in practice is an
> >    implementation decision.
>
> Is there a problem with this text?
>

no -- I meant 'when'.  Ignore this comment

>
> > Sec. 7.5.4.2.  The error-app-tag Statement
> >
> >    The "error-app-tag" statement, which is optional, takes a string as
> >    an argument.  If the constraint evaluates to false, the string is
> >    passed as <error-app-tag> in the <rpc-error> in NETCONF.
> >
> >  - all the error-message and error-app-tag sub-sections apply to
> >    RESTCONF as well as NETCONF.  They share the same error reporting
> >    structure
>
> Agree.  But this document does not define RESTCONF.
>

I hope the implicit mapping to RESTCONF is clear enough.

> > Sec. 7.5.8:
> > Sec. 7.6.7:
> > Sec. 7.7.9:
> > Sec. 7.9.6:
> >  - RESTCONF needs to be supported, or all this should be moved
> >    to NETCONF 1.2
>
> RESTCONF *is* supported, but it is not *specified* in this document.
>
> > Sec. 7.6.1.  The leaf's default value
> >
> >  - this section should mention that a false if-feature
> >    or false when-stmt removes the schema node from the
> >    tree, which overrides all this text. There is no default
> >    value if there is no schema node
>
> Howabout:
>
>   Note that if the leaf or any of its ancestors has a "when" condition
>   or "if-feature" expression that evaluates to "false", then the
>   default value is not in use.
>
>
OK

> (and ditto for leaf-list default)
>
> >  - It is confusing that 'must' and 'when' work very
> >    differently wrt/ default. must-stmt does not ignore defaults
> >    but 'when' overrides and removes the 'when', so it needs to
> >    be evaluated before the 'must' stmt:
> >
> >    leaf confusing {
> >      must "/some/val=4";
> >      when "/some/other/value/test";
> >      default 42;
> >      type int32;
> >    }
>
> Yes.
>
>

Hope this 'when-first' requirement is clear

> > Sec. 7.7.2.  The leaf-list's default values
> >
> >  - this section represents 2 new requirements to compilers
> >    that should be more apparent:
> >
> >    1) remembering the order of "default" statements
> >    2) the default only applies if 'min-elements 0' is in effect
>
> Can you suggest some text to clarify this?
>
>
Note that the YANG compiler needs to remember the
the order of "default" statements for a leaf-list.

No text for (2) is really needed.

> >  - what is the rationale for not applying the default if
> >    min-elements is > 0?
>
> B/c the default applies only if no instance exists, and if
> min-elements is > 0, there MUST exist an instance.
>
>

OK -- that matches config files as well.

> >  It looks like the leaf/container rule
> >    that mandatory and default are not allowed together is
> >    being applied here.  This should be more clear here
> >
> > Sec. 7.11.  The anyxml Statement
> >
> >  - The 'anyxml' statement should be deprecated.
> >    If not, this section needs to provide rationale for
> >    its 'current' status, given that 'anydata' has been added
> >    No use cases are provided for anyxml in the draft.
>
> It should be used when you need to model some XML data.  It is used in
> RFC 6241.
>
>
OK -- it should be deprecated in NETCONF 1.2

(Or we could just pretend implementations actually support it.)

> >  - There are few if any servers that support anyxml the way
> >    it is defined here, and that is not likely to change.
>
> Servers support the data models they advertise.  anyxml is almost
> never used in any data model, except for ietf-netconf.  A server that
> supports ietf-netconf + YANG will support the subset of XML that is
> necessary for YANG.
>
> >    The draft does not specify how the XML must be parsed,
> >    stored, or rendered later, if it is part of configuration
>
> Do you want to add more rules around this?
>

no.  I suppose anyxml encoding is already defined

>
> > Sec. 7.15.  The action Statement
> >
> >  - an action must appear directly within a container or a
> >    list, an 'augment' or a 'uses' statement.
> >    Why is 'case' statement left out of direct usage and
> >    only allowed via 'uses' or 'augment'?
>
> It is explicitly not allowed in uses:
>
>   Since an action cannot be defined an the top-level of a module or in
>   a case statement, it is an error if a grouping that contains an
>   action at the top of its node hierarchy is used at the top-level of
>   a module or in a case definition.
>
> As for augments, the text actually is broken; it doesn't mention
> action or notification at all.  I suggest we add:
>
>   If the target node is a container or list node, the "action" and
>   "notification" statements can be used within the "augment"
>   statement.
>
>

IMO it makes sense to have actions associated with the datastore itself,
located at the root level.  It seems like a CLR to forbid this usage.

> to section 7.17.
>
> (and the reason for not allowing it is that it is not clear what it
> means.  for example:
>
>     container foo {
>       choice c {
>         case a {
>           action doit { ... }
>         }
>         case b {
>           notification it-happened { ... }
>         }
>       }
>     }
> )
>
>
> >  - para 2: groupings are not reusable if they contain actions,
> >    since they are not allowed in rpc, notification, or action
> >    This should be pointed out in the section on groupings
>
> How about this NEW text in 7.12 The grouping Statement:
>
>   Note that if a grouping defines an "action" or a "notification" node
>   in its hierarchy, then it cannot be used in all contexts.  For
>   example, it cannot be used in an rpc definition.  See ^action^ and
>   ^notification^.
>
>

OK

> >  - the reason for the restriction on top-level action is not
> >    given.  The syntax would support this, and the identifier
> >    namespace is shared (same as rpc).
>
> They are different:
>
>    The "rpc" statement is used to define an RPC operation.
>
>    The "action" statement is used to define an operation connected to a
>    specific container or list data node.
>
>

Why can't it be an action associated with the datastore?

Not sure why leaf, and leaf-list are left out either,
and only list and containers can have actions.
I get it that this little rule exists, just not why it is needed
for interoperability.

> >  - the context nodes for action input and output are very different
> >    this could be more clear
>
> Can you suggest some text to clarify this?
>
>
maybe later

> >  - is the server required to process XPath or constraints on the
> >    output at some point in the execution of the action?
>
> This is not different from rpc output (or norifications).  I think it
> is the server's responsibility to send output / notifs that are
> syntactically and semanticically valid.  *how* this is done is an
> implementation detail.  (FWIW our code doesn't check such constraints;
> we leave it to the implementor to do the right thing).
>
>

OK -- I agree it is conceptual and there may not be any way
for an outside tool to verify the server correctness.

>  - there is no rationale given why the ping operation should
> >    be done as an action instead of an RPC
>
> It can be done in both ways.  I think such guidelines are out of scope
> for this document.
>

OK.

I got nothing for the YANG guidelines here.
I can imagine YANG Doctors getting deadlocked over preferences,
but vendors will will have more options.  We can worry about individual
cases in RFCs as they come up.

>
> >    list interface {
> >        key "name";
> >
> >        leaf name {
> >          type string;
> >        }
> >
> >        action ping {
> >          input {
> >            leaf destination {
> >              type inet:ip-address;
> >            }
> >          }
> >          output {
> >            leaf packet-loss {
> >              type uint8;
> >            }
> >          }
> >        }
> >      }
> >
> >  Why not use an RPC?
> >  No rationale for both ways to implement an operation
> >  like 'ping' is given.
> >
> >    rpc ping {
> >      input {
> >        leaf itf-name {
> >          mandatory true;
> >          type if:interface-ref;
> >        }
> >        leaf destination {
> >          type inet:ip-address;
> >        }
> >      }
> >      output {
> >        leaf packet-loss {
> >          type uint8;
> >        }
> >      }
> >    }
> >
> > Sec. 7.16.  The notification Statement
> >
> >    If a leaf in the notification tree has a "mandatory" statement with
> >    the value "true", the leaf MUST be present in a notification
> >    instance.
> >
> >  - Why is this apply to leaf but not container or choice?
> >    They should be mentioned here as well.
>
> ... and (leaf-)list min-elements.
>
> This sentence (about mandatory leafs) is present also for rpc
> output,input and notif.
>
> But maybe the best solution would be to remove this special sentence -
> it is already covered by the text in 8.1 - and that text is more
> complete.
>
> But I noticed that the text in 8.1 doesn't mention mandatory choices.
> I suggest:
>
> OLD:
>
>    o  The "mandatory" constraint is enforced for leafs, unless the node
>       or any of its ancestors has a "when" condition or "if-feature"
>       expression that evaluates to "false".
>
> NEW:
>
>    o  The "mandatory" constraint is enforced for leafs and choices,
>       unless the node or any of its ancestors has a "when" condition
>       or "if-feature" expression that evaluates to "false".
>
>
>

OK

> >  - No rationale is given for defining notifications within data nodes
> >    vs. top-level notification-stmt
>
> See above for actions.
>
> >  - It is not clear how RFC 5277 <filter> can be applied to the
> >     notification message that is nested within data, given the
> >    location of the 'notification' root within the data tree is
> >    not static, and different for each notification.
>
> Why wouldn't a normal filter work?
>
> For example, for the last example in 7.16.3 you can do:
>
>   <filter>
>     <interfaces xmlns="http://example.com/schema/interfaces">
>       <interface>
>         <name>eth1</name>
>       </interface>
>     </interfaces>
>   </filter>
>
> in order to receive notifs for eth1 only.
>
>
>

RFC 5277 says the filter contains the node matching the event QName,
which is nested inside the 'interface' element.

>
> > Sec. 7.17.  The augment Statement
> >
> >  - can augment path-stmts contain nested 'action' or 'notification'
> >    nodes and subnodes, like for rpc-stmt?  If, so then the
> >    sub-statements are restricted by context, e.g., action-stmt
> >    cannot be added to /foo/bar/action/input/baz.
>
> Above I suggested we add:
>
>   If the target node is a container or list node, the "action" and
>   "notification" statements can be used within the "augment"
>   statement.
>
>

OK

> I am not sure if that covers your concern?
>
> > Sec. 7.18.2.  The base Statement
> >
> >   - There are no examples or use-cases given for multiple base
> >     statements. An example should be added.
>
> Ok.
>

> .... have not reviewed rest of responses
>

> /martin

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 02 Nov 2015 10:48:03 +0900

> if they appear in a YANG 1.0 module?

Yes, and perhaps we can submit an erratum to 6020 saying that these
statements are ignored if they appear on keys.  

> Instead there are just descriptions of XML after a NETCONF <edit-config>

As I said before, I believe the role for YANG spec should be limited to
answering the question whether a given data tree is valid or not.

Originally, YANG was designed as a data modelling language for NETCONF,
so it didn't matter so much how the stuff is distributed between NETCONF
and YANG specs, but now I think it does matter. 

> when-stmt MUST be implemented.

The problem here is that XPath is supposed to be applied even if the
context node doesn't exist. An alternative that I would prefer is to
apply "when" statements only if the context node exists - which is BTW
guaranteed for "when" appearing on an augment.

I object to making "conceptual" a synonym to "hand-waving".

> so vendors can force an evaluation order if the problem ever comes up.

But that means each tool may possibly give a diferent result, or fail on
different "when" expressions. This is IMO not very good.

> elusive goal because we obsess over theory and ignore operational

Since "when" is so powerful, I think it is unsafe to leave such
loopholes in its definition.

> Does this draft claim to support RESTCONF?

Sec. 8.1 doesn't mention NETCONF so I assume it applies everywhere.

> That would be OK, except the NETCONF stuff needs to move

Yes, this would be my preferred solution.

> Are there existing ways to make the default-stmt invalid?

I gave one in the if-feature thread: a default identity that's not
implemented by the server.

Lada