Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00

>>From my perspective anyway, what I'm concerned about is that the full e2e
> solution be bundled separately from the more immediately achievable work.
> Whether or not these two are in separate sections is less material to me,
> but ultimately, we know that the section 4 solution is not depending on
> geopriv, but the later material is. I think there is value in having the
> section 4 work go forward on its own merits, and fully specifying this
> solution - I know you think this is trivial, but to me, trivial means
> achievable. :) Putting the later e2e work in a separate document would
> remove any geopriv dependencies for the section 4 work.

I would like to identify any real work which isn't just "purchasing 
requirements for PSAP RFP" in the trunk replacement part. Can you 
identify anything?

I happen to think that while end-to-end or even first-mile (something I 
haven't called out explicitly) does need geo information that the 
problem can be scoped properly so that it does not interfere with 
geopriv work. At this point, I don't see the need to specify in detail 
how the PSAP gets the location of the caller. We know it needs to - I 
don't think geopriv is going to change that. There are only two 
plausible ways to convey location - in a 'using protocol' and in some 
out-of-band retrieval mode using a geopriv-specific mechanism. I don't 
think that level of detail is controversial or likely to change.

Also, the PSAP selection problem can be partially solved with existing 
(apparently non-controversial) items in geopriv, namely the DHCP items.

Thus, as long as we assume that geopriv does its job, we can fill in the 
other pieces and make progress, treating geopriv as a suitable black box.

Thus, if we scope the work properly, I don't see why we'd bump into 
geopriv issues except saying "you guys over there, we'll need you, get 
busy".

Henning

_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency