Path Computation Element Communication Protocol (PCEP) Extension for Flow Specification
draft-ietf-pce-pcep-flowspec-13
Yes
(Deborah Brungard)
No Objection
(Alissa Cooper)
(Barry Leiba)
Note: This ballot was opened for revision 10 and is now closed.
Erik Kline
No Objection
Comment
(2020-08-22 for -10)
Sent
[ section 2 ] * "a flag is provided to indicate that the sender of a PCEP message that includes a Flow Specification is intended to be installed as a Longest Prefix Match route, or..." This didn't scan too well for me. It seems the subject is the sender as written, but perhaps the message itself is the thing that "is intended to be installed..."? Oh, perhaps this is what's meant: "a flag is provided to indicate that the sender of a PCEP message that includes a Flow Specification intends it to be installed as a Longest Prefix Match route or as a Flow Specification policy." [ section 5 ] * Is it well-known whether multibyte numeric fields are network endian or not? [ section 6 ] * "The TLVs follows" -> "The TLVs follow", I think [ section 7 ] * "carries one or more ... TLV" -> "...TLVs." * "defines following new types" -> "defines the following new types" * Purely out of curiosity, if either S=1 or G=1 can/should it be specified that the source/group addresses simply not be included (i.e. the bits indicate not only that the field is not examined but that it's not inclued)? [ section 7.1 ] * "carries one or more ... TLV" -> "...TLVs." [ section 8.4 ] * "will be place on a single tunnel" -> "will be placed into a single tunnel" perhaps? [ section 8.7 ] * Recommend splitting up the long sentence with ", however" -> ". However, ..." * "if the Flow Specification make" -> "if the Flow Specifications make"? * Maybe I've lost too much mental state between readings, but the final paragraph, as written, makes me wonder how a FlowSpec gets installed in the first place. I assume I'm missing something in my naive reading. =)
Murray Kucherawy
No Objection
Comment
(2020-08-26 for -10)
Sent
I support two things: Ben's DISCUSS position, and the various kudos from others about a very well written document. For the sake of providing one bit of feedback not covered by others: Section 13.8 is probably unnecessary.
Roman Danyliw
No Objection
Comment
(2020-08-26 for -10)
Sent
Thank you for an approachable document. Thank you to the SECDIR reviewer (Scott G. Kelly) ** Section 12. To refine what Ben Kaduk noted about the applicability of [RFC6952], Section 2.5 seems to apply for me. ** Section 12. Per “Therefore, implementations or deployments concerned with protecting privacy MUST apply the mechanisms described in the documents referenced above.”, it might be helpful to explicitly call out the specific guidance to follow. I believe that it’s to use either IPSec per Section 10.4 – 6 of RFC5440 or TLS per RFC8523 to provide transport security properties. The legacy references to TCP-AO and TCP MD5 in those documents don’t help here. ** Section 12. Per “Although this is not directly a security issue per se, the confusion and unexpected forwarding behavior may be engineered or exploited by an attacker. Therefore, implementers and operators SHOULD pay careful attention to the Manageability Considerations described in Section 13.”, I completely agree. I would say it a bit more strongly that this complexity could be a security issue. I’m envisioning a situation where the complex forwarding behaviors might create gaps in the monitoring and inspection of particular traffic or provide a path that avoids expected mitigations.
Warren Kumari
No Objection
Comment
(2020-08-26 for -10)
Not sent
I agree with Ben's DISCUSS position - I don't understand the tradeoff between the complexity of multiple objects and just a single, and believe that more text is required / needed to help clarify.
Éric Vyncke
No Objection
Comment
(2020-08-18 for -10)
Sent
Thank you for the work put into this document. I found the text easy to read albeit sometimes it could be shortened (section 1 for example). But, I prefer clarity and ease of read to concise text. I have only one non-blocking comment in section 4: documenting what is the expected behavior when receiving a "Value" != 0 could be helpful (probably the usual 'ignored'). I hope that this helps to improve the document, Regards, -éric
Deborah Brungard Former IESG member
Yes
Yes
(for -10)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -10)
Not sent
Alvaro Retana Former IESG member
(was Discuss)
No Objection
No Objection
(2020-10-07 for -11)
Sent for earlier
[Thanks for addressing my DISCUSS.]
Barry Leiba Former IESG member
No Objection
No Objection
(for -10)
Not sent
Benjamin Kaduk Former IESG member
(was Discuss)
No Objection
No Objection
(2020-10-29 for -11)
Sent for earlier
Thank you for addressing my Discuss (and Comment) points! My sole comment on the -11 is that the Abstract is a bit long.
Martin Duke Former IESG member
No Objection
No Objection
(2020-08-24 for -10)
Sent
I found this document clear to follow, so thanks. I’m somewhat concerned there are no implementations. Nits: Sec 5. Specify the error if more than 1 TLV of any type is present. Sec 7. The text is incomplete for the (*, G) case.