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

From: Vladimir Vassilev <[email-masked]>
Date: Fri, 25 Oct 2019 14:02:04 +0000

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 --------
Subject: 	New Version Notification for 
draft-vassilev-bmwg-network-interconnect-tester-02.txt
Date: 	Tue, 08 Oct 2019 05:17:47 -0700
From: 	[email-masked]
To: 	Vladimir Vassilev <[email-masked]>

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: 
https://www.ietf.org/internet-drafts/draft-vassilev-bmwg-network-interconnect-tester-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-vassilev-bmwg-network-interconnect-tester/
Htmlized: 
https://tools.ietf.org/html/draft-vassilev-bmwg-network-interconnect-tester-02
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-vassilev-bmwg-network-interconnect-tester
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-vassilev-bmwg-network-interconnect-tester-02

Abstract:
This document introduces new YANG model for use in network
interconnect testing containing modules for traffic generator and
traffic analyzer.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: tom petch <[email-masked]>
Date: Fri, 25 Oct 2019 16:37:45 +0000

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.

reference to BCP 14 is out of date

1.1.2.  Tree Diagram
"included in  this draft, "
Think positive and assume it will always be a draft - suggest
'in this document'

YANG import statements lack references

    reference       "RFC XXXX: Network Interconnect Tester";
this is not quite the same as the title of the I-D - should be the same
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.

8.  Security Considerations
requires the boiler plate from YANG Guidelines

Normative References
you need about a dozen more which make it much easier to review!

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.

Tom Petch

----- Original Message -----
From: "Vladimir Vassilev" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 25, 2019 3:02 PM

>   - name of the drafts:
draft-vassilev-bmwg-network-interconnect-tester-02
> A new version of I-D,
> Group: Individual Submission
https://www.ietf.org/internet-drafts/draft-vassilev-bmwg-network-interco
nnect-tester-02.txt
> Status:
https://datatracker.ietf.org/doc/draft-vassilev-bmwg-network-interconnec
t-tester/
> Htmlized:
https://tools.ietf.org/html/draft-vassilev-bmwg-network-interconnect-tes
ter-02
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-vassilev-bmwg-network-interc
onnect-tester
> Diff:
https://www.ietf.org/rfcdiff?url2=draft-vassilev-bmwg-network-interconne
ct-tester-02
> _______________________________________________
> bmwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg
>

---

From: Vladimir Vassilev <[email-masked]>
Date: Mon, 28 Oct 2019 12:21:38 +0000

Hello Tom,

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

>
> 1.1.2.  Tree Diagram
> "included in  this draft,"
OK
> YANG import statements lack references
OK
> this is not quite the same as the title of the I-D - should be the same
OK
> recently in an IETF Last Call
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
> requires the boiler plate from YANG Guidelines
OK
> you need about a dozen more which make it much easier to review!
OK
> start with these and form an opinion of the I-D first, and then look at

I will address all of these non-technical issues in the next revision of 
the draft. Thank you for your detailed review.

Vladimir

---

From: tom petch <[email-masked]>
Date: Tue, 29 Oct 2019 12:32:15 +0000

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

> 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

> >> I would like to make the following presentation request for the
IETF
> > 106
> >> connecting directly to the DUT and the tester over NETCONF
executing
> > the