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

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 16 Mar 2022 22:22:51 +0100

Hi Tom,

On 15/12/2021 10.39, t petch wrote:
>
> On 14/12/2021 23:31, Vladimir Vassilev wrote:
>> On 14/12/2021 10.33, t petch wrote:
>>
>>> On 13/12/2021 17:46, Vladimir Vassilev wrote:
>>>> Hi Tom and Gabor,
>>>>
>>>>
>>>> On 13/12/2021 13.08, Gábor LENCSE wrote:
>>>>> Dear All,
>>>>>
>>>>> To be honest, I haven't read the draft.
>>>>>
>>>>> I just wonder, if the entire draft is about CSMA/CD. As time passes,
>>>>> Ethernet is practically used full duplex, so I think it should be of
>>>>> primary interest.
>>>>
>>>> The draft is not about CSMA/CD in particular. It is targeting any
>>>> networking technology where the data plane in any of the interface
>>>> directions can be represented as a stream of octets. And where the
>>>> stream of octets consists of a sequence of 1. frames and 2. interframe
>>>> gaps.
>>>
>>> I continue to oppose adoption until the I-D has a less clunky and more
>>> accurate title.
>>>
>>> Reading YANG modules in the I-D, it is clear that the focus is on such
>>> as IEEE802, IEEE1588, MAC address, Ethernet, burst, interframe gap etc
>>> so while the approach is valid for a number of protocols there are
>>> plenty more for which it is invalid.
>>
>>
>> But this argument is also valid for RFC2544 among many other non-BMWG
>> documents (RFC8519 ... , etc.) This draft has the same requirements for
>> the network interface technologies it is applicable for as RFC2544 has.
>> It is for packet-switched network interfaces only indeed.
>>
>>> That limitation should be reflected in the title.
>>
>> Do you agree this is the same limitation RFC2544 fails to reflect in its
>> title?
>
> As an aside, I don't care about RFC2544; historically there are a lot 
> of RFC with bad bits in them and with the possible exception of a 
> -bis, there is no reason not to look for an improvement.
>
> I find the title of this I-D clunky and want that fixed.  I do not 
> have the same problem with the title of RFC2544.

Do you have a specific title proposal?

If the absolute goal is to make it "less clunky" by spelling the actual 
limitation of the model logic then this is one possible change:

"A YANG Data Model for Network Interconnect Tester Management" ->

"A YANG Data Model for Network Interconnect Tester Management where Traffic can be Represented as Stream of Gap and Frame Octets"

However it is easy to add a default case to the YANG model and move the 
leafs that model the traffic as stream of octets (interframe-gap etc.) 
there so that alternative models can be supported through augments from 
external modules.

I prefer this option to this particular title change.

/Vladimir

>
>
> Tom Petch
>
>
>
>>
>>
>> /Vladimir
>>
>>
>>>
>>> Tom Petch
>>>
>>>> While not spelled out this is also true for RFC2544.
>>>>
>>>>
>>>> /Vladimir
>>>>
>> .
>>

---

From: t petch <[email-masked]>
Date: Thu, 17 Mar 2022 16:48:27 +0000

> limitation of the model logic then this is one possible change:

No that is not my intention.  I think that many engineers do not 
appreciate the qualities that an identifier should have and so seek to 
incorporate too much of the semantics in what should be compact, easy to 
use and unique within the namespace.

It is the 'Network Interconnect Tester Management' that I find clunky 
and would like to be less than a string of four nouns so I want 
something along the lines of
'A YANG Data Model for Testing Interconnections'
I think that 'network' is redundant and 'tester' is not quite right, 
more a human than a piece of technology; and what are YANG Data Models 
about but management?

Tom Petch

> "A YANG Data Model for Network Interconnect Tester Management where
> Traffic can be Represented as Stream of Gap and Frame Octets"
>
>

---

From: Vladimir Vassilev <[email-masked]>
Date: Fri, 18 Mar 2022 15:34:55 +0100

On 17/03/2022 17.48, t petch wrote:
> incorporate too much of the semantics in what should be compact, easy 
> to use and unique within the namespace.
>
> more a human than a piece of technology;

The term "Network Interconnect Device" is from the title of RFC2544 and 
the term "Tester" is from sec. 6 of RFC2544.

I will add this terminology reference in the introduction.

This draft introduces model that can manage a superset of the tester 
functionality needed for a RFC2544 benchmark. However the RFC2544 
required functionality is the focus and it is indeed a network 
interconnect device and not stateful protocols, firewall or other area 
specific tester functionality in scope of the draft.

> and what are YANG Data Models about but management?

There are some precedents like:

RFC8343 - "A YANG Data Model for Interface Management"

RFC8344 - "A YANG Data Model for IP Management" RFC8022 - "A YANG Data 
Model for Routing Management" So I followed that title pattern. IMO you 
probably have a point but the tautology in the template "A YANG data 
model for ... Management" is not introduced in this draft. /Vladimir

---

From: t petch <[email-masked]>
Date: Mon, 21 Mar 2022 12:23:39 +0000

>>>>>>> On 13/12/2021 13.08, Gábor LENCSE wrote:
<snip>
> model for ... Management" is not introduced in this draft. /Vladimir

I find these titles clear and easy to use, unlike the proposed title for 
this I-D.  These lack the <noun><noun><noun><noun> construct that I 
refer to as clunky, for want of a better word.

Tom Petch

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 23 Mar 2022 09:31:44 +0100

On 21/03/2022 13.23, t petch wrote:
> I find these titles clear and easy to use, unlike the proposed title 
> for this I-D.  These lack the <noun><noun><noun><noun> construct that 
> I refer to as clunky, for want of a better word.

IMO  the title template "A YANG data model for <noun> Management" works 
for compound nouns too. Especially if the compound nouns are terms 
widely used in the workgroup e.g. Network Interconnect Device. We can 
pick a shorter version too:

* Tester
* Network Tester
* Network Interconnect Tester (current)

* Network Interconnect Device Tester (even longer)

I am OK with any of the above options.

/Vladimir