draft-ietf-sfc-proof-of-transit: yang review 2

[shwethab]

https://mailarchive.ietf.org/arch/msg/sfc/ZOf8Yb_JK68v9O40PbD2MSjqJ48/

(1) Remove "?" from the explanation text in Section 5.2.1

...FB: Will do.

(2)

OLD:
The meaning of the symbols in these diagrams is
as follows:

o Brackets "[" and "]" enclose list keys.

o Abbreviations before data node names: "rw" means configuration
(read-write), and "ro" means state data (read-only).

o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list.

o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").

o Ellipsis ("...") stands for contents of subtrees that are not
shown.

NEW:
The meaning of the symbols in YANG tree diagrams is defined in [RFC8340].

...FB: Good point. We can indeed get rid of the legacy text and refer to RFC8340.

(3) Remove and from the tree diagram

...FB: Will do.

(4) Instead of:

       +--rw active-profile-index?   profile-index-range

You can define a status leaf under pot-profile-list to indicate the activation
status.

...FB: Very doable - especially since the open source implementation in VPP also only uses and active and a standby profile.

(5) Any reason why are you using version 1? If not, please update to "1.1"

...FB: Nothing specific. The model got defined (and implemented as part of OpenDaylight) back in 2016.

(6) As your groupings are called only once, and unless you want to define them
as reusable by other modules, you may just define those as part of the main
container.

...FB: We could consider doing so. The reason why we kept the model fairly stable so far was that there is an existing implementation in open source (Opendaylight), hence the preference to not change things unless there is a real need. Would you be ok to stay with the current structure?

(7) IANA Section should be updated as follows:

OLD:
This document does not require any actions from IANA.

NEW:

IANA is requested to register the following URI in the "ns" subregistry within
the "IETF XML Registry" [RFC3688]:

  URI:  urn:ietf:params:xml:ns:yang:ietf-pot-profile
  Registrant Contact:  The IESG.
  XML:  N/A; the requested URI is an XML namespace.

IANA is requested to register the following YANG module in the "YANG Module
Names" subregistry [RFC7950] within the "YANG Parameters" registry.

  Name:  ietf-pot-profile
  Maintained by IANA:  N
  Namespace:  urn:ietf:params:xml:ns:yang:ietf-pot-profile
  Prefix:  ietf-pot-profile
  Reference:  RFC XXXX

(7) You should update the Security Section as per
https://trac.ietf.org/trac/ops/wiki/yang-security-guideline.

...FB: ACK on both points above.

And a more general note:

==
Several deployments use Traffic Engineering, policy routing, Segment
Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer
packets through a specific set of nodes. In certain cases,
regulatory obligations or a compliance policy require operators to
^^^^^^^^^^^^^^^^^^^^^^
prove that all packets that are supposed to follow a specific path
are indeed being forwarded across and exact set of pre-determined
nodes.

Do you have pointers to such regulatory obligations? It would be good to add a
pointer if you are aware of any. Thanks.

...FB: One of the co-authors and initiators of POT, Stephen, might have more specific references available.

From what I know, there are company policies that require path verification. In case we don't find a formal reference, we'll change the statement in the next revision and avoid mentioning "regulatory obligations".

Hope this helps.

Very helpful indeed. Thanks again.

Cheers, Frank

Cheers,
Med