Subject: [Ecrit] draft-winterbottom-ecrit-priv-loc

From: "Marc Linsner (mlinsner)" <[email-masked]>
Date: Mon, 22 Dec 2014 16:19:23 +0000

All,

There is consensus to move forward with this work.

The chairs will request to the milestone addition for this draft to be submitted to the IESG by September 2015, of course earlier completion is always a good thing.

James, please submit a version as an IETF draft and we will approve.

Thanks,

Marc & Roger
ECRIT co-chairs

---

From: James Winterbottom <[email-masked]>
Date: Tue, 23 Dec 2014 09:20:17 +1100

I have relabeled it draft-ietf-ecrit-held-routing-00 but it is the same draft as above with a correction to the xml.

Cheers
James

Sent from my iPhone

> On 23 Dec 2014, at 3:19 am, "Marc Linsner (mlinsner)" <[email-masked]> wrote:
> 
> All,
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: Randall Gellens <[email-masked]>
Date: Tue, 23 Dec 2014 01:36:23 -0800

I have a technical question about the draft.  From my reading, it 
appears that the extension is to add an empty 
<requestRoutingInformation> element to a HELD request, and if the 
server supports it, it includes a <routingInformation> element with 
all possible values that could be returned.  Is this correct or am I 
missing something?  If it is correct, why is the 
<requestRoutingInformation> element empty rather than contain the 
desired service?  Wouldn't it be simpler to include the specific 
service of interest (e.g., 'sos'), as in the <service> element from 
LoST and then the server only needs to look that up and return only 
that?

At 4:19 PM +0000 12/22/14, Marc Linsner (mlinsner) wrote:

>  The chairs will request to the milestone addition for this draft to 
> be submitted to the IESG by September 2015, of course earlier 
> completion is always a good thing.
>

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Go placidly amid the noise and waste, and remember what value there may
be in owning a piece thereof.                        --National Lampoon

---

From: James Winterbottom <[email-masked]>
Date: Tue, 23 Dec 2014 21:48:22 +1100

Hi Randy,

That could work, but that implies that you know what services that the system supports.
I think that I would rather make an assumption that emergency and the subset thereof are all we support and leave an extension point for people to extend from if the need ever arises.

Cheers
James

> On 23 Dec 2014, at 8:36 pm, Randall Gellens <[email-masked]> wrote:
> 
> I have a technical question about the draft.  From my reading, it appears that the extension is to add an empty <requestRoutingInformation> element to a HELD request, and if the server supports it, it includes a <routingInformation> element with all possible values that could be returned.  Is this correct or am I missing something?  If it is correct, why is the <requestRoutingInformation> element empty rather than contain the desired service?  Wouldn't it be simpler to include the specific service of interest (e.g., 'sos'), as in the <service> element from LoST and then the server only needs to look that up and return only that?
> 
>

---

From: Randall Gellens <[email-masked]>
Date: Tue, 23 Dec 2014 04:08:35 -0800

Hi James,

So the draft currently specifies that only sos and children of sos 
are returned?  I'd missed that when I read and re-read the draft.  If 
so, that's fine with me, but maybe it can be made more clear.

For example, Section 4 says:

    The routing information in the location response consists of one or
    more service elements which is identified by a service name.  The
    service name is a URI and might contain a general emergency service
    urn such as urn:service:sos or might contain a specific service urn.

To me, this says that sos is just an example of a service that might 
be returned.

What might be better would be to modify my suggestion so that a 
<service> element can be included, and if not, the default is 'sos' 
and any children of 'sos'.

At 9:48 PM +1100 12/23/14, James Winterbottom wrote:

>  I think that I would rather make an assumption that emergency and 
> the subset thereof are all we support and leave an extension point 
> for people to extend from if the need ever arises.
>
>
>  Cheers
>  James
>
>
>   > I have a technical question about the draft.  From my reading, 
> it appears that the extension is to add an empty 
> all possible values that could be returned.  Is this correct or am 
> I missing something?  If it is correct, why is the 
>>>  The chairs will request to the milestone addition for this draft 
>>> to be submitted to the IESG by September 2015, of course earlier 

-------------- Randomly selected tag: ---------------
Those are my principles. If you don't like them I have others.
    --Groucho Marx

---

From: James Winterbottom <[email-masked]>
Date: Wed, 31 Dec 2014 09:14:42 +1100

That’s a really good idea Randy, I shall do that.

The other idea I have been toying with is, if the LIS has it, allowing the LIS to return the address of the LoST server in place of the routing information itself. This would allow areas that deploy LoST servers but not forest guide networks, islands if you like, to still have the authoritative server queried directly. This won’t work in all cases, as the draft describes, but it could assist in some environments.

Cheers
James

> On 23 Dec 2014, at 11:08 pm, Randall Gellens <[email-masked]> wrote:
> 
> Hi James,
> 
> So the draft currently specifies that only sos and children of sos are returned?  I'd missed that when I read and re-read the draft.  If so, that's fine with me, but maybe it can be made more clear.
> 
> To me, this says that sos is just an example of a service that might be returned.
> 
> What might be better would be to modify my suggestion so that a <service> element can be included, and if not, the default is 'sos' and any children of 'sos'.
> 
>