Subject: [netmod] undecided Y39 define the terms system/user-controlled instances

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Jun 2014 10:29:56 +0200

We need to decide whether this is in scope of YANG 1.1 or not.

/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: t.petch <[email-masked]>
Date: Tue, 10 Jun 2014 13:00:34 +0100

I would like to see this included.  I would regard it as one of the more
important issues that will facilitate future data models (well,
re-reading that, it may depend on what the definitions are but even then
probably better defined than not).

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 02, 2014 9:29 AM

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 10 Jun 2014 17:29:10 +0200

> probably better defined than not).

We agreed during the first virtual interim that these terms should be defined in the architecture document, that is RFC 6244bis.

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jun 2014 21:23:33 +0200

> We need to decide whether this is in scope of YANG 1.1 or not.

Interim proposal:

   Proposal: Reject since this is an architectural distinction and
   should thus should be defined generically elsewhere. It does not
   seem to be a YANG 1.1 issue.

If you disagree, please speak up by June 18th.

/js

---

From: t.petch <[email-masked]>
Date: Wed, 11 Jun 2014 09:19:40 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, June 10, 2014 8:23 PM
> If you disagree, please speak up by June 18th.

Lada's response to me said further that you would put it in RFC6244bis.
That is currently Informational and so would be an unsuitable, not
impossible just eyebrow raising, as a reference for data models.

Can you really see the current definitions in e.g. netmod-routing-cfg as
being just informational, not normative?  Would the I-D make any sense
without them?

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 11 Jun 2014 10:34:59 +0200

> impossible just eyebrow raising, as a reference for data models.

I do not know whether there are any plans to revise RFC 6244. The
point raised during the virtual interim meeting is that this distinction
is not something that affects the YANG language itself.
 
> being just informational, not normative?  Would the I-D make any sense

I think there are other places in the IETF where terminology and key
concepts are defined in informational architecture documents and then
used in normative protocol documents. But then again this can be
considered once a WG revises RFC 6244. It is also conceivable to have
a separate NETCONF/YANG Terminology document that defines normatively
basic concepts.

Again, the key observation during the virtual interim was that things
not affecting YANG directly should be kept out of the YANG specification.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Jun 2014 14:49:38 +0200 (CEST)

> is not something that affects the YANG language itself.

I think this definition could go into a new revision of RFC 6244, RFC
6087, or possibly a document on "YANG Design Patterns" (doesn't exist
yet, but we have talked about it).  All these would be Information
though.

> not affecting YANG directly should be kept out of the YANG specification.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Jun 2014 15:22:23 +0200

> yet, but we have talked about it).  All these would be Information

I think Tom is right that this is quite an important data modelling concept, and it is also related to issue Y42. We have these dual lists in config and state (e.g. “interface” in RFC 7223), and so far their relationship is only explained in descriptions. Maybe we need a formal means for expressing this relationship in data models, and then the notion of user/system-controlled entries will be crucial.

So I agree with rejecting Y39 with the caveat that it might pop up as part of Y42 (and yes, we might have to ask Deep Thought what the question of the latter issue really is).

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Jun 2014 06:46:20 -0700

On Wed, Jun 11, 2014 at 6:22 AM, Ladislav Lhotka <[email-masked]> wrote:

> I think Tom is right that this is quite an important data modelling
> concept, and it is also related to issue Y42. We have these dual lists in
> config and state (e.g. "interface" in RFC 7223), and so far their
> relationship is only explained in descriptions. Maybe we need a formal
> means for expressing this relationship in data models, and then the notion
> of user/system-controlled entries will be crucial.
>
>

It would be nice if somebody could describe the problem that
needs to be solved in protocol terms. List all changes in protocol
behavior between user and system controlled instances.
This doesn't seem like simply a terminology issue to me.

So I agree with rejecting Y39 with the caveat that it might pop up as part
> of Y42 (and yes, we might have to ask Deep Thought what the question of the
> latter issue really is).
>
> Lada
>
>

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Jun 2014 16:03:01 +0200

> This doesn't seem like simply a terminology issue to me.

I am not sure whether anything has to be solved in protocol terms but sec. 4.1 in the routing draft does have some implications for server behaviour - e.g. the side effects in operational state of adding/deleting a list entry in config.

Lada