Last Call Review of draft-ietf-ecrit-similar-location-17
review-ietf-ecrit-similar-location-17-secdir-lc-kelly-2022-02-12-00
Request | Review of | draft-ietf-ecrit-similar-location |
---|---|---|
Requested revision | No specific revision (document currently at 19) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2022-02-09 | |
Requested | 2022-01-26 | |
Authors | Brian Rosen , Roger Marshall , Jeff Martin | |
I-D last updated | 2022-02-12 | |
Completed reviews |
Genart Last Call review of -17
by Russ Housley
(diff)
Secdir Last Call review of -17 by Scott G. Kelly (diff) Artart Last Call review of -17 by Claudio Allocchio (diff) Intdir Telechat review of -18 by Tatuya Jinmei (diff) |
|
Assignment | Reviewer | Scott G. Kelly |
State | Completed | |
Request | Last Call review on draft-ietf-ecrit-similar-location by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/zVAIGKTXC7TwHkfvagSfTcLpHeM | |
Reviewed revision | 17 (document currently at 19) | |
Result | Ready | |
Completed | 2022-02-12 |
review-ietf-ecrit-similar-location-17-secdir-lc-kelly-2022-02-12-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is ready. From the abstract, this document introduces a new way to provide returned location information in LoST responses that is either of a completed or similar form to the original input civic location, based on whether valid or invalid civic address elements are returned within the <findServiceResponse> message. The security considerations section considers that this mechanism may disclose information, and that implementers should consider the implications of this in the context of their service. If I were writing this section, I might start by saying (because this doc extends RFC 5222) that all of the security considerations of 5222 apply, but this is implicit, and I don't feel strongly about this. From a security considerations perspective, I think this document is ready.