YANG Model for Logical Network Elements
draft-ietf-rtgwg-lne-model-10

Please make sure you review Dan's OpsDir review (https://datatracker.ietf.org/doc/review-ietf-rtgwg-lne-model-05-opsdir-lc-romascanu-2018-01-25/) -- he has some great suggestions to further improve the document

I also have a few *very* minor nits:
Section 2: Overview
"The logical-network-element module augments existing
   interface management model by adding an"
Perhaps "management models" (plural)?

Section 3.1.  LNE Instantiation and Resource Assignment
"When an bind-lne-name is set to a valid
   LNE name, an implementation "
Perhaps "When a ..." ?

All of the examples in Appendix B and its subsections use IPv4 addresses exclusively. Please update these to use all-IPv6 or a mix of IPv4 and IPv6. See <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/> for details.

As several others have noted, the major concerns below from the Gen-ART reviewer need to be addressed:

Section 4 listed three data nodes that are sensitive or vulnerable:
   -  /logical-network-elements/logical-network-element
   -  /logical-network-elements/logical-network-element/managed
   -  /if:interfaces/if:interface/bind-lne-name

All three of them deserve a bit more discussion, although the middle
one is covered in much more detail than the other two.  If a bad actor
gets "unauthorized access" is there something more specific about each
of these that can be said?  The characterization of "network
malfunctions, delivery of packets to inappropriate destinations, and
other problems" seems very broad.  Consequences that are specific to
these data nodes would be more helpful to the reader.

This document references/augments rfc7223.  It should reference rfc7223bis instead.  The examples in Appendix B still show the interfaces-state subtree, but the main text doesn't.  Are there any other changes in rfc7223bis that would impact this document?

Russ's Gen-ART review included comments about the "vulnerable parameters" in the security considerations section in version 5. Version 6 does not seem to address those comments, nor do I see any response in email. If the authors do not intend to add the requested information, it would be good to at least say so (and hopefully explain why) via email.

No objection to the document, but a few points must addressed.

- I agree with Alvaro's point: the example should be corrected.
- This draft is NMDA compliant: it should be mentioned.

From Dan Romascanu's OPS DIR, at least the 3 first three points should be addressed (the 4rth one is a nice to have, but a bigger task IMO):

This is a very useful, well thought and well written document, which reflects
work and discussions within the RTG and OPS areas. From an operational point of
view it's a very useful tool in support of network operators that will manage
and configure logical elements. I believe that the document is almost ready,
but there are a number of issues that are worth being discussed and addressed
before approval by the IESG.

1. The name and scope of the document as presented in the title and Abstract
are not exactly reflecting the content. LNEs are not YANG LNEs as the title
says, and the type of module (a YANG module) being defined is not stated in the
Abstract. I would suggest that the document actually defines 'A Data Model and
YANG Module for Logical Network Elements'.

2. There is no reference and relationship definition in the document to the
YANG Data Model for Hardware Management defined in
https://tools.ietf.org/html/draft-ietf-netmod-entity-07. Actually the LNEs are
almost similar with the 'logical entities' that were dropped from the
netmod-entity work. It is expected that in the future network operators will
use both data models and the respective YANG modules when managing hardware
devices on which logical network entities are being run. Even if this
relationship is not explicitly present in the DM, I believe that it needs to be
looked at and mentioned in the document.

3. In Section 2 I see:

'The logical-network-element module augments existing
   interface management model by adding an identifier which is used on
   physical interface types to identify an associated LNE.'

I am wondering why the mentioning of 'physical interface types' here. What if
the interface type in not 'physical' representing a protocol layer or sublayer
on the device? After all, if all interfaces to be considered were 'physical' we
could have augmented the entity hardware module rather than the interfaces
module, as all physical interfaces are represented there as well.

4. Sections 3.2 and 3.3 seem to be written for the benefit and the perspective
of the implementations writers rather than of the operators. Are there any
hints, advice, or indications for the operators using the module to manage
their LNEs? These could be described also in the examples appendices, which are
otherwise very useful to illustrate and explain the models.

I agree with the SecDir reviewer's recommendations and would like to see text added to the Security considerations section as suggested:

https://datatracker.ietf.org/doc/review-ietf-rtgwg-lne-model-05-secdir-lc-yu-2018-02-06/