search

haomianzheng / IETF-ACTN-YANG-Model

IETF Optical YANG models in ACTN Architecture
4 stars 4 forks source link

Reply from Mahesh Jethanandani's #185

Open italobusi opened 2 months ago

italobusi commented 2 months ago

Thanks for that reference. Reading RFC 8345, and in particular paragraph 3 of Section 4.4.10, it says:

In general, a configured network topology will refer to an underlay topology and include layering information, such as the supporting node(s) underlying a node, supporting link(s) underlying a link, and supporting termination point(s) underlying a termination point.

You have provided the layering information for nodes, link, and termination points, but where is the reference to the underlay topology?

I am looking at the diffs, between -19 and -18, for the text that provides such a clarification, but do not see it. Can you point me to it?

I agree that the nodes defined in RFC 8795 do not need to copied here. However, the nodes that are defined in this draft, and do not exist in RFC 8795 need to have their own Security Considerations. By leaving the section blank for each of writeable/readable/actionable (RPCs) sections, I am not sure what is being implied. At the minimum, the document needs to say for each of the writeable/readable/actionable sections, that the nodes in this document have no security considerations.

Great. Was it validated using any of the tools, e.g. yanglint?

See: https://mailarchive.ietf.org/arch/msg/ccamp/csoJyLQ33mDdjTUiw95l9Dr9-Jk/

italobusi commented 2 months ago

I am looking at the diffs, between -19 and -18, for the text that provides such a clarification, but do not see it. Can you point me to it?

This the change we have done:

OLD

   The OTN topology model also allows reporting of the access links that          
   support the transparent client signals, defined in

NEW

   The OTN topology model also includes information about the access    
   links that support the transparent client signals, defined in