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

[Vladimir Vassilev <[e-mail]>]

On 21/03/2022 13.23, t petch wrote:
> On 18/03/2022 14:34, Vladimir Vassilev wrote:
>>
>> On 17/03/2022 17.48, t petch wrote:
>>> On 16/03/2022 21:22, Vladimir Vassilev wrote:
>>>> 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:
> <snip>
>>>>>>>
>>>>>>> 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:
>>>
>>> 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;
>>
>> 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
>
> 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

>
> Tom Petch
>