Subject: [sipcore] Comments on draft-winterbottom-sipcore-locparam-00

From: [email-masked] (Dale R. Worley)
Date: Thu, 30 Mar 2017 19:33:23 -0400

* Technical issues

A. Should this draft explicitly update this statement in RFC 6442?

   A SIP intermediary SHOULD NOT add location to a SIP request that
   already contains location.

B. Should the UE explicitly label its locationValue?

   4.  Mechanism

   A UE MUST NOT provide a loc-src parameter value.

Is this the best choice?  Might it be better to provide a way for the
UE to mark a locationValue, so that a locationValue added by a
new-type UE can be reliably distinguished from an old-type
intermediate that adds a locationValue (perforce without a loc-src
value)?

C. The meaning of "token" as an other-loc-src is not defined.

          location-source = "loc-src=" (host / other-loc-src)
          other-loc-src = token

D. Interpretation of location-source values.

The processor that interprets the locationValues must be able to
interpret the significance of the location-source values.  For
diagnostic purposes, a human can interpret host values easily enough.
But for automatic processing, would the host values (even if they are
known to be accurate) be interpretable with any reasonable amount of
effort?  Naively, it seems that the processor would need a list of all
possible host values and their classification (unless the host names
were constructed according to a rigid scheme).

It's possible that ETSI has evaluated this question and determined
that this interpretation of host values works well.

But naively, it seems to me that the values you want for automatic
processing are codes for the *roles* or *positions* within the dialog
of the adders of the locationValues.  While I was watching the
presentation, I was remembering that I'd seen such a set of values
defined somewhere, and it turns out that I was remembering the
resp-location values from draft-jesske-dispatch-reason-loc-q850-00:

                The values to be used as location are:
                U               for user
                LPN             for private network serving the local user
                LN              for public network serving the local user
                TN              for transit network
                RLN             for public network serving the remote user
                RPN             for private network serving the remote user
                INTL            for international network
                BI              for network beyond interworking point

>From this point of view, a more informative way to label
locationValues is:

          geoloc-param       =/ location-source
          location-source    = "loc-src=" loc-src-value
	  loc-src-value      = U / LPN / LN / TN / RLN / RPN / INTL /
	  		       BI / token

          geoloc-param       =/ location-host
          location-host      = "loc-host=" host

where "loc-src" can be automatically processed without the processor
understanding every possible host name, and "loc-host" very
fine-grained for diagnostic and specialty processing.

* Editorial issues

1.  Introduction

   The SIP geolocation specification [RFC6442] describes a SIP header
   field that is used to indicate that the SIP message is conveying
   location information.

I suggest changing 'describes a SIP header field that' to 'describes
the "Geolocation" SIP header field which'.

   [RFC6442] stipulates that the order of
   location values in the geolocation header field aligns with the order
   in which they were added to the header field.

"aligns with" is ambiguous -- is the first Geolocation header the
first one that was added or is the last Geolocation header the first
one that was added?  From RFC 6442 section 4.1, the first Geolocation
header is the first one added, so "aligns with" can be changed to "is"
or "is the same as".

3.  Rationale

   Thus it is intended to use this parameter in
   trust domains where Spec(T) as described in [RFC3325] exists only.

I'm not sure of the exact rules for the use of the English word
"only", but in this case it would be clearer to say

   Thus it is intended to use this parameter only in
   trust domains where Spec(T) as described in [RFC3325] exists.

4.  Mechanism

   The Augmented BNF (ABNF) [RFC5234] for this parameter is shown in
   Figure 1.

          location-source = "loc-src=" (host / other-loc-src)
          other-loc-src = token

Formally, this omits connecting location-source to the BNF for the
Geolocation header, which is done by:

   geoloc-param       =/ location-source

--

   If a node
   conforming to this specification receives a geolocation header field
   with a loc-src parameter containing an IP address then the parameter
   MUST be removed.

This might be more aggressive than we want.  The weakest acceptable
requirement, I think, is that any conforming node MAY remove such a
value and MUST ignore it in processing it.  But ETSI may have
operational experience to make it clear what the best approach is.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 31 Mar 2017 17:36:33 -0400

> D. Interpretation of location-source values.

I'm suggesting here that we want to change the example from 

      Geolocation: <cid:[email-masked]>,
           <https://lis.example.com:8222/y77syc7cuecbh>;
                    loc-src=edgeproxy.example.com

to

      Geolocation: <cid:[email-masked]>;
                     loc-src=U,
                   <https://lis.example.com:8222/y77syc7cuecbh>;
                     loc-src=LN;
	             loc-host=edgeproxy.example.com

Dale