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.

-          contained-in: for plugable items contained-in requires to be
mandatory too as a plugable item can't be "floating" in the device.  But we
then hit a problem for the 'top-level' entity which not contained in
anything (and 'fooling' the model by having it pointing to itself is not
allowed).  Contained-in can't be derived by the NC server: what to do if 2
entities of the same class are preprovisioned (together with ports and
interfaces related to subscribers)?  We need to be sure that the subscribers
are on the intended ports.

 

This would mean that the ietf-entity model would require a revision to add
leafs for these plugable items.  What is the best way to address this?

 

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

 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to