Re: [netmod] WG adoption poll - instance-data

[Balazs Lengyel]

  
  
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:


  
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  on behalf of Balázs Lengyel 
Date: Tuesday, October 9, 2018 at 11:06 AM
To: Martin Bjorklund 
Cc: "netmod-cha...@ietf.org" , "netmod@ietf.org" 
Subject: Re: [netmod] WG adoption poll - instance-data

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

regards Balazs

On 2018. 10. 09. 14:25, Martin Bjorklund wrote:

  
Hi,

Balázs Lengyel  wrote:


  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.


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 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.)


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
support adoption?


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





  regards Balazs

On 2018. 10. 09. 12:58, Martin Bjorklund wrote:

  
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


Lou Berger  wrote:


  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 th

Re: [netmod] WG adoption poll - instance-data

[Juergen Schoenwaelder]

On Tue, Oct 09, 2018 at 05:07:06PM +, Kent Watsen wrote:
> 
> 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.

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.
 
> 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!)

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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll - instance-data

[Kent Watsen]

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  on behalf of Balázs Lengyel 

Date: Tuesday, October 9, 2018 at 11:06 AM
To: Martin Bjorklund 
Cc: "netmod-cha...@ietf.org" , "netmod@ietf.org" 

Subject: Re: [netmod] WG adoption poll - instance-data

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

regards Balazs

On 2018. 10. 09. 14:25, Martin Bjorklund wrote:
> Hi,
>
> Balázs Lengyel  wrote:
>> 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.
> 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 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.)
> 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
>> support adoption?
> 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
>
>
>
>> regards Balazs
>>
>> On 2018. 10. 09. 12:58, Martin Bjorklund wrote:
>>> 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
>>>
>>>
>>> Lou Berger  wrote:
>>>> 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.
>>>&

Re: [netmod] WG adoption poll - instance-data

[Robert Wilton]

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


On 09/10/2018 13:15, Balázs Lengyel wrote:

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

On 2018. 10. 09. 12:58, Martin Bjorklund wrote:

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


Lou Berger  wrote:

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)

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll - instance-data

[Balázs Lengyel]

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


regards Balazs

On 2018. 10. 09. 14:25, Martin Bjorklund wrote:

Hi,

Balázs Lengyel  wrote:

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.

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 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.)

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
support adoption?

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




regards Balazs

On 2018. 10. 09. 12:58, Martin Bjorklund wrote:

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


Lou Berger  wrote:

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)

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com



--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll - instance-data

[Martin Bjorklund]

Hi,

Balázs Lengyel  wrote:
> 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.

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 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.)

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
> support adoption?

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



> 
> regards Balazs
> 
> On 2018. 10. 09. 12:58, Martin Bjorklund wrote:
> > 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
> >
> >
> > Lou Berger  wrote:
> >> 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)
> >>
> >> ___
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> -- 
> Balazs Lengyel   Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
> 
> 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] WG adoption poll - instance-data

[Balázs Lengyel]

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

On 2018. 10. 09. 12:58, Martin Bjorklund wrote:

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


Lou Berger  wrote:

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)

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


--
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com




smime.p7s
Description: S/MIME Cryptographic Signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod