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

[Vladimir Vassilev <[e-mail]>]

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