Subject: [netmod] WG adoption poll

From: Lou Berger <[email-masked]>
Date: Mon, 8 Oct 2018 07:38:42 -0400

All,

This is start of a two week poll on making
draft-lengyel-netmod-yang-instance-data-04 a working group
document. Please send email to the list indicating "yes/support" or
"no/do not support".  If indicating no, please state your reservations
with the document.  If yes, please also feel free to provide comments
you'd like to see addressed once the document is a WG document.

The poll ends Oct 22.

Thanks,

Lou (and co-chairs)

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 8 Oct 2018 20:41:07 +0000

Support
--- Alex

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Lou Berger
> Sent: Monday, October 08, 2018 4:39 AM
> To: NetMod WG <[email-masked]>
> Cc: NetMod WG Chairs <[email-masked]>
> Subject: [netmod] WG adoption poll
> 
> All,
> 
> draft-lengyel-netmod-yang-instance-data-04 a working group document. Please
> send email to the list indicating "yes/support" or "no/do not support".  If
> indicating no, please state your reservations with the document.  If yes, please
> also feel free to provide comments you'd like to see addressed once the
> document is a WG document.
> 
> The poll ends Oct 22.
> 
> Thanks,
> 
> Lou (and co-chairs)
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 8 Oct 2018 21:38:29 -0400

yes/support.

Thanks,
- Xufeng

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 9 Oct 2018 06:03:38 +0000

yes/support.

Cheers,
Tianran

> Sent: Monday, October 08, 2018 7:39 PM
> draft-lengyel-netmod-yang-instance-data-04 a working group document.
> Please send email to the list indicating "yes/support" or "no/do not support".
> If indicating no, please state your reservations with the document.  If yes,
> please also feel free to provide comments you'd like to see addressed once
> the document is a WG document.
> 
> The poll ends Oct 22.
> 
> Thanks,
> 
> Lou (and co-chairs)
>

---

From: Qin Wu <[email-masked]>
Date: Tue, 9 Oct 2018 06:28:10 +0000

Support adoption of this draft, 
Two quick comments on this draft
1. section 2.5 factory default setting
I would suggest to reference to draft-wu-netconf-restconf-factory-restore in section 2.5.
I think this draft is complementary to draft-wu-netconf-restconf-factory-restore-02, factory datastore can rely on yang instance data file to specify the content of factory datastore.
2. section 2.3 server capability
Server capability in the context of this draft is referred to a set of models and features which can be retrieved from yang library, I see server capability as NETCONF capability. 
I am wondering whether yang data instance file can also be used to specify capability identifiers. Some time I have trouble to understand where the server to get capability 
identifier and exchange it in the hello message.
I understand RFC6470 can advertise the capability change.

-Qin
-----邮件原件-----
发件人: netmod [mailto:[email-masked]] 代表 Lou Berger
发送时间: 2018年10月8日 19:39
收件人: NetMod WG
抄送: NetMod WG Chairs
主题: [netmod] WG adoption poll

All,

This is start of a two week poll on making
draft-lengyel-netmod-yang-instance-data-04 a working group document. Please send email to the list indicating "yes/support" or "no/do not support".  If indicating no, please state your reservations with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

The poll ends Oct 22.

Thanks,

Lou (and co-chairs)

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 9 Oct 2018 10:40:42 +0000

Hello Qin,

I will add the referemce.
Netconf server capabilities can be read from ietf-netconf-monitoring 
/ncm:netconf-state/ncm:capabilities/ncm:capability

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Oct 2018 12:44:44 +0200

I support the adoption.

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Oct 2018 12:58:22 +0200 (CEST)

Hi,

I still think that this draft should either be split into two, one for
specifiying the generic file format (ok with examples), and one for
"Documenting Server Capabilities", or the document should just be
about the file format (+ *examples*).

[The current document mixes the two; it's a bit as if we had "The
YANG language and a model for interfaces" as one doc...]

It is clear that the document specifies a file format for YANG
instance data, which is good.  But it is not clear if the document
intends to specify how a server should document its capabilities.

The Introduction mainly talks about why it is important to document
server capabilities.  But then AFAICT there is no normative
specification of how a server would document its capabilities.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Tue, 9 Oct 2018 12:19:50 +0100

+1 to Martin's comments.  I think that I made similar comments at the 
mic at IETF 102.

I strongly support the idea of documenting YANG instance data. If the WG 
timing works out I would like this to cover CBOR as well.

I also strongly support the idea of documenting server capabilities.  
But I'm opposed to conflating these two separate concerns in the same draft.

I also think that that there should be a optional mechanism to embed the 
list of module revisions (and perhaps features) that are required to 
correctly decode the instance data.

E.g., the example in section 3 contains YANG library data, but I don't 
know which version or YANG library I need to read in the instance data.  
It might have been constructed assuming the format from RFC 7895, or it 
might have been constructed using the format from YANG library bis, 
which could easily fail if my tool attempts to interpret the instance 
data against the schema in RFC 7895.  So I think that this information 
is critical for tools to be able to interpret the instance data in a 
reliable fashion.

Thanks,
Rob

On 09/10/2018 11:58, Martin Bjorklund wrote:
> .

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Oct 2018 13:25:41 +0200

> +1 to Martin's comments.  I think that I made similar comments at the 

Me too, it is also recoreded in the minutes. I thought this could be addressed
after this draft becomes a WG item.

Lada

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 9 Oct 2018 12:15:29 +0000

Hello Martin,

I agree that this document shall be about defining the file format,
and server capabilities shall only be a use-case.)

I already took out a lot of text, that explicitly recommended using
instance data for documenting capabilities. Server capabilities are only 
mentioned in the introduction chapter.
As you wrote: There is no _normative_  specification of how a server 
would document its capabilities, because this is
what the WG requested, so I removed it.

I see that I forgot to change the title and the introduction can be 
reworded to make
it more clear that documenting server capabilities is just a use-case.
(I still see it as the primary use-case for instance data.)

  If I promise to change the title and clarify the introduction can you 
support adoption?

regards Balazs

---

From: Joe Clarke <[email-masked]>
Date: Tue, 9 Oct 2018 08:17:14 -0400

> you'd like to see addressed once the document is a WG document.

I support adoption.  The biggest concern I have with this is how one
will extend the metadata.  This is more about how one augments YANG
data, but I feel it will need to be solved to make instance data truly
useful.

Joe

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Oct 2018 14:25:06 +0200 (CEST)

Hi,

Balázs Lengyel <[email-masked]> wrote:
> instance data for documenting capabilities. Server capabilities are
> only mentioned in the introduction chapter.

Hmm.  Ok, if this is what the WG wants, then it is fine to just have
server capabilities as an example use case.  (I thought that the WG
wanted a normative description of server capabilities...)

> (I still see it as the primary use-case for instance data.)

I think all text in 2 Introduction (except the last para) in this case
should be moved to section 2.1, and new text should be written in 2.

(*if* there will be a separate doc for server capabilities, the text
in 2 should be moved to that doc instead.)

>  If I promise to change the title and clarify the introduction can you

First of all I'd like to ensure that the WG in fact just wants to do
the file format.  Since people have expressed support for adopting the
draft with the current title, I'm not so sure that this is the case.

I think you should make those changes, and I support the adoption of
the modified document.  I don't see any reason not to make these
chanegs before posting as a WG doc.

/martin

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 9 Oct 2018 15:06:22 +0000

OK, If the chairs are happy with that, I can update the document before 
I store it as an official netmod document.

regards Balazs

---

From: Robert Wilton <[email-masked]>
Date: Tue, 9 Oct 2018 16:23:40 +0100

I would expect that there are many other alternative uses of YANG 
instance data.

Some possible alternatives that I can think of:
- Storing the configuration of a device at some point in time to a file, 
e.g. for archive or audit purposes.
- Storing diagnostics data, if the format of the data was defined as 
YANG data models.  Here I could imagine the data potentially being 
stored in a compressed tar file that could be taken off the device.
- Allowing YANG instance data to potentially be carried within other IPC 
message formats.
- Perhaps file based default instance data used as part of a templating 
solution.
- File based factory defaults.

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 9 Oct 2018 16:26:35 +0000

Support.

On 2018-10-08, 7:39 AM, "netmod on behalf of Lou Berger" <[email-masked] on behalf of [email-masked]> wrote:

    All,

    The poll ends Oct 22.
    
    Thanks,
    
    Lou (and co-chairs)

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 9 Oct 2018 12:42:10 -0400

Yes - support for this document. 

Susan Hares 

-----Original Message-----
From: netmod [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Monday, October 8, 2018 7:39 AM
To: NetMod WG
Cc: NetMod WG Chairs
Subject: [netmod] WG adoption poll

All,

indicating no, please state your reservations with the document.  If yes,

The poll ends Oct 22.

Thanks,

Lou (and co-chairs)

---

From: Kent Watsen <[email-masked]>
Date: Tue, 9 Oct 2018 17:07:06 +0000

As co-chair, I have two minds:

  1) requests a fix and redo the adoption poll
  2) realize that it's a living doc and regardless
     how it begins, the WG can sort it out in time.
     i.e., we're adopting to work on the problem,
     not necessarily the specific solution.

While (1) seems more proper, given the timing of 
things, I'm willing to go for (2).   To this extent,
the comments being made now be thought to carry
the same weight as Last Call comments.  The chairs
will discuss this again when making a determination
on the adoption poll.

As contributor, can we please not call this "YANG
instance data"?  - that means something else to 
me.  This seems to be more about capturing data
about a server instances.  So maybe "YANG-based
Server Instance Data"?  (open to suggestions!)

Kent

-----Original Message-----
From: netmod <[email-masked]> on behalf of Balázs Lengyel <[email-masked]>
Date: Tuesday, October 9, 2018 at 11:06 AM
To: Martin Bjorklund <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] WG adoption poll - instance-data

regards Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Oct 2018 22:54:47 +0200

> will discuss this again when making a determination

It seems there are questions about the scope of this document and
ideally there would be some agreement about the scope of the work
covered by the document at adoption time.
 
> Server Instance Data"?  (open to suggestions!)

What does 'YANG instance data' mean to you?

Why does adding 'sever' make things better?

Why can't I use this format outside a 'server'?

I think we do use phrases such as 'instantiated YANG data tree' in
other documents, so 'instance data' (which is perhaps a shorthand)
does not seem surprising to me.

/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: Balazs Lengyel <[email-masked]>
Date: Thu, 11 Oct 2018 17:24:24 +0200

Hello Kent,

If needed I can do a quick update, but

As you stated this is a living document

IMHO the scope is clear: This is only a data format draft, how
it is used is only here a set of use-cases. I did not see anyone
disagreeing with this.

I would like to avoid redoing this poll.

My wish (if the good fairy can fulfill it) is that the draft
is adopted, and I update it before the IETF to clarify the scope
as above.

Naturally I will consider all other comments too, but they may
take some time to discuss.

regards Balazs

On 2018. 10. 09. 19:07, Kent Watsen
wrote:

Kent

-----Original Message-----
From: netmod <[email-masked]> on behalf of Balázs Lengyel <[email-masked]>
Date: Tuesday, October 9, 2018 at 11:06 AM
To: Martin Bjorklund <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [netmod] WG adoption poll - instance-data

regards Balazs

Hi,

Hello Martin,

/martin

regards Balazs

Hi,

/martin

All,

The poll ends Oct 22.

Thanks,

Lou (and co-chairs)

---

From: Balázs Lengyel <[email-masked]>
Date: Sat, 13 Oct 2018 15:13:24 +0000

Hello Martin,

I see the yang-instance-data draft as a prerequisite for a draft/RFC 
about documenting server capabilities: after all my proposal is to 
document them using instance data. Actually I do plan to write a draft 
about documenting server capabilities too. However at this moment I have 
too any drafts with my name on them, so I will wait a bit.  If someone 
wants to write co-author a draft on server-capabilities that would be 
nice :-)

I hope after this clarification you will support adoption of my instance 
data draft.

regards Balazs

---

From: Lou Berger <[email-masked]>
Date: Mon, 22 Oct 2018 08:35:59 -0400

This poll is now closed and the draft is adopted.  As usual, this draft 
will now be progressed through normal working group process, including 
addressing issues raised during and after adoption.

Authors,

Please submit draft-lengyel-netmod-yang-instance-data-05.txt with only 
the date updated and the file name changed to 
draft-ietf-netmod-yang-instance-file-format-00.txt.  Please note the 
file name change.  If you object to this change please propose an 
alternative.

Thank you,

Lou (and co-chairs)