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

[t petch <[e-mail]>]

On 23/03/2022 08:31, Vladimir Vassilev wrote:
>
> 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.

Apologies for the delay - I missed your last message.

Reluctantly, since it will likely have little impact on the quality of 
the work, perhaps
A YANG data model for Network Tester Management.

I would leave the name of the I-D the same - changes there, apart from 
the mandatory one at adoption, make it harder to track the history of an 
I-D.

Tom Petch

>
> /Vladimir
>
>>
>> Tom Petch
>>
> .
>