Subject: [netmod] moving forward with schema mount

From: Kent Watsen <[email-masked]>
Date: Mon, 22 Jan 2018 20:05:54 +0000

Thank you all for the important discussion since the completion of WGLC on Nov 6th.

Per normal process, drafts typically progress once LC comments are address unless significant faults are found.  Post LC comments have been made, which needed consideration, notably the relationship with NMDA and rfc7895bis and an alternate representation of inline schema.  These have been considered respecting their impact on the last call consensus and it is the position of the chairs that it is best to advance the existing schema-mount document at this time.

Given that there are significant concerns for how the solution proposed in this draft operates with NMDA, we do think it reasonable to add an applicability statement to the draft that covers its operation in NMDA implementations. We do not believe that such a statement substantively alters the draft nor would it impact drafts that normatively reference the current draft.

In addition to resolving the remaining open thread [1], we also agree with the recently made comment that the schema mount draft should allow the use of rfc7895bis (i.e., not reference /modules-state), thereby enabling the draft's use (though not ideal) on servers supporting rfc7895bis.

The chairs will propose specific text for the updates mentioned in this message to be reviewed by the WG for correctness before final submission and advancement. 

[1] https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html

Thanks,
Kent, Lou, and Joel

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Jan 2018 09:24:25 +0100 (CET)

Hi,

So do you believe that this decision reflects rough consensus in the
WG?

I hope that the document writeup will show that the WG is divided on
this issue.

For the record, if this means that using Schema Mount *with* NMDA gets
delayed, I strongly object to this decision.

Assuming this document now moves forward as-is, can we assume that we
can start to work on the bis document immediately?  What is needed?

  1.  a new individual draft
  2.  some time until this becomes WG draft
  3.  some time before WGLC

Do we have to go through all these steps?

This new draft would immediately obsolete the current SM document,
right?  And it would mark the current SM YANG nodes as deprecated.

Maybe we can send both the original document and the bis document to
the IESG at the same time ;-)

/martin

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

---

From: joel jaeggli <[email-masked]>
Date: Tue, 23 Jan 2018 09:09:37 -0500

> delayed, I strongly object to this decision.
I don't think it does. assuming we had a draft that addresses that
problem. we could poll for working group adoption now.  and proceed with
that one accordingly. what happens there is orthogonal to sending this
one on it's way.
>   2.  some time until this becomes WG draft
call for adoption can occur once we have a draft.
> Do we have to go through all these steps?
there's roughly three weeks of more or less required process time 
between submission to a working group and the close of WGLC, everything
else is compressible to various degrees if we can satisfy our standards
for consensus, and we don't spend to much time orbiting the same point.
> the IESG at the same time ;-)
If you hurry. the first one has taken a bit over 2 years to this point,
I certainly think we can reel that in.

---

From: Kent Watsen <[email-masked]>
Date: Tue, 23 Jan 2018 16:52:50 +0000

> So do you believe that this decision reflects rough consensus
> in the WG?

Not currently, as there are two vocal groups with opposing 
viewpoints.  However, there was strong for advancing it 
before.  The chairs had to make a decision and, as you can
imagine, it wasn't easy.  Ultimately, to use a colloquialism,
a bird in hand is better than two in the bush.

> I hope that the document writeup will show that the WG is
> divided on this issue.

It will and, undoubtedly, the IETF Last Call will be an 
interesting one.

> right?  And it would mark the current SM YANG nodes as deprecated.

A WG decision, but seems reasonable.  Are there any small things
that can be done to the current model to facilitate this?

> Maybe we can send both the original document and the bis document
> to the IESG at the same time ;-)

This would be fabulous.

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Jan 2018 21:26:10 +0100

> Per normal process, drafts typically progress once LC comments are address unless significant faults are found.  Post LC comments have been made, which needed consideration, notably the relationshi…

If we take the formal road, then you may want to read again Robert
Wilton's email posted on November 2nd (Thu, 2 Nov 2017 17:06:34 +0000)
again. He does talk about YANG library alignment - so YANG library
alignment is not just post LC comments. (I personally prefer to have
technical discussion than formal discussions but if it is necessary to
g there...)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 23 Jan 2018 21:32:51 +0100

> a bird in hand is better than two in the bush.

I am not convinced that publishing two competing schema mount
solutions at more or less the same time makes the Internet work
better.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Jan 2018 13:00:29 +0100

> technical discussion than formal discussions but if it is necessary to

As a matter of fact, I proposed pretty much the same thing already back in
March 2017:

https://www.ietf.org/mail-archive/web/netmod/current/msg18045.html

Lada

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

---

From: Christian Hopps <[email-masked]>
Date: Wed, 24 Jan 2018 07:37:35 -0500

Great news.

Thanks,
Chris.

Kent Watsen <[email-masked]> writes:

> Per normal process, drafts typically progress once LC comments 
> are address unless significant faults are found.  Post LC 
> comments have been made, which needed consideration, notably the 
> relationship with NMDA and rfc7895bis and an alternate 
> representation of inline schema.  These have been considered 
> respecting their impact on the last call consensus and it is the 
> position of the chairs that it is best to advance the existing 
> schema-mount document at this time.
>
> Given that there are significant concerns for how the solution 
> proposed in this draft operates with NMDA, we do think it 
> reasonable to add an applicability statement to the draft that 
> covers its operation in NMDA implementations. We do not believe 
> that such a statement substantively alters the draft nor would 
> it impact drafts that normatively reference the current draft.
>
> In addition to resolving the remaining open thread [1], we also 
> agree with the recently made comment that the schema mount draft 
> should allow the use of rfc7895bis (i.e., not reference 
> /modules-state), thereby enabling the draft's use (though not 
> ideal) on servers supporting rfc7895bis.
>
> The chairs will propose specific text for the updates mentioned 
> in this message to be reviewed by the WG for correctness before 
> final submission and advancement.
>
> [1] 
> https://www.ietf.org/mail-archive/web/netmod/current/msg20049.html
>
> Thanks,
> Kent, Lou, and Joel
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Jan 2018 14:07:43 +0100

Hi,

Kent Watsen <[email-masked]> writes:

> Per normal process, drafts typically progress once LC comments are
> address unless significant faults are found.  Post LC comments have
> been made, which needed consideration, notably the relationship with
> NMDA and rfc7895bis and an alternate representation of inline schema.
> These have been considered respecting their impact on the last call
> consensus and it is the position of the chairs that it is best to
> advance the existing schema-mount document at this time.

I guess I have no chance but strongly object to this. Is it normal to
proceed this way without reaching WG consensus and against the will of
*both* document authors?

> proposed in this draft operates with NMDA, we do think it reasonable
> to add an applicability statement to the draft that covers its
> operation in NMDA implementations. We do not believe that such a
> statement substantively alters the draft nor would it impact drafts
> that normatively reference the current draft.
>
> In addition to resolving the remaining open thread [1],

Hmm, who resolved this thread? Lou proposed some text and nobody
expressed any agreement with it. In fact, I believe it is nothing more
than hand-waving.

I must say that the work on this draft was very frustrating for me. Even
more than on RFC 8022, and this tells you something.

Lada

> we also agree
> with the recently made comment that the schema mount draft should
> allow the use of rfc7895bis (i.e., not reference /modules-state),
> thereby enabling the draft's use (though not ideal) on servers
> supporting rfc7895bis.
>

---

From: joel jaeggli <[email-masked]>
Date: Wed, 24 Jan 2018 09:35:49 -0500

> proceed this way without reaching WG consensus and against the will of
Once the document is adopted by the working group it's the working
group's document.

The consensus call was made back here:

https://www.ietf.org/mail-archive/web/netmod/current/msg19433.html

To my mind the discussion that we picked up in the new year highlights
the limitations of the existing draft without it being fatally flawed.
To wit (and this is my opinion), this one is stable and should proceed,
clearing the path for drafts with normative dependencies; we should
proceed with an update in a timely fashion.

IETF Last call serves a useful function in that is exposes the problem
discussed here beyond the working group, particularly to those who
depend on schema mount today. I think we understand in making this
judgement call where the working group participants stand today.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 24 Jan 2018 15:55:28 +0100

> https://www.ietf.org/mail-archive/web/netmod/current/msg19433.html

So then go ahead and resolve _all_ comments that were made during
WG last call.
 
> proceed with an update in a timely fashion.

I believe the YANG library alignment issue was raised earlier than
'new year' and actually during WG last call. Since the YANG library
interim (NETCONF WG) in December we have a clearer view on YANG
library. Anyway, I expect that all WG last call comments will be dealt
with - otherwise there is a process error.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 Jan 2018 16:18:13 +0100

> https://www.ietf.org/mail-archive/web/netmod/current/msg19433.html

Ongoing threads are mentioned here, and they have to be resolved.

> the limitations of the existing draft without it being fatally flawed.

What would be fatally flawed are two different versions of schema mount.

> judgement call where the working group participants stand today.

An author objecting against his own document in the IETF LC - this sounds pretty
crazy. If possible, I'd prefer to find consensus within the WG.

Lada

> > > The chairs will propose specific text for the updates mentioned in this
> > > message to be reviewed by the WG for correctness before final submission
> > > and advancement. 
> > >

---

From: Lou Berger <[email-masked]>
Date: Wed, 24 Jan 2018 10:40:41 -0500

One additional point below.

> Once the document is adopted by the working group it's the working

A document moving away from the original authors intent or even
agreement has happened before in the IETF.  I'm aware of several cases
of it *right now*, one in this group the others in different areas.  In
the case of this group, the original (lead) author choose to remove
themselves from the work and others in the WG took over the pen.  In the
other WGs, the original authors dropped the work and new authors took it
over.  In the case of the work that I initiated that this happened with,
I'm not sure if I'm listed or not as it's been so long since I looked at
the draft, but I know I'm no longer on the front page and the WG chair
appointed editor is a non-original author who I recommended.  So your
current position is not unique, nor counter to our process.

As a reminder, it is the responsibility of the document editors to
document WG consensus -- they have a lot of latitude in how they do
this, but in the end, WG consensus is what should be captured once an a
topic is discussed. It is also the WG chairs responsibility to ensure
that a document reflects WG consensus, this includes ensuring that the
document editors/authors follow consensus and appointing editors when
the authors need assistance in this.  An editor can be appointed if you
and Martin think this is necessary, but I think the preference of the
chairs is that we don't at this late date.

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 24 Jan 2018 10:20:07 -0500

> technical discussion than formal discussions but if it is necessary to

Focusing a moment on the future and the technical, it would be most
helpful to have a document that describes SM with NMDA and YL-bis.  This
would at least be a starting point for WG discussion.  It might even
help show if the current plan is flawed.

I, personally, suspect that a proposal that changes basic approach, or
revisits past arguments, will end up in another round of very long
discussions based on what each party thinks is optimal. Therefore, I
hope that the initial proposed solution would take a minimalistic change
approach in order to garner widest support.  This consensus foundation
could then provide a foundation for further optimization to the degree
supported by WG consensus.

Lou

---

From: Christian Hopps <[email-masked]>
Date: Fri, 26 Jan 2018 09:18:55 -0500

Maybe a meeting at this point is useful? It would consolidate things and
get away from the endless email threads.

If this isn't already known to everyone. There are many people for whom
the length of time to market from IETF simple doesn't work in particular
with models. That's one big reason that openconfig exists. Sitting on
working solutions waiting for them to be perfect is just getting us
ignored by industry.

In particular when I, Lou, et al. realized we needed a way to "mount
schema" for a clean VRF and VM solution, we thought this was a simple
thing and we could do it rather quickly -- the concept is just not that
complex. The idea was picked up by Martin and Lada who produced drafts,
and there were in fact some devil in the details and those got worked
out over longer than anyone wanted, but it is what it is.

Now it seems we are supposed to wait a bunch longer on yet other works
in progress for as near as I can tell (could be wrong here as I just
don't have time to read the very long email threads that netmod
generates) capturing meta-data in a cleaner way than another. This does
*not* seem like a reason to stall this work any further.

Thanks,
Chris.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 26 Jan 2018 15:33:52 +0100 (CET)

Hi,

Christian Hopps <[email-masked]> wrote:
> generates) capturing meta-data in a cleaner way than another.

During the time since we started working on schema mount, we (the WG)
have also defined the NMDA.  All we (the SM authors and others) are
asking for is that schema mount is defined to be compatible with the
NMDA.  This is something we (the IETF) currently require of all other
drafts.

The missing piece of this puzzle is the new YANG library.  During the
interim in December a solution was picked.  This solution is
documented in the latest draft, and a new version of this draft will
be published next week, which we hope can go to WGLC.

/martin

This does

---

From: David Bannister <[email-masked]>
Date: Fri, 26 Jan 2018 09:40:00 -0500

Chris +1 on the taking too long in pursuit of the perfect model.  No
service provider or enterprise wants to put their network evolution on hold
waiting for the IETF.  Instead they will seek what they need from other
SDOs as you point out.  The IETF needs to modernize their process and
perhaps adopt some of the methods used by OpenConfig.  Read that as getting
away from a long drawn out consensus process that turns into a multi-year
effort.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Jan 2018 15:41:38 +0100

> *not* seem like a reason to stall this work any further.

What is your interpretation of 'a bunch longer'? Or said differently,
how much time do you think it will take to get the current schema
mount approved (which has pending WG last call issues) and how much
time would you find acceptable for a solution that also complies with
NMDA and YANG library bis? I believe people are willing to give the
later high priority.

/js

---

From: Christian Hopps <[email-masked]>
Date: Fri, 26 Jan 2018 10:04:23 -0500

Unfortunately, I don't have time to go into a multi-email back and forth
justifying point by point. The model is going on 2 years old now, I
think it works just fine for what operators need, and see no issue with
NMDA -- it should just work that was the point behind the NMDA design.

Thanks,
Chris.

---

From: Christian Hopps <[email-masked]>
Date: Fri, 26 Jan 2018 10:06:06 -0500

In the context of holding up this work, I don't care one iota about YANG
library bis, and it works just fine with NMDA AFAICT.

We need models to get work done.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Jan 2018 16:22:44 +0100

OK, I accept that you do not care. Please also accept that others do
care. And these people believe YANG library bis is needed.

Since you do not want to read emails and involve yourself in
discussions of technical details, I assume this is where our
conversation stops.

I tought you wanted to start a constructive conversation towards a
resolution of the problem but it seems I misunderstood.

/js

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 26 Jan 2018 10:30:35 -0500

I will ask a different question

How many people have implemented the draft? And are they talking from experience implementing the model? I have implemented LNE and NI and to be honest, when customers ask about IETF compatibility, i reference a draft and tell them it will take long time until IETF finalizes the RFC. When it does, we will update the implementation if needed. Within WG are hearing very little about implementation and operational experience and feedback during the process. 
If any company had to wait two or more years to release software, they would find themselves out of customers.

Dean

> On Jan 26, 2018, at 10:22 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Christian Hopps <[email-masked]>
Date: Fri, 26 Jan 2018 11:40:39 -0500

Hi Juergen,

I want to be understood so I'll reply again. It's not that I don't want
to involve myself in technical discussions, it's that I (and others)
think that what's being discussed now no longer matters to getting work
done. The work is good enough *now*. When we get to this point it
doesn't make sense for me to participate anymore, the problem is solved,
I need to work on other problems that aren't solved yet.

We need models for VRFs and VMs, people are now arguing about having
totally different schema mounted at the same mount point based on the
datastore (?!?) and where exactly the meta-data should reside. It's
divorced from the "get shit done" reality.

Thanks,
Chris.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Jan 2018 18:07:06 +0100

Chris,

nobody (I think) is having an issue with the lne and ni models. And it
is great to hear that you have implemented them. However, please also
understand that schema mount is a rather fundamental extension of the
YANG technology and that people maintaining that technology and
writing generic tools need to have this extension work together with
other extensions we have been working on. For you, this may be
irrelevant or not important and it may be 'divorced from your "get
shit done" reality'. But then, please accept that there are other
communities with different priorities.

I believe we will be more effective if we find a way forward that can
work for everybody involved. Trying to convince other communities that
their priorities are plain wrong is neither constructive nor does it
lead to faster progress I think.

/js

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 26 Jan 2018 10:53:19 -0800

+1 Dean.
I’m having this discussion on daily bases...
I do care about sustainability and long term growth though 

Regards,
Jeff

> On Jan 26, 2018, at 07:30, Dean Bogdanovic <[email-masked]> wrote:
>