Re: [netmod] An abundant amount of IANA if types...

[Andy Bierman]

On Fri, Apr 6, 2018 at 9:24 AM, Mahesh Jethanandani  wrote:

> Chassis based systems have line cards that support particular interface
> types. What happens to the output when a line card is plugged in or out of
> the system? In other words, is this a static or a dynamic list?
>
>
An RPC is inherently dynamic.
The output is based on the current state when the RPC is invoked.
There are lots of ways (e.g., proprietary trunk modes) that the interface
types
allowed can change dynamically.

BTW, the interface-ref in the input needs to be 'require-instance false'
to allow for interfaces that are not yet configured.


Andy

On Apr 6, 2018, at 9:03 AM, Andy Bierman  wrote:
>
> Hi,
>
> All of these suggested solutions seem OK if one were looking for the most
> disruptive
> way to solve the problem.  Tossing iana-if-types and starting over would
> achieve that result.
>
> First, this is a server capabilities problem, so it is related to the
> implementation, not the schema.
>
> Second, the if-types that are allowed at any given moment can be specific
> to the implementation
> and the interface name.
>
> I think this is the 3rd time I have suggested an RPC to solve the actual
> probem:
>
>   rpc get-allowed-if-types {
> description
>   "Retrieve the interface types allowed by the server.";
> input {
>   leaf name {
>  type if:interface-ref;
>  description
> "If present, the server will return allowed interface types
> for this interface name only.
>  If not present, then the server will return all supported
> interface types.";
>}
>  }
>  output {
>  leaf-list type {
> type identityref {
>base interface-type;
> }
> description
>   "Specifies a supported interface type";
> }
> }
>  }
>
>
> Andy
>
>
> On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton  wrote:
>
>> At the moment, I would say that the vast majority of the definitions in
>> IANA.yang are just noise because they refer to definitions that are
>> obsolete.  Our OS seems to use only 10% of the 287+ defined IANA types, and
>> that 10% includes technologies such as frame relay, serial, atm, that very
>> much seem to be on their way out.
>>
>> Using hierarchical identities and interface properties seems like a
>> reasonable solution to me (e.g. as described in
>> draft-wilton-netmod-interface-properties-00).  E.g. so rather than
>> having configuration with a direct when statement on a specific list of
>> interface types, instead the when statement can depend on the appropriate
>> interface properties.
>>
>> I also like Lada's suggestion of trying to spread out the IANA
>> definitions to the modules that are defining the technology.  So, if a
>> device implements support for PPP configuration/operational state then it
>> would also naturally define any PPP related interface identities at the
>> same time.
>>
>> If a vendor wants to define their own flavour of Ethernet interface then
>> they can do so in their vendor specific module without requiring all
>> tooling to become aware of it, and allowing the existing Ethernet
>> configuration to work as normal.
>>
>>
>>
>> On 06/04/2018 13:01, Ladislav Lhotka wrote:
>>
>>> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
>>>
 On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:

> Juergen Schoenwaelder  writes:
>
> If we would have a mechanism to deviate an identityref to a subset of
>> identity values supported by an implementation, we would have solved a
>> more generic problem. Yes, the IANA list could be 'nicer' but it will
>> never be 'nice'.
>>
> Three mechanisms can be used for this:
>
> - splitting the identities into separate modules
>
 Whatever module organization you come up with, it won't work for all
 implementations.

>>> Yes, getting the root of this structure right is perhaps somewhat
>> tricky, but I don't think that it needs to be all encompassing, or perfect.
>>
>> - using features
>
 Making every identity a feature will turn the feature system upside
 down. This is similar to making every leaf a feature.

 - using deviations (even though vendors frown on them)
>
 If my implementation only supports A and B and C, then a deviation may
 state exactly that and the problem is solved. Hoping that my specific

>>> In fact, deviations cannot delete identity values because they aren't
>>> schema
>>> nodes, so they are of no use.
>>>
>>> combination of A and B and C matches a set of modules or some set of
 features is in my view an illusion.

>>> An implementation that supports, say, a given type of tunnel interface
>>> will
>>> implement the module that covers this tunnel type. If the identity for
>>> this
>>> tunnel 

Re: [netmod] An abundant amount of IANA if types...

[Mahesh Jethanandani]

Chassis based systems have line cards that support particular interface types. 
What happens to the output when a line card is plugged in or out of the system? 
In other words, is this a static or a dynamic list?

> On Apr 6, 2018, at 9:03 AM, Andy Bierman  wrote:
> 
> Hi,
> 
> All of these suggested solutions seem OK if one were looking for the most 
> disruptive
> way to solve the problem.  Tossing iana-if-types and starting over would 
> achieve that result.
> 
> First, this is a server capabilities problem, so it is related to the 
> implementation, not the schema.
> 
> Second, the if-types that are allowed at any given moment can be specific to 
> the implementation
> and the interface name.
> 
> I think this is the 3rd time I have suggested an RPC to solve the actual 
> probem:
> 
>   rpc get-allowed-if-types {
> description
>   "Retrieve the interface types allowed by the server.";
> input {
>   leaf name {
>  type if:interface-ref;
>  description
> "If present, the server will return allowed interface types for 
> this interface name only.
>  If not present, then the server will return all supported 
> interface types.";
>}
>  }
>  output {
>  leaf-list type {
> type identityref {
>base interface-type;
> }
> description
>   "Specifies a supported interface type";
> }
> }
>  }
> 
> 
> Andy
> 
> 
> On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton  > wrote:
> At the moment, I would say that the vast majority of the definitions in 
> IANA.yang are just noise because they refer to definitions that are obsolete. 
>  Our OS seems to use only 10% of the 287+ defined IANA types, and that 10% 
> includes technologies such as frame relay, serial, atm, that very much seem 
> to be on their way out.
> 
> Using hierarchical identities and interface properties seems like a 
> reasonable solution to me (e.g. as described in 
> draft-wilton-netmod-interface-properties-00).  E.g. so rather than having 
> configuration with a direct when statement on a specific list of interface 
> types, instead the when statement can depend on the appropriate interface 
> properties.
> 
> I also like Lada's suggestion of trying to spread out the IANA definitions to 
> the modules that are defining the technology.  So, if a device implements 
> support for PPP configuration/operational state then it would also naturally 
> define any PPP related interface identities at the same time.
> 
> If a vendor wants to define their own flavour of Ethernet interface then they 
> can do so in their vendor specific module without requiring all tooling to 
> become aware of it, and allowing the existing Ethernet configuration to work 
> as normal.
> 
> 
> 
> On 06/04/2018 13:01, Ladislav Lhotka wrote:
> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  > writes:
> 
> If we would have a mechanism to deviate an identityref to a subset of
> identity values supported by an implementation, we would have solved a
> more generic problem. Yes, the IANA list could be 'nicer' but it will
> never be 'nice'.
> Three mechanisms can be used for this:
> 
> - splitting the identities into separate modules
> Whatever module organization you come up with, it won't work for all
> implementations.
> Yes, getting the root of this structure right is perhaps somewhat tricky, but 
> I don't think that it needs to be all encompassing, or perfect.
> 
> - using features
> Making every identity a feature will turn the feature system upside
> down. This is similar to making every leaf a feature.
> 
> - using deviations (even though vendors frown on them)
> If my implementation only supports A and B and C, then a deviation may
> state exactly that and the problem is solved. Hoping that my specific
> In fact, deviations cannot delete identity values because they aren't schema
> nodes, so they are of no use.
> 
> combination of A and B and C matches a set of modules or some set of
> features is in my view an illusion.
> An implementation that supports, say, a given type of tunnel interface will
> implement the module that covers this tunnel type. If the identity for this
> tunnel interface type is defined in the same module, then all is good. I don't
> get why this should be an illusion. On the contrary, I think it is the 
> cleanest
> available solution to this conformance specification problem.
> 
> Vendors not shipping proper deviations are essentially telling their
> customers that they have not yet understood model driven management.
> We need to change the mindset here instead of polluting our data
> models with hundreds or thousands of fine grained 'features'.
> I 

Re: [netmod] An abundant amount of IANA if types...

[Andy Bierman]

Hi,

All of these suggested solutions seem OK if one were looking for the most
disruptive
way to solve the problem.  Tossing iana-if-types and starting over would
achieve that result.

First, this is a server capabilities problem, so it is related to the
implementation, not the schema.

Second, the if-types that are allowed at any given moment can be specific
to the implementation
and the interface name.

I think this is the 3rd time I have suggested an RPC to solve the actual
probem:

  rpc get-allowed-if-types {
description
  "Retrieve the interface types allowed by the server.";
input {
  leaf name {
 type if:interface-ref;
 description
"If present, the server will return allowed interface types for
this interface name only.
 If not present, then the server will return all supported
interface types.";
   }
 }
 output {
 leaf-list type {
type identityref {
   base interface-type;
}
description
  "Specifies a supported interface type";
}
}
 }


Andy


On Fri, Apr 6, 2018 at 6:55 AM, Robert Wilton  wrote:

> At the moment, I would say that the vast majority of the definitions in
> IANA.yang are just noise because they refer to definitions that are
> obsolete.  Our OS seems to use only 10% of the 287+ defined IANA types, and
> that 10% includes technologies such as frame relay, serial, atm, that very
> much seem to be on their way out.
>
> Using hierarchical identities and interface properties seems like a
> reasonable solution to me (e.g. as described in
> draft-wilton-netmod-interface-properties-00).  E.g. so rather than having
> configuration with a direct when statement on a specific list of interface
> types, instead the when statement can depend on the appropriate interface
> properties.
>
> I also like Lada's suggestion of trying to spread out the IANA definitions
> to the modules that are defining the technology.  So, if a device
> implements support for PPP configuration/operational state then it would
> also naturally define any PPP related interface identities at the same time.
>
> If a vendor wants to define their own flavour of Ethernet interface then
> they can do so in their vendor specific module without requiring all
> tooling to become aware of it, and allowing the existing Ethernet
> configuration to work as normal.
>
>
>
> On 06/04/2018 13:01, Ladislav Lhotka wrote:
>
>> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
>>
>>> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
>>>
 Juergen Schoenwaelder  writes:

 If we would have a mechanism to deviate an identityref to a subset of
> identity values supported by an implementation, we would have solved a
> more generic problem. Yes, the IANA list could be 'nicer' but it will
> never be 'nice'.
>
 Three mechanisms can be used for this:

 - splitting the identities into separate modules

>>> Whatever module organization you come up with, it won't work for all
>>> implementations.
>>>
>> Yes, getting the root of this structure right is perhaps somewhat tricky,
> but I don't think that it needs to be all encompassing, or perfect.
>
> - using features

>>> Making every identity a feature will turn the feature system upside
>>> down. This is similar to making every leaf a feature.
>>>
>>> - using deviations (even though vendors frown on them)

>>> If my implementation only supports A and B and C, then a deviation may
>>> state exactly that and the problem is solved. Hoping that my specific
>>>
>> In fact, deviations cannot delete identity values because they aren't
>> schema
>> nodes, so they are of no use.
>>
>> combination of A and B and C matches a set of modules or some set of
>>> features is in my view an illusion.
>>>
>> An implementation that supports, say, a given type of tunnel interface
>> will
>> implement the module that covers this tunnel type. If the identity for
>> this
>> tunnel interface type is defined in the same module, then all is good. I
>> don't
>> get why this should be an illusion. On the contrary, I think it is the
>> cleanest
>> available solution to this conformance specification problem.
>>
>> Vendors not shipping proper deviations are essentially telling their
>>> customers that they have not yet understood model driven management.
>>> We need to change the mindset here instead of polluting our data
>>> models with hundreds or thousands of fine grained 'features'.
>>>
>> I agree that zillions of features aren't nice but it seems to be the only
>> solution that we currently have for modules of the iana-if-type style.
>>
>> Having an bulky set of identity values, most of which are of no interest,
>> is IMO
>> much worse and could also be a security issue if implementors aren't
>> careful
>> enough.
>>
> I'm not sure there is a security 

Re: [netmod] An abundant amount of IANA if types...

[Robert Wilton]

At the moment, I would say that the vast majority of the definitions in 
IANA.yang are just noise because they refer to definitions that are 
obsolete.  Our OS seems to use only 10% of the 287+ defined IANA types, 
and that 10% includes technologies such as frame relay, serial, atm, 
that very much seem to be on their way out.


Using hierarchical identities and interface properties seems like a 
reasonable solution to me (e.g. as described in 
draft-wilton-netmod-interface-properties-00).  E.g. so rather than 
having configuration with a direct when statement on a specific list of 
interface types, instead the when statement can depend on the 
appropriate interface properties.


I also like Lada's suggestion of trying to spread out the IANA 
definitions to the modules that are defining the technology.  So, if a 
device implements support for PPP configuration/operational state then 
it would also naturally define any PPP related interface identities at 
the same time.


If a vendor wants to define their own flavour of Ethernet interface then 
they can do so in their vendor specific module without requiring all 
tooling to become aware of it, and allowing the existing Ethernet 
configuration to work as normal.




On 06/04/2018 13:01, Ladislav Lhotka wrote:

On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:

On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:

Juergen Schoenwaelder  writes:


If we would have a mechanism to deviate an identityref to a subset of
identity values supported by an implementation, we would have solved a
more generic problem. Yes, the IANA list could be 'nicer' but it will
never be 'nice'.

Three mechanisms can be used for this:

- splitting the identities into separate modules

Whatever module organization you come up with, it won't work for all
implementations.
Yes, getting the root of this structure right is perhaps somewhat 
tricky, but I don't think that it needs to be all encompassing, or perfect.



- using features

Making every identity a feature will turn the feature system upside
down. This is similar to making every leaf a feature.


- using deviations (even though vendors frown on them)

If my implementation only supports A and B and C, then a deviation may
state exactly that and the problem is solved. Hoping that my specific

In fact, deviations cannot delete identity values because they aren't schema
nodes, so they are of no use.


combination of A and B and C matches a set of modules or some set of
features is in my view an illusion.

An implementation that supports, say, a given type of tunnel interface will
implement the module that covers this tunnel type. If the identity for this
tunnel interface type is defined in the same module, then all is good. I don't
get why this should be an illusion. On the contrary, I think it is the cleanest
available solution to this conformance specification problem.


Vendors not shipping proper deviations are essentially telling their
customers that they have not yet understood model driven management.
We need to change the mindset here instead of polluting our data
models with hundreds or thousands of fine grained 'features'.

I agree that zillions of features aren't nice but it seems to be the only
solution that we currently have for modules of the iana-if-type style.

Having an bulky set of identity values, most of which are of no interest, is IMO
much worse and could also be a security issue if implementors aren't careful
enough.
I'm not sure there is a security concern here, but a long list where 
most of the values are cruft doesn't really seem to help anyone.  It 
also makes it harder to know which is the right type to use.  E.g. will 
everyone know that they should use "ethernetCsmacd" rather than 
"gigabitEthernet" for an optical GE interface that doesn't actually use 
CSMA/CD ...


Thanks,
Rob




Lada


/js



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

Re: [netmod] Comments on schema mount draft

[Martin Bjorklund]

Hi,

Rohit Ranade  wrote:
> Hi Martin,
> 
> 
> 
> For below point:
> 
> “
> 
> > 4. NETCONF has some "rpc" which work on multiple mount-instances.
> >
> >==> For example  ,  or . Whether we need 
> > to give a
> >
> >guideline for how to handle such "rpc", so that other protocols which 
> > implement schema mount   also adapt accordingly ?
> >
> >Eg: Something like, for transaction management, better to operate on one 
> > mount-instance.
> 
> This would not be correct.  I think you are assuming one use case;
> where schema mount is used in a (primitive) orchestrator that actually
> talks to multiple devices (w/o transaction control).
> 
> Note that this document just defines how the *schema* is built; not
> how instance data is stored or accessed.
> 
> ”
> 
> As per example shown in section 4:
> 
>  +--rw network-instances
> 
> +--rw network-instance* [name]
> 
>+--rw name
> 
>+--rw root
> 
>   +--rw routing
> 
> 
> 
> Considering “root” as mount point :
> 
> 
> 
> When querying data from schema mounted models:
> 
> 
> 
> 
> 
>   
> 
> 
> 
>   
> 
>1
> 
> 
> 
>   
> 
> 
> 
> And
> 
> 
> 
> 
> 
> 
> 
>   
> 
>1
> 
> 
> 
> -- having ietf-netconf ns
> 
> 
> 
>  
> 
> 
> 
> Will these two give the same result ?

Yes, provided that the ietf-netconf module is mounted.


/martin



> 
> 
> 
> With Regards,
> 
> Rohit R
> 
> 
> 
> Sent from Mail for Windows 10
> 
> 
> 
> 
> From: Martin Bjorklund 
> Sent: Thursday, April 5, 2018 6:13:49 PM
> To: rohitrran...@outlook.com
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Comments on schema mount draft
> 
> Hi,
> 
> 
> Rohit Ranade  wrote:
> > Hi Martin,
> >
> >
> >
> > Thank you for your responses.
> >
> > I have gone through the LNE draft and YANG 1.1 and found some more 
> > suggestions.
> >
> >
> >
> > 1. Section 5
> >
> >"If a mounted YANG module defines an RPC operation, clients can invoke
> >
> >this operation as if it were defined as an action for the
> >
> >corresponding mount point"
> >
> >==> Below is the example from Yang 1.1 Section 7.15
> >
> >
> >
> >  >
> >   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >
> >
> >
> >  
> >
> >apache-1
> >
> >
> >
> >  2014-07-29T13:42:00Z
> >
> >
> >
> >  
> >
> >
> >
> >  
> >
> >
> >
> >   >
> > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
> >
> >
> >
> >  2014-07-29T13:42:12Z
> >
> >
> >
> >  
> >
> >   ==> Here rpc-reply only has the namespace and action name 
> > defined in the mount-instance's module.
> >
> >   The client needs to store information of the mount-instance 
> > for which the RPC request was sent and only then it can validate the 
> > rpc-reply against the data-model.
> >
> >   To avoid this work of client, whether we can think of adding 
> > meta-data to rpc-reply to provide this information to client.
> 
> If the client invokes an action, it is expected that it knows how to
> interpret the result.  This does not change with the introduction of
> schema mount.  The client obviously knows the name and input
> parameters of the action, so it seems resonable to expect that it
> knows the output parameters as well, w/o any additional meta data.
> 
> > 2. Section 5
> >
> >I would prefer the approach taken by Yang 1.1 where statements followed 
> > by XML examples   to help in clarity.
> >
> >Especially for the RPC and notification section, it is better to add 
> > clear examples
> >
> >in a "Usage Example" sub-section for this section.
> 
> The examples are given in the appendix, and there is a forward
> reference to the appendix from section 5.
> 
> 
> > 3. Yang RPC and ACTION statements:
> >
> >   If we need to view the RPC defined in a module as an ACTION after schema 
> > mount, then
> >
> >   Whenever there is update to RPC in say YANG 1.2, then the corresponding 
> > changes must be present in ACTION also, introducing a coupling between RPC 
> > and ACTION statements.
> 
> This module is written using YANG 1.1.  Unless this module is updated,
> it doesn't matter what YANG 2.0 or whatever does.
> 
> > 4. NETCONF has some "rpc" which work on multiple mount-instances.
> >
> >==> For example  ,  or . Whether we need 
> > to give a
> >
> >guideline for how to handle such "rpc", so that other protocols which 
> > implement schema mount   also adapt accordingly ?
> >
> >Eg: Something like, for transaction management, better to operate on one 
> > mount-instance.
> 
> This would not be correct.  I think you are assuming one use case;
> where schema mount is used in a (primitive) 

Re: [netmod] js review of draft-ietf-netmod-schema-mount-09

[Martin Bjorklund]

Hi,

Juergen Schoenwaelder  wrote:
> On Thu, Apr 05, 2018 at 02:33:40PM +0200, Martin Bjorklund wrote:
> > Hi,
> > 
> > Thank you for this review!  Comments inline.
> > 
> > Juergen Schoenwaelder  wrote:
> > > Here is my review of draft-ietf-netmod-schema-mount-09.
> > > 
> > > * Abstract
> > > 
> > >This document defines a mechanism to combine YANG modules into the
> > >schema defined in other YANG modules.
> > > 
> > >   I do not know what this says - I think this text is confusing. What
> > >   does it mean to 'combine' YANG modules? What is the notion of
> > >   'schema' used here?
> > 
> > Howabout:
> > 
> >   This document defines a mechanism to add the schema trees defined by
> >   a set of YANG modules into the schema tree defined in another YANG
> >   module.
> >
> 
> This is better.
> 
> > (see more below on terminology)
> > 
> > >   Does the text help someone to decide whether
> > >   this mechanisms is something worth to study in order to solve a
> > >   given modeling problem?  (A good abstract would IMHO do that.)
> > > 
> > >   Note that the mount mechanisms has serious limitations as well that
> > >   perhaps need to spelled out right up-front, i.e., it only works with
> > >   pre-defined mount-points (augments are much more flexible in this
> > >   regard, the schema mount defined here is by its very design not
> > >   very flexible.
> > 
> > I don't agree that this is a "serious limitation", and I don't think
> > an abstract should list things that the document doesn't do.
> 
> OK. Remove 'serious' but clearly this schema mount mechanism is not as
> flexible as it could me. What about this:
> 
>This document defines a mechanism to add the schema trees defined
>by a set of YANG modules onto mount points defined in another YANG
>module.
> 
> This at least hints at the fact that mount points are rather static
> citizens.

Ok.  I tweaked it to:

  This document defines a mechanism to add the schema trees defined
  by a set of YANG modules onto a mount point defined in the schema
  tree in some YANG module.

> > >   While I think I understand the difference made between
> > >   implementation-time and run-time, the description is somewhat
> > >   confusing since the run-time mount will also be exposed via YANG
> > >   library and hence defining implementation-time by 'defined by a
> > >   server implementor and is as stable as YANG library information of
> > >   the server' is somewhat fuzzy. I assume what you mean is that in the
> > >   case 2. the mounted schema is fixed at implementation time while in
> > >   the case 3. the mounted schema may vary and be discovered at
> > >   run-time. However, you do not define things this way but rather talk
> > >   about properties that do however not define things.
> > 
> > Howabout:
> > 
> > OLD:
> > 
> > + Run-time: the mounted schema is defined by instance data that is
> >   part of the mounted data model. If there are multiple instances of
> >   the same mount point (e.g., in multiple entries of a list), the
> >   mounted data model may be different for each instance.
> > 
> > NEW:
> > 
> > + Run-time: the mounted schema can vary at run time and is defined by
> >   instance data that is part of the mounted data model. If there are
> >   multiple instances of the same mount point (e.g., in multiple
> >   entries of a list), the mounted data model may be different for each
> >   instance.
> 
> Better.
>  
> > > * Glossary of New Terms
> > > 
> > >  o  top-level schema: a schema according to [RFC7950] in which schema
> > >   trees of each module (except augments) start at the root node.
> > > 
> > >   You do not import 'schema' from RFC 7950 since, well, it is not
> > >   defined in RFC 7950. I think you often mean a schema tree (as
> > >   defined in RFC 7950) when you use 'schema'. Well, even this is not
> > >   true since a 'schema tree' according to RFC 7950 is scoped to a
> > >   module. RFC 8342 defines a 'datastore schema' but then I am not sure
> > >   this corresponds to 'schema' as used in this draft. In fact, the
> > >   mounted schema may be considered part of the 'datastore schema'.  I
> > >   think we are handwaving with our terminology here but then perhaps I
> > >   am the only one who cares...
> > 
> > I have imported "schema tree" from 7950, and changed teh definition of
> > top-level schema to:
> > 
> > - top-level schema: a set of modules in which the schema
> >   trees of each module (except augments) start at the root node.
> 
> Still sounds complicated and not quite clear. Do you mean this:
> 
> - top-level schema: a set of schema trees of a set of modules starting
>   at the root node
> 
> > >   What we actually have are schema tree (of a module per RFC 7950) and
> > >   a collection of schema trees sharing a common root (this is likely
> > >   what is meant with "schema" in this document). And then schema mount
> > >   

Re: [netmod] An abundant amount of IANA if types...

[Ladislav Lhotka]

On Fri, 2018-04-06 at 14:29 +0200, Juergen Schoenwaelder wrote:
> On Fri, Apr 06, 2018 at 02:01:30PM +0200, Ladislav Lhotka wrote:
> > On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
> > > On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> > > > Juergen Schoenwaelder  writes:
> > > > 
> > > > > If we would have a mechanism to deviate an identityref to a subset of
> > > > > identity values supported by an implementation, we would have solved a
> > > > > more generic problem. Yes, the IANA list could be 'nicer' but it will
> > > > > never be 'nice'.
> > > > 
> > > > Three mechanisms can be used for this:
> > > > 
> > > > - splitting the identities into separate modules
> > > 
> > > Whatever module organization you come up with, it won't work for all
> > > implementations. 
> > > 
> > > > - using features
> > > 
> > > Making every identity a feature will turn the feature system upside
> > > down. This is similar to making every leaf a feature.
> > > 
> > > > - using deviations (even though vendors frown on them)
> > > 
> > > If my implementation only supports A and B and C, then a deviation may
> > > state exactly that and the problem is solved. Hoping that my specific
> > 
> > In fact, deviations cannot delete identity values because they aren't schema
> > nodes, so they are of no use.
> 
> Putting today's limits of YANG syntax aside for the moment, I still
> believe implementations need to publish the identities they support
> without requiring matching features or module definition.

OK, but then I certainly wouldn't call it a deviation.

> 
> > > combination of A and B and C matches a set of modules or some set of
> > > features is in my view an illusion.
> > 
> > An implementation that supports, say, a given type of tunnel interface will
> > implement the module that covers this tunnel type. If the identity for this
> > tunnel interface type is defined in the same module, then all is good. I
> > don't
> > get why this should be an illusion. On the contrary, I think it is the
> > cleanest
> > available solution to this conformance specification problem.
> > 
> > > 
> > > Vendors not shipping proper deviations are essentially telling their
> > > customers that they have not yet understood model driven management.
> > > We need to change the mindset here instead of polluting our data
> > > models with hundreds or thousands of fine grained 'features'.
> > 
> > I agree that zillions of features aren't nice but it seems to be the only
> > solution that we currently have for modules of the iana-if-type style.
> > 
> > Having an bulky set of identity values, most of which are of no interest, is
> > IMO
> > much worse and could also be a security issue if implementors aren't careful
> > enough.
> 
> If an implementation does not check input, then the code is broken,

Come on, the cyberspace is full of such code. We should do our best to enable
schemas that are as strict as possible.

In XML, it should have been clear to everybody that hardwired namespace prefixes
are broken, and yet they were used so often that eventually the prefix-URL
duality was identified as a flaw of XML itself.

Lada 

> regardless whether we restrict the identities somewhere or not. I do
> not buy the security point.
> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] Comments on schema mount draft

[Rohit Ranade]

Hi Martin,



For below point:

“

> 4. NETCONF has some "rpc" which work on multiple mount-instances.
>
>==> For example  ,  or . Whether we need to 
> give a
>
>guideline for how to handle such "rpc", so that other protocols which 
> implement schema mount   also adapt accordingly ?
>
>Eg: Something like, for transaction management, better to operate on one 
> mount-instance.

This would not be correct.  I think you are assuming one use case;
where schema mount is used in a (primitive) orchestrator that actually
talks to multiple devices (w/o transaction control).

Note that this document just defines how the *schema* is built; not
how instance data is stored or accessed.

”

As per example shown in section 4:

 +--rw network-instances

+--rw network-instance* [name]

   +--rw name

   +--rw root

  +--rw routing



Considering “root” as mount point :



When querying data from schema mounted models:





  



  

   1



  



And







  

   1



-- having ietf-netconf ns



 



Will these two give the same result ?



With Regards,

Rohit R



Sent from Mail for Windows 10




From: Martin Bjorklund 
Sent: Thursday, April 5, 2018 6:13:49 PM
To: rohitrran...@outlook.com
Cc: netmod@ietf.org
Subject: Re: [netmod] Comments on schema mount draft

Hi,


Rohit Ranade  wrote:
> Hi Martin,
>
>
>
> Thank you for your responses.
>
> I have gone through the LNE draft and YANG 1.1 and found some more 
> suggestions.
>
>
>
> 1. Section 5
>
>"If a mounted YANG module defines an RPC operation, clients can invoke
>
>this operation as if it were defined as an action for the
>
>corresponding mount point"
>
>==> Below is the example from Yang 1.1 Section 7.15
>
>
>
> 
>   xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>
>
>
>  
>
>apache-1
>
>
>
>  2014-07-29T13:42:00Z
>
>
>
>  
>
>
>
>  
>
>
>
>  
> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>
>
>
>  2014-07-29T13:42:12Z
>
>
>
>  
>
>   ==> Here rpc-reply only has the namespace and action name 
> defined in the mount-instance's module.
>
>   The client needs to store information of the mount-instance for 
> which the RPC request was sent and only then it can validate the rpc-reply 
> against the data-model.
>
>   To avoid this work of client, whether we can think of adding 
> meta-data to rpc-reply to provide this information to client.

If the client invokes an action, it is expected that it knows how to
interpret the result.  This does not change with the introduction of
schema mount.  The client obviously knows the name and input
parameters of the action, so it seems resonable to expect that it
knows the output parameters as well, w/o any additional meta data.

> 2. Section 5
>
>I would prefer the approach taken by Yang 1.1 where statements followed by 
> XML examples   to help in clarity.
>
>Especially for the RPC and notification section, it is better to add clear 
> examples
>
>in a "Usage Example" sub-section for this section.

The examples are given in the appendix, and there is a forward
reference to the appendix from section 5.


> 3. Yang RPC and ACTION statements:
>
>   If we need to view the RPC defined in a module as an ACTION after schema 
> mount, then
>
>   Whenever there is update to RPC in say YANG 1.2, then the corresponding 
> changes must be present in ACTION also, introducing a coupling between RPC 
> and ACTION statements.

This module is written using YANG 1.1.  Unless this module is updated,
it doesn't matter what YANG 2.0 or whatever does.

> 4. NETCONF has some "rpc" which work on multiple mount-instances.
>
>==> For example  ,  or . Whether we need to 
> give a
>
>guideline for how to handle such "rpc", so that other protocols which 
> implement schema mount   also adapt accordingly ?
>
>Eg: Something like, for transaction management, better to operate on one 
> mount-instance.

This would not be correct.  I think you are assuming one use case;
where schema mount is used in a (primitive) orchestrator that actually
talks to multiple devices (w/o transaction control).

Note that this document just defines how the *schema* is built; not
how instance data is stored or accessed.



/martin

>
>
>
>
>
>
>
> With Regards,
>
> Rohit R
>
>
>
> 
> From: Martin Bjorklund 
> Sent: Thursday, March 29, 2018 12:59:53 PM
> To: rohitrran...@outlook.com
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Comments on schema mount draft
>
> Hi,
>
> Rohit Ranade  wrote:
> > Hi Martin,
> >
> > W.r.t  on the main 

Re: [netmod] An abundant amount of IANA if types...

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder  writes:
> > 
> > > If we would have a mechanism to deviate an identityref to a subset of
> > > identity values supported by an implementation, we would have solved a
> > > more generic problem. Yes, the IANA list could be 'nicer' but it will
> > > never be 'nice'.
> > 
> > Three mechanisms can be used for this:
> > 
> > - splitting the identities into separate modules
> 
> Whatever module organization you come up with, it won't work for all
> implementations. 
> 
> > - using features
> 
> Making every identity a feature will turn the feature system upside
> down. This is similar to making every leaf a feature.
> 
> > - using deviations (even though vendors frown on them)
> 
> If my implementation only supports A and B and C, then a deviation may
> state exactly that and the problem is solved. Hoping that my specific
> combination of A and B and C matches a set of modules or some set of
> features is in my view an illusion.
> 
> Vendors not shipping proper deviations are essentially telling their
> customers that they have not yet understood model driven management.
> We need to change the mindset here instead of polluting our data
> models with hundreds or thousands of fine grained 'features'.

One problem is that you can't "deviate-away" support for an identity.


/martin



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

Re: [netmod] An abundant amount of IANA if types...

[Juergen Schoenwaelder]

On Fri, Apr 06, 2018 at 02:01:30PM +0200, Ladislav Lhotka wrote:
> On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
> > On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> > > Juergen Schoenwaelder  writes:
> > > 
> > > > If we would have a mechanism to deviate an identityref to a subset of
> > > > identity values supported by an implementation, we would have solved a
> > > > more generic problem. Yes, the IANA list could be 'nicer' but it will
> > > > never be 'nice'.
> > > 
> > > Three mechanisms can be used for this:
> > > 
> > > - splitting the identities into separate modules
> > 
> > Whatever module organization you come up with, it won't work for all
> > implementations. 
> > 
> > > - using features
> > 
> > Making every identity a feature will turn the feature system upside
> > down. This is similar to making every leaf a feature.
> > 
> > > - using deviations (even though vendors frown on them)
> > 
> > If my implementation only supports A and B and C, then a deviation may
> > state exactly that and the problem is solved. Hoping that my specific
> 
> In fact, deviations cannot delete identity values because they aren't schema
> nodes, so they are of no use.

Putting today's limits of YANG syntax aside for the moment, I still
believe implementations need to publish the identities they support
without requiring matching features or module definition.

> > combination of A and B and C matches a set of modules or some set of
> > features is in my view an illusion.
> 
> An implementation that supports, say, a given type of tunnel interface will
> implement the module that covers this tunnel type. If the identity for this
> tunnel interface type is defined in the same module, then all is good. I don't
> get why this should be an illusion. On the contrary, I think it is the 
> cleanest
> available solution to this conformance specification problem.
> 
> > 
> > Vendors not shipping proper deviations are essentially telling their
> > customers that they have not yet understood model driven management.
> > We need to change the mindset here instead of polluting our data
> > models with hundreds or thousands of fine grained 'features'.
> 
> I agree that zillions of features aren't nice but it seems to be the only
> solution that we currently have for modules of the iana-if-type style.
> 
> Having an bulky set of identity values, most of which are of no interest, is 
> IMO
> much worse and could also be a security issue if implementors aren't careful
> enough.

If an implementation does not check input, then the code is broken,
regardless whether we restrict the identities somewhere or not. I do
not buy the security point.

/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] js review of draft-ietf-netmod-schema-mount-09

[Juergen Schoenwaelder]

On Thu, Apr 05, 2018 at 02:33:40PM +0200, Martin Bjorklund wrote:
> Hi,
> 
> Thank you for this review!  Comments inline.
> 
> Juergen Schoenwaelder  wrote:
> > Here is my review of draft-ietf-netmod-schema-mount-09.
> > 
> > * Abstract
> > 
> >This document defines a mechanism to combine YANG modules into the
> >schema defined in other YANG modules.
> > 
> >   I do not know what this says - I think this text is confusing. What
> >   does it mean to 'combine' YANG modules? What is the notion of
> >   'schema' used here?
> 
> Howabout:
> 
>   This document defines a mechanism to add the schema trees defined by
>   a set of YANG modules into the schema tree defined in another YANG
>   module.
>

This is better.

> (see more below on terminology)
> 
> >   Does the text help someone to decide whether
> >   this mechanisms is something worth to study in order to solve a
> >   given modeling problem?  (A good abstract would IMHO do that.)
> > 
> >   Note that the mount mechanisms has serious limitations as well that
> >   perhaps need to spelled out right up-front, i.e., it only works with
> >   pre-defined mount-points (augments are much more flexible in this
> >   regard, the schema mount defined here is by its very design not
> >   very flexible.
> 
> I don't agree that this is a "serious limitation", and I don't think
> an abstract should list things that the document doesn't do.

OK. Remove 'serious' but clearly this schema mount mechanism is not as
flexible as it could me. What about this:

   This document defines a mechanism to add the schema trees defined
   by a set of YANG modules onto mount points defined in another YANG
   module.

This at least hints at the fact that mount points are rather static
citizens.
 
> >   While I think I understand the difference made between
> >   implementation-time and run-time, the description is somewhat
> >   confusing since the run-time mount will also be exposed via YANG
> >   library and hence defining implementation-time by 'defined by a
> >   server implementor and is as stable as YANG library information of
> >   the server' is somewhat fuzzy. I assume what you mean is that in the
> >   case 2. the mounted schema is fixed at implementation time while in
> >   the case 3. the mounted schema may vary and be discovered at
> >   run-time. However, you do not define things this way but rather talk
> >   about properties that do however not define things.
> 
> Howabout:
> 
> OLD:
> 
> + Run-time: the mounted schema is defined by instance data that is
>   part of the mounted data model. If there are multiple instances of
>   the same mount point (e.g., in multiple entries of a list), the
>   mounted data model may be different for each instance.
> 
> NEW:
> 
> + Run-time: the mounted schema can vary at run time and is defined by
>   instance data that is part of the mounted data model. If there are
>   multiple instances of the same mount point (e.g., in multiple
>   entries of a list), the mounted data model may be different for each
>   instance.

Better.
 
> > * Glossary of New Terms
> > 
> >  o  top-level schema: a schema according to [RFC7950] in which schema
> >   trees of each module (except augments) start at the root node.
> > 
> >   You do not import 'schema' from RFC 7950 since, well, it is not
> >   defined in RFC 7950. I think you often mean a schema tree (as
> >   defined in RFC 7950) when you use 'schema'. Well, even this is not
> >   true since a 'schema tree' according to RFC 7950 is scoped to a
> >   module. RFC 8342 defines a 'datastore schema' but then I am not sure
> >   this corresponds to 'schema' as used in this draft. In fact, the
> >   mounted schema may be considered part of the 'datastore schema'.  I
> >   think we are handwaving with our terminology here but then perhaps I
> >   am the only one who cares...
> 
> I have imported "schema tree" from 7950, and changed teh definition of
> top-level schema to:
> 
> - top-level schema: a set of modules in which the schema
>   trees of each module (except augments) start at the root node.

Still sounds complicated and not quite clear. Do you mean this:

- top-level schema: a set of schema trees of a set of modules starting
  at the root node

> >   What we actually have are schema tree (of a module per RFC 7950) and
> >   a collection of schema trees sharing a common root (this is likely
> >   what is meant with "schema" in this document). And then schema mount
> >   simply provides a mechanism to have additional (statically defined)
> >   roots in a schema.

So what are you planning to do about the term 'schema' used throughout
the module? We kind of define what a top-level schema is but leave
schema undefined and perhaps we would also benefit from having a term
like mounted schema. I am thinking along these lines:

  schema = collection of schema trees with a common root
  top-level schema = schema rooted at the root node
  mounted schema = 

Re: [netmod] An abundant amount of IANA if types...

[Ladislav Lhotka]

On Fri, 2018-04-06 at 13:36 +0200, Juergen Schoenwaelder wrote:
> On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder  writes:
> > 
> > > If we would have a mechanism to deviate an identityref to a subset of
> > > identity values supported by an implementation, we would have solved a
> > > more generic problem. Yes, the IANA list could be 'nicer' but it will
> > > never be 'nice'.
> > 
> > Three mechanisms can be used for this:
> > 
> > - splitting the identities into separate modules
> 
> Whatever module organization you come up with, it won't work for all
> implementations. 
> 
> > - using features
> 
> Making every identity a feature will turn the feature system upside
> down. This is similar to making every leaf a feature.
> 
> > - using deviations (even though vendors frown on them)
> 
> If my implementation only supports A and B and C, then a deviation may
> state exactly that and the problem is solved. Hoping that my specific

In fact, deviations cannot delete identity values because they aren't schema
nodes, so they are of no use.

> combination of A and B and C matches a set of modules or some set of
> features is in my view an illusion.

An implementation that supports, say, a given type of tunnel interface will
implement the module that covers this tunnel type. If the identity for this
tunnel interface type is defined in the same module, then all is good. I don't
get why this should be an illusion. On the contrary, I think it is the cleanest
available solution to this conformance specification problem.

> 
> Vendors not shipping proper deviations are essentially telling their
> customers that they have not yet understood model driven management.
> We need to change the mindset here instead of polluting our data
> models with hundreds or thousands of fine grained 'features'.

I agree that zillions of features aren't nice but it seems to be the only
solution that we currently have for modules of the iana-if-type style.

Having an bulky set of identity values, most of which are of no interest, is IMO
much worse and could also be a security issue if implementors aren't careful
enough.

Lada  

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

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

Re: [netmod] An abundant amount of IANA if types...

[Bogaert, Bart (Nokia - BE/Antwerp)]

Juergen,

I was not suggesting to have a feature for all identities but I would assume 
that there are several identities that logically belong to each other so these 
could be grouped.  If this would still lead to a lot of features I do not see 
how a deviation can help out here to reduce the number of identities as you do 
not have a schema node for identities so to me the only way to reduce the 
amount of interface types one supports is to define a YANG module importing 
ietf-interfaces for the base interface-type identity and defining the set of 
identities required but then this not really in-line with what is coming from 
the standardization bodies (you could re-use the same names as used in 
iana-if-type but this is not very nice).

Regards, Bart

-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: Friday, April 6, 2018 1:37 PM
To: Bogaert, Bart (Nokia - BE/Antwerp) ; Alex Campbell 
; netmod@ietf.org
Subject: Re: [netmod] An abundant amount of IANA if types...

On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > If we would have a mechanism to deviate an identityref to a subset 
> > of identity values supported by an implementation, we would have 
> > solved a more generic problem. Yes, the IANA list could be 'nicer' 
> > but it will never be 'nice'.
> 
> Three mechanisms can be used for this:
> 
> - splitting the identities into separate modules

Whatever module organization you come up with, it won't work for all 
implementations. 

> - using features

Making every identity a feature will turn the feature system upside down. This 
is similar to making every leaf a feature.

> - using deviations (even though vendors frown on them)

If my implementation only supports A and B and C, then a deviation may state 
exactly that and the problem is solved. Hoping that my specific combination of 
A and B and C matches a set of modules or some set of features is in my view an 
illusion.

Vendors not shipping proper deviations are essentially telling their customers 
that they have not yet understood model driven management.
We need to change the mindset here instead of polluting our data models with 
hundreds or thousands of fine grained 'features'.

/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] An abundant amount of IANA if types...

[Juergen Schoenwaelder]

On Fri, Apr 06, 2018 at 10:51:48AM +0200, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > If we would have a mechanism to deviate an identityref to a subset of
> > identity values supported by an implementation, we would have solved a
> > more generic problem. Yes, the IANA list could be 'nicer' but it will
> > never be 'nice'.
> 
> Three mechanisms can be used for this:
> 
> - splitting the identities into separate modules

Whatever module organization you come up with, it won't work for all
implementations. 

> - using features

Making every identity a feature will turn the feature system upside
down. This is similar to making every leaf a feature.

> - using deviations (even though vendors frown on them)

If my implementation only supports A and B and C, then a deviation may
state exactly that and the problem is solved. Hoping that my specific
combination of A and B and C matches a set of modules or some set of
features is in my view an illusion.

Vendors not shipping proper deviations are essentially telling their
customers that they have not yet understood model driven management.
We need to change the mindset here instead of polluting our data
models with hundreds or thousands of fine grained 'features'.

/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] An abundant amount of IANA if types...

[Ladislav Lhotka]

Juergen Schoenwaelder  writes:

> If we would have a mechanism to deviate an identityref to a subset of
> identity values supported by an implementation, we would have solved a
> more generic problem. Yes, the IANA list could be 'nicer' but it will
> never be 'nice'.

Three mechanisms can be used for this:

- splitting the identities into separate modules
- using features
- using deviations (even though vendors frown on them)

I also proposed in the past to define the relevant identities in small
batches in the same module that defines other data (configuration, state
etc.) for the given interface type(s), rather than maintaining the
interface types as a separate registry.

I do admit that it is also useful to have such a registry but it can be
automatically compiled from the existing modules (for example, YANG
Catalog could do this).

Lada

>
> /js
>
> On Fri, Apr 06, 2018 at 08:12:03AM +, Bogaert, Bart (Nokia - BE/Antwerp) 
> wrote:
>> Alex,
>> 
>> Not sure if this only has to do with "practical limitations providing a CLI 
>> interface"...   In a machine-to-machine interface this is less of a problem 
>> but in a human-to-machine interface it seems a bit impractical to me to find 
>> a solution for a problem to scroll through a list of 100+ completions if an 
>> operator would ask for the possible completion in case he does not know what 
>> to provide as input.  There are ways to limit this output but it can be 
>> solved on a modelling level as well.  As I indicated identities can be 
>> conditional to a feature and if implementations choose not to implement a 
>> set of interface-type related features the list becomes (a whole lot) 
>> shorter "by itself".  Now iana-if-type is just a collection of all interface 
>> types that have been defined once without any kind of "structure".
>> 
>> Regards, Bart
>> 
>> -Original Message-
>> From: Ladislav Lhotka [mailto:lho...@nic.cz] 
>> Sent: Friday, April 6, 2018 9:55 AM
>> To: Alex Campbell ; Bogaert, Bart (Nokia - 
>> BE/Antwerp) ; netmod@ietf.org
>> Subject: Re: [netmod] An abundant amount of IANA if types...
>> 
>> Hi,
>> 
>> I have argued several times in the past that the IANA interface list (and, 
>> for that matter, the iana-if-type module) is a useless pile of rubbish 
>> because
>> 
>> - for some interface classes (Ethernet, tunnels) it is way too coarse-grained
>> 
>> - on the other hand, it contains a lot of stuff that nobody will ever use
>> 
>> - using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for 
>> Ethernet is outright stupid
>> 
>> - YANG identities allow for encoding important relationships in interface 
>> types,in the flat list all this information is lost 
>> 
>> - as you say, implementing the iana-if-type module means that all interface 
>> types listed therein become valid.
>> 
>> So yes, I do believe that it would be useful if authoritative expert groups 
>> develop a better structure of interface type identities.
>> 
>> Lada
>>   
>> On Thu, 2018-04-05 at 23:59 +, Alex Campbell wrote:
>> > I haven't seen any previous discussions on the topic, but we have a 
>> > similar problem.
>> > Note this is not really to do with YANG itself, so much as the 
>> > practical limitations of the software package that provides our CLI 
>> > interface.
>> > In NETCONF, the existence of extra unused identities doesn't pose any 
>> > problem.
>> > 
>> > From: netmod  on behalf of Bogaert, Bart 
>> > (Nokia -
>> > BE/Antwerp) 
>> > Sent: Thursday, 5 April 2018 8:21 p.m.
>> > To: netmod@ietf.org
>> > Subject: [netmod] An abundant amount of IANA if types...
>> >  
>> > Hi,
>> >  
>> > We were wondering if it would make sense to introduce features in the 
>> > IANA if types YANG model to enable grouping of related interface 
>> > types.  This would allow implementations to include only the types it 
>> > really requires (by supporting the related features but not the 
>> > others) and (in case of a CLI
>> > interface) would reduce the possible completions if an operator would 
>> > ask for the possible values of the type of an interface.
>> > Has this ever been considered/discussed?
>> >  
>> > Best regards,
>> > Bart
>> > ___
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> ___
>> 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 

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

Re: [netmod] An abundant amount of IANA if types...

[Juergen Schoenwaelder]

If we would have a mechanism to deviate an identityref to a subset of
identity values supported by an implementation, we would have solved a
more generic problem. Yes, the IANA list could be 'nicer' but it will
never be 'nice'.

/js

On Fri, Apr 06, 2018 at 08:12:03AM +, Bogaert, Bart (Nokia - BE/Antwerp) 
wrote:
> Alex,
> 
> Not sure if this only has to do with "practical limitations providing a CLI 
> interface"...   In a machine-to-machine interface this is less of a problem 
> but in a human-to-machine interface it seems a bit impractical to me to find 
> a solution for a problem to scroll through a list of 100+ completions if an 
> operator would ask for the possible completion in case he does not know what 
> to provide as input.  There are ways to limit this output but it can be 
> solved on a modelling level as well.  As I indicated identities can be 
> conditional to a feature and if implementations choose not to implement a set 
> of interface-type related features the list becomes (a whole lot) shorter "by 
> itself".  Now iana-if-type is just a collection of all interface types that 
> have been defined once without any kind of "structure".
> 
> Regards, Bart
> 
> -Original Message-
> From: Ladislav Lhotka [mailto:lho...@nic.cz] 
> Sent: Friday, April 6, 2018 9:55 AM
> To: Alex Campbell ; Bogaert, Bart (Nokia - 
> BE/Antwerp) ; netmod@ietf.org
> Subject: Re: [netmod] An abundant amount of IANA if types...
> 
> Hi,
> 
> I have argued several times in the past that the IANA interface list (and, 
> for that matter, the iana-if-type module) is a useless pile of rubbish because
> 
> - for some interface classes (Ethernet, tunnels) it is way too coarse-grained
> 
> - on the other hand, it contains a lot of stuff that nobody will ever use
> 
> - using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for 
> Ethernet is outright stupid
> 
> - YANG identities allow for encoding important relationships in interface 
> types,in the flat list all this information is lost 
> 
> - as you say, implementing the iana-if-type module means that all interface 
> types listed therein become valid.
> 
> So yes, I do believe that it would be useful if authoritative expert groups 
> develop a better structure of interface type identities.
> 
> Lada
>   
> On Thu, 2018-04-05 at 23:59 +, Alex Campbell wrote:
> > I haven't seen any previous discussions on the topic, but we have a 
> > similar problem.
> > Note this is not really to do with YANG itself, so much as the 
> > practical limitations of the software package that provides our CLI 
> > interface.
> > In NETCONF, the existence of extra unused identities doesn't pose any 
> > problem.
> > 
> > From: netmod  on behalf of Bogaert, Bart 
> > (Nokia -
> > BE/Antwerp) 
> > Sent: Thursday, 5 April 2018 8:21 p.m.
> > To: netmod@ietf.org
> > Subject: [netmod] An abundant amount of IANA if types...
> >  
> > Hi,
> >  
> > We were wondering if it would make sense to introduce features in the 
> > IANA if types YANG model to enable grouping of related interface 
> > types.  This would allow implementations to include only the types it 
> > really requires (by supporting the related features but not the 
> > others) and (in case of a CLI
> > interface) would reduce the possible completions if an operator would 
> > ask for the possible values of the type of an interface.
> > Has this ever been considered/discussed?
> >  
> > Best regards,
> > Bart
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> ___
> 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] An abundant amount of IANA if types...

[Bogaert, Bart (Nokia - BE/Antwerp)]

Alex,

Not sure if this only has to do with "practical limitations providing a CLI 
interface"...   In a machine-to-machine interface this is less of a problem but 
in a human-to-machine interface it seems a bit impractical to me to find a 
solution for a problem to scroll through a list of 100+ completions if an 
operator would ask for the possible completion in case he does not know what to 
provide as input.  There are ways to limit this output but it can be solved on 
a modelling level as well.  As I indicated identities can be conditional to a 
feature and if implementations choose not to implement a set of interface-type 
related features the list becomes (a whole lot) shorter "by itself".  Now 
iana-if-type is just a collection of all interface types that have been defined 
once without any kind of "structure".

Regards, Bart

-Original Message-
From: Ladislav Lhotka [mailto:lho...@nic.cz] 
Sent: Friday, April 6, 2018 9:55 AM
To: Alex Campbell ; Bogaert, Bart (Nokia - 
BE/Antwerp) ; netmod@ietf.org
Subject: Re: [netmod] An abundant amount of IANA if types...

Hi,

I have argued several times in the past that the IANA interface list (and, for 
that matter, the iana-if-type module) is a useless pile of rubbish because

- for some interface classes (Ethernet, tunnels) it is way too coarse-grained

- on the other hand, it contains a lot of stuff that nobody will ever use

- using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for Ethernet 
is outright stupid

- YANG identities allow for encoding important relationships in interface 
types,in the flat list all this information is lost 

- as you say, implementing the iana-if-type module means that all interface 
types listed therein become valid.

So yes, I do believe that it would be useful if authoritative expert groups 
develop a better structure of interface type identities.

Lada
  
On Thu, 2018-04-05 at 23:59 +, Alex Campbell wrote:
> I haven't seen any previous discussions on the topic, but we have a 
> similar problem.
> Note this is not really to do with YANG itself, so much as the 
> practical limitations of the software package that provides our CLI interface.
> In NETCONF, the existence of extra unused identities doesn't pose any problem.
> 
> From: netmod  on behalf of Bogaert, Bart 
> (Nokia -
> BE/Antwerp) 
> Sent: Thursday, 5 April 2018 8:21 p.m.
> To: netmod@ietf.org
> Subject: [netmod] An abundant amount of IANA if types...
>  
> Hi,
>  
> We were wondering if it would make sense to introduce features in the 
> IANA if types YANG model to enable grouping of related interface 
> types.  This would allow implementations to include only the types it 
> really requires (by supporting the related features but not the 
> others) and (in case of a CLI
> interface) would reduce the possible completions if an operator would 
> ask for the possible values of the type of an interface.
> Has this ever been considered/discussed?
>  
> Best regards,
> Bart
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] An abundant amount of IANA if types...

[Martin Bjorklund]

Ladislav Lhotka  wrote:
> Hi,
> 
> I have argued several times in the past that the IANA interface list (and, for
> that matter, the iana-if-type module) is a useless pile of rubbish because
> 
> - for some interface classes (Ethernet, tunnels) it is way too coarse-grained
> 
> - on the other hand, it contains a lot of stuff that nobody will ever use
> 
> - using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for Ethernet
> is outright stupid
> 
> - YANG identities allow for encoding important relationships in interface 
> types,in the flat list all this information is lost 
> 
> - as you say, implementing the iana-if-type module means that all interface
> types listed therein become valid.
> 
> So yes, I do believe that it would be useful if authoritative expert groups
> develop a better structure of interface type identities.

I agree.  At the time when we did ietf-interfaces, not many people had
experience with using identities; and we didn't have YANG 1.1.  So we
just used what we had in the MIB, but as identities.  Now that we have
much more experience, it would be great to build a better way to
identify interfaces and their properties.



/martin



> 
> Lada
>   
> On Thu, 2018-04-05 at 23:59 +, Alex Campbell wrote:
> > I haven't seen any previous discussions on the topic, but we have a similar
> > problem.
> > Note this is not really to do with YANG itself, so much as the practical
> > limitations of the software package that provides our CLI interface.
> > In NETCONF, the existence of extra unused identities doesn't pose any 
> > problem.
> > 
> > From: netmod  on behalf of Bogaert, Bart (Nokia -
> > BE/Antwerp) 
> > Sent: Thursday, 5 April 2018 8:21 p.m.
> > To: netmod@ietf.org
> > Subject: [netmod] An abundant amount of IANA if types...
> >  
> > Hi,
> >  
> > We were wondering if it would make sense to introduce features in the IANA 
> > if
> > types YANG model to enable grouping of related interface types.  This would
> > allow implementations to include only the types it really requires (by
> > supporting the related features but not the others) and (in case of a CLI
> > interface) would reduce the possible completions if an operator would ask 
> > for
> > the possible values of the type of an interface.
> > Has this ever been considered/discussed?
> >  
> > Best regards,
> > Bart
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> 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] An abundant amount of IANA if types...

[Ladislav Lhotka]

Hi,

I have argued several times in the past that the IANA interface list (and, for
that matter, the iana-if-type module) is a useless pile of rubbish because

- for some interface classes (Ethernet, tunnels) it is way too coarse-grained

- on the other hand, it contains a lot of stuff that nobody will ever use

- using the cabalistic (and wrong, in fact) name "ethernetCsmacd" for Ethernet
is outright stupid

- YANG identities allow for encoding important relationships in interface 
types,in the flat list all this information is lost 

- as you say, implementing the iana-if-type module means that all interface
types listed therein become valid.

So yes, I do believe that it would be useful if authoritative expert groups
develop a better structure of interface type identities.

Lada
  
On Thu, 2018-04-05 at 23:59 +, Alex Campbell wrote:
> I haven't seen any previous discussions on the topic, but we have a similar
> problem.
> Note this is not really to do with YANG itself, so much as the practical
> limitations of the software package that provides our CLI interface.
> In NETCONF, the existence of extra unused identities doesn't pose any problem.
> 
> From: netmod  on behalf of Bogaert, Bart (Nokia -
> BE/Antwerp) 
> Sent: Thursday, 5 April 2018 8:21 p.m.
> To: netmod@ietf.org
> Subject: [netmod] An abundant amount of IANA if types...
>  
> Hi,
>  
> We were wondering if it would make sense to introduce features in the IANA if
> types YANG model to enable grouping of related interface types.  This would
> allow implementations to include only the types it really requires (by
> supporting the related features but not the others) and (in case of a CLI
> interface) would reduce the possible completions if an operator would ask for
> the possible values of the type of an interface.
> Has this ever been considered/discussed?
>  
> Best regards,
> Bart
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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