Subject: [Netconf] Virtual Interim Results

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Dec 2017 06:20:28 +0000

This meeting concluded with an [anonymous] poll with the following results:

  Which option do you prefer?                     Most favored: Alt B
  Should licensing be considered now?             80% no
  Should h/w insertion/removal be considered now? 80% no
  Should sem-ver be considered now?               80% no

Note: Alt B is described on the slide #5 posted here:  https://datatracker.ietf.org/meeting/interim-2017-netconf-01/materials/slides-interim-2017-netconf-01-sessa-yang-library-options

These selections now need to be confirmed on the list.  Since it's assumed that all interested parties attended the meeting, these decisions will be final unless there are any objections raised in a week's time.

Thanks,
Kent & Mahesh

---

From: Lou Berger <[email-masked]>
Date: Thu, 14 Dec 2017 08:17:10 -0500

Hi,

Sorry I wasn't able to attend this short-notice interim - I had to run a
long-scheduled meeting. See below for some questions and comments.

> Note: Alt B is described on the slide #5 posted here:  https://datatracker.ietf.org/meeting/interim-2017-netconf-01/materials/slides-interim-2017-netconf-01-sessa-yang-library-options
Reading the notes it is subject to interpretation how B addresses the
questions/issues raised on the objectives slide, I'm not sure who, but I
think this information is needed to evaluate this alternative.  Can
someone (Martin?) provide this?

> These selections now need to be confirmed on the list.  Since it's assumed that all interested parties attended the meeting, these decisions will be final unless there are any objections raised in…
I guess I have no choice but to object.    I'm an interested party who
was unable to attend this very short notice interim - so am proof that
this assertion is false.  This is a process objection, which I really
don't like making, but as chair of NetMod I feel obligated to make it as
NetMod has many interested parties and that WG wasn't even notified of
the meeting -- I know most of us at least track both groups/lists, but I
don't think it fair to assume that all interested in Library do.

As an individual contributor, I suspect that the choice is a fine one,
but would like to understand how (b) addresses  the objectives on slides
2 and 3 or is even intended to be implemented - e.g., I read "Each
datastore refers to a schema" as meaning library is retrievable from
every datastore, and I'd be surprised if that was the intent.  --
Although, I think an answer that library is metadata, not operational
data, and therefore retrievable and identical in all datastores is a
workable answer; just not one I personally expected.

Lou

>
> Thanks,
> Kent & Mahesh
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Dec 2017 14:29:00 +0100

> don't think it fair to assume that all interested in Library do.

This was a NETCONF interim. I do not think there is a process
requirement that NETMOD is formally notified. So what exactly is your
process objection? That NETMOD was not formally notified or do you
object to the statement that "it is assumed that all interested
parties attended the meeting"? Sure, this assertion may not be true
but the complete sentence was:

These selections now need to be confirmed on the list.  Since it's
assumed that all interested parties attended the meeting, these
decisions will be final unless there are any objections raised in a
week's time.

So what is basis of your process objection? Can we simply stop this
debate and get back to the technical issues. Do you have any technical
concerns with alternative B?

/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: Lou Berger <[email-masked]>
Date: Thu, 14 Dec 2017 09:03:15 -0500

Juergen,

Sigh.

taking this out of order, and restoring context:

>  So what exactly is your
> process objection? 

The original message that I responded to says:
>>     Since it's assumed that all interested parties attended the meeting,
>>    these decisions will be final unless there are any objections
raised in a week's time.

and my response is:
> I'm an interested party who
> this assertion is false. 

I'm not sure how this could be more clear, do you really need more
explanation?

> requirement that NETMOD is formally notified.
It is not uncommon for chairs to agree to run the process for a document
that overlaps multiple WGs in one wg and to keep the other WG informed
of updates.  This is what happened for revised datastores as well as
this document.

> That NETMOD was not formally notified or do you
Yes, so I raised an objection, one based on both the assertion (as a
chair of WG that has interest in this document) and a technical concern
(as a contributor) -- I frankly don't understand why are you pushing
back on this?

> concerns with alternative B?
Please see my original message and feel free to respond.

Thanks,
Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 14 Dec 2017 15:14:22 +0100

> I'm not sure how this could be more clear, do you really need more

I understand your concern, I still do not see how you justify a
'process objection'. Perhaps my understanding what a 'process
objection' is is differnet from yours.

/js

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 14 Dec 2017 15:33:00 +0100

Hello all,

with respect to "process", a subscription to ietf announce and a few 
filters thrown into that to enable you to only see what you want to know 
might significantly increase visibility (at least for me it does).

Also, yes 5 days is pretty much "on short notice", too short for my 
schedule at least.

Viele Grüße,

Henk

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Dec 2017 15:34:48 +0100 (CET)

Lou Berger <[email-masked]> wrote:
> every datastore, and I'd be surprised if that was the intent. 

With Alt A - C, the yang-library data is normal operational state.

When it says "each datastore refers to a schema", the word "datastore"
refers to a list entry in the "datastore" list shown in the figure.
The text really just says the same as the tree diagram:

    +ro datastore* [name]
       |  +ro name      identityref
       |  +ro schema    > ../../schema/name

  "a datastore refers to a schema"

/martin

---

From: Lou Berger <[email-masked]>
Date: Thu, 14 Dec 2017 09:37:00 -0500

> Also, yes 5 days is pretty much "on short notice", too short for my 
Strictly speaking this too is a process violation, but not the one I
objected to...

Lou

PS I'm looking forward to the technical discussion on this topic.

---

From: Lou Berger <[email-masked]>
Date: Thu, 14 Dec 2017 09:42:30 -0500

Thanks Martin, see below.

> With Alt A - C, the yang-library data is normal operational state.

so is only available from that data store, right.  I think this has to
be made explicit when documenting this as I've seen this misinterpreted
(I asked a handful of folks and got different answers...)

can you summarize how b addresses, the objectives:
>
> o As efficient as possible for a client to consume.
> Since the size of the yang library can be quite large, it
> shouldbe possible for clients to cache the yang library
> information.
>
> o A dynamic datastore must be able to implement a module or
> feature that is not implemented in the conventional
> datastores.
>
> o It must be possible to NOT implement a module or feature in
> operational, even if it is implemented in some other datastore.
> This is required for transition purposes; a server that wants to
> implement <operational> should not have to implement all
> modules at once.
>
> o A given module can only be implemented in one revision in all
> datastores. If a module is implemented in more than one
> datastores, the same revision is implemented in all these
> datastores.
>
> o Multiple revisions can be used for import, if import-by revision
> is used.
>
> o Nice to have: make it possible to be used by schema mount

Thanks,
Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Dec 2017 15:58:18 +0100 (CET)

> (I asked a handful of folks and got different answers...)

Yes, I think you have already made this comment on the list, and I
have updated the document (not yet published) with:

  All data nodes in "ietf-yang-library" are "config false", and thus
  accessible in the operational state datastore.

> > shouldbe possible for clients to cache the yang library

There's a global checksum, and a checksum per schema.  So a client can
cache the yang library contents.

> > feature that is not implemented in the conventional

The dynamic datastore would have its own schema, which would not be
the same as the schema for the conventional datastores.

> > implement <operational> should not have to implement all

The operational state datastore would have its own schema, which would
not be the same as the schema for the other datastore.

> > datastores, the same revision is implemented in all these

This objective is redundant; it is a requirement from RFC 7950.  The
YANG library is a reporting module; the server is supposed to follow
RFC 7950 and use YANG library to report what it implements.

> > o Multiple revisions can be used for import, if import-by revision

This is the same for all solutions; the proposed way of handling this
is to have a list of imported modules, keyed by module name and
revision.

> > o Nice to have: make it possible to be used by schema mount

This alternative defines a reusable "schema", which schema mount can
re-use.  See Rob's presentation from the last IETF, for example.  He
has also sent this to the list (see his message from 2017-11-09,
"Alternative YANG library structure for 7895bis")

/martin

---

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 14 Dec 2017 16:17:19 +0100

The integration of YANG Library and Schema Mount has been discussed in NETMOD WG. Process-wise it would be more appropriate to forward the interim invitation to NETMOD maillist.

IETF process allows the announcement of virtual interims one week before the call but says in the same sentence "(ideally two)". Obviously one week is too short for many people.

Cheers,
Mehmet

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Henk
> Birkholz
> Sent: Thursday, December 14, 2017 3:33 PM
> To: Lou Berger <[email-masked]>; Kent Watsen <[email-masked]>;
> [email-masked]
> Subject: Re: [Netconf] Virtual Interim Results
> 
> Hello all,
> 
> with respect to "process", a subscription to ietf announce and a few filters
> thrown into that to enable you to only see what you want to know might
> significantly increase visibility (at least for me it does).
> 
> Also, yes 5 days is pretty much "on short notice", too short for my schedule
> at least.
> 
> Viele Grüße,
> 
> Henk
> 
> >> I guess I have no choice but to object.    I'm an interested party
> >> who was unable to attend this very short notice interim - so am proof
> >> that this assertion is false.  This is a process objection, which I
> >> really don't like making, but as chair of NetMod I feel obligated to
> >> make it as NetMod has many interested parties and that WG wasn't even
> >> notified of the meeting -- I know most of us at least track both
> >> groups/lists, but I don't think it fair to assume that all interested in Library
> do.
> >

---

From: Kent Watsen <[email-masked]>
Date: Thu, 14 Dec 2017 16:59:57 +0000

Hi Mehmet, et al.,

> The integration of YANG Library and Schema Mount has been discussed in NETMOD WG. Process-wise it would be more appropriate to forward the interim invitation to NETMOD maillist.

I agree that it would've been goodness and that we should've done this, but not an actual IETF process violation, right?

> IETF process allows the announcement of virtual interims one week before the call but says in the same sentence "(ideally two)". Obviously one week is too short for many people.

FWIW, a week's notice was given (see [1], and note the PS at bottom), as is the minimum allowed per [2].  The chairs discussed the short timing, but it was either this or wait until after the New Year, introducing weeks of delay.   We felt it worth pushing for the more aggressive timing in this circumstance.  Please note, as my co-chairs and AD will attest, I'm consistently trying to be fair with people's time; this circumstance is an outlier and does not represent a modus operandi going forward.

[1] https://www.ietf.org/mail-archive/web/netconf/current/msg13870.html
[2] https://www.ietf.org/iesg/statement/interim-meetings.html

Kent

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=YZauR_d5ZV2d0fjZPJunktulsZsXas5iGoPq315lB_4&s=zjI9ZPuuLAAVGS7FqGsbY3ecwITmwIlsVi259m7z1go&e=

---

From: Lou Berger <[email-masked]>
Date: Thu, 14 Dec 2017 13:57:31 -0500

>   accessible in the operational state datastore.
WFM

> is to have a list of imported modules, keyed by module name and

Thanks for the above.

> "Alternative YANG library structure for 7895bis")

I think it would be good to understand / define impact to schema mount
as part of this discussion.  I infer from your response, that an update
to schema mount will be required  for it to be aligned with this new
definition of library, correct?  Why not just do it as part of this bis,
probably as a feature as not all implementations of YL will implement
SM?  This seems cleaner to me and would ensure alignment between YL and
SM solutions.

Thanks,
Lou

---

From: "Mehmet Ersue" <[email-masked]>
Date: Thu, 14 Dec 2017 20:32:52 +0100

Hi Kent,

yes, you are right. There is no IETF process we've violated. 
However, I would like to suggest to follow the process we agreed for the NMDA architecture draft also in this case. 
For drafts in the interest of both WGS I think we should collect the opinion of and involve both maillists for final consensus. 

Thanks,
Mehmet

> From: Kent Watsen [mailto:[email-masked]]
> Sent: Thursday, December 14, 2017 6:00 PM
> To: Mehmet Ersue <[email-masked]>; 'Henk Birkholz'
> <[email-masked]>; 'Lou Berger' <[email-masked]>;
> [email-masked]
> > The integration of YANG Library and Schema Mount has been discussed in
> NETMOD WG. Process-wise it would be more appropriate to forward the
> interim invitation to NETMOD maillist.
> 
> I agree that it would've been goodness and that we should've done this, but
> not an actual IETF process violation, right?
> 
> 
> > IETF process allows the announcement of virtual interims one week before
> the call but says in the same sentence "(ideally two)". Obviously one week is
> too short for many people.
> 
> FWIW, a week's notice was given (see [1], and note the PS at bottom), as is
> the minimum allowed per [2].  The chairs discussed the short timing, but it
> was either this or wait until after the New Year, introducing weeks of delay.
> We felt it worth pushing for the more aggressive timing in this circumstance.
> Please note, as my co-chairs and AD will attest, I'm consistently trying to be
> fair with people's time; this circumstance is an outlier and does not represent
> a modus operandi going forward.
> 
> > filters thrown into that to enable you to only see what you want to
> > know might significantly increase visibility (at least for me it does).
> >
> > >> who was unable to attend this very short notice interim - so am
> > >> proof that this assertion is false.  This is a process objection,
> > >> which I really don't like making, but as chair of NetMod I feel
> > >> obligated to make it as NetMod has many interested parties and that
> > >> WG wasn't even notified of the meeting -- I know most of us at
> > >> least track both groups/lists, but I don't think it fair to assume
> > >> that all interested in Library
> > do.
> > >
> > > requirement that NETMOD is formally notified. So what exactly is
> > > your process objection? That NETMOD was not formally notified or do
> > > you object to the statement that "it is assumed that all interested
> > > debate and get back to the technical issues. Do you have any
> > > technical concerns with alternative B?
> > >
> > > /js
> > >
> >
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_netconf&d=DwIFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXc
> >
> WzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=YZauR_d5Z
> V2d0fjZ
> >
> PJunktulsZsXas5iGoPq315lB_4&s=zjI9ZPuuLAAVGS7FqGsbY3ecwITmwIlsVi25
> 9m7z
> > 1go&e=
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 15 Dec 2017 15:27:15 +0100

> SM?  This seems cleaner to me and would ensure alignment between YL and

I think it is cleaner if yang library just defines yang library and
schema mount adds to it whatever is needed to make schema mount work
(if any). What we are trying to achieve is that yang library is
designed to make this possible (by exposing named schemas that can be
referenced). I think it is not desirable that yang library depends on
schema mount, even if guarded by a feature, since this leads to
circular dependencies between specifications, which makes it difficult
to move technology forward later on.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 15 Dec 2017 15:35:12 +0100

> to move technology forward later on.

I agree, the only thing that's needed is the ability to include mounted schemas
in the YANG library's "schema" list. Schema mount data that complement/augment
YANG library could then simply refer to these schemas.

Lada 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Lou Berger <[email-masked]>
Date: Mon, 18 Dec 2017 15:22:42 -0500

> to move technology forward later on.
I'm fine with SM being an independent document/module, but I think this
doesn't change the need to understand  understand / define impact to
schema mount as part of this discussion.  From my perspective, YL is
really more about server metadata than true operational data.  While I
don't object to accessing server metadata as operational data I do think
we should make sure there aren't unintended consequences that are
unreasonable.  SM brings in additional form of server metadata and
affords an opportunity to test the approach.  It seems to me that if we
don't see the metadata access approach as viable  for a second case.
i.e., SM, I don't see how we can consider it a good/viable general solution.

Lou