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

[Vladimir Vassilev <[e-mail]>]

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.

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
>