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 |