Hi,
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.
Alissa
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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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)
Nits:
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)
Thanks,
Lou (and co-authors)
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________
rtgwg mailing list
rt...@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
