Subject: [Ecrit] AD evaluation: draft-ietf-ecrit-held-routing-03

From: Alissa Cooper <[email-masked]>
Date: Thu, 12 Nov 2015 11:52:46 -0800

I have reviewed this document and it is in good shape. I have a few items to discuss before issuing the IETF LC and some nits that should be resolved together with any LC comments.

== General ==

I do not believe this document updates RFC 6881. This document makes no recommendation about the circumstances under which the extension it defines should be used, so it’s not really specifying any kind of best current practice. In fact, I think a reasonable question one could ask upon reading this document is “when should this extension be used”? But in any event it seems incorrect to say it updates RFC 6881.

I will note that I am not in the camp that believes that references to terminology documents need to be normative. That seems particularly true here given that the terms being defined are all entities and realistically the label an entity has on it does not affect the entity’s ability to properly implement the HELD protocol. But I will not stand in the way of the WG’s decision to call out the downrefs in IETF LC and add them to the downref registry if that’s what you want to do.

== Sec 4 ==

I think I understand why the draft describes how the LIS gets the routing URI from a LoST server in Section 3, but given that the point of this mechanism is to fill in a gap when there is no LoST server, I don’t think it’s a point that should be re-emphasized. So, a suggestion:

OLD
How the
   LIS obtains this information is left to implementation, one possible
   option is that the LIS acquires it from a LoST server, other
   possibilities are described in Section 3 <https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-03#section-3>.

NEW
How the
   LIS obtains this information is left to implementation. Possibilities are described in Section 3 <https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-03#section-3>.

Also, if I’m reading this right, there are two error cases where the LIS response would be the same: if the LIS doesn’t understand the extension, and if the LIS cannot obtain routing information. Why is it okay to have both of these errors look the same to the client making the request? Would it not be useful for the client to know whether its request was not understood at all, or whether the LIS just doesn’t know what URI to send? And if the two cases really are meant to have the same result, they should be described in the same way (i.e., shouldn’t the second case say “MUST return location as normal” if it were to match the first case?).

== Sec 7 ==

There seems to be a bit lurking here that I’d like to understand:

This represents additional information about the Target,
   as a consequence it is recommended that this option only be used when
   a location URI is returned by the LIS.

What is the valid use case for a LIS to send a routing URI but no location URI? That is, how does the LIS know how to find the PSAP if it doesn’t know the location? Is this for those one-PSAP-for-the-whole-country cases? Understanding that will help make sense of this recommendation, because on its face it seems to call into question the third-party authorization model in RFC 6155. That is, if a third party is appropriately authorized to make a request on behalf of a Target, why should that party not be trusted with a routing URI in the absence of a location URI?

Nits:

== Abstract ==

s/This document specifies an extension to the HELD protocol/This document specifies an extension to the HELD protocol, updating [RFC 5985],/

== Sec 1 ==

s/Networks of forest guides have not eventuated/Networks of forest guides have not materialized/

s/This document describes adding an extension/This document describes an extension/

== Sec 2 ==

Please expand the acronyms on first use.

== Sec 3 ==

s/such a HELD/such as HELD/

== Sec 7 ==

Expand “LCP” on first use.

== Sec 10 ==

s/Keith Drage ofr/Keith Drage for/

---

From: James Winterbottom <[email-masked]>
Date: Sat, 14 Nov 2015 08:23:51 +1100

Thanks Alissa,

Comments inline.

Cheers
James

> On 13 Nov 2015, at 6:52 am, Alissa Cooper <[email-masked]> wrote:
> 

[AJW] I am not sure that I agree with the assessment of the not updating RFC 6881. I can see that if a request always contains the option then it may get a PSAP URI back, if it doesn’t then it can try LoST. The problem is that in cases where there is no public LoST server, if they don’t ask for the routing URI then they won’t be able to route. So in answer to your question, the extension should always be sent in a request, it may not always get an answer. Even in NENA there seem to be varying opinions on whether LoST servers will be publicly assessable or not, so I don’t think that we can assume that LoST is the public’s answer to all things related to emergency routing.

> I will note that I am not in the camp that believes that references to terminology documents need to be normative. That seems particularly true here given that the terms being defined are all entit…

[AJW] I don’t mind either way, I was really just following what seems to be convention.

>    LIS obtains this information is left to implementation. Possibilities are described in Section 3 <https://tools.ietf.org/html/draft-ietf-ecrit-held-routing-03#section-3>.

[AJW] I am fine with that. I think LoST was actually added to that sentence as a result of comments in a pervious version. I shall remove it and replace it with your recommendation.

> What is the valid use case for a LIS to send a routing URI but no location URI? That is, how does the LIS know how to find the PSAP if it doesn’t know the location? Is this for those one-PSAP-for-t…

[AJW] Perhaps this could be worded better. Section 5.2 of RFC 5985 says “A successful response to a location request MUST contain a PIDF-LO and/or Location URI(s)”. So what the sentence is really trying to say is that the LIS shouldn’t return a location value and the routing information, it should only a location URI when the routing information is returned.

> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 16 Nov 2015 09:04:25 -0800

Hi James,

Thanks, some responses inline.

> On Nov 13, 2015, at 1:23 PM, James Winterbottom <[email-masked]> wrote:
> 
> Thanks Alissa,
> 
> Comments inline.
> 
> Cheers
> James
> 
>> On 13 Nov 2015, at 6:52 am, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Ok. My point is that at present the document doesn’t actually make the recommendation that implementations should always send the routing request. It is silent on this. A proper update to RFC 6881 would explain what the recommendation(s) are for requests and responses and would use the requirements notation as it is used in 6881 (e.g., “ED-, etc.). 

> [AJW] I don’t mind either way, I was really just following what seems to be convention.

Ok, the shepherd write-up says one of the authors wants these to be normative.

> [AJW] Perhaps this could be worded better. Section 5.2 of RFC 5985 says “A successful response to a location request MUST contain a PIDF-LO and/or Location URI(s)”. So what the sentence is really t…

Not following your last sentence above still, could you re-phrase?

Thanks,
Alissa

>> [email-masked] <mailto:[email-masked]>

---

From: James Winterbottom <[email-masked]>
Date: Tue, 17 Nov 2015 06:29:53 +1100

Thanks Alissa,

More inline.

> On 17 Nov 2015, at 4:04 am, Alissa Cooper <[email-masked]> wrote:
> 
> Hi James,
> 

[AJW] I will add these to the relevant sections.

> Ok, the shepherd write-up says one of the authors wants these to be normative.

[AJW] That was probably me and I was only keeping with convention if that isn’t really a convention then I can move but if no one has a strong opinion either way then I will just leave them.

>>> — SNIP

[AJW] For a LIS to return a HELD locationResponse the response must contain a location, that location may be a location URI or a location value. A HELD locationResponse cannot ever contain just a routing response. They main reason for returning a location to a third-party that requested the information using an identity extension was that the party wanted to route a message somewhere, and that they would first query a LIS and then use that location to query a LoST server. Since the extension described in this document eliminates the need for the LoST interaction, there is also little need to return a location value, a locationURI will do. Does that help? 

>>> https://www.ietf.org/mailman/listinfo/ecrit <https://www.ietf.org/mailman/listinfo/ecrit>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 18 Nov 2015 13:30:50 -0800

Hi James,

> On Nov 16, 2015, at 11:29 AM, James Winterbottom <[email-masked]> wrote:
>> 
>>> 
>>>> 

I think it would be preferable for them to be informative.

> [AJW] For a LIS to return a HELD locationResponse the response must contain a location, that location may be a location URI or a location value. A HELD locationResponse cannot ever contain just a r…

Ah, sorry, I was missing that this was about value vs. URI as opposed to returning location at all. I would suggest making a small addition to the text to make this clear:

This represents additional information about the Target,
   as a consequence it is recommended that this option only be used when
   the LIS returns a location URI, not a location value.

Thanks,
Alissa

---

From: James Winterbottom <[email-masked]>
Date: Thu, 19 Nov 2015 10:49:35 +1100

Thanks Alissa

Sent from my iPhone

> On 19 Nov 2015, at 8:30 am, Alissa Cooper <[email-masked]> wrote:
> 
> Hi James,
>

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 20 Nov 2015 09:32:17 -0800

I will initiatie IETF LC when the rev gets posted.

Thanks,
Alissa

> On Nov 18, 2015, at 3:49 PM, James Winterbottom <[email-masked]> wrote:
> 
> Thanks Alissa
> 
> Sent from my iPhone
> 
> On 19 Nov 2015, at 8:30 am, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi James,
>> 
>>> On Nov 16, 2015, at 11:29 AM, James Winterbottom <[email-masked] <mailto:[email-masked]>> wrote:
>>>> 
>>>>> 
>>>>>>

---

From: James Winterbottom <[email-masked]>
Date: Sat, 21 Nov 2015 19:36:50 +1100

Hi Alissa,

I think the only comment of yours that I didn’t comment on was the one surrounding the LIS understanding the new option but not being able to provide routing information.

When we were originally writing the document we came to this scenario and found three options:
	1) Just return location and ignore the routing request (this is what the document currently says)
	2) Pass something back, anything
	3) Pass something back and say, but indicate it may not be the droid they are looking for (LoST allows for this approach with the defaultMappingReturned warning).

The original reason for going with 1 was simplicity. If you requested routing, got nothing you would try LoST. Similarly if you requested routing and got a response saying, “eh, not sure, try this one”, then the requestor would probably try LoST anyway. I guess that with 3, at least the requestor has something.

If there is general agreement, then I will add an attribute to the routingInformation element that can indicate if it is default or not, and require the LIS to always respond with something if it understands the extension.

Cheers
James