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

From: t petch <[email-masked]>
Date: Mon, 13 Dec 2021 10:39:42 +0000

I find the title of this I-D clunky and since the title is something 
that should stay the same for the life of a document, then I think that 
that should be changed before adoption.

Network Interconnect Tester Management is, well , clunky.

Reading the I-D it would appear to be CSMA-CD only in which case I 
expect the title to reflect that so something like

YANG Modules for the Management of CSMA-CD Network Tests.

YANG Modules for the Management of CSMA-CD Network Testing.

YANG Modules for the Management of Tests of CSMA-CD Networks.

I find the Abstract likewise inappropriate but see that as something 
that can be changed later.

Tom Petch

On 08/11/2021 15:33, Vladimir Vassilev wrote:
>
> On 08/11/2021 15.52, Vladimir Vassilev wrote:
>> Hi,
>>
>> In summary
>>
>> 1. Tom Petch posted an objection based on the prefixes for the
>> traffic-analyzer and traffic-generator modules being too short. The
>> only change in -07 addresses this concern and updates the prefixes
>> from tg: -> nttg:, "ta:" -> "ntta:".
>>
>> 2. Jürgen Schönwälder provided useful input on the YANG design of the
>> modules. Recommendations that the work group can take into account if
>> it decides to adopt this draft.
>
>
> One significant point raised by Juergen that did not have to do with the
> design of the YANG modules that needs to be formally addressed:
>
>> - Why would a WG work on this and then publish the result as
>>     Informational and not Standards Track?
>
> The rule of thumb is that all drafts with YANG modules have to be in the
> Standards Track.
>
>
> /Vladimir
>
>
>>
>> /Vladimir
>>
>>
>> On 08/09/2021 15.35, MORTON JR., AL wrote:
>>> BMWG:
>>>
>>> A WG Adoption Call for the Internet-Draft on
>>>
>>>        A YANG Data Model for Network Interconnect Tester Management
>>>             draft-vassilev-bmwg-network-interconnect-tester-06
>>>
>>> will be open from 8 September through 6 October, 2021.
>>>
>>> Please weigh-in on this topic by providing:
>>>   + whether or not you believe the working group should adopt this
>>> Internet-Draft
>>> as a work item, for eventual publication as an Informational RFC.
>>> + your current comments on the draft from your adoption call review
>>> (recent comments on the list should be referenced).
>>> + whether or not you are willing to review new versions of the draft
>>> during
>>> development.
>>>
>>> Send your comments to this list @[email-masked]
>>>
>>> A URL for this Internet-Draft is [0]
>>>
>>> Al
>>> bmwg co-chair
>>>
>>> [0]
>>> https://datatracker.ietf.org/doc/html/draft-vassilev-bmwg-network-interconnect-tester-06.txt
>>>
>>>
>>> _______________________________________________
>>> bmwg mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/bmwg
>>
>> _______________________________________________
>> bmwg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/bmwg
>
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg

---

From: Gábor LENCSE <[email-masked]>
Date: Mon, 13 Dec 2021 13:08:40 +0100

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.

Best regards,

Gábor

12/13/2021 11:39 AM keltezéssel, t petch írta:
> that should stay the same for the life of a document, then I think 
> that that should be changed before adoption.
>
>

---

From: t petch <[email-masked]>
Date: Mon, 13 Dec 2021 12:34:15 +0000

> Ethernet is practically used full duplex, so I think it should be of

This is two YANG modules and the import of them is conditional on the 
interface being of type ethernetCsmacd as specified in RFC3635.  As it 
stands, the title suggests that this I-D is applicable everywhere, X.25, 
token ring etc which I think misleading.  In the context of YANG 
modules, which is what this I-D is all about, then I think Csmacd or 
ethernetCsmacd is accurate.

Tom Petch

---

From: Vladimir Vassilev <[email-masked]>
Date: Mon, 13 Dec 2021 18:46:56 +0100

Hi Tom and Gabor,

> Ethernet is practically used full duplex, so I think it should be of 

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.

While not spelled out this is also true for RFC2544.

/Vladimir

---

From: t petch <[email-masked]>
Date: Tue, 14 Dec 2021 09:33:18 +0000

> stream of octets consists of a sequence of 1. frames and 2. interframe

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.  That limitation should be 
reflected in the title.

Tom Petch

> .

---

From: Vladimir Vassilev <[email-masked]>
Date: Wed, 15 Dec 2021 00:31:01 +0100

On 14/12/2021 10.33, t petch wrote:

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

/Vladimir

---

From: t petch <[email-masked]>
Date: Wed, 15 Dec 2021 09:39:48 +0000

> Do you agree this is the same limitation RFC2544 fails to reflect in its

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.

Tom Petch