Subject: [netmod] poll of interest on I-Ds submitted to the NETMOD WG

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Nov 2013 08:00:12 +0100

Hi,

at the last WG meeting in Vancouver, we did run out of time to discuss
what to do with the various individual I-Ds that have been submitted
to the NETMOD WG. So I like to poll for opinions on the list in order
to get a feeling where we are. In particular, I like to poll for
opinions on whether the following I-Ds should be worked on in an IETF
working group and how you see the priorities. In particular, it would
be nice to know who is willing to actively review documents and also
who is planning to implement the technology proposed in the various
I-Ds.

YANG Infrastructure:

[1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt
[2] http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt
[3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt

Data Models:

[4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt
[5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt

Other Stuff:

[6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt

If I am missing an I-D that is mature enough to be included in this
list, please let me know.

/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: Wed, 20 Nov 2013 14:23:39 +0100 (CET)

> [1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt

My problem with this document is that it identifies a couple of real
issues, but the proposed solution doesn't address them.  Specifically
the problem w/ import-by revision (2.1.1) and the problem with
supporting just an identity but not the data tree in a module (last
sentence in 2.2).  (In fact, I think the YANG specification needs to
be updated to fix these issues).

> [2]
> http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt

I obviously think this is a good idea, but I can also see that doing
this as part of a minor update to YANG (1.1) makes sense.

(we implement most of the features in this document already)

> [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt

I think this document should be adopted, I am willing to review it,
and we are already implementing this mapping.

> [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt

I support these documents, but I am not sure that NETMOD is the right
home for them.  I am also willing to review them from a YANG
perspective; I cannot claim that I have enough domain expertise
though.

> [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt

This document touches the important issue of how to model a
network-wide system, including the devices in the network.  (We
actually discussed this issue in a bar bof in Maastricht).  But I
think the solution described is too implementation-specific, and thus
limiting for other implementations.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Nov 2013 07:03:05 -0800

On Wed, Nov 20, 2013 at 5:23 AM, Martin Bjorklund <[email-masked]> wrote:

> > [1]
> http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt
>

For import-by-revision, the min-version and max-version can be set the
same for every module used in the conformance profile.  Why doesn't
this address the definition-drift problem that import-by-revision does
a horrible job attempting to solve?

For importing only meta-data like identities, the module-conformance leaf
would be set to 'import'.  Why doesn't this address the problem of the
confused client that does not know if this module is implemented of just
imported
for meta-data?

IMO any solution that uses the YANG module for all conformance information
is going to be module-centric.  In order to describe service-level
conformance,
multiple YANG modules and even NETCONF capabilities may be required.

> perspective; I cannot claim that I have enough domain expertise

+1 although there does not seem to be enough interest in the IETF
to do domain-specific data models.  In SNMP days, there were
WGs for specific MIB modules.  I think this time the YANG work will
probably happen in other SDOs.

> limiting for other implementations.

I think the problem of network-wide data models is different than the NFS
Mount type solution in this draft.  The concept of config that is changed
on server X, but affects X, Y, and Z needs a lot of thought.  IMO it is too
complicated to standardize.  We can standardize the mid-level-manager
that is actually running the network-wide model, but distribution through
proprietary clustering (or other management frameworks) is going to
be too implementation-specific.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Nov 2013 17:03:39 +0100 (CET)

> a horrible job attempting to solve?

B/c if a module uses import-by-revision it doesn't work.  Maybe the
proper solution would be to remove import-by-revision.  Then your
solution would work for the conformance problem.

> confused client that does not know if this module is implemented of just

B/c if a server advertises module foo, it means it implements
everything in module foo (minus features).  This is a YANG rule, and
it cannot be changed by advertising additional capabilities (which the
client may or may not understand).

> multiple YANG modules and even NETCONF capabilities may be required.

Agreed.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Nov 2013 09:13:38 -0800

> solution would work for the conformance problem.

I am trying to avoid a new version of YANG.
Of course import-by-revision is unusable but it isn't the only dead weight
in the language.

The usage model for min-version and max-version is not explained well
in the draft, but the YANG conformance is supposed to be updated
over time as reality dictates.

Think of the "install_requires" in setup.py:

 install_requires=[
        'TurboGears >= 1.5.1',
        'TurboKid',
        'TGExpandingFormWidget',
        'WebTest',
        'SQLObject>=0.10.1',
        docutils >= 0.3, <=0.5
    ],

This actually provides more variants than 1 range, but the required usage
depends on the actual conformance requirements.

There are 2 main use -cases:

  * min-revision: the required functionality was added to the module
    in a specific release

  * max-revision: functionality in use was altered or broken in a specific
release

In a way, import-by-revision works in YANG Conformance. (e.g., Foo==1.5.1
in the example above), because it isn't an import-stmt at at all.  It is
a conformance-stmt. The only thing needed to freeze a snapshot for
conformance purposes is the complete list of module/revision-dates
used by the conformance profile.  Each time module X is published,
a new conformance-stmt update is needed, identifying the module/dates
used at the time of publication. The min-revision/max-revision can be
removed.

However, import-by-revision is totally broken in YANG and should
never be used.  If module A uses module B/rev1 and module C uses module
B/rev2
then the server is advertising 2 revisions of B.

I prefer that only 1 revision of each module is loaded into the server.
The language should be robust enough so the current version of each module
can be loaded into a new server without breaking any old clients.
The way to do that is to explicitly state the conformance in a way that
does not change if the module is updated (like SMIv2 has had for about 20
years ;-)

> client may or may not understand).

IMO the additional YANG package info allows the server to sort out
the list of capabilities.  They are too course-grained.  Current YANG is
broken
if the server MUST implement the entire base just to use a typedef out
of a module.  The complete list is needed by the client.  The ability to
grab the YANG modules from the server, and compile them on the fly
to generate an exact view of the "server contract" is light years ahead
of SNMP and CLI. (So the answer cannot be advertise an incomplete
module set.)

Andy

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 20 Nov 2013 14:40:45 -0800

My feedback inline with [RP]

> [1] http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt

[RP] Did not read it, can not comment

> http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt

[RP] I support this work but with lower priority than the ones below.

> [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt

[RP] I support adoption. I read this draft a couple of times and exchanged
private emails with the author . This goes with the discussion on proposed
Netconf extensions to support JSON as an option to XML. This is something
we also touched upon in the presentation of Opendaylight "asks" for
Netconf/Netmod WGs..

I can spend time to review the draft and help it further.

> [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt

[RP] I support adoption. I read this draft a couple of times as well and
used it as a base for our work on Services Function Chaining models.

I can spend time to review the draft and help it further.

> [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt

[RP] Is there anybody working on a device model to complement this one?

> [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt

[RP] I read it and certainly support this work.

I can spend time to review the draft and help it further.

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 21 Nov 2013 10:16:39 +0100

Hi,

I agree with Martin that a conservative update to YANG (let's call it 1.1) is needed. IMO, the alternative is a series of ugly hacks (extensions) implementing pretty much the same changes but pretending - for political or marketing reasons - it is still the good old YANG 1.0. I think this would actually undermine the standard.

YANG 1.1 could include (parts of) [1], [2], or perhaps even [3] - having sections "JSON encoding" along with "XML encoding".

Regarding new data models: The core modules were a necessary exercise for the NETCONF WG, and they helped a lot in shaping "best practice" approaches and revealing problems, such as the relationship between configuration and state data.

However, I am not convinced that NETMOD WG is the right place for the development of a new set of domain-specific modules. One issue that we saw was that domain experts kept popping up randomly during the process with new comments and requests. So, while the result is hopefully good, it took way too much time. I think a more concentrated effort involving all domain experts at once is needed.

Lada

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

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 21 Nov 2013 21:01:59 +0000

I'd like to express my opinion inline.

Thanks,

- Xufeng

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Juergen
> Schoenwaelder
> Sent: Wednesday, November 20, 2013 2:00 AM
> To: [email-masked]
> Subject: [netmod] poll of interest on I-Ds submitted to the NETMOD WG
> 
> Hi,
> 
> at the last WG meeting in Vancouver, we did run out of time to discuss what
> to do with the various individual I-Ds that have been submitted to the
> NETMOD WG. So I like to poll for opinions on the list in order to get a feeling
> where we are. In particular, I like to poll for opinions on whether the
> following I-Ds should be worked on in an IETF working group and how you
> see the priorities. In particular, it would be nice to know who is willing to
> actively review documents and also who is planning to implement the
> technology proposed in the various I-Ds.
> 
> YANG Infrastructure:
> 

[XL] I support the idea to update YANG to a new version. We'd also like to have a solution soon, so if a new version of YANG takes too long to settle, we'd like to have something in between.

> [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt

[XL] Support this, and we are implementing this way.

> [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt

[XL] I support this. Actually we are preparing a draft to augment the topology for transport network (this draft currently covers topologies for OSPF and ISIS). We have started the implementation.

> If I am missing an I-D that is mature enough to be included in this list, please
> let me know.
> 
> /js
> 
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 26 Nov 2013 17:47:02 +0100

Hi,

one week has passed and I have seen input from _five_ people. This is
not a whole lot of people I think. If you have an interest in any of
the proposed work, please speak up now. Likewise, if you have strong
reasons why you think some work should not be done, please speak up as
well. I plan to draw conclusions from this poll next week - so please
send your comments until Dec. 1st.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 26 Nov 2013 18:30:29 -0800

> http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt

Obviously support this work

> http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-00.txt

Support this work as YANG extensions, not as a new version of YANG.

> > [3] http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt

This work is coupled to RESTCONF so if that gets chartered then
this work must be chartered as well.

> > [5] http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt

Support both drafts.  Not clear to me that NETMOD WG is
the correct WG to do domain-specific data models.  The
"MIB WG Model" (spin up a WG for just that module and close
it when the module is done) had mixed success in the past.
IMO the NETMOD WG should focus on the YANG language.

> > [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt

Not sure if this is solving a real standards problem or
just exposing some server implementation details,
so I don't support this draft at this time.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Nov 2013 07:31:26 +0100

Andy Bierman <[email-masked]> writes:

...

> Support this work as YANG extensions, not as a new version of YANG.

I am strongly against any use of extensions that violates the rule stated in RFC6020, sec. 6.3.1, namely:

   If a YANG compiler does not support a particular extension, which
   appears in a YANG module as an unknown-statement (see Section 12),
   the entire unknown-statement MAY be ignored by the compiler.

It is not the only use case for YANG to serve as guidelines for server implementors. For instance, I am now talking to guys that develop user interfaces from data models. For them, this extension would be a showstopper. Every vendor could (and would) define their own XPath functions, and then interoperability would be gone.

...

> IMO the NETMOD WG should focus on the YANG language.

I agree. The approach to domain-specific models might be something for the IESG to discuss and decide, based also on the past experience.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Nov 2013 07:19:58 -0800

On Tue, Nov 26, 2013 at 10:31 PM, Ladislav Lhotka <[email-masked]> wrote:

> It is not the only use case for YANG to serve as guidelines for server
> implementors. For instance, I am now talking to guys that develop user
> interfaces from data models. For them, this extension would be a
> showstopper. Every vendor could (and would) define their own XPath
> functions, and then interoperability would be gone.
>
>

OK -- I do not feel strongly that the XPath extensions should be added.
I agree that RFC 6020 did not properly define how to add XPath functions
to the server or how to deal with invalid function call exceptions.
I think it forbids new functions instead.

However I do not think a new YANG version is warranted at this time. The
deployment
costs for a new language version go much farther than the compiler writers.
The YANG module readers, writers, and developers have to deal with 2
versions for
several years.  Breaking YANG 1.0 implementations is just as bad by RFC
as it is by extension.  (Ask the SMIng WG survivors how easy it is to
make changes to a deployed modeling language ;-)

...
> >> > [5]
> http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt
> >> >
> >>
> >
> I agree. The approach to domain-specific models might be something for the
> IESG to discuss and decide, based also on the past experience.
>
> Lada
>
>

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Nov 2013 17:07:50 +0100

> I think it forbids new functions instead.

In my view, this is actually a feature. New XPath functions for use in “must” and “when” should imply a new YANG version, as long as their semantics cannot be formally specified.

Perhaps it would be useful to distinguish XPath functions in NETCONF filters from those that are used in “must” and “when”. While the former are essentially analogical to new RPCs, the latter affect the meaning of a data model. A client that doesn’t support an XPath function simply won’t use it in filters, but an unknown function in a YANG module cannot be ignored.

> 
> However I do not think a new YANG version is warranted at this time. The deployment

In this respect, how does the function-defining extension help in comparison to a bumped YANG version? The difference seems mainly psychological, actual software changes will be pretty much identical.

> The YANG module readers, writers, and developers have to deal with 2 versions for

The basic assumption should be that YANG 1.1 won’t break any existing modules.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Nov 2013 08:25:33 -0800

....
> The basic assumption should be that YANG 1.1 won’t break any existing
That isn't the problem. New tools working with old modules
is usually not a problem. Deploying new modules that break old
tools is the problem.

Lada

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Nov 2013 17:44:25 +0100

> is usually not a problem. Deploying new modules that break old

But this will only get worse with new tools appearing (hopefully) in the future. If there are things in YANG that need to be fixed, it should be done as soon as possible.

Lada

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Wed, 27 Nov 2013 23:33:27 +0000

Hi Juergen,
here is my input - inline <ALEX>
Thanks
--- Alex

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Tuesday, November 26, 2013 8:47 AM
To: [email-masked]
Subject: Re: [netmod] poll of interest on I-Ds submitted to the NETMOD WG

Hi,

one week has passed and I have seen input from _five_ people. This is not a whole lot of people I think. If you have an interest in any of the proposed work, please speak up now. Likewise, if you have strong reasons why you think some work should not be done, please speak up as well. I plan to draw conclusions from this poll next week - so please send your comments until Dec. 1st.

/js

> http://tools.ietf.org/id/draft-bierman-netmod-yang-conformance-01.txt

<ALEX> 
Conformance is an important aspect.  The issues pointed out are the right ones.  The solution needs more work, but I think this is a good working group item.  
</ALEX>

> http://tools.ietf.org/id/draft-bjorklund-netmod-yang-xpath-extensions-

<ALEX> Support
</ALEX>

 [3] 
> http://tools.ietf.org/id/draft-lhotka-netmod-yang-json-02.txt

<ALEX> I think this is important and needs to be worked on.  Part of the restconf, which is important as well, having a JSON alternative to XML to encode information makes a lot of sense
</ALEX>

> Data Models:

<ALEX> General comment:  I think data models are an important enabler for applications; data models for common items should be taken up for standardization by IETF and netmod makes for a natural home for these.  So, I am strongly supporting these.  

Of course, it is a possible that some of the data models will be developed in other working groups with expertise for the particular subject matter.  However, I don't think that YANG is mainstream enough yet where this will just happen by itself in other working groups.  
<ALEX>

> [4] http://tools.ietf.org/id/draft-huang-netmod-acl-03.txt

<ALEX> 
Obviously, I am biased here - I strongly support this.  ACLs and SPFs are among the most important items to configure today; no configuration solution is complete unless it addresses these.  There are many applications, also in the SDN space, which involve configuring stateless packet filters and access control rules and which will benefit from standardization.   
</ALEX>

> http://tools.ietf.org/id/draft-clemm-netmod-yang-network-topo-01.txt

<ALEX>
Same here.  I am biased here and I strongly support this.  Network topology is also needed by I2RS and can be considered a foundational data model.  It adds the aspect of data models that capture a network-level abstraction, not just a device-level abstraction.  Also, Open Daylight is already implementing to this.  
</ALEX>

> [6] http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt

<ALEX>
Again, I am biased.  I strongly support this.  The reason why this is important is that this enables federated data stores which can incorporate information/data from other systems without duplicating model development efforts.  It facilitates the development e.g. of northbound SDN controller interfaces and offers an alternative to the conventional information and mediation layers which make e.g. EMSs and NMSs hard to maintain (since everything needs to be mediated and supported).  It is possible to constrain the scope of this draft to specific use cases and scenarios as needed.  
</ALEX>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Nov 2013 15:58:04 -0800

On Wed, Nov 27, 2013 at 3:33 PM, Alexander Clemm (alex) <[email-masked]>wrote:

> <ALEX> General comment:  I think data models are an important enabler for
> applications; data models for common items should be taken up for
> standardization by IETF and netmod makes for a natural home for these.  So,
> I am strongly supporting these.
>
> Of course, it is a possible that some of the data models will be developed
> in other working groups with expertise for the particular subject matter.
>  However, I don't think that YANG is mainstream enough yet where this will
> just happen by itself in other working groups.
> <ALEX>
>
>
>

The plan was discussed 2 IETFs ago -- pretty much the same thing we did with
MIB modules for 20 years -- at least 1 YANG doctor will be following every
WG effort to create a YANG module. The domain experts figure out the info
model
and the YANG expert(s) help translate their ideas to NETCONF/YANG (or
RESTCONF/YANG ;-)
It's better than just early review, because the help is throughout the
process.

IMO the domain-specific data models being done now in NETMOD are taking a
long
time because domain experts are being brought into the process fairly late,
and perhaps
that is because it is done in NETMOD WG instead of the INT or RTG area.

Andy