Document: draft-hautakorpi-sipping-uri-list-handling-refused-03.txt Reviewer: Eric Gray Review Date: 4/29/2008 IETF LC End Date: 4/29/2008 Summary: This draft may be nearly ready for publishing as an RFC - either Informational or Proposed Standard (depending on the answer to one of my 2 questions) Comments: I have 2 questions: 1) Why is this intended to be published as an Informational RFC? This does not report message formats, code point assignments, protocol (extended) behaviors defined elsewhere - it defines them here. The very first sentence in the abstract starts - "This document specifies the ..." Hence it seems to me that this document is a specification and should probably be a PS RFC. 2) What is the deployment scenario envisioned that has a security exposure to Eavesdropping and/or Disclosure that does not have similar exposures to other forms of attack (e.g. - MitM)? The security considerations section says "attackers are not supposed to have access to the protocol messages between those [trusted] elements [that would handle message containing the P-Refused-URI-List P-Header]." Presumably an attacker would need to have such access if it was in a position to eavesdrop on the contents of a 403 (Forbidden) response. Otherwise, the draft is in very good shape.