Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GPP
RFC 7315

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

(Richard Barnes) Yes

(Jari Arkko) (was Discuss) No Objection

Alissa Cooper (was Discuss) No Objection

Comment (2014-04-10 for -13)
No email
send info
In side discussion with Richard, we came up with the following text to be added to 4.3:

Note that P-Visited-Network information reveals the location of the user, to the level of the coverage area of the visited network. For a national network, for example, P-Visited-Network would reveal that the user is in the country in question.

It would be helpful to state the hop-by-hop integrity protection requirement from 6.3 in 4.3.1 as well.

(Spencer Dawkins) No Objection

Comment (2014-04-08 for -13)
No email
send info
In this text: 4.3.2.2.  Procedures at the registrar and proxy	
 		
	Note that a received P-Visited-Network-ID from a UA is a failure case	
	and MUST be deleted when the request is forwarded.

is "a failure case" the right description?

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

Comment (2014-04-10 for -13)
No email
send info
In 4.1.1:
   The P-Associated-URI header field is applicable in SIP networks where
   the SIP provider a set of identities that a user can claim (in header
   fields like the From header field) in requests that the UA generates.

I think you are missing a verb here.

(Kathleen Moriarty) No Objection

Comment (2014-04-07 for -13)
No email
send info
Some comments to consider:

Section 4.3.2 should cover privacy issues related to the content (DNS names) of the P-Visited-Network-ID header field.

Section 4.6: The letter 't' is missing in the second to last paragraph at the end of the word  present.
   When presen
   only one instance of the header MUST be present in a particular
   request or response.

Section 5.5 and 5.6 cover P-Charging-Function-Addresses header field syntax and P-Charging-Vector header syntax respectively.  The section does not include a discussion on fraud and it seems like this would be important?  Several of the other sections do include security implications prior to the Security Considerations section.  This is a non-blocking comment since trust and integrity are listed as important to prevent modifications, but it would be good to see mention of fraud as the motivation for an attack either in these sections or in the Security Considerations section.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection