[netmod] Notifications in schema mount when mounting multiple NEs.
Hi, In RFC 8528 section 5 there is a discussion on notifications and mount point. After reviewing the RFC, I couldn't find how a notification's reporting entity would be assigned that has a mount point when you have a list of network elements. I also couldn't find any examples in the IETF github site for schema mount. Can anyone provide me an example of what the might look like? I'm not sure what the reporting entity would look like. Thanks, Tim ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Performance considerations for draft-ietf-netmod-nmda-diff
Hi Alex, As long as there isn't any requirements of specific error messages (like resource exceeded) that you want to use if the requests cannot be fulfilled, I think that might be ok; obviously the concern may be security related but also simply related to resource constraints - an authorized system could ask for a comparison that the device simply couldn't complete. That gets lost in security section. BR, Tim From: Alexander Clemm Sent: Wednesday, July 17, 2019 1:38 PM To: Carey, Timothy (Nokia - US) ; netmod@ietf.org Subject: RE: Performance considerations for draft-ietf-netmod-nmda-diff Hi Tim, this aspect is currently mentioned in the security considerations, specifically the last paragraph (https://tools.ietf.org/html/draft-ietf-netmod-nmda-diff-02#page-14), mentioning the fact that comparing datastores for differences requires a certain amount of processing resources, which could be leveraged by an attacker to consume resources via illegitimate requests, and outlining mitigations (ranging from NACM, to limiting the number of requests per time interval and reserving the option to reject a request). Do you think this is sufficient? Adding a separate performance considerations section is of course possible but would be somewhat redundant. --- Alex From: netmod mailto:netmod-boun...@ietf.org>> On Behalf Of Carey, Timothy (Nokia - US) Sent: Wednesday, July 17, 2019 5:50 AM To: netmod@ietf.org<mailto:netmod@ietf.org> Subject: [netmod] Performance considerations for draft-ietf-netmod-nmda-diff Hi, In reviewing the NMDA differences draft, a comment was made that we need to be careful resources requirements placed on the target elements in order to perform the comparison. In some situations the datastores can be quite large and the compute capabilities (CPU, memory) somewhat constrained. Should we add a performance consideration section in this draft with maybe how we would expect a server to respond if the requirements of the request or the associated response exceed the "current" capabilities of the target? BR, Tim ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Performance considerations for draft-ietf-netmod-nmda-diff
Hi, In reviewing the NMDA differences draft, a comment was made that we need to be careful resources requirements placed on the target elements in order to perform the comparison. In some situations the datastores can be quite large and the compute capabilities (CPU, memory) somewhat constrained. Should we add a performance consideration section in this draft with maybe how we would expect a server to respond if the requirements of the request or the associated response exceed the "current" capabilities of the target? BR, Tim ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] draft-wu-netmod-factory-default-01: Actually resetting the device to factory defaults
Hi, In the IETF 103 meeting a comment was made that using the reset-datastore RPC doesn't actually reset the device to factory settings. I would like to suggest that this RPC when applied to the start-up store have the capability to actually reset the device the factory settings. This might require a device reboot to finalize the action but we do need an option that I can actually place the device in a configuration That resembles the device when it first arrives from the "factory". I would believe this would be the main use case for this type of reset-datastore operation. Did I misunderstand the comment? BR, Tim ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] WG Last Call: draft-ietf-netmod-entity-05
Kent, Yes it would be good set a target date so it communicates to the industry the intent, allowing them to plan their migration. It also allows the industry to provide feedback regarding the migration period. I wanted to reiterate Barts request for the hardware module to have state module in an Appendix. What you don't want is have the industry organizations that use the modules to create their own state modules - this will cause undue fragmentation that will harm the advancement of YANG. BR, Tim -Original Message- From: Kent Watsen [mailto:kwat...@juniper.net] Sent: Thursday, December 07, 2017 2:03 PM To: Juergen Schoenwaelder ; Bogaert, Bart (Nokia - BE/Antwerp) Cc: NetMod WG Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-entity-05 All, Picking up on Juergen's comment: > If these deprecated objects are essential for BBF (please confirm), > then it might be better to define them in a separate module... I agree that the objects should be defined in a separate module. The request, as I understand it, is for there be an "ietf-hardware-state" module defined in the Appendix of this draft. I believe that doing so is consistent with the NMDA guidelines: (b) Models that require immediate support for "in use" and "system created" information SHOULD be structured for NMDA. A non-NMDA version of these models SHOULD exist, either an existing model or a model created either by hand or with suitable tools that mirror the current modeling strategies. Both the NMDA and the non-NMDA modules SHOULD be published in the same document, with NMDA modules in the document main body and the non-NMDA modules in a non-normative appendix. The use of the non-NMDA model will allow temporary bridging of the time period until NMDA implementations are available. Of course, we should ask, for how long is it that the IETF (SDOs in general) should publish these -state modules? During the discussion at the beginning of the first session in Singapore, I said something along the lines of "so long as there is market demand for it", which seems a bit too open-ended for my taste. I recommend that we set a date, perhaps a couple years out, after which we (the IETF) will no longer publish or maintain such foo-state modules. Thoughts? Kent // as co-chair = original message == Bart, I think the reason for the difference is that the interfaces model was published as an RFC before while the hardware model is new and hence it seems to look a bit odd to define new deprecated objects. If these deprecated objects are essential for BBF (please confirm), then it might be better to define them in a separate module that then can silently die while systems move to NMDA (and so we do not have the deprecated objects with us in the hardware module forever - or at least as long as we use YANG 1.1). /js On Tue, Dec 05, 2017 at 02:35:29PM +, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > Hello, > > The latest draft does not contain an appendix with the deprecated > state tree (to support the non-NMDA model as specified in RFC6087bis > section 4.23.3), so if it is published in this way, there is an issue > at the level of BBF TR-383. > > Note that the draft-ietfnetmod-rfc7223bis does include the deprecated > container interfaces-state. > > Best regards, > Bart Bogaert > > -Original Message- > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, November 29, 2017 6:36 PM > To: NetMod WG > Cc: NetMod WG Chairs > Subject: [netmod] WG Last Call: draft-ietf-netmod-entity-05 > > All, > > This starts a two-week working group last call on > draft-ietf-netmod-entity-05. > > The working group last call ends on December 13. > Please send your comments to the netmod mailing list. > > Positive comments, e.g., "I've reviewed this document and believe it > is ready for publication", are welcome! > This is useful and important, even from authors. > > Thank you, > Netmod Chairs > > ___ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > man_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW > zoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=chLVKwaAcdC6Llko8 > SagGTdtaLVTMJRVuFxx-MbXvQU&s=1sxGcVU9OMbpjTMNke_r8CkLGnSnNhrwXl1aqAiqd > Is&e= > ___ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail > man_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcW > zoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=chLVKwaAcdC6Llko8 > SagGTdtaLVTMJRVuFxx-MbXvQU&s=1sxGcVU9OMbpjTMNke_r8CkLGnSnNhrwXl1aqAiqd > Is&e= -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103
[netmod] BBF Entity Augmentations
Reposting to fix formatting errors in the original message - still looking for comments. Hello, In using the Entity module within the BBF, we have made several enhancements to the module that we would like the IETF to consider for inclusion in the next draft of the module as we consider these enhancements to be of use to the wider YANG community. I have included the tree definitions in this email thread. If you like the actual YANG files please let us know and we can provide those to the authors. Specifically we have done the following enhancements: 1Added a new generic reset action for a physical entity module: bbf-entity-reset-action augment /ent:entity-state/ent:physical-entity: +---x reset +---w input +---w reset-type? identityref 2Added a parent/child entity capability for physical entities 3Added a couple of common attributes for the manufacturer name and model module: bbf-entity-extension augment /ent:entity/ent:physical-entity: +--rw class? identityref +--rw contained-in* -> ../../ent:physical-entity/name +--rw parent-rel-pos? int32 +--rw mfg-name? string +--rw model-name? string 4Introduced a new type of identity and container for a pluggable transceiver module: bbf-entity-pluggable-transceiver augment /ent:entity-state/ent:physical-entity: +--ro pluggable-transceiver-data augment /ent:entity/ent:physical-entity: +--rw pluggable-transceiver 5Introduced a new reference between the interface and the port module: bbf-interface-port-reference augment /if:interfaces/if:interface: +--rw port-layer-if entity-ref BR, Tim ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Corrections needed in the draft-ietf-netmod-entity-00
Alex, Yes - but the problem is more than sensors or whatever entities the entity module provides support. The problem is an import/reference structural problem with respect to the IANA entity (imports IETF entity) and IETF entity imports the IANA entity. We think the proper, future proof method is to move the entities to the IANA entity and have the IETF entity import that module. It's a simple future proof fix that doesn't change the actual model behavior. We don't think importing the IANA entity is a problem for servers to support. BR, Tim From: Alex Campbell [mailto:alex.campb...@aviatnet.com] Sent: Thursday, October 06, 2016 5:41 PM To: Carey, Timothy (Nokia - US) Cc: netmod@ietf.org Subject: Re: Corrections needed in the draft-ietf-netmod-entity-00 Hi, If you are referring to the circular reference in the expresssion 'derived-from-or-self(../class, "iana-entity", "sensor")', I would rather see sensor-data separated into another module than see entity-physical-class moved to iana-entity. This would be more consistent with the RFC 7223 interface model, where interface-type-specific modules augment the basic generic interface module with interface-type-specific data. It also leaves open the possibility of a server not supporting iana-entity if it doesn't need any of the standard entity types. Alex From: netmod mailto:netmod-boun...@ietf.org>> on behalf of Carey, Timothy (Nokia - US) mailto:timothy.ca...@nokia.com>> Sent: Friday, 7 October 2016 2:38 a.m. To: netmod@ietf.org<mailto:netmod@ietf.org> Subject: [netmod] Corrections needed in the draft-ietf-netmod-entity-00 Hello, The BBF plans to use the Entity module as one of our common YANG modules within the BBF. The current draft of the module has some errors that we feel need corrected. Specifically there is a circular reference for the identity entity-physical-class; we feel that this should be moved to the iana-entity-module. What does the group think? BR, Tim ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] BBF Augmentations for the Entity draft (draft-ietf-netmod-entity-00)
Hello, In using the Entity module within the BBF, we have made several enhancements to the module that we would like the IETF to consider for inclusion in the next draft of the module as we consider these enhancements to be of use to the wider YANG community. I have included the tree definitions in this email thread. If you like the actual YANG files please let us know and we can provide those to the authors. Specifically we have done the following enhancements: 1Added a new generic reset action for a physical entity module: bbf-entity-reset-action 1. augment /ent:entity-state/ent:physical-entity: +---x reset +---w input 2. +---w reset-type? identityref 2Added a parent/child entity capability for physical entities 3Added a couple of common attributes for the manufacturer name and model module: bbf-entity-extension augment /ent:entity/ent:physical-entity: +--rw class? identityref +--rw contained-in* -> ../../ent:physical-entity/name +--rw parent-rel-pos? int32 +--rw mfg-name? string 4 +--rw model-name? string 4Introduced a new type of identity and container for a pluggable transceiver module: bbf-entity-pluggable-transceiver 5 augment /ent:entity-state/ent:physical-entity: +--ro pluggable-transceiver-data augment /ent:entity/ent:physical-entity: 6 +--rw pluggable-transceiver 5Introduced a new reference between the interface and the port module: bbf-interface-port-reference 6 augment /if:interfaces/if:interface: 7 +--rw port-layer-if entity-ref BR, Tim ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
[netmod] Corrections needed in the draft-ietf-netmod-entity-00
Hello, The BBF plans to use the Entity module as one of our common YANG modules within the BBF. The current draft of the module has some errors that we feel need corrected. Specifically there is a circular reference for the identity entity-physical-class; we feel that this should be moved to the iana-entity-module. What does the group think? BR, Tim ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
