Re: [bmwg] Fwd: New Version Notification for draft-vassilev-bmwg-network-interconnect-tester-02.txt

[tom petch <[e-mail]>]

----- Original Message -----
From: "Vladimir Vassilev" <[e-mail]>
To: "tom petch" <[e-mail]>om>; <[e-mail]>
Sent: Monday, October 28, 2019 12:21 PM

> Hello Tom,
>
> On 25/10/2019 18.37, tom petch wrote:
> > Vladimir
> >
> > A quick look suggests some editing is needed.
> >
> > line length exceeds that permitted for an RFC in the YANG tree
diagram -
> > in practical terms, this means the presentation on my screen is a
mess.
> OK
> >
> > reference to BCP 14 is out of date
>
> You are referring to RFC 8174 recently added to BCP 14. It says that
RFC
> 2119 applies only to text where MUST, SHOULD etc. are in capital
letters
> only. Since this draft does not have a single instance of any of those
> words in capital letters the BCP 14 reference altogether can be
removed.
> Do you agree this is the correct action?

Vladimir,

not really.  You do have a lower case 'should' and there has been much
debate over the years as to whether or not that is meant to be Normative
or not and the latest BCP14 makes that clear so I think that you should
have the latest BCP14 boiler plate.

Also, come Last Call, you may find reviewers wanting you to clarify
points and add text which does include SHOULD or MUST and then you have
to add it back in, so I would include the latest text.

Picking up the point below about vlan, this is where the IETF is not
doing the job it might.  'vlan' appears in many YANG modules with
several flavours thereof; yes, we might get a better resolution on the
netmod list but really, apart from our IEEE liaison, I do not know where
to go for the best advice on this.  I saw this issue surface recently on
I2RS which, thinking about it, makes sense and there, the outcome was
     import ieee802-dot1q-types {...      reference
        "IEEE Std 802.1Qcp-2018: Bridges and Bridged
         Networks - Amendment: YANG Data Model.";
i.e. anything vlan we import from the IEEE module.  I did query making
an IETF module normatively dependent on an IEEE module and the ADs said
that that was fine so that is the direction in which I think that the
IETF should go.

Tom Petch

> > 1.1.2.  Tree Diagram
> > "included in  this draft,"
> > Think positive and assume it will always be a draft - suggest
> > 'in this document'
> OK
> >
> > YANG import statements lack references
> OK
> >
> >      reference       "RFC XXXX: Network Interconnect Tester";
> > this is not quite the same as the title of the I-D - should be the
same
> OK
> > IMHO
> >
> > need more references for the leaf or grouping;
> > you have
> >        "IEEE 802-2014 Clause 9.2";
> > which then needs to be in the I-D Normative References while
> >   802.1q
> > needs to be a reference and in the I-D references and I think is the
> > wrong document for VLAN i.e. replaced by a later IEEE one; this came
up
> > recently in an IETF Last Call
> >
> > 802.1p
> > likewise.
> I suggest we clarify this one on the netmod list and see if we can
avoid
> the local definition of Ethernet packet header grouping in the
> traffic-generator module and instead move it to ietf-if-ethernet.yang
> and import it from there. Same goes for the Ethernet specific filter
> definitions part of the traffic-analyzer and instead reuse mechanisms
> from ietf-access-control-list.yang
> > 8.  Security Considerations
> > requires the boiler plate from YANG Guidelines
> OK
> >
> > Normative References
> > you need about a dozen more which make it much easier to review!
> OK
> >
> > I realise that these are non-technical issues but I find it fruitful
to
> > start with these and form an opinion of the I-D first, and then look
at
> > technical ones.
>
> I will address all of these non-technical issues in the next revision
of
> the draft. Thank you for your detailed review.
>
> Vladimir
>
> >
> > Tom Petch
> >
> >
> > ----- Original Message -----
> > From: "Vladimir Vassilev" <[e-mail]>
> > To: <[e-mail]>
> > Cc: <[e-mail]>
> > Sent: Friday, October 25, 2019 3:02 PM
> >
> >
> >> Hi,
> >>
> >> I would like to make the following presentation request for the
IETF
> > 106
> >> bmwg session:
> >>
> >>    - name of the drafts:
> > draft-vassilev-bmwg-network-interconnect-tester-02
> >>    - name of presentation: A YANG Data Model for Network
Interconnect
> >> Tester Management
> >>    - name of the presenter(s): Vladimir Vassilev
> >>    - desired time request (in minutes): 10-15 min
> >>    - local or remote: local
> >>
> >> Early reviews of the draft and feedback on the mailing list is
> > welcome.
> >> In addition to the presentation I have added a hackathon project
> > "BMWG -
> >> Implement RFC2544 for NETCONF/YANG managed tester and DUT"
> >>
> >> Expected result: Standalone command line application written in
Python
> >> connecting directly to the DUT and the tester over NETCONF
executing
> > the
> >> RFC2544 test and reporting the results.
> >>
> >> I am bringing a prototype FPGA based hardware implementing the
> >> NETCONF/YANG interface published in the draft which has more
> >> deterministic behavior then the software implementation completed
> > during
> >> the last hackathon.
> >>
> >> Anyone interested in this work is welcome to join the team.
> >>
> >> Vladimir
> >>
> >> -------- Forwarded Message --------
> >> Date: Tue, 08 Oct 2019 05:17:47 -0700
> >> From: [e-mail]
> >> To: Vladimir Vassilev <[e-mail]>
> >>
> >> A new version of I-D,
> > draft-vassilev-bmwg-network-interconnect-tester-02.txt
> >> has been successfully submitted by Vladimir Vassilev and posted to
the
> >> IETF repository.
> >>
> >> Name: draft-vassilev-bmwg-network-interconnect-tester
> >> Revision: 02
> >> Title: A YANG Data Model for Network Interconnect Tester Management
> >> Document date: 2019-10-08
> >> Group: Individual Submission
> >> Pages: 25
> >> URL:
> >>