Skip to main content

Last Call Review of draft-ietf-insipid-logme-reqs-11

Request Review of draft-ietf-insipid-logme-reqs
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-01-13
Requested 2016-12-21
Authors Peter Dawes , Chidambaram Arunachalam
I-D last updated 2017-01-06
Completed reviews Secdir Last Call review of -11 by Sean Turner (diff)
Genart Last Call review of -11 by Stewart Bryant (diff)
Opsdir Last Call review of -11 by Dan Romascanu (diff)
Genart Telechat review of -12 by Stewart Bryant
Assignment Reviewer Sean Turner
State Completed
Request Last Call review on draft-ietf-insipid-logme-reqs by Security Area Directorate Assigned
Reviewed revision 11 (document currently at 12)
Result Has nits
Completed 2017-01-06
After getting over my initial reaction that was something like "srsly!? we're
going to standardize the exact opposite of 'do not track'", I realized that
this is a requirements draft for an IETF approved WG and a chartered work item
of that WG :)

0) s3.2: Is the intent to define a protocol mechanism to determine if the two
or domains are part of the same trust domain?  This requirement could be
achieved by saying out-of-band bilateral agreements are the mechanism to
establish the domain.

1) s5.1: REQ1 - Did you mean to say "using SIP standard logging format"?  Is
there another logging format other than SIP CLF?

2) s5.1: Should the must be MUST in the following:

  All log retrieval mechanisms must adhere to
  authorization and privacy protection policies
  set forth by the network administrator.

3) s5.2: REQ3 seems odd to me - Isn't this kind of like a SIP thing?  I mean if
SIP doesn't allow adding new headers then didn't somebody sink your battleship?
 But SIP does allow you to add arbitrary headers so I think I'm missing
something as to why this is needed?

4) s5.2: REQ3 - Reads a bit awkward to me how about:

  It MUST be possible to mark a SIP request or response for
  logging by inserting a "log me" marker.

i.e., remove "of interest"

5) s5.2: REQ4 - Again this seems like a basic SIP thing - I mean are there
fields that SIP requires be stripped?

6) Is there a missing requirement based on the security considerations that
requires the this marker MUST be removed at the earliest opportunity if it has
been incorrectly inserted?