[CCAMP] Acting AD review of draft-ietf-ccamp-mw-topo-yang-08

["Eric Vyncke (evyncke)" <[e-mail]>]

Dear CCAMP WG,

As you may have read, after a discussion with John Scudder, I am the temporary / acting responsible AD for draft-ietf-ccamp-mw-topo-yang-08.

Therefore, here is my AD review of the document. Before proceeding to the next step in the publication process (i.e., IETF Last Call), I am requesting a reply (and ‘the WG has agreed XYZ’ is fine)  or a text change for all the points below (except when noted). My comments below are in Markdown, so they can be imported easily as Github issues.

I sincerely hope it helps,

-éric

PS: I am based in Belgium/Europe UTC+1 and planning to take some days off for end of the year after next week. So, please accept my apologies for late replies.

# NITS (no need to reply or act)

## Leafs vs. leaves

I am non-English speaker, but I think that the plural form of ‘leaf’ is ‘leaves’.

## Section 4 and configurtion

s/configurtion/configuration/

## S 6.3.2 json

Please use JSON in uppercase

## Behaviour vs. behavior

In US English, I think that the correct writing is ‘behavior’.

## E.g. comma

“E.g.” should be followed by a comma.

## SVG diagrams

Several figures are quite complex and would benefit of adding a SVG rendering in addition to the ASCII art. This could be time consuming but there are tools to assist you, notable aasvg (which is really impressive and worth a try), see also https://authors.ietf.org/en/diagrams.


# COMMENTS (expecting either reply or a document update)

## S 1 L0/L1

Please expand `L0/L1`at first use. Same for L2 (even if obvious)

## S 1 L2 Ethernet

Isn’t `L2 Ethernet` a pleonasm ?

## S 1 where it e.g. could be used

I do not think that `where it e.g. could be used` is correct English, suggest using “could be used, e.g., ...;”

## S 1.1

While this section title includes ‘definition’, it actually contains only acronyms expansions. Suggest to either define the terms or change the section title.

## S 2

If the normative BCP14 uppercase words are not used in the I-D (which is the case AFAICT), then there is no need to include the BCP14 template (and the associated references). Suggest removing this section.

## Prefixes in Data Node Names

Should there be a section/table like often found in other YANG models RFCs ? E.g., https://datatracker.ietf.org/doc/html/rfc8795#section-1.3

## S 3.1 is dry

Most of the RFC explain the YANG tree notably with basic explanations and relationships among other leaves.

## S 3.1 leaves names

It seems that a recommended practice in YANG modules is to avoid repeating the module/parent name in the leaves names. E.g., s/mw-bandwidth/bandwidth/

## Repetitive text about L1 not being L3

The I-D contains some repetitive text such as `cannot be used to perform cross-connection or switching of the traffic to create network connectivity across multiple microwave`, which is also somehow obvious. Suggest to at least avoid the repetition.

## S 3.4 2nd paragraph

Perhaps due to my lack of expertise in radio links, but here are a list of points causing my eyebrows to raise:

- `admin-status and ... are recommended to be reported`: isn’t admin-status also a configurable leaf ?

- `are recommended`: am I correct that this is not the normative “RECOMMENDED” ?

- `recommended to be reported for links only`: why not for carriers as well? It may well be the case for currently deployed products, but 1/ this may change 2/ this justification could be added in the text.

- `Enable and disable of a radio link is instead done in the constituent carriers`: same comment as above. I tend to see a radio link as a ‘LACP LAG group’ with the constituent ‘Ethernet links’ that can be individually monitored/configured.

## S 3.5 missing revision date in the module

Normally, in the YANG module name, the revision date is included.

## S 3.5 missing references

Normally, a YANG module add text about references before the actual YANG module(s).


## S3.5 microwave-bandwidth



Should the unit be “bits/seconds” rather than `bits/seconds`?



## S A.1



What about using an IPv6 address rather than `192.0.2.3` for `ietf-te-topology:te-tp-id`? (I am a big fan of IPv6, feel free to ignore this suggestion)



## S B



Are there informative references to the models cited in `interface reference topology (ifref) and bandwidth-availability-topology (bwa) models` ?