Skip to main content

Dissemination of Flow Specification Rules for IPv6
draft-ietf-idr-flow-spec-v6-22

Revision differences

Document history

Date Rev. By Action
2020-12-31
22 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-12-15
22 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-12-15
22 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-12-15
22 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-12-14
22 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-12-14
22 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-12-14
22 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-12-14
22 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-22.txt
2020-12-14
22 (System) New version approved
2020-12-14
22 (System) Request for posting confirmation emailed to previous authors: Robert Raszuk , Christoph Loibl , Susan Hares
2020-12-14
22 Christoph Loibl Uploaded new revision
2020-12-10
21 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-12-02
21 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-11-25
21 (System) RFC Editor state changed to EDIT
2020-11-25
21 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-11-25
21 (System) Announcement was received by RFC Editor
2020-11-25
21 (System) IANA Action state changed to In Progress
2020-11-25
21 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-11-25
21 Cindy Morgan IESG has approved the document
2020-11-25
21 Cindy Morgan Closed "Approve" ballot
2020-11-25
21 Cindy Morgan Ballot approval text was generated
2020-11-25
21 Alvaro Retana IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2020-11-24
21 Éric Vyncke
[Ballot comment]
Thank you for addressing my DISCUSS point in the security section in the latest revision. I am now balloting a NO OBJECTION so …
[Ballot comment]
Thank you for addressing my DISCUSS point in the security section in the latest revision. I am now balloting a NO OBJECTION so clearing my previous blocking DISCUSS.

Regards

-éric

PS: I still have doubts about the implementation status wiki page though ;-)

-------- IGNORE TEXT BELOW ----------
The rest below is for archival purpose as all the points have been addressed.

Thank you for the work put into this document. It is indeed due time to filter also those IPv6 packets ;-)

Please find below one blocking DISCUSS point, some non-blocking COMMENT points, and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

I am puzzled by the absence of a flow spec for the first Next-Header being a specific value and by the absence of a flowspec for the occurence of any extension header in the extension header chain. Extension headers are an important difference compared to IPv4 and could be 'nasty' as well (e.g., hop-by-hop header). Why was this not considered by the authors ? Or is there another document in the WG to address this issue ?

== COMMENTS ==

-- Section 3.3 --
How is the upper-layer defined here? Basically, how a node can determine whether it is an extension header or an upper-layer header? While I agree that there are not too many new upper-layer protocols being specified, I would prefer to have a definition of "upper-layer" here either by listing (or referring to a IANA registry) all existing extension headers (then all 'next header' not being 'extension header' are by default 'upper layer') or vice-versa.

-- Section 3.6 --
Just curious ;-) Why is bit 7 not used in this encoding ?

-- Section 3.7 --
I share Ben Kaduk's concern about the encoding of the flow label in less than 20 bits.

== NITS ==

-- Section 3.1 (and possibly others) --
Sometimes the field 'length' is all lower case and sometimes it is capitalized.

-- Section 3.8.2 (and possibly others) --
Please use RFC 5952 to write IPv6 addresses.
2020-11-24
21 Éric Vyncke [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss
2020-11-24
21 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-21.txt
2020-11-24
21 (System) New version approved
2020-11-24
21 (System) Request for posting confirmation emailed to previous authors: Christoph Loibl , Robert Raszuk , Susan Hares
2020-11-24
21 Christoph Loibl Uploaded new revision
2020-11-16
20 Benjamin Kaduk [Ballot comment]
Thank you for addressing my discuss (and comment!) points!
2020-11-16
20 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2020-11-16
20 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-11-16
20 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-11-16
20 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-20.txt
2020-11-16
20 (System) New version approved
2020-11-16
20 (System) Request for posting confirmation emailed to previous authors: Robert Raszuk , Susan Hares , Christoph Loibl
2020-11-16
20 Christoph Loibl Uploaded new revision
2020-11-05
19 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-11-05
19 Bernie Volz Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Donald Eastlake. Submission of review completed at an earlier date.
2020-11-05
19 Martin Vigoureux [Ballot comment]
Hi,

should Type 13 for IPv4 be Unassigned or Reserved ?


Nit:
s/and propose/and proposes/
2020-11-05
19 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-11-04
19 Erik Kline
[Ballot comment]
[[ discuss ]]

[ general ]

* I agree with existing discuss points raised.


[[ comments ]]

[ section 3.8,{1,2} ]

* Per …
[Ballot comment]
[[ discuss ]]

[ general ]

* I agree with existing discuss points raised.


[[ comments ]]

[ section 3.8,{1,2} ]

* Per RFC 5952 section 4.3, s/upper hex/lower hex/g for IPv6 address strings.


[[ nits ]]

[ appendix A ]

* s/non of/none of/, I think
2020-11-04
19 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-11-04
19 Murray Kucherawy
[Ballot comment]
Why are the SHOULDs in Section 3.3, 3.4, and 3.5 not MUSTs?  Put another way: When might someone legitimately do other than what …
[Ballot comment]
Why are the SHOULDs in Section 3.3, 3.4, and 3.5 not MUSTs?  Put another way: When might someone legitimately do other than what it says?
2020-11-04
19 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-11-04
19 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-11-04
19 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-11-04
19 Warren Kumari
[Ballot comment]
Thanks to Qin Wu for the OpsDir review. if Qin hadn't asked the "why isn't this folded into the upcoming -bis" (and Christoph's …
[Ballot comment]
Thanks to Qin Wu for the OpsDir review. if Qin hadn't asked the "why isn't this folded into the upcoming -bis" (and Christoph's answer) I would have had to ballot DISCUSS. 

I do support Ben's DISCUSS, and, even more, Eric's
2020-11-04
19 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-11-04
19 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-11-04
19 Robert Wilton
[Ballot comment]
Hi,

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

A couple …
[Ballot 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
2020-11-04
19 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-11-04
19 Robert Wilton
[Ballot comment]
Hi,

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

A couple …
[Ballot 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
2020-11-04
19 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-11-03
19 Éric Vyncke
[Ballot discuss]
Thank you for the work put into this document. It is indeed due time to filter also those IPv6 packets ;-)

Please find …
[Ballot discuss]
Thank you for the work put into this document. It is indeed due time to filter also those IPv6 packets ;-)

Please find below one blocking DISCUSS point, some non-blocking COMMENT points, and some nits.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

I am puzzled by the absence of a flow spec for the first Next-Header being a specific value and by the absence of a flowspec for the occurence of any extension header in the extension header chain. Extension headers are an important difference compared to IPv4 and could be 'nasty' as well (e.g., hop-by-hop header). Why was this not considered by the authors ? Or is there another document in the WG to address this issue ?
2020-11-03
19 Éric Vyncke
[Ballot comment]
== COMMENTS ==

-- Section 3.1 --
Smart idea to have an offset but I wonder whether "Offset < Length < 129" is …
[Ballot comment]
== COMMENTS ==

-- Section 3.1 --
Smart idea to have an offset but I wonder whether "Offset < Length < 129" is true... Esp. with some IPv6 addresses with an embedded IPv4 address (32 bit) at offset 96. Isn't "Offset + Length <= 128" better ?

-- Section 3.3 --
How is the upper-layer defined here? Basically, how a node can determine whether it is an extension header or an upper-layer header? While I agree that there are not too many new upper-layer protocols being specified, I would prefer to have a definition of "upper-layer" here either by listing (or referring to a IANA registry) all existing extension headers (then all 'next header' not being 'extension header' are by default 'upper layer') or vice-versa.

-- Section 3.6 --
Just curious ;-) Why is bit 7 not used in this encoding ?

-- Section 3.7 --
I share Ben Kaduk's concern about the encoding of the flow label in less than 20 bits.

== NITS ==

-- Section 3.1 (and possibly others) --
Sometimes the field 'length' is all lower case and sometimes it is capitalized.

-- Section 3.8.2 (and possibly others) --
Please use RFC 5952 to write IPv6 addresses.
2020-11-03
19 Éric Vyncke [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke
2020-11-03
19 Benjamin Kaduk
[Ballot discuss]
A fairly minor point, but I think that allowing Type 13 (flow label)
component values to be encoded as 2-byte quantities encourages the …
[Ballot discuss]
A fairly minor point, but I think that allowing Type 13 (flow label)
component values to be encoded as 2-byte quantities encourages the
selection of non-random flow label values, and thus violates the
guidance from RFC 6437 that these values "should be chosen such that
their bits exhibit a high degree of variability" and that "third parties
should be unlikely to be able to guess the next value that a source of
flow labels will choose."  While having the short 1-byte encoding for a
flow label of 0 might be reasonable, a 2-byte label can represent at
most 16 bits of the 20-bit identifier space, discouraging the use of the
high 4 bits, when such bits of unpredictability are scarce already.
Let's discuss how big an issue this is and what might be done to
mitigate it.

Please also confirm that we are providing all the information required of
us by RFC 5701 and 5575bis (see comments on Section 6.1); I am not sure
whether I am reading the references correctly in these regards.

There seems to be an error in the sample code (flow_rule_cmp_v6()): the
snippet
              if comp_a.offset < comp_b.offset:
                  return A_HAS_PRECEDENCE
              if comp_a.offset < comp_b.offset:
                  return B_HAS_PRECEDENCE
duplicates the condition, whereas the condition should be swapped for
correct operation.
2020-11-03
19 Benjamin Kaduk
[Ballot comment]
Thanks for this straightforward and easy-to-read document!  Just a few
minor comments.

Section 3.3

  This component uses the Numeric Operator (numeric_op) described …
[Ballot comment]
Thanks for this straightforward and easy-to-read document!  Just a few
minor comments.

Section 3.3

  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).

Why only SHOULD?  (Likewise for Section 3.4, 3.5, etc.)

Section 3.7

  Contains a list of {numeric_op, value} pairs that are used to match
  the 20-bit Flow Label IPv6 header field ([RFC8200] Section 3).

[It seems that RFC 8200 §3 just points to RFC 8200 §6, which itself
mostly points to RFC 6437.  I don't know if it is useful to
short-circuit some of those references.]

Section 3.8.1

  The following example demonstrates the prefix encoding for: "packets
  from ::1234:5678:9A00:0/64-104 to 2001:DB8::/32 and upper-layer-

Where is the "/64-104" notation introduced?  I did not see it in RFC
4291
.  (It also appears in §3.8.2, though the latter uses "/65-104"
to demonstrate the operation of padding.)

Section 4

  The definition for the order of traffic filtering rules from
  [I-D.ietf-idr-rfc5575bis] Section 5.1 is reused with new
  consideration for the IPv6 prefix offset.  As long as the offsets are
  equal, the comparison is the same, retaining longest-prefix-match
  semantics.  If the offsets are not equal, the lowest offset has
  precedence, as this flow matches the most significant bit.

I will note just to confirm my understanding that this procedure seems
to give higher precedence to, e.g., 1234::/1-4 than to
::1234:5678:9a00/81-128 even though the latter is inspecting more bits
of the address/prefix.  (To be clear, some choice has to be made and I
have no reason to prefer a different one over this one, I am just
exploring the consequences of this choice.)

It is again (as per 5575bis) surprising that we allow for a "not-equal"
comparison of differently encoded (e.g., flow label) values that have
the same semantic meaning, but I expect the same response (and no
document change) as when I made the comment the first time.

Section 5

  The validation procedure is the same as specified in
  [I-D.ietf-idr-rfc5575bis] Section 6 with the exception that item a)
  of the validation procedure should now read as follows:

Are there also any AFI/SAFI differences from 5575bis to consider in
terms of "routes received over"/etc.?

Section 6.1

  This extended community uses the same encoding as the IPv6 address
  specific Route Target extended community [RFC5701] Section 2 with the
  high-order octet of the Type always set to 0x80 and the Sub-Type
  always TBD.

RFC 5701 suggests that since we are allocating the "TBD" sub-type value,
we should also state what the semantics of the "local administrator"
2-octet field are.

  Interferes with: All BGP Flow Specification redirect Traffic
  Filtering Actions (with itself and those specified in
  [I-D.ietf-idr-rfc5575bis] Section 7.4).

I think we are supposed to also state what action to take when
encountering interfering actions.

Section 7

It was a little surprising to me that the inability to match (e.g.) TCP
flags or Port values on non-initial IP fragments was not reiterated in
the security considerations of 5575bis.  I don't think it would make
sense to mention that just in this document's security considerations,
though -- if we are to change anything it should be in 5575bis.  But I
guess we had that conversation already, at
https://mailarchive.ietf.org/arch/msg/idr/zvpLPjllvKWFuyraZUVz8lB8Wz0/
and thus no change is expected.

Section 8.1.2

(side note) it seems a little weird to have the IPv4 version be the one
that gets the unqualified (e.g., "Destination Prefix") name.
2020-11-03
19 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2020-11-02
19 Takeshi Takahashi Request for Last Call review by SECDIR Completed: Ready. Reviewer: Takeshi Takahashi. Sent review to list.
2020-11-02
19 Roman Danyliw [Ballot comment]
Thank you to Vincent Roca for the SECDIR review.

Thanks for modernizing Flowspec.

Nits in Appendix A:
s/a array/an array/
s/accorinding/according/
2020-11-02
19 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-11-02
19 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-19.txt
2020-11-02
19 (System) New version approved
2020-11-02
19 (System) Request for posting confirmation emailed to previous authors: Christoph Loibl , Robert Raszuk , Susan Hares
2020-11-02
19 Christoph Loibl Uploaded new revision
2020-11-02
18 (System)   40776: changed ambiguous time:  2020-11-01 01:52:57 --> 2020-11-01 00:52:57
2020-11-01
19 Bernie Volz Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Donald Eastlake.
2020-11-01
18 Barry Leiba
[Ballot comment]
Thanks for clearing up my confusion on the DISCUSS point that I had, and for posting -18 with resolutions to that and my …
[Ballot comment]
Thanks for clearing up my confusion on the DISCUSS point that I had, and for posting -18 with resolutions to that and my comments.

I’ll leave the remaining comment here for the record, leaving it for the editors to do what they think best.

  In the case Length minus Offset is 0 every address matches.  Length
  MUST always be in the range 0-128 and Length minus Offset MUST always
  be 0 or more, otherwise this component is malformed.

Is there actually value in allowing 129 ways to match every address (length=offset=0, length=offset=1, length=offset=87, and so on)?  If not, it seems less prone to error to say that length=offset=0 matches every address, and otherwise length MUST be greater than offset or the component is malformed.  No?
2020-11-01
18 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2020-11-01
18 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-11-01
18 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-18.txt
2020-11-01
18 (System) New version approved
2020-11-01
18 (System) Request for posting confirmation emailed to previous authors: Susan Hares , Robert Raszuk , Christoph Loibl
2020-11-01
18 Christoph Loibl Uploaded new revision
2020-10-31
17 Barry Leiba
[Ballot discuss]
This should be extremely straightforward: either there’s a typo... or I simply don’t understand.  In the Abstract:

  Dissemination of Flow Specification Rules …
[Ballot discuss]
This should be extremely straightforward: either there’s a typo... or I simply don’t understand.  In the Abstract:

  Dissemination of Flow Specification Rules provides a Border Gateway
  Protocol extension for the propagation of traffic flow information
  for the purpose of rate limiting or filtering IPv4 protocol data
  packets.

Is that supposed to say “IPv6”?
2020-10-31
17 Barry Leiba
[Ballot comment]
A few minor comments:

— Section 3.1 —

  The offset has been defined
  to allow for flexible matching on part of …
[Ballot comment]
A few minor comments:

— Section 3.1 —

  The offset has been defined
  to allow for flexible matching on part of the IPv6 address where it
  is required to skip (don't care) of N first bits of the address.

I can’t parse this sentence, nor make sense of the parenthetical.  Can you reword it?

  In the case Length minus Offset is 0 every address matches.  Length
  MUST always be in the range 0-128 and Length minus Offset MUST always
  be 0 or more, otherwise this component is malformed.

Is there actually value in allowing 129 ways to match every address (length=offset=0, length=offset=1, length=offset=87, and so on)?  If not, it seems less prone to error to say that length=offset=0 matches every address, and otherwise length MUST be greater than offset or the component is malformed.  No?

— Section 3.8.1 —

  Neither for the destination prefix pattern (length - offset = 32 bit)
  nor for the source prefix pattern (length - offset = 40 bit) any
  padding is needed (both patterns end on a octet boundary).

This isn’t grammatical.  How about this?:

NEW
  Padding is not needed either for the destination prefix pattern
  (length - offset = 32 bit) or for the source prefix pattern
  (length - offset = 40 bit), as both patterns end on a octet
  boundary.
END
2020-10-31
17 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2020-10-28
17 Martin Duke
[Ballot comment]
IIUC the truth table for Type 12 (Fragment) is as follows:

          Offset = 0          …
[Ballot comment]
IIUC the truth table for Type 12 (Fragment) is as follows:

          Offset = 0            Offset > 0

M = 0    NOT (FF | IsF)  (LF)       

M = 1      (FF)                    ?

IsF is the two right cells in the table, but there is no way to express the lower right cell using these semantics. If IsF meant "neither first nor last fragment" it would be possible to express all possibilities using the bitmask and bitmask_op. Maybe that's a use case we don't envision right now, but I don't see any downside in being able to express it.

Otherwise, this is a great document. Thanks!
2020-10-28
17 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-10-27
17 Bernie Volz Request for Telechat review by INTDIR is assigned to Donald Eastlake
2020-10-27
17 Bernie Volz Request for Telechat review by INTDIR is assigned to Donald Eastlake
2020-10-26
17 Carlos Pignataro Assignment of request for Telechat review by INTDIR to Carlos Pignataro was rejected
2020-10-26
17 Bernie Volz Request for Telechat review by INTDIR is assigned to Carlos Pignataro
2020-10-26
17 Bernie Volz Request for Telechat review by INTDIR is assigned to Carlos Pignataro
2020-10-26
17 Éric Vyncke Requested Telechat review by INTDIR
2020-10-25
17 Dale Worley Request for Last Call review by GENART Completed: Ready. Reviewer: Dale Worley. Sent review to list.
2020-10-23
17 Vincent Roca Request for Telechat review by SECDIR Completed: Ready. Reviewer: Vincent Roca. Sent review to list.
2020-10-22
17 Tero Kivinen Request for Last Call review by SECDIR is assigned to Takeshi Takahashi
2020-10-22
17 Tero Kivinen Request for Last Call review by SECDIR is assigned to Takeshi Takahashi
2020-10-22
17 Tero Kivinen Request for Telechat review by SECDIR is assigned to Vincent Roca
2020-10-22
17 Tero Kivinen Request for Telechat review by SECDIR is assigned to Vincent Roca
2020-10-22
17 Amy Vezza Placed on agenda for telechat - 2020-11-05
2020-10-22
17 Alvaro Retana IESG state changed to IESG Evaluation from Waiting for Writeup
2020-10-22
17 Alvaro Retana Ballot has been issued
2020-10-22
17 Alvaro Retana [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana
2020-10-22
17 Alvaro Retana Created "Approve" ballot
2020-10-22
17 Alvaro Retana Ballot writeup was changed
2020-10-22
17 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-10-21
17 Min Ye Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Jonathan Hardwick.
2020-10-20
17 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2020-10-20
17 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-flow-spec-v6-17. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-idr-flow-spec-v6-17. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Flow Spec Component Types registry at:

https://www.iana.org/assignments/flow-spec/

the registry will be updated so that [ RFC-to-be ] is added to the reference for the registry.

Second, the existing registry: Flow Spec Component Types

will be changed to include IPv6 Flow Specification Component Types as follows:

Type Value: 0
IPv4 Name: Reserved
IPv6 Name: Reserved
Reference: [ RFC-to-be ]

Type Value: 1
IPv4 Name: Destination Prefix
IPv6 Name: Destination IPv6 Prefix
Reference: [ RFC-to-be ]

Type Value: 2
IPv4 Name: Source Prefix
IPv6 Name: Source IPv6 Prefix
Reference: [ RFC-to-be ]

Type Value: 3
IPv4 Name: IP Protocol
IPv6 Name: Upper-Layer Protocol
Reference: [ RFC-to-be ]

Type Value: 4
IPv4 Name: Port
IPv6 Name: Port
Reference: [ RFC-to-be ]

Type Value: 5
IPv4 Name: Destination Port
IPv6 Name: Destination Port
Reference: [ RFC-to-be ]

Type Value: 6
IPv4 Name: Source Port
IPv6 Name: Source Port
Reference: [ RFC-to-be ]

Type Value: 7
IPv4 Name: ICMP Type
IPv6 Name: ICMPv6 Type
Reference: [ RFC-to-be ]

Type Value: 8
IPv4 Name: ICMP Code
IPv6 Name: ICMPv6 Code
Reference: [ RFC-to-be ]

Type Value: 9
IPv4 Name: TCP flags
IPv6 Name: TCP flags
Reference: [ RFC-to-be ]

Type Value: 10
IPv4 Name: Packet length
IPv6 Name: Packet length
Reference: [ RFC-to-be ]

Type Value: 11
IPv4 Name: DSCP
IPv6 Name: DSCP
Reference: [ RFC-to-be ]

Type Value: 12
IPv4 Name: Fragment
IPv6 Name: Fragment
Reference: [ RFC-to-be ]

Type Value: 13
IPv4 Name: Unassigned
IPv6 Name: Flow Label
Reference: [this document]

Type Value: 14-254
IPv4 Name: Unassigned
IPv6 Name: Unassigned
Reference:

Type Value: 255
IPv4 Name: Reserved
IPv6 Name: Reserved
Reference: [ RFC-to-be ]

Third, in the Generic Transitive Experimental Use Extended Community Sub-Types registry on the Border Gateway Protocol (BGP) Extended Communities registry page located at:

https://www.iana.org/assignments/bgp-extended-communities

a new registration will be made as follows:

Sub-Type Value: TBD
Name: Flow spec rt-redirect-ipv6 format
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-10-20
17 Qin Wu Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Qin Wu. Sent review to list.
2020-10-20
17 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Qin Wu
2020-10-20
17 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Qin Wu
2020-10-20
17 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-17.txt
2020-10-20
17 (System) New version approved
2020-10-20
17 (System) Request for posting confirmation emailed to previous authors: Susan Hares , Robert Raszuk , Christoph Loibl
2020-10-20
17 Christoph Loibl Uploaded new revision
2020-10-19
16 Wesley Eddy Request for Last Call review by TSVART Completed: Ready. Reviewer: Wesley Eddy. Sent review to list.
2020-10-12
16 Wesley Eddy Request for Last Call review by TSVART is assigned to Wesley Eddy
2020-10-12
16 Wesley Eddy Request for Last Call review by TSVART is assigned to Wesley Eddy
2020-10-12
16 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-16.txt
2020-10-12
16 (System) New version approved
2020-10-12
16 (System) Request for posting confirmation emailed to previous authors: Robert Raszuk , Christoph Loibl , Susan Hares
2020-10-12
16 Christoph Loibl Uploaded new revision
2020-10-09
15 Jean Mahoney Request for Last Call review by GENART is assigned to Dale Worley
2020-10-09
15 Jean Mahoney Request for Last Call review by GENART is assigned to Dale Worley
2020-10-08
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alexey Melnikov
2020-10-08
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alexey Melnikov
2020-10-08
15 Min Ye Request for Last Call review by RTGDIR is assigned to Jonathan Hardwick
2020-10-08
15 Min Ye Request for Last Call review by RTGDIR is assigned to Jonathan Hardwick
2020-10-07
15 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-10-07
15 Amy Vezza
The following Last Call announcement was sent out (ends 2020-10-21):

From: The IESG
To: IETF-Announce
CC: jie.dong@huawei.com, idr@ietf.org, Jie Dong , draft-ietf-idr-flow-spec-v6@ietf.org, …
The following Last Call announcement was sent out (ends 2020-10-21):

From: The IESG
To: IETF-Announce
CC: jie.dong@huawei.com, idr@ietf.org, Jie Dong , draft-ietf-idr-flow-spec-v6@ietf.org, idr-chairs@ietf.org, aretana.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Dissemination of Flow Specification Rules for IPv6) to Proposed Standard


The IESG has received a request from the Inter-Domain Routing WG (idr) to
consider the following document: - 'Dissemination of Flow Specification Rules
for IPv6'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-10-21. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Dissemination of Flow Specification Rules provides a Border Gateway
  Protocol extension for the propagation of traffic flow information
  for the purpose of rate limiting or filtering IPv4 protocol data
  packets.

  This specification extends I-D.ietf-idr-rfc5575bis with IPv6
  functionality.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-idr-flow-spec-v6/



No IPR declarations have been submitted directly on this I-D.




2020-10-07
15 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-10-07
15 Alvaro Retana Requested Last Call review by RTGDIR
2020-10-07
15 Alvaro Retana Last call was requested
2020-10-07
15 Alvaro Retana Ballot approval text was generated
2020-10-07
15 Alvaro Retana Ballot writeup was generated
2020-10-07
15 Alvaro Retana IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-10-07
15 Alvaro Retana Last call announcement was generated
2020-09-21
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-09-21
15 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-15.txt
2020-09-21
15 (System) New version approved
2020-09-21
15 (System) Request for posting confirmation emailed to previous authors: Susan Hares , Robert Raszuk , Christoph Loibl
2020-09-21
15 Christoph Loibl Uploaded new revision
2020-08-17
14 Alvaro Retana === AD Review of draft-ietf-idr-flow-spec-v6-14 ===
https://mailarchive.ietf.org/arch/msg/idr/XzAvmUG31Lx4crDNhJ6lcWFYmKs/
2020-08-17
14 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2020-08-12
14 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-14.txt
2020-08-12
14 (System) New version approved
2020-08-12
14 (System) Request for posting confirmation emailed to previous authors: Christoph Loibl , Susan Hares , Robert Raszuk
2020-08-12
14 Christoph Loibl Uploaded new revision
2020-08-05
13 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2020-08-05
13 Alvaro Retana Notification list changed to Jie Dong <jie.dong@huawei.com>, aretana.ietf@gmail.com from Jie Dong <jie.dong@huawei.com>
2020-07-31
13 John Scudder
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.
It defines protocol extensions and procedures for applying BGP flowspec to IPv6 packets.
Yes the type is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  Dissemination of Flow Specification Rules [I-D.ietf-idr-rfc5575bis]
  provides a protocol extension for propagation of traffic flow
  information for the purpose of rate limiting or filtering.  The
  [I-D.ietf-idr-rfc5575bis] specifies those extensions for IPv4
  protocol data packets only.

  This specification extends [I-D.ietf-idr-rfc5575bis] and defines
  changes to the original document in order to make it also usable and
  applicable to IPv6 data packets.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

This document goes relatively smoothly in the WG. There was discussion about whether this draft should merge with another draft (5575bis) which is a revision of flowspec for IPv4. The WG has decided to move forward with 2 separate drafts (V4 and V6 respectively) at current stage. 

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Implementation report:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-flow-spec-v6%20implementations

The features defined in this draft has been implemented by more than 2 vendors and one open source.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd think after the nits are resolved, this document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Nothing beyond the normal checks.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/DstP2r-tUHzYWr9qQXEq0wmu5rk/

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/bIeEFVJ3pv_WS5QNVhmXqEq5a2k/

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/Nw0HSCWUR2_yrgqZQgkM4Z7AZ5Q/


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR Disclosure.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Solid consensus according to the review and discussion on the list.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

None.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

According to the ID nits check, there is 1 error, 6 warnings and 2 comments. The authors needs to resolve the ID nits:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-flow-spec-v6-11.txt


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as either normative or informative?

In addition to the normative and informative references, it also has one reference subsection which contains a URI.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

None of existing RFCs status will be changed by this document.

In both abstraction and introduction, it is mentioned that this is an extension to RFC5575bis, while it is considered RFC5575bis will not be updated by this document.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA section is consistent with the body of the document. A detailed specification of the initial contents for the registry is provided, while that allocations procedures for future registrations are not defined yet.

IANA is requested to create and maintain a new registry entitled:
  "Flow Spec IPv6 Component Types" containing the initial entries as specified in Table 1 of this document.

          +-------+-------------------------+-----------------+
          | Value | Name                    | Reference      |
          +-------+-------------------------+-----------------+
          | 1    | Destination IPv6 Prefix | [this document] |
          | 2    | Source IPv6 Prefix      | [this document] |
          | 3    | Next Header            | [this document] |
          | 4    | Port                    | [this document] |
          | 5    | Destination port        | [this document] |
          | 6    | Source port            | [this document] |
          | 7    | ICMPv6 type            | [this document] |
          | 8    | ICMPv6 code            | [this document] |
          | 9    | TCP flags              | [this document] |
          | 10    | Packet length          | [this document] |
          | 11    | DSCP                    | [this document] |
          | 12    | Fragment                | [this document] |
          | 13    | Flow Label              | [this document] |
          +-------+-------------------------+-----------------+

            Table 1: Registry: Flow Spec IPv6 Component Types

IANA maintains a registry entitled "Generic Transitive Experimental
  Use Extended Community Sub-Types".  For the purpose of this work,
  IANA is requested to assign a new value:

  +------------+----------------------------------------+-------------+
  | Sub-Type  | Name                                  | Reference  |
  | Value      |                                        |            |
  +------------+----------------------------------------+-------------+
  | TBD        |            Flow spec rt-redirect-ipv6 | [this      |
  |            | format                                | document]  |
  +------------+----------------------------------------+-------------+

      Table 2: Registry: Generic Transitive Experimental Use Extended
                            Community Sub-Types

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document defines a new registry, while the allocation procedure is not provided yet.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No review or automated checks required.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG module defined in this document.
2020-07-31
13 John Scudder Responsible AD changed to Alvaro Retana
2020-07-31
13 John Scudder IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-07-31
13 John Scudder IESG state changed to Publication Requested from I-D Exists
2020-07-31
13 John Scudder IESG process started in state Publication Requested
2020-07-31
13 John Scudder Tag Waiting for Referenced Document cleared.
2020-07-30
13 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-13.txt
2020-07-30
13 (System) New version approved
2020-07-30
13 (System) Request for posting confirmation emailed to previous authors: Robert Raszuk , Christoph Loibl , Susan Hares
2020-07-30
13 Christoph Loibl Uploaded new revision
2020-07-10
12 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-12.txt
2020-07-10
12 (System) New version approved
2020-07-10
12 (System) Request for posting confirmation emailed to previous authors: Susan Hares , Christoph Loibl , Robert Raszuk
2020-07-10
12 Christoph Loibl Uploaded new revision
2020-06-23
11 Jie Dong
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.
It defines protocol extensions and procedures for applying BGP flowspec to IPv6 packets.
Yes the type is indicated in the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  Dissemination of Flow Specification Rules [I-D.ietf-idr-rfc5575bis]
  provides a protocol extension for propagation of traffic flow
  information for the purpose of rate limiting or filtering.  The
  [I-D.ietf-idr-rfc5575bis] specifies those extensions for IPv4
  protocol data packets only.

  This specification extends [I-D.ietf-idr-rfc5575bis] and defines
  changes to the original document in order to make it also usable and
  applicable to IPv6 data packets.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

This document goes relatively smoothly in the WG. There was discussion about whether this draft should merge with another draft (5575bis) which is a revision of flowspec for IPv4. The WG has decided to move forward with 2 separate drafts (V4 and V6 respectively) at current stage. 

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

Implementation report:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-flow-spec-v6%20implementations

The features defined in this draft has been implemented by more than 2 vendors and one open source.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd: Jie Dong
Responsible Area Director: Alvaro Retana


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd performed the review on:
1) Nits
2) Technical review 
3) Implementation report
4) IPR check

The document shepherd think after the nits are resolved, this document is ready for publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Nothing beyond the normal checks.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes.

Susan Hares: no IPR
https://mailarchive.ietf.org/arch/msg/idr/DstP2r-tUHzYWr9qQXEq0wmu5rk/

Robert Raszuk: no IPR
https://mailarchive.ietf.org/arch/msg/idr/bIeEFVJ3pv_WS5QNVhmXqEq5a2k/

Christoph Loibl: no IPR
https://mailarchive.ietf.org/arch/msg/idr/Nw0HSCWUR2_yrgqZQgkM4Z7AZ5Q/


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR Disclosure.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Solid consensus according to the review and discussion on the list.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

None.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

According to the ID nits check, there is 1 error, 6 warnings and 2 comments. The authors needs to resolve the ID nits:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-idr-flow-spec-v6-11.txt


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not relevant for MIB Doctor, Media type, or URI.

(13) Have all references within this document been identified as either normative or informative?

In addition to the normative and informative references, it also has one reference subsection which contains a URI.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

None.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

None of existing RFCs status will be changed by this document.

In both abstraction and introduction, it is mentioned that this is an extension to RFC5575bis, while it is considered RFC5575bis will not be updated by this document.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA section is consistent with the body of the document. A detailed specification of the initial contents for the registry is provided, while that allocations procedures for future registrations are not defined yet.

IANA is requested to create and maintain a new registry entitled:
  "Flow Spec IPv6 Component Types" containing the initial entries as specified in Table 1 of this document.

          +-------+-------------------------+-----------------+
          | Value | Name                    | Reference      |
          +-------+-------------------------+-----------------+
          | 1    | Destination IPv6 Prefix | [this document] |
          | 2    | Source IPv6 Prefix      | [this document] |
          | 3    | Next Header            | [this document] |
          | 4    | Port                    | [this document] |
          | 5    | Destination port        | [this document] |
          | 6    | Source port            | [this document] |
          | 7    | ICMPv6 type            | [this document] |
          | 8    | ICMPv6 code            | [this document] |
          | 9    | TCP flags              | [this document] |
          | 10    | Packet length          | [this document] |
          | 11    | DSCP                    | [this document] |
          | 12    | Fragment                | [this document] |
          | 13    | Flow Label              | [this document] |
          +-------+-------------------------+-----------------+

            Table 1: Registry: Flow Spec IPv6 Component Types

IANA maintains a registry entitled "Generic Transitive Experimental
  Use Extended Community Sub-Types".  For the purpose of this work,
  IANA is requested to assign a new value:

  +------------+----------------------------------------+-------------+
  | Sub-Type  | Name                                  | Reference  |
  | Value      |                                        |            |
  +------------+----------------------------------------+-------------+
  | TBD        |            Flow spec rt-redirect-ipv6 | [this      |
  |            | format                                | document]  |
  +------------+----------------------------------------+-------------+

      Table 2: Registry: Generic Transitive Experimental Use Extended
                            Community Sub-Types

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

This document defines a new registry, while the allocation procedure is not provided yet.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

No review or automated checks required.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

No YANG module defined in this document.
2020-04-24
11 Susan Hares 4 implementations have been found online.  Shepherd will need to work with authors to finalize the implementation reports.
2020-04-24
11 Susan Hares Tag Waiting for Referenced Document set.
2020-04-24
11 Susan Hares IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for Implementation
2020-04-24
11 Susan Hares Notification list changed to Jie Dong <jie.dong@huawei.com>
2020-04-24
11 Susan Hares Document shepherd changed to Jie Dong
2020-04-24
11 Susan Hares IETF WG state changed to Waiting for Implementation from In WG Last Call
2020-04-20
11 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-11.txt
2020-04-20
11 (System) New version approved
2020-04-20
11 (System) Request for posting confirmation emailed to previous authors: Christoph Loibl , Robert Raszuk , Susan Hares
2020-04-20
11 Christoph Loibl Uploaded new revision
2020-02-28
10 Susan Hares IPR poll in progress
2020-02-28
10 Susan Hares IETF WG state changed to In WG Last Call from WG Document
2019-11-03
10 Christoph Loibl New version available: draft-ietf-idr-flow-spec-v6-10.txt
2019-11-03
10 (System) New version approved
2019-11-03
10 (System) Request for posting confirmation emailed to previous authors: Danny McPherson , Robert Raszuk , Susan Hares , idr-chairs@ietf.org, " akarch@cisco.com" , Burjiz Pithawala
2019-11-03
10 Christoph Loibl Uploaded new revision
2018-05-19
09 (System) Document has expired
2018-03-21
09 John Scudder Changed consensus to Yes from Unknown
2018-03-21
09 John Scudder Intended Status changed to Proposed Standard from None
2017-11-15
09 Susan Hares New version available: draft-ietf-idr-flow-spec-v6-09.txt
2017-11-15
09 (System) New version approved
2017-11-15
09 (System) Request for posting confirmation emailed to previous authors: Burjiz Pithawala , Danny McPherson , " akarch@cisco.com" , Robert Raszuk , Susan Hares
2017-11-15
09 Susan Hares Uploaded new revision
2017-09-14
08 (System) Document has expired
2017-03-13
08 Susan Hares New version available: draft-ietf-idr-flow-spec-v6-08.txt
2017-03-13
08 (System) New version approved
2017-03-13
08 (System) Request for posting confirmation emailed to previous authors: Burjiz , Danny McPherson , Robert Raszuk , Susan Hares , idr-chairs@ietf.org, " akarch@cisco.com"
2017-03-13
08 Susan Hares Uploaded new revision
2016-09-20
07 (System) Document has expired
2016-03-19
07 Susan Hares New version available: draft-ietf-idr-flow-spec-v6-07.txt
2014-11-10
06 akarch@cisco.com New version available: draft-ietf-idr-flow-spec-v6-06.txt
2014-03-20
05 akarch@cisco.com New version available: draft-ietf-idr-flow-spec-v6-05.txt
2014-01-28
04 akarch@cisco.com New version available: draft-ietf-idr-flow-spec-v6-04.txt
2012-04-29
03 Robert Raszuk New version available: draft-ietf-idr-flow-spec-v6-03.txt
2011-10-25
02 (System) New version available: draft-ietf-idr-flow-spec-v6-02.txt
2011-10-07
01 (System) New version available: draft-ietf-idr-flow-spec-v6-01.txt
2011-06-02
00 (System) New version available: draft-ietf-idr-flow-spec-v6-00.txt