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

["MORTON JR., AL" <[e-mail]>]

Hi Vladimir, see far below,

> -----Original Message-----
> From: bmwg <[e-mail]> On Behalf Of t petch
> Sent: Wednesday, April 27, 2022 11:41 AM
> To: Vladimir Vassilev <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [bmwg] WG Adoption Call for draft-vassilev-bmwg-network-
> interconnect-tester-07
> 
> 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
[acm] 

Can you accept Tom's proposal? I think can conclude WG Adoption if so.

Let us know, thanks,
Al
bmwg co-chair


> 
> >
> > /Vladimir
> >
> >>
> >> Tom Petch
> >>
> > .
> >
> 
> _______________________________________________
> bmwg mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bmwg__;!!Bhd
> T!l17Me3CDEcR16blokZwcAJXZIlqvc_braTl2c0P7HWZO6MM-
> LVsYlfe1SXeh5wjuTYorJTQr1tb5$