Telechat Review of draft-ietf-i2rs-yang-l3-topology-08

Request Review of draft-ietf-i2rs-yang-l3-topology
Requested rev. no specific revision (document currently at 16)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2017-01-03
Requested 2016-12-01
Authors Alexander Clemm, Jan Medved, Robert Varga, Xufeng Liu, Hariharan Ananthakrishnan, Nitin Bahadur
Draft last updated 2017-01-19
Completed reviews Rtgdir Early review of -01 by Tony Przygienda (diff)
Opsdir Telechat review of -08 by Ron Bonica (diff)
Secdir Telechat review of -08 by Hilarie Orman (diff)
Genart Last Call review of -08 by Paul Kyzivat (diff)
Yangdoctors Early review of -02 by Carl Moberg (diff)
Rtgdir Early review of -10 by Christian Hopps (diff)
Yangdoctors Early review of -10 by Ladislav Lhotka (diff)
Rtgdir Early review of -10 by Michael Richardson (diff)
Secdir Last Call review of -13 by Hilarie Orman (diff)
Genart Last Call review of -13 by Paul Kyzivat (diff)
Assignment Reviewer Hilarie Orman
State Completed
Review review-ietf-i2rs-yang-l3-topology-08-secdir-telechat-orman-2017-01-19
Reviewed rev. 08 (document currently at 16)
Review result Has Issues
Review completed: 2017-01-19


			  Security review of
	       A YANG Data Model for Layer 3 Topologies

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call

The document provides "illustrative examples" of extensions to the
YANG data model for IP unicast networks.  The specific cases covered
in the draft are OSPF and IS-IS.

The security considerations state:

"It is therefore important that the NETCONF access control model is
vigorously applied to prevent topology configuration by unauthorized

NETCONF (RFC6536) states:

  3.7.3.  Data Model Design Considerations

    Designers need to clearly identify any sensitive data, notifications,
    or protocol operations defined within a YANG module.  For such
    definitions, a "nacm:default-deny-write" or "nacm:default-deny-all"
    statement ought to be present, in addition to a clear description of
    the security risks.

I don't see any guidance or examples of this in the draft under
discussion.  Shouldn't there be some?  Or at least a statement of why
they aren't included?


Page 27 typo "The moodel defines a protocol independent YANG ... ".
"moodel" should be "model".

The use of "holistic" and "conceptual" in the opening paragraph caused
me to pause in puzzlement:
"The model allows an application to have a holistic view of the
topology of a Layer 3 network, all contained in a single conceptual
YANG datastore."

I think that "holistic" means "stated in a single data language", and
"conceptual" means "it is not a single datastore but it could be,
conceptually."  Or something like that.  Less new-agey phrasing might
convey the idea more directly.