[Lsr] Roman Danyliw’s DISCUSS on draft-ietf-ospf-yang-26

[Alvaro Retana <[e-mail]>]

[It looks like the datatracker didn’t send out the text to Roman’s
DISCUSS.  I didn’t receive it, nor do I see it in the mail archive.  So I’m
pasting it here. — Alvaro.]

- - - - - - - - - - -
DISCUSS
- - - - - - - - - - -

A “discuss to discuss”.  Per the convention outlined in
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, thank you for
clearly noting the implication of not securing these nodes properly.

Furthermore, following the convention, I would have expected Section 4 to
have enumerated the sensitive writeable/creatable/deletable data nodes; and
the sensitive readable nodes individually.  For a model this large, I can
imagine that individual enumeration would be a long list.

In the case of read operations, the text opens with saying that “some of
the readable data nodes ...” and later says “The exposure of the ... LSDB
will expose the detailed topology ...”.  Can you help me understand which
part of ietf-ospf.yang is the LSDB and which parts refer to “some of the
readable nodes”?  Is there are a difference, or is this text asserting that
all parts of the modules are sensitive and need access control?

A related line of questioning for the write operation.  The text opens with
saying that “There are a number of data nodes defined in ietf-ospf.yang ...
[and that] [w]rite operations ... to these nodes without proper protection
can have a negative effect on the network operations ... [and] ... the
ability to modify OSPF configuration ...” is problematic.  Can you help me
understand which parts of the text is the “OSPF configuration” vs. “there
are number of data nodes ...”?  If there isn’t a different, is the text
asserting that all parts of the modules are sensitive and need access
control?


- - - - - - - - - - -
COMMENT
- - - - - - - - - - -

(1) Idnits returned a seemingly valid few reference issues:

  ** Downref: Normative reference to an Experimental RFC: RFC 1765

  ** Downref: Normative reference to an Experimental RFC: RFC 4973

(2) Editorial
-- Section 4.  Isn’t RFC8341, “the Network Configuration Access Control
Model” rather than the “NETCONF access control model”?

-- Section 4.  Typo.  s/specificationn/specification/

-- Section 4.  Remove the duplicate instance of the phrase “for legacy
implementations that do not support key-chains”.

-- Section 4.  Typo.  s/The OSPF YANG module support/the OSPF YANG module
supports/

Alvaro Retana