[Sip] Comments on draft-ietf-sip-location-conveyance-03

["Drage, Keith (Keith)" <[e-mail]>]

I have the following comments on the above draft:

Structural
----------

1)	Abstract: From reading the document, it is clear that presence systems are not covered at all in this document for various reasons. Therefore PUBLISH, SUBSCRIBE and NOTIFY are essentially out of scope. It seems to me that this should be made much more explicit in the abstract.

2)	The SIP extension guidelines (RFC 4485) need to be applied to this document, which requires some substantial restructuring. The absence of application of these rules mean that the requirements of the document are extremely unclear. For example RFC 4485 states (section 4.5):

   Developers of protocols often get caught up in syntax issues, without
   spending enough time on semantics.  The semantics of a protocol are
   far more important.  SIP extensions MUST clearly define the semantics
   of the extensions.  Specifically, the extension MUST specify the
   behaviors expected of a UAC, UAS, and proxy in processing the
   extension.  This is often best described by having separate sections
   for each of these three elements.  Each section SHOULD step through
   the processing rules in temporal order of the most common messaging
   scenario.

Absence of this application means that in places in this document it is impossible to determine whether a requirement and its required support occurs as the sender of the location information, or the receiver of the location information.

3)	Section 1 (and possibly section 2) should be redrafted taking into account RFC 4485 section 4.7:

   Too often, extension documents dive into detailed syntax and
   semantics without giving a general overview of operation.  This makes
   understanding of the extension harder.  It is RECOMMENDED that
   extensions have a protocol overview section that discusses the basic
   operation of the extension.  Basic operation usually consists of the
   message flow, in temporal order, for the most common case covered by
   the extension.  The most important processing rules for the elements
   in the call flow SHOULD be mentioned.  Usage of the RFC 2119 [1]
   terminology in the overview section is NOT RECOMMENDED, and the
   specification should explicitly state that the overview is tutorial
   in nature only.  This section SHOULD expand all acronyms, even those
   common in SIP systems, and SHOULD be understandable to readers who
   are not SIP experts. [27] provides additional guidance on writing
   good overview sections.

I found this text much too wordy, and considered that it should be possibly to convey the necessary information to the reader in about half the length.

4)	Section 3 need to have all the RFC 2119 language removed (see history-info and outbound as examples). I remain open as to whether it appears at the start of the document, as here and in history-info, or at the end, as in outbound, but given the length, we may want to consider moving it to the end.

5)	Section 6 should probably follow immediately on from the procedures in the bulk of section 4, and probably be split as in comment 2) above.

6)	Section 7 should be integrated into the main procedures text.

Technical
---------

7)	Section 1, of the three examples given in this introduction, item 2) is out of scope. I had to read an awful lot of text to discover that fact. 

8)	Section 2, 1st paragraph. Probably not appropriate to use the term "trust model". That term is defined in RFC 3324 and RFC 3325, and I am not convinced the usage here is one and the same.

9)	Section 2, 3rd para. 

   No routing of the request based on the location contents is required
   in this case, therefore no SIP Proxies between these two UAs need to
   view the location information contained in the SIP message(s).  The 
   UAC should know certain types of messages will be routed based on 
   the UA's location when creating a message.  

Did not understand what this paragraph is meant to be telling me - can you explain it.

10)	Section 3.1 UAC-4: This is not a generic requirement as it is already identified that certain methods are outside the scope of this document.

11)	Section 3.1 UAC-9, UAC-10: I assume this is specified this way so that misconfiguration releases the location rather than hides it. I believe this contravenes the regulatory requirements of some countries. I believe in Japan privacy requirements are more important that the transmission of the information for emergency calls. If someone from Japan was writing these requirements they would therefore indicate exactly the opposite.

12)	Section 3.2 UAS-6 and section 3.3 Proxy-4. Firstly this is halfway into implementation. Secondly if it is required to address location errors in requests, why is the same consideration not given to location errors in responses. 

13)	Section 3.3 Proxy-1: This merely repeats RFC 3261, rather than developing a new requirement.

14)	Section 3.3 Proxy-3: This seems to be rewriting the requirements to correspond to the solution. I understand the problem is that the solution cannot distinguish between multiple locations, nor understand the reliability, and therefore a receiver may get confused. Firstly this does not seem to me to be a SIP issue, and secondly in general the ability to transport multiple locations could be regarded as useful - they just need some form of assertion as to who provided which location.

15)	Section 4 and elsewhere. I don't find location in responses well described at all. It seems to be an afterthought, rather than something that is decided based on a full set of requirements. I have already made a comment with regard to requirements on error handling. Should we support location in response, or force the UAS to generate a request of its own in order to send a location?

16)	Section 4. Should the instances of "URI" here be "URN".

17)	Section 4 specifies:

   Because a person's location is generally considered to be sensitive 
   in nature, certain security measures need to be taken into account 
   when transmitting such information.  Section 26 of [RFC3261] defines
   the security functionality SIPS for transporting SIP messages with 
   either TLS or IPSec, and S/MIME for encrypting message bodies from 
   SIP intermediaries that would otherwise have access to reading the 
   clear-text bodies.  SIP endpoints SHOULD implement S/MIME to encrypt
   the PIDF-LO message body (part) end-to-end.  The SIPS-URI from 
   [RFC3261] MUST be implemented for message protection (message 
   integrity and confidentiality) and SHOULD be used when S/MIME is not
   used.  

   The entities sending and receiving location MUST obey the privacy 
   and security rules in the PIDF-LO, regarding retransmission and 
   retention, to be compliant with this specification.

   Self-signed certificates SHOULD NOT be used for protecting PIDF-LO, 
   as the sender does not have a secure identity of the recipient.

However RFC 4119 is already normatively referenced which contains the following text:

   For the purposes of this document, only the securing of a PIDF
   document as a whole, rather than element-by-element security, is
   considered.  None of the requirements [10] suggest that only part of
   the information in a location object might need to be protected while
   other parts are unprotected; virtually any such configuration would
   introduce potentials for privacy leakage.  Consequently, the use of
   MIME-level security is appropriate.

   S/MIME [5] allows security properties (including confidentiality,
   integrity, and authentication properties) to be applied to the
   contents of a MIME body.  Therefore, all PIDF implementations that
   support the XML Schema extensions for location information described
   in this document MUST support S/MIME; in particular, they MUST
   support the CMS [6] EnvelopedData and SignedData content types, which
   are used for encryption and digital signatures, respectively.  It is
   believed that this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3,
   and 14.4.

   Additionally, all compliant applications MUST implement the AES
   encryption algorithm for S/MIME, as specified in [8] (and per REQ
   15.1).  Of course, implementations MUST also support the baseline
   encryption and digital signature algorithms described in the S/MIME
   specification.

   S/MIME generally entails the use of X.509 [9] certificates.  In order
   to encrypt a request for a particular destination end-to-end (i.e.,
   to a Location Recipient), the Location Generator must possess
   credentials (typically an X.509 certificate) that have been issued to
   the Location Recipient.  Implementations of this specification SHOULD
   support X.509 certificates for S/MIME, and MUST support password-
   based CMS encryption (see [6]).  Any symmetric keying systems SHOULD
   derive high-entropy content encoding keys (CEKs).  When X.509
   certificates are used to sign PIDF Location Objects, the
   subjectAltName of the certificate SHOULD use the "pres" URI scheme.

Which set of text takes precedence?

18)	Section 4:

   More than one location representation or format MAY be included in 
   the same message body part, but all MUST point at the same position 
   on the earth (altitude not withstanding), as this would confuse the 
   recipient by pointing at more than one position within the same 
   message body part.  There MAY be a case in which part or parts of 
   one location format and part or parts of another format exist in the
   same message body part.  These complementary pieces of information 
   MUST point at the same position on the earth, yet are incomplete 
   within their own format. For example, there maybe be a latitude and 
   longitude in coordinate format and a civic altitude value to 
   complete a 3-dimensional position of a thing (i.e. which floor of a 
   building the UA is on in a building at a particular lat/long 
   coordinates pair).

Not sure what "altitude not withstanding" means, particular as this is a RFC 2119 MUST sentence.

Additionally, the paragraph repeats the essence of the "same position on the earth" in two separate MUST statements.

19)	Section 4:

   There MAY be more than one PIDF-LO in the same SIP message, but each
   in separate message body parts. Each location body part MAY point at
   different positions on the earth (altitude not withstanding).  If 
   the message length exceeds the maximum message length of a single 
   packet (1300 bytes), TCP MUST to be used for proper message 
   fragmentation and reassembly.  

Why is the final sentence stronger than RFC 3261. I assume your thinking is emergency calls, but that is only one of the uses of this document. And surely if emergency calls is the problem, then the requirement has to be made as an update to RFC 3261 for all emergency calls, not just those that happen to carry location.

20)	Section 4:

   Several push-based SIP Request Methods are capable (and applicable) 
   of carrying location, including:

      INVITE, 
      REGISTER, 
      UPDATE, and
      MESSAGE, 

   While the authors do not yet see a reason to have location conveyed 
   in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a 
   reason to prevent carrying a PIDF-LO within these Method Requests as
   long as the SIP message meets the requirements stated within this 
   document.  Discussing Location in the PUBLISH Request Method will be
   for another document.  

The draft seems to go to a great deal of effort to ensure the information is carried end to end, but then suggests that the information might be entrusted to non end-to-end messages. I would suggest that the header and body are declared out of scope for ACK and CANCEL.

21)	Section 4:

   A 200 OK to a SIP Request MAY carry the UAS's PIDF-LO back to the 
   UAC that provided its location in the original request, but this is 
   not something that can be required due to the timing of the request 
   to 200 OK messages, with potential local/user policy requiring the 
   called user to get involved in determining if the caller is someone 
   they wish to give their location to (and at what precision).

I don't understand what this is trying to convey. Please explain?

22)	Section 4.1:

   It is envisioned that HTTP, through the http_URL in [RFC216], and 
   HTTPS [RFC2818] MAY be used to dereference a location-by-reference 
   PIDF-LO.

Do we place any requirement to support HTTP at any location receiver, so that location by reference when received actually works?

23)	Is it not sufficient to say that RFC 2119 applies, and therefore the security considerations of RFC 2119 applies.

NITS
----

24)	Section 3.1 UAC-8: As by-reference doesn't carry the PIDF-LO within SIP, but within HTTP, the text is wrong.

25)	Can we consistently use "request" or "response" rather than "message" following RFC 3261 terminology?

26)	Section 4:

   Several push-based SIP Request Methods are capable (and applicable) 
   of carrying location, including:

      INVITE, 
      REGISTER, 
      UPDATE, and
      MESSAGE, 

   While the authors do not yet see a reason to have location conveyed 
   in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a 
   reason to prevent carrying a PIDF-LO within these Method Requests as
   long as the SIP message meets the requirements stated within this 
   document.  Discussing Location in the PUBLISH Request Method will be
   for another document.  

This document is under WG control, the contents have nothing to do with the authors vision!!

27)	Section 4.1: 1st para: delete "and IANA registers" as superfluous and change "is to be used" to "can be used"

28)	Suggest using lower case throughout, including initial letter, for the name of the option-tag. 

29)	Section 4.1, table of headers needs a table number. As it follows the conventions of RFC 3261 (as indicated by reference), it should have an empty space under the "where" column. However see other technical comments about appearance in responses.

30)	Section 4.2, delete the words "a new 4XX level error is created here", as this is totally obvious from the rest of the words.

31)	Section 9. Delete "4xx error" before "response code"


regards

Keith

Keith Drage
[e-mail]
tel: [phone]

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip