Re: [netmod] instance file parsing

[Andy Bierman]

On Fri, Nov 30, 2018 at 11:28 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> I doubt it makes sense to carry an entire yang library schema with the
> instance data. The modules are actually known via the namespaces. If
> you want to capture the schema, dump the relevant yang library into
> another instance file.
>
>
The capability URIs used in NETCONF are not too verbose.
I agree that more efficient solutions are possible.

1) YANG library instance file
The instance-data-set includes a URL to the instance file for the YANG
library
used to generate the associated data node.

2) YANG catalog
 The instance-data-set includes a URL to the appropriate yangcatalog.org
info


/js
>

Andy


>
> On Fri, Nov 30, 2018 at 07:07:03PM +, Robert Wilton wrote:
> > I also think that the instance data header needs to have a way of
> indicating
> > which modules (and versions/revisions) the instance data applies to.
> >
> > It can be optional, so producers that know it is not required can leave
> it
> > out.  But I think that it is required, at least for situations where
> being
> > able to programmatically consume the instance data in a robust way is
> > important.
> >
> > Thanks,
> > Rob
> >
> >
> > On 30/11/2018 17:48, Andy Bierman wrote:
> > > Hi,
> > >
> > > I don't see much standards value in this draft so far.
> > > It seems the parser of the file needs to know the YANG library
> information
> > > for the instance file data in some out-of-scope non-standard manner.
> > > This is what we already have today just by naming the file in a
> specific
> > > way.
> > >
> > > Is the intent that the instance-data-set leafs will be used to
> determine
> > > the module revisions, features, and deviations used in the children
> > > or the 'data' node?
> > >
> > > Andy
> > >
> > >
> > >
> > > ___
> > > 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
>
>
> --
> 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] instance file parsing

[Juergen Schoenwaelder]

I doubt it makes sense to carry an entire yang library schema with the
instance data. The modules are actually known via the namespaces. If
you want to capture the schema, dump the relevant yang library into
another instance file.

/js

On Fri, Nov 30, 2018 at 07:07:03PM +, Robert Wilton wrote:
> I also think that the instance data header needs to have a way of indicating
> which modules (and versions/revisions) the instance data applies to.
> 
> It can be optional, so producers that know it is not required can leave it
> out.  But I think that it is required, at least for situations where being
> able to programmatically consume the instance data in a robust way is
> important.
> 
> Thanks,
> Rob
> 
> 
> On 30/11/2018 17:48, Andy Bierman wrote:
> > Hi,
> > 
> > I don't see much standards value in this draft so far.
> > It seems the parser of the file needs to know the YANG library information
> > for the instance file data in some out-of-scope non-standard manner.
> > This is what we already have today just by naming the file in a specific
> > way.
> > 
> > Is the intent that the instance-data-set leafs will be used to determine
> > the module revisions, features, and deviations used in the children
> > or the 'data' node?
> > 
> > Andy
> > 
> > 
> > 
> > ___
> > 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


-- 
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] instance file parsing

[Robert Wilton]

I also think that the instance data header needs to have a way of 
indicating which modules (and versions/revisions) the instance data 
applies to.


It can be optional, so producers that know it is not required can leave 
it out.  But I think that it is required, at least for situations where 
being able to programmatically consume the instance data in a robust way 
is important.


Thanks,
Rob


On 30/11/2018 17:48, Andy Bierman wrote:

Hi,

I don't see much standards value in this draft so far.
It seems the parser of the file needs to know the YANG library information
for the instance file data in some out-of-scope non-standard manner.
This is what we already have today just by naming the file in a 
specific way.


Is the intent that the instance-data-set leafs will be used to determine
the module revisions, features, and deviations used in the children
or the 'data' node?

Andy



___
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] instance file parsing

[Andy Bierman]

Hi,

I don't see much standards value in this draft so far.
It seems the parser of the file needs to know the YANG library information
for the instance file data in some out-of-scope non-standard manner.
This is what we already have today just by naming the file in a specific
way.

Is the intent that the instance-data-set leafs will be used to determine
the module revisions, features, and deviations used in the children
or the 'data' node?

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

[netmod] instance file format timestamp

[Balázs Lengyel]

  
  
On 2018. 11. 30. 13:48, Juergen
  Schoenwaelder wrote:


  
PS: I am also concerned about the revision being not fine grained
 enough to be useful. I would love to have a much more precise
 timestamp telling me when the instance data was recorded. I would
 probably replace 'revision' with simply a 'timestamp' or add next
 to a 'revision' a more fine grained 'timestamp'.

   BALAZS: I agree that in some use cases a timestamp would be useful e.g.
   diagnostic data from a real live YANG server.
   However in other use cases like documenting factory default, defining
   default configuration to be preloaded or documenting server capabilities I
   see no need for the timestamp. It is not interesting exactly at which
   hour/minute/second the server capabilities were documented.
   So while I would not like to add the timestamp in the draft, the draft
   documents, that additional metadata like a timestamp may be added to the
   instance data set.


  
  Having an (optional) timestamp with proper granularity seems rather
basic for me and I fail to see why we would not define this.

BALAZS: Don't really agree, but I will add the optional timestamp
  as you think its important.
-- 
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] Datastore leaf for yang instance data

[Balázs Lengyel]

On 2018. 11. 28. 16:43, Robert Wilton wrote:


On 28/11/2018 15:32, Juergen Schoenwaelder wrote:

On Wed, Nov 28, 2018 at 03:27:26PM +, Robert Wilton wrote:

On 28/11/2018 10:20, Juergen Schoenwaelder wrote:

On Wed, Nov 28, 2018 at 09:41:12AM +, Balázs Lengyel wrote:

I do not buy this story. Your software needs to decide somehow what
instance data means. A config true leaf in candidate means something
different than the same config true leaf in running and this yet 
again
means something different than the same config true leaf in 
operational.


/js
BALAZS: As I understood the WG decided that this draft should only 
be about
the format of the yang instance data. What the SW does with it is 
out of
scope. So considerations whether instance data should be loaded 
into running

or candidate or not at all, are outside the scope.

If you do not know what the instance data means, any attempt to use it
is kind of broken.
I want to provide a datastore indicator, but how that should be 
used (and

thus what is exactly means) is out of scope.

I disagree. The datastore indicator is needed to understand what the
data means, i.e., to do anything meaningful with it.
I think that a datastore indicator is useful sometimes.  E.g. it 
might be
helpful in some cases to know that the data was associated with a 
particular

datastore.

But in the general case I think that this is just "data at rest", and
probably the key thing to know is whether (i) the data relates to
configuration, or (ii) the data relates to operational state.

This could potentially be inferred from a datastore leaf, or perhaps 
this
distinction could more explicitly be made by a separate field, which 
I would
make an enumeration or identity, since there might be other types of 
data in

future, such as capability information or diagnostics.


I do not understand why a datastore leaf is not sufficient and why we
need yet something new. If ever needed, NMDA does allow us to define
new datastores.


Because a distinction between "candidate" vs "running" vs "intended" 
won't necessarily be that useful.  Although knowing "running" vs 
"intended" would allow the client to know whether it is pre/post 
template expansion and that might be useful.


The second reason is that I don't know whether things like 
capabilities and diagnostics will be new datastores or just part of 
operational.  I don't think that either of these two areas have really 
been properly worked out yet.  I presume that they will come over 
time, once more network management becomes more automated.


Thanks,
Rob


BALAZS: You are right, that these areas are not worked out. That is 
exactly why they are out of scope. This is only about the format, and 
not about the usage. As we already have about 10 use cases with 
different needs, none of which are specified exactly, I want to avoid 
defining specific metadata for use cases we don't fully understand. 
Note: it is possible and documented that the metadata can be 
extended/augmented.


regards balazs

--
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] yang-instance-file-format - do we need a special file extension ?

[Balázs Lengyel]

OK, so lets go with option 3.
balazs

On 2018. 11. 30. 16:17, Juergen Schoenwaelder wrote:

On Fri, Nov 30, 2018 at 12:48:48PM +, Balázs Lengyel wrote:

Hello, Joe, Jurgen,

RFC6020 doesn't really register� file extensions, but rather media types.
I don't feel we need a new mediatype for this as we really use json and
xml. However I see it useful to document in the file extension that this
is not just any plain old XML; it is yang instance data in XML format.�
Alternatives:

 1. Use the .yid file extension (my favorite)
 2. Use 2 separate file extensions: .yidxml, .yidjson
 3. just use .xml and .json


I would have used .json or .xml; the content of the file after all is
self-describing and tools like 'file' might learn how to recognize the
content. Extensions like .yidxml and .yidjson looks a bit horrible to
me and so far I never had any real problems using .json and .xml for
arbitrary json and xml files (and .json and .xml helps generic tools
so calling it .yid means that I have to go and teach tools that .yid
is either .json and .xml). Try loading .json and .xml in your
favourite editor and then load a .yid file. Big difference for my
editor. So from my perspective, do nothing (and then people and tools
will likely use option 3).

/js


--
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] yang-instance-file-format - do we need a special file extension ?

[Juergen Schoenwaelder]

On Fri, Nov 30, 2018 at 12:48:48PM +, Balázs Lengyel wrote:
>Hello, Joe, Jurgen,
> 
>RFC6020 doesn't really register� file extensions, but rather media types.
>I don't feel we need a new mediatype for this as we really use json and
>xml. However I see it useful to document in the file extension that this
>is not just any plain old XML; it is yang instance data in XML format.�
>Alternatives:
> 
> 1. Use the .yid file extension (my favorite)
> 2. Use 2 separate file extensions: .yidxml, .yidjson
> 3. just use .xml and .json
>

I would have used .json or .xml; the content of the file after all is
self-describing and tools like 'file' might learn how to recognize the
content. Extensions like .yidxml and .yidjson looks a bit horrible to
me and so far I never had any real problems using .json and .xml for
arbitrary json and xml files (and .json and .xml helps generic tools
so calling it .yid means that I have to go and teach tools that .yid
is either .json and .xml). Try loading .json and .xml in your
favourite editor and then load a .yid file. Big difference for my
editor. So from my perspective, do nothing (and then people and tools
will likely use option 3).

/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

[netmod] yang-instance-file-format - do we need a special file extension ?

[Balázs Lengyel]

Hello Qin,

Do you have a better suggestion for the file extension?

regards Balazs

On 2018. 11. 29. 2:53, Qin Wu wrote:

The abbreviation of YANG instance data yid may confuse with YANG identitifer 
short name
"
YANG Identifier:  Numeric object identifier, which is a fixed-length
   numeric value that represents a particular schema node within a
   YANG module schema tree.  The length and format of a YANG
   identifier are defined in the YANG Identifier Registry.  Also
   called a "YID".
"
I believe they are not same thing.

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Joe Clarke
发送时间: 2018年11月28日 22:36
收件人: Balázs Lengyel; netmod@ietf.org
主题: Re: [netmod] Fwd: New Version Notification for 
draft-ietf-netmod-yang-instance-file-format-00.txt

On 11/23/18 07:48, Balázs Lengyel wrote:

Do you have to register the ".yid" file extension as well?

BALAZS: Is there a registry for file extensions? I was not aware.

RFC6020 section 14 registers media types that include file extensions for .yin 
and .yang.  I am asking are you proposing to do the same and registering 
something like application/yang-instance-data with a .yid extension?

Joe

___
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

[netmod] yang-instance-file-format - do we need a special file extension ?

[Balázs Lengyel]

  
  
Hello, Joe, Jurgen,
RFC6020 doesn't really register  file extensions, but rather
  media types. I don't feel we need a new mediatype for this as we
  really use json and xml. However I see it useful to document in
  the file extension that this is not just any plain old XML; it is
  yang instance data in XML format.  Alternatives:

  Use the .yid file extension (my favorite)
  Use 2 separate file extensions: .yidxml, .yidjson
  just use .xml and .json

What is the rule, do I need to register a file extension as a
  media-type? Is that optional? Is that needed?
regards Balazs

On 2018. 11. 28. 15:48, Juergen
  Schoenwaelder wrote:


  On Wed, Nov 28, 2018 at 09:35:55AM -0500, Joe Clarke wrote:

  
On 11/23/18 07:48, Balázs Lengyel wrote:


  
Do you have to register the ".yid" file extension as well?

  
  BALAZS: Is there a registry for file extensions? I was not aware.



RFC6020 section 14 registers media types that include file extensions
for .yin and .yang.  I am asking are you proposing to do the same and
registering something like application/yang-instance-data with a .yid
extension?


  
  
Isn't this just json and xml? If we need specific media types, I think
it would be two.

In theory, it would be even nicer if the document would be written in
such a way that it works with any (future) encoding. The way things
are defined today, by referring to responses of specific protocol
operations, is a bit odd. Does it matter whether the XML is returned
by a NETCONF  or RESTCONF/HTTP GET? Ideally, the format of
the instance files would be coming out of the data encoding
specifications (plus the architectural framework of datastores).

/js



-- 
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] instance file format and etags/timestamps, xml attributes

[Juergen Schoenwaelder]

On Fri, Nov 30, 2018 at 12:28:09PM +, Balázs Lengyel wrote:
>Hello Jurgen,
> 
>Thanks for the comments. See answers below.
> 
>regards Balazs
> 
>On 2018. 11. 28. 11:01, Juergen Schoenwaelder wrote:
> 
>  draft-ietf-netmod-yang-instance-file-format-00.txt says:
> 
> The JSON format SHALL follow the format of the reply returmed for a
> RESTCONF GET request directed at the datastore resource:
> {+restconf}/data.  ETags and Timestamps SHOULD NOT be included, but
> if present SHOULD be ignored.
> 
>  I assume that you mean the JSON content in the message-body of the
>  HTTP Response message for GET message. My understanding is that ETags
>  and Timestamps (what are these precisely?) are carried in the HTTP
>  header. So how could the ETag or 'Timestamps' be in the JSON data?  We
>  should not mess up the HTTP difference between header data and payload
>  data.
> 
>BALAZS: OK, I will correct it. Yes, it is the payload that I want to
>include in the instance data.
>I thought that lower level etags/timestamps are returned inside the
>get-response payload. On re-reading RFC8040 I see my mistake.

The more I think of it, defining the format by refering to specific
protocol operations really seems to be broken and causing complex
maintenance problems in the future. If you fetch , you do
not do a GET on {+restconf}/data.

>  I also do not fully understand the text concerning the XML format.
> 
> The XML format SHALL follow the format returned for a NETCONF GET
> operation.  The  anydata (which is not part of the real data
> itself) SHALL contain all data that would be inside the 
> wrapper element of a reply to the  operation.  XML attributes
> SHOULD NOT be present, however if a SW receiving a YANG Based
> Instance data file encounters XML attributes unknown to it, it MUST
> ignore them, allowing them to be used later for other purposes.
> 
>  It is unclear what exactly is the instance data - the entire reponse?
>  Everything inside ? Everything inside and including ? I
>  assume the second sentence is trying to say the later but I do not
>  find it very clear not does it seem to be right. The examples show to
>  content of the NETCONF  inside a 
>  container that belongs to the instance data format (two times 
>  but in different namespaces).
> 
>BALAZS: I will try to reword it to clarify the issue. How about:
> 
>An instance data set is made up of header part and content-data. The
>content-data is all data inside the anydata data node.
> 
>The header part is defined by the -ietf-instance-data module while the
>content-data is defined by the target YANG modules. The content-data�
>SHALL contain all data that would be inside the  wrapper element of
>a reply to the  operation .� �
> 
>I hope this conveys that content data excludes the  wrapper element
>from the get-reply.

As explained above already, I meanwhile believe it is wrong to define
the format by refering to protocol operations. A NETCONF  (using
NETCONF writing style) is wrong for any NMDA datastore content. We
should define the instance data format by refering to the XML and JSON
YANG encoding rules and not by refering to specific protocol
operations.

>  It is also unclear to me why XML attributes are to be removed. Why is
>  that? If I snapshot , why should I remove important
>  information such origin annotations? And removing attributes is
>  actually plain wrong if you consider that attributes carry XML
>  namespaces.
> 
>BALAZS: You are right, although some attributes might be absent in some
>use cases.� E.g. namespace as you pointed out is always needed. However
>e.g. origin may be present if the instance data is a snapshot of the
>operational datastore, but it may be absent if the instance data is used
>to document readOnly server capabilities.
> 
>So I propose to change the text to:
> 
>  Some XML attributes (e.g. metadata like origin) MAY be absent.
>  SW handling YANG Instance data MUST ignore
>  XML attributes unknown to it, allowing them to be used
>  later for other purposes.

I disagree and I would prefer to be silent. The YANG models and the
encoding rules define the content. The instance format document has no
right to mess around with that. Whether origin is there or not is well
defined elsewhere. It is not the job of this document to repeat or
even change what is said elsewhere.
 
>  /js
> 
>  PS: I am also concerned about the revision being not fine grained
>  enough to be useful. I would love to have a much more precise
>  timestamp telling me when the instance data was recorded. I would
>  probably replace 'revision' with simply a 'timestamp' or add next
>  to a 'revision' a more fine grained 'timestamp'.
> 
>BALAZS: I agree that in some use cases a timestamp would be useful e.g.
>diagnostic data from a real live YANG server.
>However in other us

Re: [netmod] instance file format and etags/timestamps, xml attributes

[Balázs Lengyel]

  
  
Hello Jurgen,
Thanks for the comments. See answers below.
regards Balazs

On 2018. 11. 28. 11:01, Juergen
  Schoenwaelder wrote:


  draft-ietf-netmod-yang-instance-file-format-00.txt says:

   The JSON format SHALL follow the format of the reply returmed for a
   RESTCONF GET request directed at the datastore resource:
   {+restconf}/data.  ETags and Timestamps SHOULD NOT be included, but
   if present SHOULD be ignored.

I assume that you mean the JSON content in the message-body of the
HTTP Response message for GET message. My understanding is that ETags
and Timestamps (what are these precisely?) are carried in the HTTP
header. So how could the ETag or 'Timestamps' be in the JSON data?  We
should not mess up the HTTP difference between header data and payload
data.

BALAZS: OK, I will correct it. Yes, it is the
  payload that I want to include in the instance data. 
  I thought that lower level etags/timestamps are returned inside
  the get-response payload. On re-reading RFC8040 I see my mistake.

  

I also do not fully understand the text concerning the XML format.

   The XML format SHALL follow the format returned for a NETCONF GET
   operation.  The  anydata (which is not part of the real data
   itself) SHALL contain all data that would be inside the 
   wrapper element of a reply to the  operation.  XML attributes
   SHOULD NOT be present, however if a SW receiving a YANG Based
   Instance data file encounters XML attributes unknown to it, it MUST
   ignore them, allowing them to be used later for other purposes.

It is unclear what exactly is the instance data - the entire reponse?
Everything inside ? Everything inside and including ? I
assume the second sentence is trying to say the later but I do not
find it very clear not does it seem to be right. The examples show to
content of the NETCONF  inside a 
container that belongs to the instance data format (two times 
but in different namespaces).

BALAZS: I will try to reword it to clarify
the issue. How about:
An instance data set is made up of header
part and content-data. The content-data is all data inside the
anydata data node. 
  
The header part is defined by the
-ietf-instance-data module while the content-data is defined by
the target YANG modules. The content-data  SHALL contain all
data that would be inside the  wrapper element of a
reply to the  operation .   
  
I hope this conveys that content data
excludes the  wrapper element from the get-reply.


  

It is also unclear to me why XML attributes are to be removed. Why is
that? If I snapshot , why should I remove important
information such origin annotations? And removing attributes is
actually plain wrong if you consider that attributes carry XML
namespaces.

BALAZS: You are right, although some
attributes might be absent in some use cases.  E.g. namespace as
you pointed out is always needed. However e.g. origin may be
present if the instance data is a snapshot of the operational
datastore, but it may be absent if the instance data is used to
document readOnly server capabilities.
  
So I propose to change the text to:
Some XML attributes (e.g. metadata like origin) MAY be absent. 
SW handling YANG Instance data MUST ignore   
XML attributes unknown to it, allowing them to be used 
later for other purposes.


  
/js

PS: I am also concerned about the revision being not fine grained
enough to be useful. I would love to have a much more precise
timestamp telling me when the instance data was recorded. I would
probably replace 'revision' with simply a 'timestamp' or add next
to a 'revision' a more fine grained 'timestamp'.

BALAZS: I agree that in some use cases a
timestamp would be useful e.g. diagnostic data from a real live
YANG server. 
However in other use cases like documenting factory default,
defining default configuration to be preloaded or documenting
server capabilities I see no need for the timestamp. It is not
interesting exactly at which hour/minute/second the server
capabilities were documented.
So while I would not like to add the timestamp in the draft, the
draft documents, that additional metadata like a timestamp may
be added to the instance data set.


  



-- 
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] for a future rfc6991bis

[Juergen Schoenwaelder]

This is already on my list (was already proposed by Balázs).

/js

On Fri, Nov 30, 2018 at 11:25:44AM +0100, Martin Bjorklund wrote:
> Balázs Lengyel  wrote:
> > Hello,
> > 
> > In a similar manner we found multiple uses for the
> > ietf-netconf-acm:node-instance-identifier. We
> > imported nacm just to reuse this type.
> > Anyone else interested?
> 
> Yes, this is a useful type that is not just NACM-specific.  We also
> use in various places.
> 
> 
> /martin
> 
> 
> > 
> > regards Balazs
> > 
> > On 2018. 11. 29. 12:03, Robert Wilton wrote:
> > 
> >  Hi Juergen,
> > 
> >  YANG library currently defines the type "revision-identifer". Is this a 
> > typedef that should
> >  logically migrate to rfc6991bis?
> > 
> >  Thanks,
> >  Rob
> > 
> >  On 14/11/2018 08:16, Ladislav Lhotka wrote:
> > 
> >  On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:
> > 
> >  Hi,
> > 
> >  Alex Campbell  wrote:
> > 
> >  Does a percentage really need a single standard type in the first
> >  place? How about "units percent;"?
> > 
> >  At this point, after hearing about how different modules have
> >  differing requirement on this type, I tend to agree.
> > 
> >  +1
> > 
> >  Or even "units %;"
> > 
> >  Lada
> > 
> >  /martin
> > 
> >  
> >  From: netmod  on behalf of Acee Lindem (acee)
> >  
> >  Sent: Wednesday, 14 November 2018 5:03 a.m.
> >  To: Juergen Schoenwaelder; Balázs Lengyel
> >  Cc: NETMOD WG
> >  Subject: Re: [netmod] for a future rfc6991bis
> > 
> >  On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder"
> >   >  j.schoenwael...@jacobs-university.de> wrote:
> > 
> >  On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> >  > Hello,
> >  >
> >  > In some cases I want a percentage without fractions. This could be
> >  > defined
> >  > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the
> >  > range's
> >  > argument.
> >  >
> >  > typedef percent-short {
> >  > type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type
> >  out
> >  > all the 101 integer values :-)
> >  > }
> >  >
> > 
> >  I guess we need to settle on a small number of percentage types that
> >  people find useful and then module authors hopefully find what they
> >  need. I am not sure that listing 101 numbers is a good pattern to use
> >  (although it does achieve what you want). For percentages that have no
> >  fraction, you likely want to derive from a base type that is efficient
> >  to encode for binary encodings such as CBOR.
> > 
> >  Or simply define a type with a base type of unit8 type and a range of
> >  0-100.
> > 
> >  Acee
> > 
> >  /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
> > 
> >  ___
> >  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
> > 
> > --
> > Balazs Lengyel   Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

-- 
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] for a future rfc6991bis

[Martin Bjorklund]

Balázs Lengyel  wrote:
> Hello,
> 
> In a similar manner we found multiple uses for the
> ietf-netconf-acm:node-instance-identifier. We
> imported nacm just to reuse this type.
> Anyone else interested?

Yes, this is a useful type that is not just NACM-specific.  We also
use in various places.


/martin


> 
> regards Balazs
> 
> On 2018. 11. 29. 12:03, Robert Wilton wrote:
> 
>  Hi Juergen,
> 
>  YANG library currently defines the type "revision-identifer". Is this a 
> typedef that should
>  logically migrate to rfc6991bis?
> 
>  Thanks,
>  Rob
> 
>  On 14/11/2018 08:16, Ladislav Lhotka wrote:
> 
>  On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:
> 
>  Hi,
> 
>  Alex Campbell  wrote:
> 
>  Does a percentage really need a single standard type in the first
>  place? How about "units percent;"?
> 
>  At this point, after hearing about how different modules have
>  differing requirement on this type, I tend to agree.
> 
>  +1
> 
>  Or even "units %;"
> 
>  Lada
> 
>  /martin
> 
>  
>  From: netmod  on behalf of Acee Lindem (acee)
>  
>  Sent: Wednesday, 14 November 2018 5:03 a.m.
>  To: Juergen Schoenwaelder; Balázs Lengyel
>  Cc: NETMOD WG
>  Subject: Re: [netmod] for a future rfc6991bis
> 
>  On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder"
>j.schoenwael...@jacobs-university.de> wrote:
> 
>  On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
>  > Hello,
>  >
>  > In some cases I want a percentage without fractions. This could be
>  > defined
>  > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the
>  > range's
>  > argument.
>  >
>  > typedef percent-short {
>  > type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type
>  out
>  > all the 101 integer values :-)
>  > }
>  >
> 
>  I guess we need to settle on a small number of percentage types that
>  people find useful and then module authors hopefully find what they
>  need. I am not sure that listing 101 numbers is a good pattern to use
>  (although it does achieve what you want). For percentages that have no
>  fraction, you likely want to derive from a base type that is efficient
>  to encode for binary encodings such as CBOR.
> 
>  Or simply define a type with a base type of unit8 type and a range of
>  0-100.
> 
>  Acee
> 
>  /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
> 
>  ___
>  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
> 
> --
> 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] for a future rfc6991bis

[Balázs Lengyel]

  
  
Hello, 

In a similar manner we found multiple uses for the ietf-netconf-acm:node-instance-identifier.
  We imported nacm just to reuse this type.
  Anyone else interested?
regards Balazs

On 2018. 11. 29. 12:03, Robert Wilton
  wrote:

Hi
  Juergen,
  
  
  YANG library currently defines the type "revision-identifer".  Is
  this a typedef that should logically migrate to rfc6991bis?
  
  
  Thanks,
  
  Rob
  
  
  On 14/11/2018 08:16, Ladislav Lhotka wrote:
  
  On Wed, 2018-11-14 at 09:10 +0100, Martin
Bjorklund wrote:

Hi,
  
  
  Alex Campbell  wrote:
  
  Does a percentage really need a single
standard type in the first

place? How about "units percent;"?

  
  At this point, after hearing about how different modules have
  
  differing requirement on this type, I tend to agree.
  

+1


Or even "units %;"


Lada



  
  /martin
  
  
  
  

From: netmod  on behalf of
Acee Lindem (acee)



Sent: Wednesday, 14 November 2018 5:03 a.m.

To: Juergen Schoenwaelder; Balázs Lengyel

Cc: NETMOD WG

Subject: Re: [netmod] for a future rfc6991bis


On 11/13/18, 9:07 AM, "netmod on behalf of Juergen
Schoenwaelder"

 wrote:


 On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs
Lengyel wrote:

 > Hello,

 >

 > In some cases I want a percentage without
fractions. This could be

 > defined

 > using range, by specifying the numbers 0 | 1 | 2
... 99 | 100 in the

 > range's

 > argument.

 >

 > typedef percent-short {

 >   type percent { range 0 | 1 | 2 ... 99 | 100;
} // didn't type

out

 >   all the 101 integer values :-)

 > }

 >


 I guess we need to settle on a small number of
percentage types that

 people find useful and then module authors hopefully
find what they

 need. I am not sure that listing 101 numbers is a good
pattern to use

 (although it does achieve what you want). For
percentages that have no

 fraction, you likely want to derive from a base type
that is efficient

 to encode for binary encodings such as CBOR.


Or simply define a type with a base type of unit8 type and a
range of

0-100.


Acee






 /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



___

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