[Softwires] Benjamin Kaduk's Discuss on draft-ietf-softwire-yang-14: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-softwire-yang-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-softwire-yang/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document has 7 listed authors/editors.  Since, per RFC 7322, documents
listing more than five authors are unusaul, and seven is greater than five,
let's talk about the author count.

The binding-table-versioning container's "version" leaf is of type uint64
but the in-module description indicates that it is a timestamp.  If it is
actually supposed to be a timestamp, then the units and zero time need to
be specified, but it seems more likely that this should just be described
as an abstract version number, if I understand the prose text about this
container correctly.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please expand CE on first usage.

Section 4.1

It feels a little strange to put something as generic as
/if:interfaces/if:interface/if:statistics:sent-ipv4-packets in the
ietf-softwire-ce module.  Are these counters likely to be useful for other
(non-softwire?) tunneling techniques?

Section 5.2

   o  softwire-num-max: used to set the maximum number of softwire
      binding rules that can be created on the lw4o6 element
      simultaneously.  This paramter must not be set to zero because
      this is equivalent to disabling the BR instance.

This seems to leave it ambiguous whether a server should reject an attempt
to set it to zero, or accept it but diable the BR instance.

Section 7

            leaf enable-hairpinning {
              type boolean;
              default "true";
              description
                "Enables/disables support for locally forwarding
                 (hairpinning) traffic between two CEs.";
              reference "Section 6.2 of RFC7596";

Is a global toggle sufficient or would there be cases where more
fine-grained control would be needed?

Section 8

    container algo-versioning {
[...]
      leaf date {

        type yang:date-and-time;
        description
          "Timestamp when the algorithm instance was activated.

           An algorithm instance may be provided with mapping
           rules that may change in time (for example, increase
           the size of the port set). When an abuse party
           presents an external IP address/port, the version
           of the algorithm is important because depending on
           the version, a distinct customer may be identified.

nit: "abuse party" is probably not a term that everyone is familiar with.
(similarly in br-instances)

Section 9

Is there any possibility of a situation where the
invalid-/added/modified-entry notifications cause a substantial amount of
notification traffic (i.e., a DoS level of traffic)?