Subject: [netmod] yang 1.1 last call comment resolution

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Nov 2015 10:08:46 +0100

Hi,

given the discussion at IETF 94, here is what I think where we are
with resolving the last call comments (I am following the structure of
Martin's IETF 94 slides). It would be nice to close the remining open
ones as soon as possible so that Martin can produce -09.  Once we have
-09, we will have a second WG last call so that people can do a final
check whether the edits from -07 to -09 address all the comments that
were raised in a satisfying manner.

If you disagree with any of the following, please raise your voice.

- New function: if-feature and default

  I think the resolution is to disallow default values that are
  depending on a feature.

- New function: accessible tree in when

  I think the resolution is to adopt the proposed solution.

- Old function: augment mandatory nodes

  I think this is moving towards relaxing the MUST NOT rules and
  to allow mandatory nodes in 'safe' augmentations.

- Old function: unique module names

  I think the resolution is to adopt the compromise solution.

- New feature: non-unique config false leaf-lists

  It is unclear where we are with this. While there was some
  discussion at IETF 94, there was no clear indication whether this
  change should be done or not. More input would be welcome.

- New feature: keyless lists and non-unique leaf-lists in config

  This seems to be dead.

- New feature: change semantics of the choice and when statements

  This seems to be dead.

- Old function: make auto-delete for choice and when non-NETCONF specific

  Revision -08 of YANG 1.1 defines auto-deletion as a property of the
  NETCONF edit-config operation and the issue is whether this
  auto-deletion behaviour is a NETCONF specific edit-config property
  or a general YANG datastore validation property that equally applies
  to RESTCONF, COMI, ...

  It is unclear where we are with this. More input would be welcome.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Nov 2015 18:20:45 +0900 (JST)

>   change should be done or not. More input would be welcome.

I think there are two options:

  A.  Allow non-config leaf-lists to have duplicate values.

  B.  Add a new keyword "allow-duplicates true|false" to leaf-list.
      It is an error if allow-duplicates is true in config.

B feels more correct to me, but A is obviously simpler.

>   It is unclear where we are with this. More input would be welcome.

I think it would be very confusing if e.g. RESTCONF behaved
differently than NETCONF.  However, I can see how it might make sense
for a server on a constrained device to not do auto-delete - but OTOH
such a server probably don't do "must" and "when" checking at all.
And it might have specialized data models that don't use such
constructs.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Nov 2015 13:24:14 -0800

> B feels more correct to me, but A is obviously simpler.

Agreed.
It seems like a data model property, not a server implementation choice.

The leaf-list is broken in many ways but it gets fixed 1 little bit at a
time.
We added a "delete-all" enumeration in our server for deleting an entire
leaf-list
because the current delete (specify every instance) is too cumbersome.

There is also no good way to test if a particular leaf-list instance exists.
If you provide a leaf-list with an instance in a <get*> filter, it is
treated
as a content-match node. (i.e., return all siblings or none)
There is no way to just retrieve just leaf-list foo=42.  You have to
retrieve
all foo nodes with a selection filter, then test all the values on the
client.

> And it might have specialized data models that don't use such
I don't like any of the NETCONF-specific text in YANG 1.1.
YANG datastore constraints refer to a conceptual "valid datastore".
There is no reason to talk about specific protocol behavior,
except that we are too lazy to put protocol text where it belongs.

It should at least be clear that datastore validation does not at all depend
on how the datastore contents were changed.  The current text does
not even fully support <copy-config>, so it does not even support NETCONF,
let alone RESTCONF.

IMO auto-deletion should not be changed.
It works fine and the only issue that has ever come up is
auto-deleting data from an edit-config payload.

/martin

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Nov 2015 22:37:30 +0100

> auto-deleting data from an edit-config payload.

Huh? Can you please elaborate what the issue is? Why would one delete
data from edit-config payload?

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Nov 2015 13:44:44 -0800

> data from edit-config payload?

Well, not from the payload, but rather that data from the
<config> payload is created in the target datastore and then immediately
deleted because a when-stmt is false.  For example, the edit applies
interface
parameters for "when if:type='ethernetCsmacd'" to an interface with a
different type.

The server doesn't really care which node caused another when-stmt to
become false.
This corner-case is treated as just another auto-deletion.

/js
Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 7 Nov 2015 08:59:13 -0800

>   I think the resolution is to adopt the proposed solution.

I strongly object to the change to XPath accessible tree for RPC and
notifications.
(page 44 - 45, bullets 3 - 5) State data MUST NOT be included in the
accessible tree.

E.g., rpc/input went from the <rpc> message itself to <rpc> + running +
state.
It should be just <rpc> + running.  It is a massive change to include state
data
in the processing of RPC or notifications. The server has to implement the
:xpath capability in NETCONF.

I strongly object to the text that requires the accessible tree to be
modified for processing
when-stmts  (3 bullets in 7.21.5).  This requires massive and complicated
implementation changes.   IMO the most interoperable thing to do is just run
the specified XPath expression on the existing conceptual document.

If people use bad XPath then maybe bad things happen.  YANG Doctors
will prevent that in IETF modules.  In reality, XPath that doesn't work
usually
gets fixed at some point.

>   to allow mandatory nodes in 'safe' augmentations.

There was some discussion about moving the 6087bis text I wrote into
YANG 1.1 to make it normative. OK with me.

>   I think the resolution is to adopt the compromise solution.

which was what?

>   change should be done or not. More input would be welcome.

OK with just allowing this without a new keyword.

> - New feature: keyless lists and non-unique leaf-lists in config

good

> - New feature: change semantics of the choice and when statements

good

>   or a general YANG datastore validation property that equally applies

good - YANG should describe what happens inside a conceptual datastore

IMO it could be more clear that this auto-deletion applies to every
datastore and is
not really considered validation.  If so, then it would not be instant,
but rather enforced only on the 'running' config.

It is really if-feature on steroids. ;-)

(No I do not have suggested text right now to make this more clear)

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 09 Nov 2015 11:31:10 +0100

> B feels more correct to me, but A is obviously simpler.

I don't have a strong preference here. Could A cause any problems?

> differently than NETCONF.  However, I can see how it might make sense

I don't know whether auto-deletion is really the preferred choice of
every NETCONF/RESTCONF user but I think it would be countre-productive
to require all protocols that might use YANG to apply this behaviour.

> such a server probably don't do "must" and "when" checking at all.

Why not? For example, such an implementation can do this validation with
DSDL schemas using off-the shelf RELAX NG and XSLT implementations.

Lada

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 09 Nov 2015 11:48:47 +0100

>> Juergen Schoenwaelder <[email-masked]> wrote:

...

Agreed.

> auto-deleting data from an edit-config payload.

IMO a scarier prospect is the ripple effect where an edit-config causes
some remote part(s) of the data tree to disappear.

I looked into the existing uses of "when" and none of them seems to be
really designed for the auto-deletion option. That is, auto-deletion is
either impossible (e.g. if "when" involves just a list key) or otherwise
it would clearly be an operator error (e.g. if interface type is changed
by mistake).

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Nov 2015 08:17:56 -0800

> it would clearly be an operator error (e.g. if interface type is changed

I do not agree.
The when-stmt and choice-stmt change the schema tree.
The false schema nodes are like false if-feature nodes.
This is what makes "must" different than "when".
If an error is returned instead of deletion, then there is no difference
between must and when statements.  YANG has worked this way from
the very beginning, so I do not understand what the problem is now.
This "general confusion" argument is really weak.

Lada

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Nov 2015 18:53:16 +0100 (CET)

> I don't have a strong preference here. Could A cause any problems?

Well, I agree with what Andy wrote:

  It seems like a data model property, not a server implementation
  choice.

> DSDL schemas using off-the shelf RELAX NG and XSLT implementations.

If a device can run off-the shelf XLST then it is not very
constrained, and it can probably run any of the off-the shelf NETCONF
servers that already handle this.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Nov 2015 19:27:19 +0100 (CET)

> (page 44 - 45, bullets 3 - 5) State data MUST NOT be included in the

This is issue Y04.  I assume you prefer Y04-04.  I can live with this,
even though it would be odd that the accessible tree for leafref and
must are different.

> :xpath capability in NETCONF.

No it doesn't.  Just like it doesn't have to implement :xpath in order
to support a normal "must" on a config node.

> gets fixed at some point.

I obviously prefer the current text, but I can live with this also,
except that at least we must state that a dummy node gets created in
order to have a context node.  We should be aware that the current
text defines a deterministic behavior, and if we change it this will
remain an unclear situation.

> >   I think the resolution is to adopt the compromise solution.

The (revised) proposal is:

  The names of all standard modules and submodules MUST be unique.
  Developers of enterprise modules are RECOMMENDED to choose names for
  their modules that will have a low probability of colliding with
  standard or other enterprise modules, e.g., by using the enterprise
  or organization name as a prefix for the module name.  Witin a
  server, all module names MUST be unique.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Nov 2015 14:56:44 +0100

> The when-stmt and choice-stmt change the schema tree.

It's not about the schema tree but rather about what the server does if
a data tree doesn't conform to the schema.

What happens if the client sends some instances that are not in the
schema at all? Will the server simply ignore these?

And what happens if the client sends two competing cases of a choice in
the same edit-config? Will the server toss a bitcoin and auto-delete one
of the cases?

> This is what makes "must" different than "when".

There are other significant differences, the server can behave either
way, and the client can achieve the same things either way. 

> the very beginning, so I do not understand what the problem is now.

Well, I did express my reservations against auto-deletion several times
in the past, e.g.

https://mailarchive.ietf.org/arch/msg/netmod/SR9UUgFzuBcGlTHuvbKAmhVDk9w

However, it seems I am not alone now.

Lada