GRE-in-UDP Encapsulation
draft-ietf-tsvwg-gre-in-udp-encap-19

Thanks for the well-written document.

I agree with Ben's comments about Section 1.

I'm balloting no objection, but I have a few comments that may be worth considering:

- general: The draft has a structure where you mention requirements in one section, then go into more detail in later sections. While this is a perfectly reasonable structure, it has resulted in a fair bit of redundant 2119 language. In general it's better to avoid that because it can make future updates more error prone. In this case, most of the language is consistent, so it's probably not worth changing. But there are a few cases where the language appears inconsistent, or is restated in sufficiently different ways to be potentially confusing. I've tried to call out specifics, but may have missed some.

-1, paragraph 5, first sentence: I found the sentence structure confusing. I think you mean to say that GRE-in-UDP tunnels are not safe to carry arbitrary traffic over the Internet, but it can be read to mean to say that since the internet is an arbitrary traffic environment, it's not safe to use GRE-in-UDP on it.

-1, paragraph 6: When might security not be a concern? Would it make sense to start with an assumption that security _is_ a concern, then consider situations for which it might not be?

- 6.1, paragraph 1: Previous sections said UDP checksums SHOULD be used for IPv4. Should this section be interpreted to mean that _if_ the checksum is used, it MUST be processes this way? If so, that could use clarification.

-6.2, paragraph 2: Does the allowance to use the zero-checksum in some cases violate the MUST for UDP checksums over IPv6?

-8, third paragraph:
Isn’t this just a restatement of the previous requirement that all traffic carried over default gre-in-udp tunnels must be congestion controlled?

-8, paragraph 5:
This also seems a restatement of the requirement that traffic on generic tunnels MUST be congestion controlled. Given that you probably don’t select your network path based on the nature of the data, I think it’s better stated in the original terms.

-8, last paragraph:
Do circuit-breakers really keep non congestion-controlled traffic from “escaping”, or does it mitigate the damage if it does escape?

-11, 2nd paragraph: Previous sections just said DTLS can be used if there are security concerns. This is not consistent with that. (I prefer the SHOULD to a "can")

-11, last paragraph: Is SHOULD sufficient for this case?

Rick Casarez <rick.casarez@gmail.com> performed the opsdir review

Thank you, Lucy for the proposed text on using encryption and DTLS.

- Section 5: Do you need to say that (non-handshake?) traffic
that is not properly protected with DTLS MUST be discarded?

- Does 6.2(c) (in the 1st list) suggest some form of new DoS
vector? Not sure myself.