Last Call Review of draft-ietf-insipid-logme-reqs-11
review-ietf-insipid-logme-reqs-11-secdir-lc-turner-2017-01-06-00
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 |
review-ietf-insipid-logme-reqs-11-secdir-lc-turner-2017-01-06-00
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?