IETF conflict review for draft-tsou-behave-natx4-log-reduction
conflict-review-tsou-behave-natx4-log-reduction-03
Yes
(Spencer Dawkins)
No Objection
(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Barry Leiba)
(Ben Campbell)
(Benoît Claise)
(Deborah Brungard)
(Joel Jaeggli)
(Martin Stiemerling)
(Terry Manderson)
Note: This ballot was opened for revision 00 and is now closed.
Ballot question: "Is this the correct conflict review response?"
Spencer Dawkins Former IESG member
Yes
Yes
(for -00)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -01)
Unknown
Alissa Cooper Former IESG member
(was Discuss)
No Objection
No Objection
(for -01)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -00)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -00)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(for -01)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -01)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(2015-08-19 for -01)
Unknown
I agree with Stephen's point that the recommendations are obvious. Additionally, this document does not even reference a BCP (RFC 6302) on recommended logging procedures (as pointed out by Alissa). Given the increased security risk mentioned, the IESG needs to discuss what to do with this draft.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -01)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2015-08-20 for -01)
Unknown
I have no firm opinion on this yet - will follow the IESG discussion with interest!
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -00)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-08-06 for -01)
Unknown
I'm interested to see the response to Alissa's discuss.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -01)
Unknown
Stephen Farrell Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2015-08-20 for -01)
Unknown
Comments for the ISE/Authors: The IESG discussed which kind of 5742 response to send for this because the draft makes some kinds of attack easier, (the draft itself says "the reduced range sizes proposed by the present document increase the attacker's chances"), this could maybe be considered to justify a response of "The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval." In this case the IESG figured that this did not justify trying to have the draft to be processed in the IETF stream. (My own opinion is that it's a borderline case but nobody on the IESG including me strongly felt that we needed to try drag this into the IETF stream.) One significant issue with that is that one cannot tell from the draft just how much worse this might make attacks as there is not sufficient detail in section 2 to allow one to do any analysis of that aspect. The IESG did I think agree that this draft would be much better if it had sufficient detail to allow deployments to make that calculation and if the security considerations documented how that ought be done. My other comments below were not discussed by the IESG. - General: I find it very hard to see what's useful here that's not included in the references. Section 2 is so vague as to be utterly obvious. While a document with some real detail could arguably be a good ISE output, an arm-wave like this seems odd to me. - General: there should be some recognition that any logging of this nature generates highly privacy sensitive information that really is better deleted as soon as can be. - intro, para 2: "For various reasons it is necessary to log these mappings" That is both too coy and assumes necessity which I think is too strong a statement. - intro; why are megabytes per second scary? Seems like a small number to me. This ought be qualified as per binding to be a useful estimate - intro, last para: be better to synopsise or repeat the reqs here - it is not very "introductory" to use such opaqueness here - section 2: I wonder what a bad actor could do if they knew the block allocation scheme? was that considered? one can't I guess describe that given there is no block allocation scheme described in sufficient detail.
Terry Manderson Former IESG member
No Objection
No Objection
(for -01)
Unknown