Skip to main content

Last Call Review of draft-ietf-rtgwg-lne-model-05

Request Review of draft-ietf-rtgwg-lne-model
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-01-31
Requested 2018-01-17
Authors Lou Berger , Christian Hopps , Acee Lindem , Dean Bogdanović , Xufeng Liu
I-D last updated 2018-01-20
Completed reviews Yangdoctors Early review of -02 by Martin Björklund (diff)
Rtgdir Early review of -02 by Ravi Singh (diff)
Genart Last Call review of -05 by Russ Housley (diff)
Secdir Last Call review of -05 by Taylor Yu (diff)
Opsdir Last Call review of -05 by Dan Romascanu (diff)
Assignment Reviewer Russ Housley
State Completed
Request Last Call review on draft-ietf-rtgwg-lne-model by General Area Review Team (Gen-ART) Assigned
Reviewed revision 05 (document currently at 10)
Result Not ready
Completed 2018-01-20
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.

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.


Abstract: YANG appears in the title and the introduction.  So, I was a
bit surprised that YANG did not appear anywhere in the Abstract.

This document seems to refer to itself as "RFC XXXX" and "RFC TBD".
Please pick one and use it throughout the document.