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

[t petch <[e-mail]>]

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; and what are YANG Data Models 
about but management?

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