Sorry about the slow response.  See below.

On 2/8/2018 8:36 AM, Alissa Cooper wrote:
Russ, thanks for your review. I don’t think your major concern quite rises to 
the level of being DISCUSS-worthy, but I’ve flagged it in my No Objection 
ballot and would expect a response from the authors.


On Jan 20, 2018, at 6:36 PM, Russ Housley <hous...@vigilsec.com> wrote:

Reviewer: Russ Housley
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

Document: draft-ietf-rtgwg-lne-model-05
Reviewer: Russ Housley
Review Date: 2018-01-20
IETF LC End Date: 2018-01-31
IESG Telechat date: 2018-02-08

Summary: Not Ready

Major Concerns:

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.
We've been struggling what more should be said here - and this the reason for the delayed response - note that the text does pay particular note to the one really special node in the model:

   /logical-network-elements/logical-network-element/managed:  While
      this leaf is contained in the previous list, it is worth
      particular attention as it controls whether information under the
      LNE mount point is accessible by both the host device and within
      the LNE context.  There may be extra sensitivity to this leaf in
      environments where an LNE is managed by a different party than the
      host device, and that party does not wish to share LNE information
      with the operator of the host device.

Furthermore, the current text is largely pattered after what is typically covered in YANG models and we don't see this model as having  fundamentally different than the reference foundational YANG models.  -06 does add important text on secure data access and and access control of specific operations.  Is this sufficient?

Minor Concerns:

Section 1.1: Please update the first paragraph to reference RFC 8174
in addition to RFC 2119, as follows:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Done (in -06)


Abstract: YANG appears in the title and the introduction.  So, I was a
bit surprised that YANG did not appear anywhere in the Abstract.
Done (in -06)
This document seems to refer to itself as "RFC XXXX" and "RFC TBD".
Please pick one and use it throughout the document.
Done (in -06)

Lou (and co-authors)

Gen-art mailing list
rtgwg mailing list

rtgwg mailing list

Reply via email to