+1 on Kyle's remarks[1], and well-put. IMO, this doc seems useful and should move forward as informational.
While I do also think a BCP would be great, since we're not there yet an informational RFC articulating the points this one does is a very welcome step forward and much better than nothing, IMO. -Jake PS: Also +1 to Paul Vixie's suggestion that the objections should ideally be phrased as a pull request. There's perhaps room for some editorial improvements, but as it stands it's pretty readable, and has some crucial information about the new challenges that transport header encryption introduces to existing operational practices. So my +1 on objections-as-pull-request is because I'm not understanding the tone or balance problems that were raised. I don't see what kinds of edits would address them outside of "stop acknowledging that there are new challenges raised by transport header encryption" or "add 14 pages duplicating info in the referenced RFCs about why encryption is good". Both of these seem counterproductive to me, so absent a more specific set of productive suggestions (ones that don't lose information about the new operational challenges that are introduced by transport header encryption), I am against stalling publication of this doc as an RFC based on the objections raised so far. [1] Kyle's remarks: https://mailarchive.ietf.org/arch/msg/tsvwg/0UNJbELTHMw7xjV9SIXoavADK6g/ _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
