Subject: [netmod] draft minutes yang 1.1 interim meeting new york

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Sep 2014 12:08:29 +0200

Hi,

here are the draft minutes - please let me know what needs to be
fixed. 

http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt

I have to send the minutes to the secretariat for inclusion in the
proceedings by the end of next week - so please send me any
corrections until Thursday next week.

/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: "Sterne, Jason (Jason)" <[email-masked]>
Date: Fri, 19 Sep 2014 18:06:32 +0000

Hi guys,

Is there rough consensus on current "best practices" for nested sub-modules ?  I know there's been a lot of debate over this one in the past months.

Is it incorrect to do simple nesting like a C #include,  e.g. 
module a includes submodule b (but not c)
module b includes submodule c

Jason

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Friday, September 19, 2014 6:08 AM
To: [email-masked]
Subject: [netmod] draft minutes yang 1.1 interim meeting new york

Hi,

here are the draft minutes - please let me know what needs to be fixed. 

I have to send the minutes to the secretariat for inclusion in the proceedings by the end of next week - so please send me any corrections until Thursday next week.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 19 Sep 2014 14:12:12 -0400 (EDT)

"Sterne, Jason (Jason)" <[email-masked]> wrote:
> Hi guys,
> 
> Is there rough consensus on current "best practices" for nested
> sub-modules ?  I know there's been a lot of debate over this one in
> the past months.
> 

The problem is that RFC 6020 in unclear about this.  Hence Y49 in
order to clarify.

I think that everyone agree that including all submodules in the main
module is legal.  What is unclear is if:

  module a include b  (but not c)
  submodule b include c

is legal or not.

So - if you instead do

  module a include b and c

you're good.

/martin

---

From: [email-masked]
Date: Mon, 22 Sep 2014 09:13:28 +0800

* Y16 module advertisement optimization / Y54 remove the advertisement of 
conformance information in NETCONF hello message

  - MB: YANG 1.0 modules will continue to be advertised in hello
    messages but for YANG 1.1 modules, we may advertise only a module
    set 'hash'.
 
  - MB: We should provide access to the module list in the same way
    for NETCONF and RESTCONF.
 
  - DB: We may have to support different module sets on
    NETCONF/RESTCONF or different module sets for different users or
    different module sets for different datastores.
 
  - MB: Since hello basically works, is this really a problem to fix,
    given the overall overhead of the secure transports NC is running
    over? RC does not have the equivalent of hello.
 
  - JS: The hello message size is mostly an issue for short lived
    sessions.
  - JH: Or for sessions running over links with noticeable packet loss
    rates.
  - DB: This may be an issue for eNodeBs.
 
  Proposal: We do not send YANG 1.1 module URIs but instead we send a
  hash or identifier. 

[frank]: I think it's enough that server only send a hash to indicate all 
modules' 
conformance information. It's not necessary that every module send it's 
own hash
in hello message, because moudles' conformance information are not too 
large, client
can get all modules' conformance information when it find server's 
conformance has changed.

please see my new draft:
http://datatracker.ietf.org/doc/draft-frank-netconf-conformance/

 - JS: What is the scope of the hash or identifier? Is it scoped by
    the user or just by the NETCONF server? Do we go with a hello RPC
    or just pull this from a data model? Data model allows control
    from NACM, which may be a feature. Use the RESTCONF model as a
    starting point? Or revise RFC 6022?

  - BL: RFC6022 has NACM applied to it and thus it provides
    effectively information specific to a user.
  - LL: I suggest to factor the protocol bindings out of the YANG 1.1
    specification into a different document.
  - JS: It would be nice to have the meta model Randy has been talking
    about but right now it seems a major surgery to a 1.1 update.
  - MB: Perhaps it is sufficient if all NETCONF specific parts are
    flagged in proper subsections.

  Proposal: We create a new ietf-yang-advertisement module that
  details a data model for the advertisement of YANG data models (that
  works in the same way for NETCONF and RESTCONF).

[frank]: I have created a module called ietf-netconf-conformance to 
support
client to get server's detail conformance information.

please see my new draft:
http://datatracker.ietf.org/doc/draft-frank-netconf-conformance/

"netmod" <[email-masked]> 写于 2014-09-19 18:08:29:

> Juergen Schoenwaelder <[email-masked]> 
> 发件人:  "netmod" <[email-masked]>
> 
> 2014-09-19 18:08
> 
> 请答复 给
> Juergen Schoenwaelder <[email-masked]>
> 
> 收件人
> 
> [email-masked], 
> 
> 抄送
> 
> 主题
> 
> [netmod] draft minutes yang 1.1 interim meeting new york
> 
> Hi,
> 

> [附件 "netmod-2014-09-18-minutes.txt" 被 冯冲10136492/user/zte_ltd 删
> 除]_______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2014 08:28:18 +0200

>   module a include b  (but not c)

Yes. IMO YANG 1.1 spec should state that all submodules must be included
from the main module, and then without further ado all submodules have
access to all definitions from the main module and all other
submodules. Anything else hardly makes sense because the main module and
all submodules share the same namespace anyway.

For compatibility, includes from submodules can remain legal but they
would be a no-op.

While this proposal is not strictly backward compatible, I think it
could be considered a bugfix.

Lada

>
>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> [email-masked]

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2014 08:35:16 +0200

Hi,

I am not sure I agree with the following:

Juergen Schoenwaelder <[email-masked]> writes:

>    Proposal: Keep features as the unit of conformance in YANG 1.1 but
>    consider certain improvements:
>      - indicate in the module advertisement data model the conformance
>        associated with a module (full = "all base data nodes, rpcs,
>        notifications", )

I think "full" should mean "everything except nodes depending on
features that the server does not advertise".

My understanding was that "base" means only nodes that don't depend on
any feature, regardless of what the server advertises.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Sep 2014 12:54:47 +0200

> any feature, regardless of what the server advertises.

I understood full as in draft-bierman-netmod-yang-conformance-03.txt:

   o  full: Full implementation of the module base is required.  This is
      the default value if the require-conformance statement is not
      present.

I assume 'full' is kind of a misnomer but I think we did refer to
Andy's I-D during the discussions. So from this perspective, do you
agree with the minutes?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2014 13:21:21 +0200

> Andy's I-D during the discussions. So from this perspective, do you

IMO “full” is not only a misnomer but also a dubious alternative to “import”. A server advertising full conformance + feature X should implement all data nodes that depend only on feature X.

I don’t think the proposal should be as it is in the minutes. I actually noticed this already in Etherpad but since the discussion had already moved elsewhere, I didn’t want to reopen it, so I am doing it now.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Sep 2014 13:37:42 +0200

> I don’t think the proposal should be as it is in the minutes. I actually noticed this already in Etherpad but since the discussion had already moved elsewhere, I didn’t want to reopen it, so I am d…

Lada,

if you want to fix the minutes, send a clear patch here. If you want
to continue a discussion, please do it in a thread that has the issue
in the subject line. I am not clear what your goal here is.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2014 13:52:32 +0200

> in the subject line. I am not clear what your goal here is.

Why, my goal of course is to patch the minutes. BTW, I think the part about “import” conformance level fell through the cracks somehow - it should follow after the dangling comma in the parentheses. I propose this change:

OLD

NEW

     - indicate in the module advertisement data model the conformance
       associated with a module (full = "all data nodes, rpcs,
       notifications that are ether unconditional or depend on advertised
       features", import = “only extensions, typedefs, groupings, identities
       and features that are defined at the top level of the module")

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Sep 2014 14:16:46 +0200

>        and features that are defined at the top level of the module")

Thanks for the concrete proposal. 

But I am not sure - at least I have been using the definition of
'full' in Andy's draft during the meeting (I recall that I looked the
I-D up because I was unsure about the semantics).

So I guess it would help to hear from the other participants what they
recall we have been discussing when we mentioned 'full'.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2014 14:23:41 +0200

> I-D up because I was unsure about the semantics).

I formulated what “full” is supposed to mean in the discussion, along the above lines, and nobody protested. I am not going to search for it the webex recording though. :-) 

> recall we have been discussing when we mentioned 'full’.

Yes, that would be useful.

Thanks, Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 22 Sep 2014 14:27:18 +0200 (CEST)

> recall we have been discussing when we mentioned 'full'.

I think both explanaitions are correct, but Lada's proposal is more
detailed.  In the end it doesn't matter much b/c we need to agree on
concrete text in the document anyway.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Sep 2014 14:30:06 +0200

On Mon, Sep 22, 2014 at 09:13:28AM +0800, [email-masked] wrote:
> conformance information.

This is exactly what was discussed. But then we also discussed that it
is not really a hash but more of an identifier for the given module
set. We also discussed what the scope of such an identifier would be.

> http://datatracker.ietf.org/doc/draft-frank-netconf-conformance/

We are aware of the I-D and there were some concerns that the I-D is
too complex and has elements we do not understand (like what are
'functions') nor was it clear that including deviation into the
get-schema-conformance RPC was a good idea.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Sep 2014 06:50:11 -0700

> Andy's I-D during the discussions. So from this perspective, do you

The term "module base":

   o  module base: There is an implied "base" version of the module,
      which includes all statements which are not conditional.  The
      module base may be empty, a subset of all statements, or the
      entire module.

The term "conditional node"

  o  conditional node: An object that has one or more "if-feature" sub-
      statements associated with it.  Note that objects affected by
      "when" statements are not considered conditional for conformance
      purposes.

Hopefully not all people skip over the Terms section because they think
it is part of the boilerplate.

I am about to publish draft-04 that addresses only module-level
conformance,.
The 1 day spent at the interim helped understand the problems of
conformance drift and conformance ambiguity a little better.

There are still some details that are broken wrt/ interim consensus.
For example, many client applications expect the entire module set
used by the server will be advertised.  Removing modules from this
advertisement will break such applications.

> /js
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2014 16:03:08 +0200

On 22 Sep 2014, at 15:50, Andy Bierman <[email-masked]> wrote:

> 
> 
> On Mon, Sep 22, 2014 at 3:54 AM, Juergen Schoenwaelder <[email-masked]> wrote:

I didn’t skip that section, and that’s why I raised this issue. Unconditional nodes are not enough for full conformance - if they were, why bother with features?

Lada

> 
> I am about to publish draft-04 that addresses only module-level conformance,.

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Sep 2014 07:09:38 -0700

On Mon, Sep 22, 2014 at 7:03 AM, Ladislav Lhotka <[email-masked]> wrote:

> I didn't skip that section, and that's why I raised this issue.
> Unconditional nodes are not enough for full conformance - if they were, why
> bother with features?
>
>
huh?
The server can choose it if wants to advertise any features from a module.
Simply importing another module does not pull in any statements associated
with
a YANG feature.

Perhaps the term "full" should be "base" instead.
The term "full" is not relevant to YANG conformance.
There are only the parts that are not conditional (base)
and an ad-hoc collection of purely optional conditional parts.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Sep 2014 16:20:30 +0200

On Mon, Sep 22, 2014 at 04:03:08PM +0200, Ladislav Lhotka wrote:
> 
> I didn’t skip that section, and that’s why I raised this issue. 
> Unconditional nodes are not enough for full conformance - if
> they were, why bother with features?

This is why I said 'full' is a misnomer. I have changed the minutes as
follows:

Index: netmod-2014-09-18-minutes.txt
===================================================================
--- netmod-2014-09-18-minutes.txt	(revision 72)
+++ netmod-2014-09-18-minutes.txt	(working copy)
@@ -162,8 +169,10 @@
    Proposal: Keep features as the unit of conformance in YANG 1.1 but
    consider certain improvements:
      - indicate in the module advertisement data model the conformance
-       associated with a module (full = "all base data nodes, rpcs,
-       notifications", )
+       associated with a module (base = "all unconditional data nodes,
+       rpcs, notifications", import = "only extensions, typedefs,
+       groupings, identities and features that are defined at the top
+       level of the module")
      - support import by revision >= N OR remove import by revision
        (which is mostly important for groupings that get modified)
      - allow adding/removing features/if-features in revised YANG

Does this resolve this issue with the minutes?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2014 16:21:40 +0200

> and an ad-hoc collection of purely optional conditional parts.

module M {
  ...
  feature X;
  leaf foo { type empty; }
  leaf bar {
    if-feature X;
    type uint8;
  }
}

Now, the server advertises module M with feature X, and also claims
"full" conformance. Is it OK if it only implements "foo" and not "bar"
(because only the former is a part of "base module")?

The point is as soon as a feature is advertised, the corresponding
conditional parts are no more purely optional.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Sep 2014 07:49:13 -0700

> (because only the former is a part of "base module")?

nobody has ever suggested that implementation of an optional part
could be done instead of the non-optional parts.

> conditional parts are no more purely optional.
yes -- that is how YANG features work.  Not sure why we need reminding of
that.

Advertising "module=M&revision=2014-01-01" is needed so the module set is
complete. Applications use that for a parts list, not conformance.  The
server
would only add "&features=X" if it elected to support the conditional parts
for X.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2014 17:04:26 +0200

> could be done instead of the non-optional parts.

My understanding of full conformance is that *both* foo and bar must be implemented in this case.

> yes -- that is how YANG features work.  Not sure why we need reminding of that.
> 
> complete. Applications use that for a parts list, not conformance.  The server
> would only add "&features=X" if it elected to support the conditional parts for X.

In my view, full/import is orthogonal to feature specification. A module may be advertised with "&features=X” and only import conformance level.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Sep 2014 08:16:16 -0700

> implemented in this case.

If the server does not advertise feature X: foo is mandatory to implement
If the server does advertise feature X: foo and bar are mandatory to
implement

> In my view, full/import is orthogonal to feature specification. A module
> may be advertised with "&features=X" and only import conformance level.
>
>

My understanding is the all objects are mandatory to implement unless they
have
"if-feature" statements. Then all of the corresponding features must be
advertised by
the server or the data node does not need to be supported.

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2014 17:34:11 +0200

On 22 Sep 2014, at 17:16, Andy Bierman <[email-masked]> wrote:

> If the server does advertise feature X: foo and bar are mandatory to implement
> 
> 
> 
> >
> >
> My understanding is the all objects are mandatory to implement unless they have
> "if-feature" statements. Then all of the corresponding features must be advertised by

Maybe it would be wiser to wait till the next revision of the conformance draft because the package declaration is a source of additional confusion (for me at least).

Anyway, my understanding of full/import conformance declaration at the *module* level is that the server is able to say:

1. full = I am implementing everything.

2. import = I am only using top-level groupings, typedefs, features etc. from that module.

Features then seem really orthogonal to this information because conditional nodes may be both in the data trees and in top-level groupings.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Sep 2014 17:35:48 +0200

Folks,

can we please stop discussing issues in this thread? This thread is
for discussing meeting minutes.

Thanks.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2014 17:43:56 +0200

> Index: netmod-2014-09-18-minutes.txt

I don’t think so. What is the difference between full and base wrt to advertised features?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Sep 2014 17:56:21 +0200

> I don’t think so. What is the difference between full and base wrt to advertised features?

It is unclear. It was unclear during the meeting. The purpose of
minutes is to reflect the meeting. I happy to change base back to
full. ;-)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 22 Sep 2014 18:33:02 +0200

> minutes is to reflect the meeting. I happy to change base back to

Actually, it might be better to delete the text in parentheses and leave it to the draft to define these terms properly.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 Sep 2014 20:54:49 +0200

> Actually, it might be better to delete the text in parentheses and leave it to the draft to define these terms properly.

These are minutes - they do not define anything. I will add 'e.g.,' in
front of base and I hope this resolves this issue with the minutes.

NEW:

     - indicate in the module advertisement data model the conformance
       associated with a module (e.g., base = "all unconditional data
       nodes, rpcs, notifications", import = "only extensions,
       typedefs, groupings, identities and features that are defined
       at the top level of the module")

/js

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Sep 2014 15:55:12 -0400

> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt

For I2RS purposes, close enough.  Thank you for taking the minutes.

My action item is to write up a more specific set of discussion minutes for
I2RS and derive our next actions from WG discussion.

-- Jeff

---

From: [email-masked]
Date: Tue, 23 Sep 2014 08:57:26 +0800

Juergen Schoenwaelder <[email-masked]> 写于 
2014-09-22 20:30:06:

> 2014-09-22 20:30
> [email-masked], 
> Re: [netmod] draft minutes yang 1.1 interim meeting new york
> 

I agree it's not really a hash, it is a identifier. But I think this 
identifier
should be open to vendor to define. I suggest WG use conformance-ID 
mentioned in 
my draft as terminology for this identifier.

> get-schema-conformance RPC was a good idea.

'optional functions' is just 'feature' in YANG.