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

[Vladimir Vassilev <[e-mail]>]

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:
>>>>>>> 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:
>
> 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

>
> Tom Petch
>
>>
>> "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
>>>>>>
>>>> .
>>>>
>> .
>>