Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)
draft-ietf-sip-acr-code-05

Note: This ballot was opened for revision 05 and is now closed.

Lars Eggert No Objection

Section 3., paragraph 1:
>    A server (generally acting on behalf of the called party, though this
>    need not be the case) MAY generate a 433 (Anonymity Disallowed)
>    response when it receives an anonymous request, and the server
>    refuses to fulfill the request because the requestor is anonymous.

  There should be a statement somewhere in this section that a 443
  SHOULD NOT (or MUST NOT?) be generated in response to other requests.

(Cullen Jennings; former steering group member) (was Discuss, No Record, Discuss, Yes) Yes

(Jari Arkko; former steering group member) Yes

(Jon Peterson; former steering group member) Yes

(Sam Hartman; former steering group member) Yes

(Chris Newman; former steering group member) No Objection

(Dan Romascanu; former steering group member) No Objection

(David Ward; former steering group member) No Objection

(Lisa Dusseault; former steering group member) No Objection

Should the interoperability with the PSTN be described in more detail or made part of the requirements for PSTN/SIP gateways?

I note that the reference to RFC 3325 is on the edge of being a normative reference, because that's where the 'id' privacy type is defined.

(Magnus Westerlund; former steering group member) No Objection

(Mark Townsley; former steering group member) No Objection

(Ron Bonica; former steering group member) No Objection

(Ross Callon; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Tim Polk; former steering group member) No Objection