Subject: [i2rs] Handling technical concerns and progressing topology models

From: Alia Atlas <[email-masked]>
Date: Tue, 31 Jan 2017 18:59:10 -0500

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