William,
Not sure how this can be done in all cases. Assume we have a box that allows ‘n’ boards to be plugged in slots 1..n. During pre-provisioning we configure 2 boards of the same type, one in slot 1 and another in slot 2. We also pre-provision the ports and allocate subscriber interfaces and assign data specific to these subscribers (so in a way this will be related to e.g. how the ports are wired via an MDF). The device is not really able to determine by itself which board is contained in slot 1 (supporting the subscribers that are wired via MDF to terminate on this board) and the other to the board in slot 2. The only way the device would be able to do so autonomously would be when e.g. a serial number related to the boards is provided by the operator when pre-provisioning the board. The serial number is retrievable from the inventory information present in the board and hence the device could relate a board to a specific slot. However… when the board gets broken it is temporarily (or even permanently in case the board is really broken) replaced by another board of the same type but with a different serial number. This would then mean that the operator also needs to modify that serial number since the serial number in the inventory no longer matches the one entered by the operator when configuring the board (it is not really expected/allowed that the NC server would modify the RW data for that board). Not really sure this is an elegant way of exposing this serial number management to a network operator. So don’t we need a mechanism via configuration (i.e. R/W leafs) to configure this “containment” ? 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. >> From: William Lupton [mailto:wlup...@broadband-forum.org] Sent: 01 August 2016 11:14 To: Bogaert, Bart (Nokia - BE) Cc: netmod@ietf.org Subject: Re: [netmod] BBF extensions to ietf-entity Maybe configuration of the entity tree for pluggable items should be handled via augmentations that are specific to pluggable items? There seems to be an analogy with interfaces here. The ietf-interfaces module provides only a read-only view of the interface stack, and interface type-specific modules are expected to provide a means of configuring the stack for interfaces of that type (where necessary). William On 29 Jul 2016, at 15:04, Bogaert, Bart (Nokia - BE) <bart.boga...@nokia.com> 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. - 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. >> _______________________________________________ netmod mailing list <mailto:netmod@ietf.org> netmod@ietf.org <https://www.ietf.org/mailman/listinfo/netmod> https://www.ietf.org/mailman/listinfo/netmod
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
