Subject: [Last-Call] Opsdir last call review of draft-ietf-idr-flow-spec-v6-17

From: Qin Wu via Datatracker <[email-masked]>
Date: Tue, 20 Oct 2020 07:08:31 -0700

Reviewer: Qin Wu
Review result: Ready

I have reviewed this document on behalf of the Operations and Management
Directorate. I believe this document is well written. One clarification
question I want to ask here is why not consolidate this document into
I-D.ietf-idr-rfc5575bis since rc5575bis has just begun. Regarding Type 13 -
Flow Label , I am wondering why Type 13 component values can not be be encoded
as 8-byte quantities? why len=11 is not supported for IPv6 case? Regarding "the
Sub-Type always TBD" in section 6.1, I want to suggest to add reference to IANA
section, i.e., section 8.2.

---

From: Christoph Loibl <[email-masked]>
Date: Thu, 22 Oct 2020 10:53:53 +0200

Hi Qin,

Thank you for the feedback on the draft. See my answers to your questions inline below.

> On 20.10.2020, at 16:08, Qin Wu via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Qin Wu
> Review result: Ready
> 
> I-D.ietf-idr-rfc5575bis since rc5575bis has just begun.

This has been a longer discussion in the IDR working group and it has been decided that IPv6 FS should remain a separate document. Since this rfc5575-bis is not targeted to introduce new functionality and implementations of RFC5575 can easily adopt rfc5575-bis. At the same time we also agreed that we want to finalise FS IPv6 shortly after the -bis.

> Regarding Type 13 -
> as 8-byte quantities? why len=11 is not supported for IPv6 case?

The 20-bit numeric value fits into a 4-byte value. (8-byte len=11 is fine (the draft has a SHOULD there) but inefficient and not recommended).

> Regarding "the

I will put that on the list for potential changes.

Thanks

Cheers Christoph 

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