Subject: [Idr] Robert Wilton's No Objection on draft-ietf-idr-flow-spec-v6-19: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Wed, 04 Nov 2020 02:52:12 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-idr-flow-spec-v6-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

Thank you for this document.  Even without the specific domain knowledge I
found this document easy to read and understand.

A couple of minor comments that you may wish to consider:

    3.  IPv6 Flow Specification components

       Types 4, 5, 6, 9, 10 and 11, as defined in [I-D.ietf-idr-rfc5575bis],
       also apply to IPv6.

Also giving the descriptive names for these types might aid the reader here.

    3.3.  Type 3 - Upper-Layer Protocol

       This component uses the Numeric Operator (numeric_op) described in
       [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1.  Type 3 component values
       SHOULD be encoded as single octet (numeric_op len=00).

The "(numeric_op len=00)" threw me off at first, until I referenced back to
section 4.2.1.1.  Possibly, this might be more clear as "(i.e., numeric_op len
field=00)".  Obviously, if you decide to change this, then there are other
places that need to be updated as well.

    3.4.  Type 7 - ICMPv6 Type

The text wasn't super clear to me whether the a Type 3 componet could/should be
specified to match protocol-value 58 as well as a Type 7 field. I would presume
that either is allowed, but I was unsure whether it might be helpful to clarify
this further.

Regards,
Rob

---

From: Christoph Loibl <[email-masked]>
Date: Mon, 9 Nov 2020 10:45:29 +0100

Hi Robert,

> On 04.11.2020, at 11:52, Robert Wilton via Datatracker <[email-masked]> wrote:
> Thank you for this document. Even without the specific domain knowledge I found this document easy to read and understand.

Thank you for your review. We considered your comments and edited the document (see my answers inline below). The updated document will be published soon (datatracker is closed, so we cannot update too often) - see the attached document.

Cheers Christoph

> ```
> ```

Christoph: Added the names of the types.

> ```
> ```
> The "(numeric_op len=00)" threw me off at first, until I referenced back to section 4.2.1.1. Possibly, this might be more clear as "(i.e., numeric_op len field=00)". Obviously, if you decide to change this, then there are other places that need to be updated as well.
> 

Christoph: I would rather stick to the current version since it is exactly the expression that rfc5575bis uses. 

> ```
> ```
> The text wasn't super clear to me whether the a Type 3 componet could/should be specified to match protocol-value 58 as well as a Type 7 field. I would presume that either is allowed, but I was unsure whether it might be helpful to clarify this further.

Christoph: You may add a Type 3 component matching on protocol-value 58. However it is not needed, because you can only match ICMPv6 Type numbers when the packet actually is a ICMPv6 packet. This is also true with TCP/UDP port numbers ICMPv6 Code. We are actually reusing the text from rfc5575bis.

-- 
Christoph Loibl
[email-masked] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 9 Nov 2020 09:54:09 +0000

Hi Christoph,

Thanks for the update.  I've not checked your doc, but your answers look fine.

Regards,
Rob

From: Christoph Loibl <[email-masked]>
Sent: 09 November 2020 09:45
To: Rob Wilton (rwilton) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Idr] Robert Wilton's No Objection on draft-ietf-idr-flow-spec-v6-19: (with COMMENT)

Hi Robert,

> On 04.11.2020, at 11:52, Robert Wilton via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

Cheers Christoph

--
Christoph Loibl
[email-masked]<mailto:[email-masked]> | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at