Skip to main content

Telechat Review of draft-ietf-lime-yang-connectionless-oam-methods-11
review-ietf-lime-yang-connectionless-oam-methods-11-secdir-telechat-kaduk-2017-10-25-00

Request Review of draft-ietf-lime-yang-connectionless-oam-methods
Requested revision No specific revision (document currently at 13)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2017-10-24
Requested 2017-10-11
Authors Deepak Kumar , Zitao Wang , Qin Wu , Reshad Rahman , Srihari Raghavan
I-D last updated 2017-10-25
Completed reviews Yangdoctors Early review of -03 by Carl Moberg (diff)
Opsdir Telechat review of -10 by Jouni Korhonen (diff)
Secdir Telechat review of -11 by Benjamin Kaduk (diff)
Genart Telechat review of -09 by Brian E. Carpenter (diff)
Assignment Reviewer Benjamin Kaduk
State Completed
Request Telechat review on draft-ietf-lime-yang-connectionless-oam-methods by Security Area Directorate Assigned
Reviewed revision 11 (document currently at 13)
Result Ready
Completed 2017-10-25
review-ietf-lime-yang-connectionless-oam-methods-11-secdir-telechat-kaduk-2017-10-25-00
This draft is basically providing a YANG model as an abstraction over existing
(connectionless OAM) functionality, perhaps with some intention of facilitating
similar functionality in new spaces.  (E.g., ICMP ping/traceroute exist, but
entries are also given for SFC, MPLS, MPLS-TP, TWAMP, BIER, and I do not expect
that all of those currently have such functionality.).

The modeled functionality is intended to be run over management protocols such
as NETCONF or RESTCONF (i.e., ssh or HTTPS), which are at least nominally
secure transports.  Though it is possible to configure either of them in an
insecure fashion, I don't feel a particular need to beat the reader over the
head with notes about actually verifying TLS certificates, etc..  The security
considerations duly mention that access control is appropriate and that some
operations may be considered sensitive or vulnerable in some environments,
which is true, and probably the most that can reasonably be said at this level
of abstraction.

I do see several appearances of an abstract "location-type" field and other
system identifiers ("identityref", "system-id", MAC/IPv4/IPv6 addresses), which
 are sometimes considered sensitive, especially when they can be associated
back to individual users, which leads to privacy considerations about user
tracking and similar.  Since this is OAM work, I don't actually know that there
are real users in scope as opposed to fixed infrastructure, but perhaps a
statement in the security considerations about privacy and this sort of
identifiers would still be useful.

The document could benefit from some general copy editing for
language/grammar/etc., but unfortunately given the short turnaround between
last call end and the telechat, I cannot provide a more detailed patch or
comments at the present time.