Subject: Re: [netmod] Moving the WG discussion on mount forward

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 1 Mar 2016 22:56:06 +0000

What I would like to see:

(1) Terminology included which unambiguously partitions the functions of the three different type of mount options discussed in this WG (i.e., structural mount, alias mount, and peer mount).    This would be needed even if only the structural mount technology itself is specified in the draft.

(2) Agreement from draft authors that any Mount options build off of a common, extensible syntax.

(3) Agreement from OpenDaylight developers that the peer mount definition corresponds to the meaning of their "Mount"

Eric

> From: netmod, February 29, 2016 3:40 PM
> 
> 
> All,
> 
> At last week's interim, Martin committed to update his document based on the
> meeting and then work with the other mount document authors (i.e., Lada and
> Alex) on a future version.  Martin has now published this version:
> https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-02
> 
> Lada also said that he was okay with using Martin's document as a starting point
> for the working group document on this topic.  (Keep in mind a -00 WG
> document is a starting point, not and end point.)
> 
> We'd now like to ask for additional feedback from other WG contributors on
> their opinions on what they would like see added to base document in order for
> it to be accepted as a WG document.
> So please review the document and send comments to the list -- again on what
> areas need to be covered for the document to be accepted as a -00 WG draft.
> We're hoping for comments within the next week or so.
> 
> Thank you,
> Netmod chairs
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 03 Mar 2016 14:29:55 +0100

Lou Berger <[email-masked]> writes:

> All,
>
> At last week's interim, Martin committed to update his document based
> on the meeting and then work with the other mount document authors
> (i.e., Lada and Alex) on a future version.  Martin has now
> published this version:
> Lada also said that he was okay with using Martin's document
> as a starting point for the working group document on this
> topic.  (Keep in mind a -00 WG document is a starting point, not
> and end point.)

OK, but let me say right away that I would very much prefer the
alternative solution sketched in appendix D.2. It is IMO unacceptable to
use a YANG extension for defining mount points, because it requires both
servers and clients to support such an extension, otherwise no
interoperability is possible. It is important to stick to what
sec. 6.3.1 in 6020bis says because there is no mechanism for signalling
what YANG extensions an implementation supports. Having more
extensions like this would undermine the value of YANG as a standard
data modelling language.

Moreover, it seems unnecessary to define mount-points in the first
place. We have no augment-points so why do we need mount-points? I'd
argue that any implementation supporting augments would require only
minor modifications to support mount points specified through schema
node identifiers.

Lada

>
> We'd now like to ask for additional feedback from other WG
> contributors on their opinions on what they would like see added
> to base document in order for it to be accepted as a WG document.
> So please review the document and send comments to the list --
> again on what areas need to be covered for the document to be
> accepted as a -00 WG draft.  We're hoping for comments within the
> next week or so.
>
> Thank you,
> Netmod chairs
>

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Mar 2016 15:21:24 +0100

> minor modifications to support mount points specified through schema

I have no clear opinion whether defining mount points explicitely via
YANG extensions is goodness or not. Concerning YANG 1.1 Section 6.3.1,
can you please detail what exactly your concern is? The relevant text
is this:

   The processing of extensions depends on whether support for those
   extensions is claimed for a given YANG parser or the tool set in
   which it is embedded.  An unsupported extension, appearing in a YANG
   module as an unknown-statement (see Section 14) MAY be ignored in its
   entirety.  Any supported extension MUST be processed in accordance
   with the specification governing that extension.

Why do you believe a YANG implementation not supporting the mount
point extension can not simply ignore it?

/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: Ladislav Lhotka <[email-masked]>
Date: Thu, 3 Mar 2016 16:18:44 +0100

> On 03 Mar 2016, at 15:21, Juergen Schoenwaelder <[email-masked]> wrote:
> 

If a client doesn't support that extension, it will receive what looks like mysterious data in replies to get or get-config (or their RESTCONF equivalents) and is likely to choke. The server isn't able to tell whether the client knows about the "extended" model or not.

You may say it is the same with YSDL, but in fact YSDL doesn't pretend it can be used with clients that are unaware of it. From the YANG point of view, however, modules that are intended to be used with YSDL can be developed and published without waiting for a YANG extension to be standardized first, because they are just good old YANG modules.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Mar 2016 16:38:58 +0100

> If a client doesn't support that extension, it will receive what looks like mysterious data in replies to get or get-config (or their RESTCONF equivalents) and is likely to choke. The server isn't…

Has it not always been the case that unexpected data is ignored?

> You may say it is the same with YSDL, but in fact YSDL doesn't pretend it can be used with clients that are unaware of it. From the YANG point of view, however, modules that are intended to be used…

I do not really see the difference. A client that does not understand
the YDSL module will see the same unexpected data. If you are saying
that YSDL can't be incrementally deployed, well then I believe there
is a bigger problem.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 3 Mar 2016 17:24:08 +0100

> On 03 Mar 2016, at 16:38, Juergen Schoenwaelder <[email-masked]> wrote:
> 

No. Data that aren't in the schema are clearly invalid.

> that YSDL can't be incrementally deployed, well then I believe there

Well, yes, and I think it is true for structural-mount, too. A device that implements rtgyangdt's concepts can hardly be managed with old clients either way.

But my question here is: What's the real benefit of the mount-point extension? If it is just to define an alias for a location in the schema, then it's not needed because we can use schema node identifiers for the same purpose.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 3 Mar 2016 17:53:54 +0100

> No. Data that aren't in the schema are clearly invalid.

This is defined where? Anyway, if this is the case, then both mount
proposals are broken since both do not define the data mounted on a
mount point in the schema.

> But my question here is: What's the real benefit of the mount-point
> extension? If it is just to define an alias for a location in the
> schema, then it's not needed because we can use schema node
> identifiers for the same purpose.

This is a valid question to ask. I just commented on your YANG
extension argument, which I do not find too convincing.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 04 Mar 2016 13:22:06 +0100

> This is defined where? Anyway, if this is the case, then both mount

I would say that if sending arbitrary rubbish along with YANG-defined
data isn't forbidden, then it is a bug in the spec. Maybe I am spoiled
by XML schema languages, but the idea of "anyxml everywhere" is
quite disturbing.

> mount point in the schema.

Both proposals define it, I believe: structural mount in the
"mount-point" list, and YSDL in the "schema" list.

> extension argument, which I do not find too convincing.

So let me clarify my position: If the mount-point extension is used only
for giving a label to a schema location, then it's OK (but
unnecessary). However, if mount-point conveys other semantics
(e.g. conformance-related) then it most likely violates sec. 6.3.1 in
6020bis.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 4 Mar 2016 13:33:53 +0100

> "mount-point" list, and YSDL in the "schema" list.

But it is not defined in the _schema_. So for an old client, the
mounted data is going to be 'arbitrary rubbish' along with
YANG-defined data.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 4 Mar 2016 13:49:58 +0100

> On 04 Mar 2016, at 13:33, Juergen Schoenwaelder <[email-masked]> wrote:
> 

You probably mean that it isn't defined in a YANG module. But even now, in order to construct a complete schema, one needs extra info, e.g. from hello or yang-library. In "ietf-interfaces" there is also no indication that IP stuff appears somewhere as soon as "ietf-ip" is added to the data model. Both structural-mount and YSDL extend this extra information with a specification of how the (sets of) modules are glued together.

> mounted data is going to be 'arbitrary rubbish' along with

Yes, neither structural-mount nor YSDL can be added without further ado to the current protocols.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 5 Mar 2016 09:44:40 +0100

> mounted data is going to be 'arbitrary rubbish' along with

To legalize 'arbitrary rubbish' in the schema, one could define the
mount point as anydata. That is, instead of using a new mount-point
extension as proposed in [1], one would write:

     container logical-devices {
       list logical-device {
         key name;
         leaf name {
           type string;
         }

         anydata logical-device { yangmnt:mount-point; }
       }
     }

(This example corresponds to the example in Appendix A in [1].)

/js

[1] draft-bjorklund-netmod-structural-mount-02.txt

---

From: Lou Berger <[email-masked]>
Date: Wed, 9 Mar 2016 17:53:50 -0500

Eric,
    Great comments -- see below

> (1) Terminology included which unambiguously partitions the functions of the three different type of mount options discussed in this WG (i.e., structural mount, alias mount, and peer mount).    Thi…
I think this is a good topic to track / update as the solution captured
in the document evolves.  One question I have is what the WG draft on
this topic should be called. I'm (without hat) leaning towards
nemod-schema-mount in order to avoid the discussion/association with a
particular solution approach.

> (2) Agreement from draft authors that any Mount options build off of a common, extensible syntax.
I'm pretty sure I heard all parties say that this was a good idea -- and
I'd expect the WG to ensure that the WG solution heads that way (unless
some agreed upon reason leads the WG away from this position.)

> (3) Agreement from OpenDaylight developers that the peer mount definition corresponds to the meaning of their "Mount"
I think this is something that will have to come from WG participants
who are also (or can represent) ODL developers.
Thanks,
Lou