Subject: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

From: Qin Wu <[email-masked]>
Date: Mon, 6 May 2019 12:06:37 +0000

Hi, Chairs:
Sorry for late follow up, thanks Jurgen, Andy,Joe, Joel and all others for good comments, here is the update based on discussion and suggestion on the mailing list
The diff is:
https://www.ietf.org/rfcdiff?url2=draft-wu-netmod-factory-default-03
We believe it is ready for second adoption poll. Thanks!

-Qin (on behalf of authors)
发件人: netmod [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2019年4月9日 2:36
收件人: [email-masked]
主题: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

This message concludes the adoption poll for draft-wu-netmod-factory-default-02   The working group consensus supports working on the problem, but fundamental concerns were raised regarding the solution, specifically around reseting datastores versus resetting devices.  The chairs feel that these issues should be addressed before proceeding with the adoption.

Authors, please update and resubmit the draft addressing the comments received during the adoption poll.  Another adoption poll will be issued when ready.
Thank you,
Kent (and Lou and Joel)

On Mar 25, 2019, at 4:34 PM, Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

This email begins a 2-week adoption poll for:

    https://tools.ietf.org/html/draft-wu-netmod-factory-default-02

Please voice your support or objections before April 8.<x-apple-data-detectors://1>

Kent (and Lou)
_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 6 May 2019 15:11:32 +0000

On May 6, 2019, at 08:06, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Chairs:

Hey, Qin.  I read through the changes, and I have a couple of additional comments.

First, the term “YANG server” sounds odd to me.  I know what you mean, but I haven’t seen this defined before.  Maybe just saying a device or host is sufficient?

When you talk about the datastore to be reset, you list <running>, <startup>, and <candidate>.  You state that each will receive the contents of <factory-default>.  The <candidate> DS wouldn’t need that.  I think it would just be zeroed out.

I think the RPC should reset any and all non-derived read-write datastores and not imply that a specific DS’s contents (i.e., the factory-default DS) is copied to them.  This way, other DSes would just be handled by this RPC based on implementation.  The <factory-default> can exist as the factory default contents for <startup>.

Joe

-Qin (on behalf of authors)
发件人: netmod [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2019年4月9日 2:36
收件人: [email-masked]<mailto:[email-masked]>
主题: Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02

Kent (and Lou)

---

From: tom petch <[email-masked]>
Date: Wed, 8 May 2019 11:31:35 +0000

----- Original Message -----
From: "Joe Clarke (jclarke)" <[email-masked]>
Sent: Monday, May 06, 2019 4:11 PM
>
> On May 6, 2019, at 08:06, Qin Wu
<[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi, Chairs:
> Sorry for late follow up, thanks Jurgen, Andy,Joe, Joel and all others
for good comments, here is the update based on discussion and suggestion
on the mailing list
> First, the term “YANG server” sounds odd to me.  I know what you mean,
but I haven’t seen this defined before.  Maybe just saying a device or
host is sufficient?

Joe

If you look at the various RFC - YANG, Netconf, NMDA - they all define
the terms 'client' and 'server'; in the context, 'YANG server' seems
appropriate.

Tom Petch

>
> When you talk about the datastore to be reset, you list <running>,
<startup>, and <candidate>.  You state that each will receive the
contents of <factory-default>.  The <candidate> DS wouldn’t need that.
I think it would just be zeroed out.
>
> I think the RPC should reset any and all non-derived read-write
datastores and not imply that a specific DS’s contents (i.e., the
factory-default DS) is copied to them.  This way, other DSes would just
be handled by this RPC based on implementation.  The <factory-default>
can exist as the factory default contents for <startup>.
> This message concludes the adoption poll for
draft-wu-netmod-factory-default-02   The working group consensus
supports working on the problem, but fundamental concerns were raised
regarding the solution, specifically around reseting datastores versus
resetting devices.  The chairs feel that these issues should be
addressed before proceeding with the adoption.
>
> Authors, please update and resubmit the draft addressing the comments
received during the adoption poll.  Another adoption poll will be issued
when ready.
> Thank you,
> Kent (and Lou and Joel)
>
>
>
> On Mar 25, 2019, at 4:34 PM, Kent Watsen
> Please voice your support or objections before April
8.<x-apple-data-detectors://1>

------------------------------------------------------------------------
--------

> [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 May 2019 13:53:27 +0200 (CEST)

> the terms 'client' and 'server'; in the context, 'YANG server' seems

I agree w/ Joe.  I had the same comment when I read
draft-ietf-netmod-yang-instance-file-format; it uses the term "YANG
server".

I think these documents should import and use the term "server" from
RFC 8342 where it is defined as:

   o  server: An entity that provides access to YANG-defined data to a
      client, over some network management protocol.

Perhaps we should have a term "YANG-based server" or something as an
alias to "server" as defined above.  In some documents the short word
"server" may sound too generic.  But "YANG server" doesn't sound right
to me.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 May 2019 14:08:07 +0200

> "server" may sound too generic.  But "YANG server" doesn't sound right

I find terms like 'YANG server' or 'YANG-based server' a bit confusing
since the server is not talking YANG (there is no YANG protocol) and
the server is also not sending/receiving YANG but YANG-defined data.

Unless there is a possibility of confusion, importing the 'server'
definition from RFC 8342 and using the terms 'server' is perhaps good
enough.

/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: Qin Wu <[email-masked]>
Date: Thu, 9 May 2019 13:51:21 +0000

Thank Juergen, Martin and Tom for good suggestions, will address your comments in the update after adoption.

________________________________
Qin Wu
Mobile：+86-13914734360<tel:+86-13914734360>(Mobile Number)
Email：[email-masked]<mailto:[email-masked]>

发件人： Juergen Schoenwaelder<[email-masked]<mailto:[email-masked]>>
收件人： Martin Bjorklund<[email-masked]<mailto:[email-masked]>>
抄送： netmod<[email-masked]<mailto:[email-masked]>>
主题： Re: [netmod] Adoption poll for draft-wu-netmod-factory-default-02
时间： 2019-05-08 20:08:40

/js

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Thu, 9 May 2019 14:28:49 +0000

> On May 8, 2019, at 07:31, tom petch <[email-masked]> wrote:
> 

It was the combination of the two words as “YANG server” which throws me.  You’re serving data modeled using YANG.  Anyway, it sounds like there’s a good referential solution to this from Jürgen and Martin, so that should sort this out.

Joe

---

From: tom petch <[email-masked]>
Date: Fri, 10 May 2019 10:50:46 +0000

----- Original Message -----
From: "Joe Clarke (jclarke)" <[email-masked]>
Sent: Thursday, May 09, 2019 3:28 PM

> It was the combination of the two words as “YANG server” which throws
me.  You’re serving data modeled using YANG.  Anyway, it sounds like
there’s a good referential solution to this from Jürgen and Martin, so
that should sort this out.

Joe,

yes, I can see what you mean.  I was objecting to the use of 'host',
'device' or such like having just read
draft-dai-quic-netconf-00.txt
which wants to reserve client and server for the transport and go to
manager and agent for netconf.

We have been down this road before, with SNMP and NETCONF, and the
confusion it creates is considerable.  If authors cannot cope with
well-established terminology, then they should not be writing I-Ds - if
that I-D comes up for adoption in its present form, I will resolutely
oppose, all the way to IETF Last Call.

</rant>

Tom Petch