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

From: <[email-masked]>
Date: Tue, 4 Apr 2017 10:24:04 +0000

Hi Dale,
Thank you for your extensive Review and the questions.
The answers are below and will hopefully clarify the issues we have also discussed during the SIPCOER meeting.
 
Best Regards
 
Roland
 
> -----Ursprüngliche Nachricht-----
> Von: sipcore [mailto:[email-masked]] Im Auftrag von Dale R.
> Worley
> Gesendet: Donnerstag, 30. März 2017 18:33
> An: [email-masked]
> Betreff: [sipcore] Comments on draft-winterbottom-sipcore-locparam-00
> 
> * 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.
 
So seen from our perspective is a SHOULD NOT an option. With regard to our deraft we assume that there can be more than one location within the message.This is was the ETSI M493 project is describing in their Specification.
 
> 
> B. Should the UE explicitly label its locationValue?
No, it is intended to use this parameter in trust domains where Spec(T) as described in [RFC3325] exists only.

> 
>    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)?
 
It is intended to use this parameter in trust domains where Spec(T) as described in [RFC3325] exists only. 
 
> 
> 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
 
That value allows you to use other than host to be included within the loc-src.
> 
> 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.
 
ETSI has evaluated this and already described within ES 203 178 and DraftES/NTECH-00025
 
> 
> 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.
 
The labeling itself would help within one network which entity has included the loc-serc but seen from multiple network approach this would not really help. Because it is not known which element from which Service provider has included the loc-src.
Also within the own network this indication may not help since a couple of entites may within the LN or also within a INTL.
> * Editorial issues
I will change the text based on your following comments within the next version of the document.
 
> 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
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

> -----Ursprüngliche Nachricht-----
> Von: sipcore [mailto:[email-masked]] Im Auftrag von Dale R.
> Worley
> Gesendet: Freitag, 31. März 2017 01:33
> An: [email-masked]
> Betreff: [sipcore] Comments on draft-winterbottom-sipcore-locparam-00
> 
> * 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
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 04 Apr 2017 19:58:11 -0400

> described in [RFC3325] exists only. 

OK...  But it seems that UE/UA can be part of a trust domain, and thus
Spec(T) applies.  See e.g., section 8 of RFC 3325, "If a UA is part of
the Trust Domain from which it received a message ...".  Whereas this
draft says that a UE/UA must not apply a loc-src regardless of whether
it's within the trust domain or not.

> That value allows you to use other than host to be included within the

That's true, it does, but the text of the draft doesn't specify what the
semantics of such a token would be, or reserve that the token must be as
specified by another document.  The BNF allows a syntax whose semantics
is entirely unexplained.

Dale