Dear I2RS Working Group, There has been significant discussion around draft-ietf-i2rs-yang- network-topo-10 <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/> as a side-effect of IESG balloting. While the focus of the IESG concerns was on having clearly written security considerations, the active discussion clearly demonstrated both different perspectives on how the model could be used and specific technical concerns that were not adequately clear in the draft or adequately handled to conform with the existing standardized YANG work. As a vital part of the IETF process, when there are valid technical concerns that haven't been addressed, it is necessary to handle them. Therefore, I am returning both draft-ietf-i2rs-yang-network-topo and draft-ietf-i2rs-yang-l3-topology-08 <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/> to the WG.
The specific technical concern is around the model defining a 'server-provided' flag to indicate when configuration (config true) nodes actually contain and should be treated like operation state (config false) nodes, which overrides normal YANG behavior. >From discussions among the authors, NETMOD Chairs, I2RS Chairs, TEAS Chairs, and myself, the best long-term technical solution continues to be based upon use of the active work in NetMod that is draft-ietf-netmod-revised-datastores-00 <https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/>. Alex Clemm and Xufeng Liu, with Pavan Beeram's and Kent Watsen's kind assistance, will be writing the details of the specific issues and use-cases and proposed solutions to send to the list in the next couple weeks. I anticipate that the draft-ietf-i2rs-yang-network-topo will have a new appendix that will describe the applicability and give examples, based upon use of the WG-selected solution. This is for clarity because it is clear that there are nuances here that are not universally understood in the WG. Both draft-ietf-i2rs-yang-network-topo and draft-ietf-i2rs-yang-l3-topology <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/> provide models that can be generally used. However the details of applicability are complex for a number of reasons. The model is intended for use by both routers and controllers. The data can come from different sources and the relationships between that data is an important part of that model. The particular data domain being modeled has natural complexities. A key question that I am looking to the WG to answer is what is the time-criticality of getting these drafts published soon versus when draft-ietf-netmod-revised-datastores <https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/> completes (which may be a while)? If urgent, the WG may need to examine short-term solutions. Since the initial trigger for this discussion was around the Security Considerations, I know that Alex will be shortly publishing an updated draft-ietf-i2rs-yang-network-topo that is based on the existing yang security considerations recommendations (though updated to reflect multiple protocols may be used). Moving forward, as more features are available in YANG models, I expect those aspects, when used, to also potentially impact security considerations. The silence on the list since last week has been due to very active discussion trying to clarify and articulate the technical concerns and determine potential solutions. Regards, Alia
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
