Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts

[William Lupton]

Andy,

This thread started with discussion of an apparent ambiguity in the current 
text:

OLD

It is acceptable to reuse the same revision statement within unpublished 
versions (i.e., Internet-Drafts), but the revision date MUST be updated to a 
higher value each time the Internet-Draft is re-posted.

—— 

It became clear from the subsequent discussion (thanks Randy!) that the above 
text isn’t intended to mean “reuse the identical revision statement, INCLUDING 
THE REVISION DATE” but to mean “reuse the revision statement, UPDATING THE 
REVISION DATE”.

Then other people raised other points, e.g only updating the revision date if 
the YANG has changed, distinguishing between the document and the YANG 
contained therein, and distinguishing between YANG in IDs and YANG created by 
other SDOs. My proposed new text tries to address all of these:

NEW:

It is not required to keep the full revision history of draft versions (e.g., 
modules contained within Internet-Drafts). That is, within a sequence of draft 
versions, only the most recent revision need be recorded in the module. 
However, if the module has changed, the revision date of the most recent 
revision MUST be updated to a later date whenever a new version is made 
available (e.g., via a new version of an Internet-Draft).

——

I believe that this retains the original intent in a way that resolves the 
original ambiguity and addresses the other points that were raised. It it’s 
“worse”, how is it worse (apart from being longer, on which point mea culpa)?

Thanks,
William

> On 19 Aug 2016, at 15:42, Andy Bierman  wrote:
> 
> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley  > wrote:
> Andy Bierman > writes:
> > An Internet-Draft is NOT a means of "publishing" a specification;
> 
> As I said, that's the theory, but practice is considerably different.
> 
> Anybody that implements a work-in-progress knows they are taking a risk
> on an unstable document.  The guideline already says MUST update
> the revision date.
> 
> Not sure what more you want to guidelines document to do.
>  
> Dale
> 
> Andy
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] derived-from-or-self leads to circular import

[Ladislav Lhotka]

> On 29 Aug 2016, at 12:42, William Lupton  wrote:
> 
> Regardless of whether circular import is permitted, isn’t it best avoided 
> from a layering point of view? In general I would think that a module should 
> be importing things that (a) it needs, and (b) don’t need it. W.

If possible, yes. However, not everything is strictly layered, sometimes it 
might be useful to put definitions into separate modules even if they are 
coupled in both directions.

Where cyclic references would be really harmful (groupings, identities), YANG 
spec excludes them explicitly - because they are harmful within the same 
module, too.

Lada

> 
>> On 29 Aug 2016, at 11:34, Ladislav Lhotka  wrote:
>> 
>>> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE) 
>>>  wrote:
>>> 
>>> Just taking another approach on this: why do we have the restriction on
>>> circular imports?  Is this really required?  If not then this may be solved
>>> in another way too (but will take some time before it gets into the YANG
>>> compilers I'm afraid).
>> 
>> In fact, it isn't really needed. Unlike imports in programming languages 
>> such as Python, import in YANG doesn't incorporate the imported module 
>> contents, just gives access to objects in a foreign namespace.

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

Re: [netmod] derived-from-or-self leads to circular import

[Bogaert, Bart (Nokia - BE)]

> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE)
 wrote:
> 
> Just taking another approach on this: why do we have the restriction 
> on circular imports?  Is this really required?  If not then this may 
> be solved in another way too (but will take some time before it gets 
> into the YANG compilers I'm afraid).

In fact, it isn't really needed. Unlike imports in programming languages
such as Python, import in YANG doesn't incorporate the imported module
contents, just gives access to objects in a foreign namespace.


[Bart Bogaert] This comes from RFC6020bis (and I guess it’s in RFC6020 too):
There MUST NOT be any circular chains of imports. For example, if
module "a" imports module "b", "b" cannot import "a".

If this restriction is not really needed then why do we have that
restriction stated as such in the RFC?  The ConfD compiler reports exactly
this failure when trying to compile the IETF entity model for YANG 1.1
(tried 6.2 Confd-basic which can be obtained freely).  iana-entity.yang
imports ietf-entity (for the entity-physical-class identity) and
ietf-entity.yang imports iana-entity for the sensor identity - well that is
after changing the ietf-entiy model to also fix the error that the
derived-from-or-self function only has 2 parameters instead of 3 as
currently in the YANG models (the call to derived-from-or-self checks the
class leaf for "ent:sensor").  Fact is that the way the IETF/IANA entity
model is now defined in YANG results in something that results in
compilation errors and we need something that compiles error-free, meaning
we have to modify the iana and ietf-entity YANG model in some way.

Bart

Lada

> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data Contact number +32 3 2408310 
> (+32 477 673952)
> 
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 
> 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential 
> information intended for a specific individual and purpose, and is 
> protected by law. If you are not the intended recipient, you should 
> delete this message. Any disclosure, copying, or distribution of this 
> message, or the taking of any action based on it, is strictly 
> prohibited without the prior consent of its author.
>>> 
> 
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: 26 August 2016 14:33
> To: j.schoenwael...@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
> 
> Juergen Schoenwaelder  wrote:
>> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder  wrote:
 On Fri, Jul 29, 2016 at 12:50:13PM +, Bogaert, Bart (Nokia - 
 BE)
> wrote:
 
 [...]
 
> In order to correctly compile (using confdc) we also need to 
> import iana-entity for the identities defined in there.  However 
> this is leading a circular dependency:
> 
> 1.   Iana-entity imports ietf-entity (to 'resolve'
> entity-physical-class)
> 
> 2.   Ietf-entity imports iana-entity (to obtain the indentities
> defined
> in there)
> 
> One way to solve this is to move the definition of 
> entity-physical-class from ietf-entity to iana-entity which would 
> resolve the fact that iana-entity requires an import of 
> ietf-entity (ietf-entity needs to import iana-entity anyhow, so it 
> can also pick the typedef from the same module too).
 
 I think moving the definition of entity-physical-class into 
 iana-entity makes sense.
>>> 
>>> Ok.  It feels a bit backwards to me though, but I can see the value 
>>> of having the iana module self-contained.
>>> 
>> 
>> Well, it may look backwards if people want to reuse the base identity 
>> but none of the IANA assigned identities - but then it might be good 
>> if people at least look at IANA assigned identities. Or are there 
>> other reasons why you think this may be looking 'backwards'?
> 
> I makes ietf-entity dependent on iana-entity, since the base identity 
> is defined in iana-entity.
> 
> But OTOH, even if we solved that, ietf-entity is dependent on 
> iana-entity b/c of the value 'sensor'.
> 
> So in this case it is probably fine, but I'm not sure about the 
> general idea.
> 
> 
> /martin
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C






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

Re: [netmod] Design-Time schema mount

[Balazs Lengyel]

  
  
Hello Andy,
Martin's main problem was that we would need to update the
  original modules if the mount changes. I showed that design-time
  mount can be defined without modifying the original modules, if
  you specify the mount information in a separate file. So what
  specific problems are you concerned about?
I do not want to make schema-mount a purely design-time solution.
  However I feel that the ability to define the mounts in design
  time is an important use-case that does not cause any problems.

regards Balazs


On 2016-08-26 19:53, Andy Bierman
  wrote:


  
  Hi,


I agree with Martin about not specifying which YANG modules
can be mounted under some mount point, in the YANG module.


The mount point needs some basic properties (like "config
  root", "opstate root", whatever).
Then data nodes are classified somehow (e.g.
  config=true/false) and that determines
what content can be mounted under that mount-point.


The combination of modules on the server needs to be a
  deployment decision to
prevent issues like Martin describes below.




Andy


  
  
On Fri, Aug 26, 2016 at 5:38 AM, Martin
  Bjorklund 
  wrote:
  Ladislav
Lhotka  wrote:
> Martin Bjorklund 
writes:
>
> > Hi,
> >
> > [replying to the first post in this (old) thread;
the thread got a bit
> > off-topic]
> >
> > Balazs Lengyel 
wrote:
> >> Hello,
> >>
> >> As I understand it, Schema-mount today does
not support an important
> >> use-case which we definitely need, but others
also indicated they
> >> want.
> >>
> >> I want to specify off-line in design time
which models will be mounted
> >> where. Many of my nodes know in design-time
what their model structure
> >> will be, so I want a way to be able to
document this in YANG.
> >
> > I'd like to understand this use case in more
detail.  You say that
> > that a "node knows in design-time" that YANG
models it will use.  Thus
> > it seems natural to be able to specify which other
modules to mount in
> > the YANG module itself.
>
> Did you have a chance to look into my slides from
Berlin? I sketched some
> solutions there.

Well, that's a *solution*.  I'd like to understand the
*problem* first ;)

> > The problem I see with this is that it is very
limited to the use case
> > where each implementation defines its own YANG
modules.  Suppose you
> > have such a model, for example:
> >
> >    module A {
> >      ...
> >      mount ... {
> >        mount-module B;
> >        mount-module C;
> >      }
> >   }
> >
> > [pseudo-code for module A that specifies that it
mounts B and C]
> >
> > Now, suppose you take this module A to another
implementation, and it
> > needs to augment something into module C;
essentially this means that
> > it would like to mount B, C and new module D. 
 This will not be
> > possible unless it modifies module A.
>
> Not necessarily, D could contain an augment with a
target specified by a
> schema node identifier that uses nodes from both A and
C.

Not if B and D are defined as standalone modules, e.g. if B
is
ietf-interfaces and D is ietf-ip.

> Imagine that instead of "ietf-ip" augmenting
"ietf-interfaces" it would
> be the other way around: "ietf-interfaces" mounts
"ietf-ip". Then the
> augment in ietf-ipv6-router-advertisements
>
>   augment "/if:interfaces-state/if:interface/ip:ipv6"
{ ... }
>
> needn't be changed.

This would be an entirely different kind of mount!  The
current mount
doesn't work like that; it doesn't give you visibility into
the
combined models - by design.

Re: [netmod] derived-from-or-self leads to circular import

[William Lupton]

Regardless of whether circular import is permitted, isn’t it best avoided from 
a layering point of view? In general I would think that a module should be 
importing things that (a) it needs, and (b) don’t need it. W.

> On 29 Aug 2016, at 11:34, Ladislav Lhotka  wrote:
> 
>> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE) 
>>  wrote:
>> 
>> Just taking another approach on this: why do we have the restriction on
>> circular imports?  Is this really required?  If not then this may be solved
>> in another way too (but will take some time before it gets into the YANG
>> compilers I'm afraid).
> 
> In fact, it isn't really needed. Unlike imports in programming languages such 
> as Python, import in YANG doesn't incorporate the imported module contents, 
> just gives access to objects in a foreign namespace.

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

Re: [netmod] derived-from-or-self leads to circular import

[Ladislav Lhotka]

> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE)  
> wrote:
> 
> Just taking another approach on this: why do we have the restriction on
> circular imports?  Is this really required?  If not then this may be solved
> in another way too (but will take some time before it gets into the YANG
> compilers I'm afraid).

In fact, it isn't really needed. Unlike imports in programming languages such 
as Python, import in YANG doesn't incorporate the imported module contents, 
just gives access to objects in a foreign namespace.

Lada

> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data
> Contact number +32 3 2408310 (+32 477 673952)
> 
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium
> Fortis 220-0002334-42
> VAT BE 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential information
> intended for a specific individual and purpose, and is protected by law. If
> you are not the intended recipient, you should delete this message. Any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited without the prior consent of its
> author.
>>> 
> 
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: 26 August 2016 14:33
> To: j.schoenwael...@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
> 
> Juergen Schoenwaelder  wrote:
>> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder  wrote:
 On Fri, Jul 29, 2016 at 12:50:13PM +, Bogaert, Bart (Nokia - BE)
> wrote:
 
 [...]
 
> In order to correctly compile (using confdc) we also need to
> import iana-entity for the identities defined in there.  However
> this is leading a circular dependency:
> 
> 1.   Iana-entity imports ietf-entity (to 'resolve'
> entity-physical-class)
> 
> 2.   Ietf-entity imports iana-entity (to obtain the indentities
> defined
> in there)
> 
> One way to solve this is to move the definition of
> entity-physical-class from ietf-entity to iana-entity which
> would resolve the fact that iana-entity requires an import of
> ietf-entity (ietf-entity needs to import iana-entity anyhow, so
> it can also pick the typedef from the same module too).
 
 I think moving the definition of entity-physical-class into
 iana-entity makes sense.
>>> 
>>> Ok.  It feels a bit backwards to me though, but I can see the value
>>> of having the iana module self-contained.
>>> 
>> 
>> Well, it may look backwards if people want to reuse the base identity
>> but none of the IANA assigned identities - but then it might be good
>> if people at least look at IANA assigned identities. Or are there
>> other reasons why you think this may be looking 'backwards'?
> 
> I makes ietf-entity dependent on iana-entity, since the base identity is
> defined in iana-entity.
> 
> But OTOH, even if we solved that, ietf-entity is dependent on iana-entity
> b/c of the value 'sensor'.
> 
> So in this case it is probably fine, but I'm not sure about the general
> idea.
> 
> 
> /martin
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

"Bogaert, Bart (Nokia - BE)"  wrote:
> Hi Martin,
> 
> In BBF this pointer from HW to interface will be available (it has 
> been proposed in the Berling BBF meeting already).

I assume this is done as an augmentation?  Is it an augmentation to the
interface list, or to the hardware list?  I.e., is it a pointer from an
interface to the hardware, or the other way around?
[Bart Bogaert] It is an augmentation to the hardware list

Bart

I would prefer to view the hardware list as just monitoring (config
false) [1], and have config true pointers from the higher-level concepts
back to the hardware [2].  Possibly with config false back-pointers.

[1] this doesn't preclude the config true list in current ietf-entity.

[2] this pointer is (as noted) often implicit in the interface name today.


/martin





> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data Contact number +32 3 2408310 
> (+32 477 673952)
> 
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 
> 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential 
> information intended for a specific individual and purpose, and is 
> protected by law. If you are not the intended recipient, you should 
> delete this message. Any disclosure, copying, or distribution of this 
> message, or the taking of any action based on it, is strictly 
> prohibited without the prior consent of its author.
> >> 
> 
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: 29 August 2016 11:06
> To: Bogaert, Bart (Nokia - BE)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] BBF extensions to ietf-entity
> 
> Hi,
> 
> [We had mail server problems during the weekend, so this reply might 
> not get the thread's history right.]
> 
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > Martin Bjorklund  wrote:
> > "Bogaert, Bart (Nokia - BE)"  wrote:
> > > I would like to bring this to the ietf-entity group.  Currently 
> > > BBF is proposing to add new RW leafs to the entity object.  This 
> > > is done in the context of plugable entities and hence it means 
> > > that when an operator (via a NC client) configures a plugable item 
> > > it is required to define the entity type.  For this reason 
> > > additional RW attributes are needed.  Two of the new leafs are 
> > > class and contained-in (same as
> the RO class leaf).
> > > 
> > > -  class: we think that the class leaf needs to be mandatory
but
> > > adding this via an augment is not possible as we can't add a 
> > > mandatory leaf via an augment.  Making class implicit for the 
> > > client based on "some information" exchanged between device 
> > > vendors and management applications is maybe not such a sound
approach.
> > 
> > Can you explain in more detail how this would be used?  The idea is 
> > that 'class' is a property of the physical hw, and that the 
> > underlying system provides this info.  I can see that it could be 
> > useful for the client to set this if the system can't do the 
> > classification (i.e., the system-set value is 'unknown').  But 
> > that's probably not the use case you had in mind?
> > 
> > [Bart Bogaert] Assume you have a system with a number of slots that 
> > can hold several different cards and the system was deployed in the 
> > field with some cards inserted and some other slots that were still 
> > left empty.  When an operator wants to extend the system we can have 
> > 2
> ways of doing this:
> > 1. a field engineer goes 'on-site' and plugs cards in the system.  
> > If done this way, the system itself can detect what has been 
> > inserted and we do not really need the RW leafs.  However in this 
> > case an operator has to wait configuring user services on these 
> > cards until they are
> inserted.
> > 2. the network operator determines that a node will "run out" of 
> > available ports and hence wants to start planning new configuration 
> > and hence he wants to configure some boards in the empty slots and 
> > even may want to start to pre-configure certain data of the ports 
> > contained by these boards.  In that case we need the RW leaf to 
> > indicate which board type will be inserted as the service that can 
> > be offered depends on the board being inserted.  When the board is 
> > inserted, the planned configuration can directly be applied to the 
> > newly inserted board (given the fact that the detected class is the 
> > same
> as the planned class).
> 
> Shouldn't this be handled by the support for pre-configuration in the 
> interfaces data model?  I.e., the general model would be that the 
> entity/hardware list is monitoring of the hardware that is really 
> present, and other models that need to refer to this hardware (like
> interfaces) support pre-configuration.
> 
> The interface model lacks an explicit 

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

"Bogaert, Bart (Nokia - BE)"  wrote:
> Hi Martin,
> 
> In BBF this pointer from HW to interface will be available (it has been
> proposed in the Berling BBF meeting already).

I assume this is done as an augmentation?  Is it an augmentation to
the interface list, or to the hardware list?  I.e., is it a pointer
from an interface to the hardware, or the other way around?

I would prefer to view the hardware list as just monitoring (config
false) [1], and have config true pointers from the higher-level
concepts back to the hardware [2].  Possibly with config false
back-pointers.

[1] this doesn't preclude the config true list in current ietf-entity.

[2] this pointer is (as noted) often implicit in the interface name
today.


/martin





> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data
> Contact number +32 3 2408310 (+32 477 673952)
> 
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium
> Fortis 220-0002334-42
> VAT BE 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential information
> intended for a specific individual and purpose, and is protected by law. If
> you are not the intended recipient, you should delete this message. Any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited without the prior consent of its
> author.
> >> 
> 
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com] 
> Sent: 29 August 2016 11:06
> To: Bogaert, Bart (Nokia - BE)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] BBF extensions to ietf-entity
> 
> Hi,
> 
> [We had mail server problems during the weekend, so this reply might not get
> the thread's history right.]
> 
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > Martin Bjorklund  wrote:
> > "Bogaert, Bart (Nokia - BE)"  wrote:
> > > I would like to bring this to the ietf-entity group.  Currently BBF 
> > > is proposing to add new RW leafs to the entity object.  This is done 
> > > in the context of plugable entities and hence it means that when an 
> > > operator (via a NC client) configures a plugable item it is required 
> > > to define the entity type.  For this reason additional RW attributes 
> > > are needed.  Two of the new leafs are class and contained-in (same as
> the RO class leaf).
> > > 
> > > -  class: we think that the class leaf needs to be mandatory but
> > > adding this via an augment is not possible as we can't add a 
> > > mandatory leaf via an augment.  Making class implicit for the client 
> > > based on "some information" exchanged between device vendors and 
> > > management applications is maybe not such a sound approach.
> > 
> > Can you explain in more detail how this would be used?  The idea is 
> > that 'class' is a property of the physical hw, and that the underlying 
> > system provides this info.  I can see that it could be useful for the 
> > client to set this if the system can't do the classification (i.e., 
> > the system-set value is 'unknown').  But that's probably not the use 
> > case you had in mind?
> > 
> > [Bart Bogaert] Assume you have a system with a number of slots that 
> > can hold several different cards and the system was deployed in the 
> > field with some cards inserted and some other slots that were still 
> > left empty.  When an operator wants to extend the system we can have 2
> ways of doing this:
> > 1. a field engineer goes 'on-site' and plugs cards in the system.  If 
> > done this way, the system itself can detect what has been inserted and 
> > we do not really need the RW leafs.  However in this case an operator 
> > has to wait configuring user services on these cards until they are
> inserted.
> > 2. the network operator determines that a node will "run out" of 
> > available ports and hence wants to start planning new configuration 
> > and hence he wants to configure some boards in the empty slots and 
> > even may want to start to pre-configure certain data of the ports 
> > contained by these boards.  In that case we need the RW leaf to 
> > indicate which board type will be inserted as the service that can be 
> > offered depends on the board being inserted.  When the board is 
> > inserted, the planned configuration can directly be applied to the 
> > newly inserted board (given the fact that the detected class is the same
> as the planned class).
> 
> Shouldn't this be handled by the support for pre-configuration in the
> interfaces data model?  I.e., the general model would be that the
> entity/hardware list is monitoring of the hardware that is really present,
> and other models that need to refer to this hardware (like
> interfaces) support pre-configuration.
> 
> The interface model lacks an explicit pointer to the entity/hardware model;
> but in many systems this reference is implicit in the name of 

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

Hi Martin,

In BBF this pointer from HW to interface will be available (it has been
proposed in the Berling BBF meeting already).

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.
>> 


-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: 29 August 2016 11:06
To: Bogaert, Bart (Nokia - BE)
Cc: netmod@ietf.org
Subject: Re: [netmod] BBF extensions to ietf-entity

Hi,

[We had mail server problems during the weekend, so this reply might not get
the thread's history right.]

"Bogaert, Bart (Nokia - BE)"  wrote:
> Martin Bjorklund  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > I would like to bring this to the ietf-entity group.  Currently BBF 
> > is proposing to add new RW leafs to the entity object.  This is done 
> > in the context of plugable entities and hence it means that when an 
> > operator (via a NC client) configures a plugable item it is required 
> > to define the entity type.  For this reason additional RW attributes 
> > are needed.  Two of the new leafs are class and contained-in (same as
the RO class leaf).
> > 
> > -  class: we think that the class leaf needs to be mandatory but
> > adding this via an augment is not possible as we can't add a 
> > mandatory leaf via an augment.  Making class implicit for the client 
> > based on "some information" exchanged between device vendors and 
> > management applications is maybe not such a sound approach.
> 
> Can you explain in more detail how this would be used?  The idea is 
> that 'class' is a property of the physical hw, and that the underlying 
> system provides this info.  I can see that it could be useful for the 
> client to set this if the system can't do the classification (i.e., 
> the system-set value is 'unknown').  But that's probably not the use 
> case you had in mind?
> 
> [Bart Bogaert] Assume you have a system with a number of slots that 
> can hold several different cards and the system was deployed in the 
> field with some cards inserted and some other slots that were still 
> left empty.  When an operator wants to extend the system we can have 2
ways of doing this:
> 1. a field engineer goes 'on-site' and plugs cards in the system.  If 
> done this way, the system itself can detect what has been inserted and 
> we do not really need the RW leafs.  However in this case an operator 
> has to wait configuring user services on these cards until they are
inserted.
> 2. the network operator determines that a node will "run out" of 
> available ports and hence wants to start planning new configuration 
> and hence he wants to configure some boards in the empty slots and 
> even may want to start to pre-configure certain data of the ports 
> contained by these boards.  In that case we need the RW leaf to 
> indicate which board type will be inserted as the service that can be 
> offered depends on the board being inserted.  When the board is 
> inserted, the planned configuration can directly be applied to the 
> newly inserted board (given the fact that the detected class is the same
as the planned class).

Shouldn't this be handled by the support for pre-configuration in the
interfaces data model?  I.e., the general model would be that the
entity/hardware list is monitoring of the hardware that is really present,
and other models that need to refer to this hardware (like
interfaces) support pre-configuration.

The interface model lacks an explicit pointer to the entity/hardware model;
but in many systems this reference is implicit in the name of the interface.


/martin



> There are customers using method 1 and other customers use method 2.
> 
> > -  contained-in: for plugable items contained-in requires to be
> > mandatory too as a plugable item can't be "floating" in the device.
> 
> Can you explain in more detail what this means, and provide some use 
> cases?
>
> [Bart Bogaert] For DSL we are faced with "wiring" aspects that "ripple 
> through" to the MDF.  So assume we again have a system with plugable
slots.
> If we have 2 slots containing the same type of board (same class) and 
> the operator is applying the pre-configuration mode of working (method 
> 2 in above), we have to be sure that user A, connected to the first 
> port of the board plugged in the first slot will really be in slot 1.  
> If the NC client has no means 

Re: [netmod] BBF extensions to ietf-entity

[Martin Bjorklund]

Hi,

[We had mail server problems during the weekend, so this reply might
not get the thread's history right.]

"Bogaert, Bart (Nokia - BE)"  wrote:
> Martin Bjorklund  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > I would like to bring this to the ietf-entity group.  Currently BBF is
> > proposing to add new RW leafs to the entity object.  This is done in the
> > context of plugable entities and hence it means that when an operator (via a
> > NC client) configures a plugable item it is required to define the entity
> > type.  For this reason additional RW attributes are needed.  Two of the new
> > leafs are class and contained-in (same as the RO class leaf). 
> > 
> > -  class: we think that the class leaf needs to be mandatory but
> > adding this via an augment is not possible as we can't add a mandatory leaf
> > via an augment.  Making class implicit for the client based on "some
> > information" exchanged between device vendors and management applications is
> > maybe not such a sound approach.
> 
> Can you explain in more detail how this would be used?  The idea is
> that 'class' is a property of the physical hw, and that the underlying
> system provides this info.  I can see that it could be useful for the
> client to set this if the system can't do the classification (i.e.,
> the system-set value is 'unknown').  But that's probably not the use
> case you had in mind?
> 
> [Bart Bogaert] Assume you have a system with a number of slots that can hold
> several different cards and the system was deployed in the field with some
> cards inserted and some other slots that were still left empty.  When an
> operator wants to extend the system we can have 2 ways of doing this:
> 1. a field engineer goes 'on-site' and plugs cards in the system.  If done
> this way, the system itself can detect what has been inserted and we do not
> really need the RW leafs.  However in this case an operator has to wait
> configuring user services on these cards until they are inserted.
> 2. the network operator determines that a node will "run out" of available
> ports and hence wants to start planning new configuration and hence he wants
> to configure some boards in the empty slots and even may want to start to
> pre-configure certain data of the ports contained by these boards.  In that
> case we need the RW leaf to indicate which board type will be inserted as
> the service that can be offered depends on the board being inserted.  When
> the board is inserted, the planned configuration can directly be applied to
> the newly inserted board (given the fact that the detected class is the same
> as the planned class).

Shouldn't this be handled by the support for pre-configuration in the
interfaces data model?  I.e., the general model would be that the
entity/hardware list is monitoring of the hardware that is really
present, and other models that need to refer to this hardware (like
interfaces) support pre-configuration.

The interface model lacks an explicit pointer to the entity/hardware
model; but in many systems this reference is implicit in the name of
the interface.


/martin



> There are customers using method 1 and other customers use method 2.
> 
> > -  contained-in: for plugable items contained-in requires to be
> > mandatory too as a plugable item can't be "floating" in the device.
> 
> Can you explain in more detail what this means, and provide some use
> cases?
>
> [Bart Bogaert] For DSL we are faced with "wiring" aspects that "ripple
> through" to the MDF.  So assume we again have a system with plugable slots.
> If we have 2 slots containing the same type of board (same class) and the
> operator is applying the pre-configuration mode of working (method 2 in
> above), we have to be sure that user A, connected to the first port of the
> board plugged in the first slot will really be in slot 1.  If the NC client
> has no means to detect which board is plugged in which slot (they are both
> of the same class) we need other means to ensure the containment is as
> intended (and user A being connected to the first port of the board in slot
> A is also visualized as such on the GUI of the NC client).  Using the serial
> number of the board seems not very practical as board may break and are sent
> to repair or replaced by another board of the same type but with a different
> serial number.  I do not think operators will like it a lot to manage a
> system in a manual way based on these attributes hence also a need to plan a
> board in a specific slot.

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

Re: [netmod] derived-from-or-self leads to circular import

[Bogaert, Bart (Nokia - BE)]

"Reorganization" of the modules as they are currently defined in IETF is
required in order to avoid the "circular import" error reported by the ConfD
compiler (e.g. confdc of TailF).  I guess that when we remove this
restriction (as far as I remember, a #include equivalent is possible in
C/C++) then at least the modules compile in its current form (that means
after correcting the calls to derived-from-or-self to having only parameters
instead of 3 as they are currently defined in the IETF modules).  I agree
that this is not related to the comment made whether re-organizing
iana-entities in such a way that it defines the identity (rather then
importing it from ietf-entity).

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.
>> 


-Original Message-
From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: 29 August 2016 09:27
To: Bogaert, Bart (Nokia - BE)
Cc: Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import

I fail to see what this thread has to do with circular imports.

/js

On Mon, Aug 29, 2016 at 07:17:58AM +, Bogaert, Bart (Nokia - BE) wrote:
> Just taking another approach on this: why do we have the restriction 
> on circular imports?  Is this really required?  If not then this may 
> be solved in another way too (but will take some time before it gets 
> into the YANG compilers I'm afraid).
> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data Contact number +32 3 2408310 
> (+32 477 673952)
> 
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 
> 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential 
> information intended for a specific individual and purpose, and is 
> protected by law. If you are not the intended recipient, you should 
> delete this message. Any disclosure, copying, or distribution of this 
> message, or the taking of any action based on it, is strictly 
> prohibited without the prior consent of its author.
> >> 
> 
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com]
> Sent: 26 August 2016 14:33
> To: j.schoenwael...@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
> 
> Juergen Schoenwaelder  wrote:
> > On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Fri, Jul 29, 2016 at 12:50:13PM +, Bogaert, Bart (Nokia - 
> > > > BE)
> wrote:
> > > > 
> > > > [...]
> > > >  
> > > > > In order to correctly compile (using confdc) we also need to 
> > > > > import iana-entity for the identities defined in there.  
> > > > > However this is leading a circular dependency:
> > > > > 
> > > > > 1.   Iana-entity imports ietf-entity (to 'resolve'
> > > > > entity-physical-class)
> > > > > 
> > > > > 2.   Ietf-entity imports iana-entity (to obtain the
indentities
> defined
> > > > > in there)
> > > > > 
> > > > > One way to solve this is to move the definition of 
> > > > > entity-physical-class from ietf-entity to iana-entity which 
> > > > > would resolve the fact that iana-entity requires an import of 
> > > > > ietf-entity (ietf-entity needs to import iana-entity anyhow, 
> > > > > so it can also pick the typedef from the same module too).
> > > > 
> > > > I think moving the definition of entity-physical-class into 
> > > > iana-entity makes sense.
> > > 
> > > Ok.  It feels a bit backwards to me though, but I can see the 
> > > value of having the iana module self-contained.
> > >
> > 
> > Well, it may look backwards if people want to reuse the base 
> > identity but none of the IANA assigned identities - but then it 
> > might be good if people at least look at IANA assigned identities. 
> > Or are there other reasons why you think this may be looking
'backwards'?
> 
> I makes ietf-entity dependent on iana-entity, since the base identity 
> is defined in iana-entity.
> 
> But OTOH, even if we solved that, ietf-entity is dependent on 
> iana-entity b/c of the value 'sensor'.
> 
> So in this case it is probably fine, but I'm not sure about the 
> general idea.
> 
> 
> /martin



-- 
Juergen Schoenwaelder   

Re: [netmod] derived-from-or-self leads to circular import

[Juergen Schoenwaelder]

I fail to see what this thread has to do with circular imports.

/js

On Mon, Aug 29, 2016 at 07:17:58AM +, Bogaert, Bart (Nokia - BE) wrote:
> Just taking another approach on this: why do we have the restriction on
> circular imports?  Is this really required?  If not then this may be solved
> in another way too (but will take some time before it gets into the YANG
> compilers I'm afraid).
> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data
> Contact number +32 3 2408310 (+32 477 673952)
> 
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium
> Fortis 220-0002334-42
> VAT BE 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential information
> intended for a specific individual and purpose, and is protected by law. If
> you are not the intended recipient, you should delete this message. Any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited without the prior consent of its
> author.
> >> 
> 
> 
> -Original Message-
> From: Martin Bjorklund [mailto:m...@tail-f.com] 
> Sent: 26 August 2016 14:33
> To: j.schoenwael...@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
> 
> Juergen Schoenwaelder  wrote:
> > On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Fri, Jul 29, 2016 at 12:50:13PM +, Bogaert, Bart (Nokia - BE)
> wrote:
> > > > 
> > > > [...]
> > > >  
> > > > > In order to correctly compile (using confdc) we also need to 
> > > > > import iana-entity for the identities defined in there.  However 
> > > > > this is leading a circular dependency:
> > > > > 
> > > > > 1.   Iana-entity imports ietf-entity (to 'resolve'
> > > > > entity-physical-class)
> > > > > 
> > > > > 2.   Ietf-entity imports iana-entity (to obtain the indentities
> defined
> > > > > in there)
> > > > > 
> > > > > One way to solve this is to move the definition of 
> > > > > entity-physical-class from ietf-entity to iana-entity which 
> > > > > would resolve the fact that iana-entity requires an import of 
> > > > > ietf-entity (ietf-entity needs to import iana-entity anyhow, so 
> > > > > it can also pick the typedef from the same module too).
> > > > 
> > > > I think moving the definition of entity-physical-class into 
> > > > iana-entity makes sense.
> > > 
> > > Ok.  It feels a bit backwards to me though, but I can see the value 
> > > of having the iana module self-contained.
> > >
> > 
> > Well, it may look backwards if people want to reuse the base identity 
> > but none of the IANA assigned identities - but then it might be good 
> > if people at least look at IANA assigned identities. Or are there 
> > other reasons why you think this may be looking 'backwards'?
> 
> I makes ietf-entity dependent on iana-entity, since the base identity is
> defined in iana-entity.
> 
> But OTOH, even if we solved that, ietf-entity is dependent on iana-entity
> b/c of the value 'sensor'.
> 
> So in this case it is probably fine, but I'm not sure about the general
> idea.
> 
> 
> /martin



-- 
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] derived-from-or-self leads to circular import

[Bogaert, Bart (Nokia - BE)]

Just taking another approach on this: why do we have the restriction on
circular imports?  Is this really required?  If not then this may be solved
in another way too (but will take some time before it gets into the YANG
compilers I'm afraid).

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.
>> 


-Original Message-
From: Martin Bjorklund [mailto:m...@tail-f.com] 
Sent: 26 August 2016 14:33
To: j.schoenwael...@jacobs-university.de
Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import

Juergen Schoenwaelder  wrote:
> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Jul 29, 2016 at 12:50:13PM +, Bogaert, Bart (Nokia - BE)
wrote:
> > > 
> > > [...]
> > >  
> > > > In order to correctly compile (using confdc) we also need to 
> > > > import iana-entity for the identities defined in there.  However 
> > > > this is leading a circular dependency:
> > > > 
> > > > 1.   Iana-entity imports ietf-entity (to 'resolve'
> > > > entity-physical-class)
> > > > 
> > > > 2.   Ietf-entity imports iana-entity (to obtain the indentities
defined
> > > > in there)
> > > > 
> > > > One way to solve this is to move the definition of 
> > > > entity-physical-class from ietf-entity to iana-entity which 
> > > > would resolve the fact that iana-entity requires an import of 
> > > > ietf-entity (ietf-entity needs to import iana-entity anyhow, so 
> > > > it can also pick the typedef from the same module too).
> > > 
> > > I think moving the definition of entity-physical-class into 
> > > iana-entity makes sense.
> > 
> > Ok.  It feels a bit backwards to me though, but I can see the value 
> > of having the iana module self-contained.
> >
> 
> Well, it may look backwards if people want to reuse the base identity 
> but none of the IANA assigned identities - but then it might be good 
> if people at least look at IANA assigned identities. Or are there 
> other reasons why you think this may be looking 'backwards'?

I makes ietf-entity dependent on iana-entity, since the base identity is
defined in iana-entity.

But OTOH, even if we solved that, ietf-entity is dependent on iana-entity
b/c of the value 'sensor'.

So in this case it is probably fine, but I'm not sure about the general
idea.


/martin


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

Re: [netmod] BBF extensions to ietf-entity

[Bogaert, Bart (Nokia - BE)]

HI Martin,


"Bogaert, Bart (Nokia - BE)"  wrote:
> I would like to bring this to the ietf-entity group.  Currently BBF is 
> proposing to add new RW leafs to the entity object.  This is done in 
> the context of plugable entities and hence it means that when an 
> operator (via a NC client) configures a plugable item it is required 
> to define the entity type.  For this reason additional RW attributes 
> are needed.  Two of the new leafs are class and contained-in (same as the
RO class leaf).
> 
> -  class: we think that the class leaf needs to be mandatory but
> adding this via an augment is not possible as we can't add a mandatory 
> leaf via an augment.  Making class implicit for the client based on 
> "some information" exchanged between device vendors and management 
> applications is maybe not such a sound approach.

Can you explain in more detail how this would be used?  The idea is that
'class' is a property of the physical hw, and that the underlying system
provides this info.  I can see that it could be useful for the client to set
this if the system can't do the classification (i.e., the system-set value
is 'unknown').  But that's probably not the use case you had in mind?


[Bart Bogaert] Assume you have a system with a number of slots that can hold
several different cards and the system was deployed in the field with some
cards inserted and some other slots that were still left empty.  When an
operator wants to extend the system we can have 2 ways of doing this:
1. a field engineer goes 'on-site' and plugs cards in the system.  If done
this way, the system itself can detect what has been inserted and we do not
really need the RW leafs.  However in this case an operator has to wait
configuring user services on these cards until they are inserted.
2. the network operator determines that a node will "run out" of available
ports and hence wants to start planning new configuration and hence he wants
to configure some boards in the empty slots and even may want to start to
pre-configure certain data of the ports contained by these boards.  In that
case we need the RW leaf to indicate which board type will be inserted as
the service that can be offered depends on the board being inserted.  When
the board is inserted, the planned configuration can directly be applied to
the newly inserted board (given the fact that the detected class is the same
as the planned class).

There are customers using method 1 and other customers use method 2.

> -  contained-in: for plugable items contained-in requires to be
> mandatory too as a plugable item can't be "floating" in the device.

Can you explain in more detail what this means, and provide some use cases?


[Bart Bogaert] For DSL we are faced with "wiring" aspects that "ripple
through" to the MDF.  So assume we again have a system with plugable slots.
If we have 2 slots containing the same type of board (same class) and the
operator is applying the pre-configuration mode of working (method 2 in
above), we have to be sure that user A, connected to the first port of the
board plugged in the first slot will really be in slot 1.  If the NC client
has no means to detect which board is plugged in which slot (they are both
of the same class) we need other means to ensure the containment is as
intended (and user A being connected to the first port of the board in slot
A is also visualized as such on the GUI of the NC client).  Using the serial
number of the board seems not very practical as board may break and are sent
to repair or replaced by another board of the same type but with a different
serial number.  I do not think operators will like it a lot to manage a
system in a manual way based on these attributes hence also a need to plan a
board in a specific slot.

Hope this clarifies a bit more.

Best regards,

> Bart Bogaert
> 
> Broadband-Access System Architect Data
> 
> Contact number +32 3 2408310 (+32 477 673952)
> 
>  
> 
> NOKIA
> 
> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 
> 0404 621 642 Register of Legal Entities Antwerp
> 
> 
> 
> <<
> This message (including any attachments) contains confidential 
> information intended for a specific individual and purpose, and is 
> protected by law. If you are not the intended recipient, you should 
> delete this message. Any disclosure, copying, or distribution of this 
> message, or the taking of any action based on it, is strictly 
> prohibited without the prior consent of its author.
> >> 
> 
>  
> 


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

Re: [netmod] Regarding IPR on draft-ietf-netmod-routing-cfg-23

[Ladislav Lhotka]

No, I'm not aware of any IPR that applies to this draft.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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