Skip to main content

Last Call Review of draft-ietf-ccamp-otn-topo-yang-11
review-ietf-ccamp-otn-topo-yang-11-yangdoctors-lc-krejci-2020-10-16-00

Request Review of draft-ietf-ccamp-otn-topo-yang-11
Requested revision 11 (document currently at 18)
Type Last Call Review
Team YANG Doctors (yangdoctors)
Deadline 2020-10-16
Requested 2020-09-25
Requested by Daniele Ceccarelli
Authors Haomian Zheng , Italo Busi , Xufeng Liu , Sergio Belotti , Oscar Gonzalez de Dios
I-D last updated 2020-10-16
Completed reviews Secdir Telechat review of -18 by Watson Ladd
Opsdir Last Call review of -17 by Dan Romascanu (diff)
Secdir Last Call review of -17 by Watson Ladd (diff)
Genart Last Call review of -17 by Stewart Bryant (diff)
Yangdoctors Last Call review of -11 by Radek Krejčí (diff)
Rtgdir Early review of -16 by Michael Richardson (diff)
Comments
Would it be possible to have a joint review with: https://tools.ietf.org/html/draft-ietf-ccamp-otn-tunnel-model-11 ?
Both document specify YANG models for OTN networks, one is about topology and the other one about tunnels.
I'll put the same request while asking for the review of the tunnel model.
Thanks!
Assignment Reviewer Radek Krejčí
State Completed
Request Last Call review on draft-ietf-ccamp-otn-topo-yang by YANG Doctors Assigned
Posted at https://mailarchive.ietf.org/arch/msg/yang-doctors/FvG3V0_fBzOhKPcvCpCThWHcLaA
Reviewed revision 11 (document currently at 18)
Result Ready w/issues
Completed 2020-10-16
review-ietf-ccamp-otn-topo-yang-11-yangdoctors-lc-krejci-2020-10-16-00
This is my yang doctor review of draft draft-ietf-ccamp-otn-topo-yang-11 with
the ietf-otn-topology@2020-09-21 YANG module.

Despite the size of the module, its structure is very simple repeatedly
following a pattern of augmenting ietf-te-topology by groupings defined in
ietf-layer1-types module.

Datatracker's validation with yanglint reports a number of warnings, but they
are false positive (fixed in yanglint 1.9.16 - the fixed version still reports
warnings, but they are all from the imported ietf-layer1-type module).

My only note to the module itself is about the two defined groupings - I'm not
sure about the reusability of the groupings in other modules. If the
reusability is not the concern, I don't see any reason to define them.

Regarding the draft, as a reader, I would appreciate a more targeted
description in section 3. Instead of just dumping the tree diagram in section
3.2, it would be useful to split it into several areas with some brief
descriptions and examples.

The list of paths is introduced in Section 6 as "the subtrees and data nodes
and their sensitivity/vulnerability", but I don't see explained/described the
mentioned sensitivity/vulnerability of those paths.

The prefix of the YANG module (also referred to in Section 7 ) - 'otntopo' -
seems inconsistent to me. The relevant ietf-te-topology has 'tet' (so I would
expect 'otnt' here), on the other hand, the ietf-otn-tunnel has 'otn-tunnel'
prefix (then I would expect 'otn-topo' prefix here). The 'otntopo' seems to
introduce just another format. As a reader/user, I would prefer if the modules
from a common group could use some common and obvious rules for prefixes.