Re: [bmwg] WG Adoption Call for draft-vassilev-bmwg-network-interconnect-tester-06

[tom petch <[e-mail]>]

From: Vladimir Vassilev <[e-mail]>
Sent: 10 September 2021 08:43

On 09/09/2021 12.05, tom petch wrote:
> From: bmwg <[e-mail]> on behalf of MORTON JR., AL <[e-mail]>
> Sent: 08 September 2021 14:35
>
> BMWG:
>
> A WG Adoption Call for the Internet-Draft on
>
>        A YANG Data Model for Network Interconnect Tester Management
>             draft-vassilev-bmwg-network-interconnect-tester-06
>
> will be open from 8 September through 6 October, 2021.
>
> Please weigh-in on this topic by providing:
>
> + whether or not you believe the working group should adopt this Internet-Draft
> as a work item, for eventual publication as an Informational RFC.
> + your current comments on the draft from your adoption call review
> (recent comments on the list should be referenced).
> + whether or not you are willing to review new versions of the draft during
> development.
>
> <tp>
> Oppose
>
> I commented in January and some of my comments have been addressed, some have not.
>
> The one I regard as most significant is that this uses two character prefix for the YANG modules.  Prefix must be unique across the entire IETF, everything from every WG, everything not from a WG, so while brevity is attractive, I see them as belonging with modules that will be widely used, widely known - interfaces comes to mind. I do not see this in this category,
>
> I have yet to see a YANG doctor approve of a two-character prefix but I have seen opposition.


There is no problem to add longer prefixes. "tg:" -> "nttg:", "ta:" ->
"ntta:" where "nt" stands for network test.

<tp>

If there will be other BMWG YANG modules in the future, then there would be 
a case for grouping them together with a prefix that starts the same, something more generic than 'nt'.  'bmwg' is long IMHO and the 'wg' does not really belong there.  The best I could come up with would be 'bm' which did not seem very good so I did not mention it before.  WG like PIM and LDP have the advantage of us here.  The current list of prefix, some good, can be seen in iana under 'YANG Module Names'

Tom Petch

The intention with this draft is to provide "widely used, widely known"
modules. The equivalent of ping and tcpdump functionality in YANG terms
but also very deterministic and precise method for specification of test
traffic for the dataplane. If the IETF and the authors manage to pull
this off these modules will be the base modules augmented by vendors of
network test equipment and very likely regular networking equipment will
have implementation for verification and troubleshooting purposes.

There is reference code that implements RFC2544 as a simple python
script using the model specified in the draft -
https://github.com/vlvassilev/litenc/blob/master/tntapi/example/ietf-network-interconnect-tester/rfc2544.py


and a reference device side implementation with open-source and
open-hardware design  -
https://www.hackster.io/lightside-instruments/network-programmability-kit-for-ultra96-07435c


significant part of this work was done at IETF Hackathon events.


/Vladimir


>
> The author's response was to do it later n the process, that it would mean changing code.  Well the later in the process the more code there will be to change, more work, more mistakes from anyone involved..
>
> There are other glitches in the  YANG module but I see this as the one to fix before considering any other.
>
> Tom Petch
>
>
> Send your comments to this list @[e-mail]
>
> A URL for this Internet-Draft is [0]
>
> Al
> bmwg co-chair
>
> [0] https://datatracker.ietf.org/doc/html/draft-vassilev-bmwg-network-interconnect-tester-06.txt
>