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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 25 Feb 2003 16:33:08 -0500

Heh, right. I've been considering the 'last mile' chunk to be between the
end user (currently, their POTS phone - in the future, their IP phone) and
the selection router - that's how I thought we were using the term in our
conf call, and hence my confusion (I was contrasting the terms 'last mile'
with 'trunking replacement' on the call). The use of the term 'access' in
the title of section 4 made me think you were describing the access portion
of the network (i.e. copper to the home, etc). Your suggestion in the intro
to the section that the transport could be analog or ISDN but might be
replaced with DSL certainly supported that reading. I thought the term
'trunking' was used casually there.

I guess looking more closely at that section, requirement M-7 and a few
others might have tipped me off that these requirements were about the
trunking replacement. The definition in section 3 of 'last mile emergency
service' also is a pretty good indicator. I don't know if this would have
been unclear to someone who hadn't been on our conference call. I imagine
that paraphrasing the definition of 'last mile' from section 3 in the intro
to section 4 would clear up any conceivable ambiguity. I also would avoid
using the term 'access' in the title of section 4.

>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.

- J

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Tuesday, February 25, 2003 7:06 AM
> To: King, Kimberly S.
> Cc: Peterson, Jon; [email-masked]
> Subject: Re: [Sipping-emergency] Re: [Sipping-emergency]
> draft-schulzrinne-sipping-emergency-req-00
> 
> 
> Maybe we're getting closer to the source of the confusion... 
> During the 
> teleconference, I had associated 'last-mile' with the 
> recently-completed 
> NENA effort, which only deals with what section 4 describes. 
> Since it's 
> the last mile before reaching the PSAP/ECC, I used that term. Maybe 
> others were thinking of what I'd consider 'first-mile', i.e., from a 
> VoIP phone to a PSTN gateway?
> 
> That might explain a few of the rounds of discussion... Jon, Allison: 
> where's first and last? :-)
> 
> King, Kimberly S. wrote:
> > Henning,
> > 
> > 
> >>"In last-mile access, an ECC replaces an analog (CAMA) or 
> >>digital (ISDN) 
> >>trunk with packet-based access,
> >>typically over one or more high-speed access lines such as DSL 
> >>or leased 
> >>lines."
> >>
> >>Suggestions on how to make this clearer are welcome.
> > 
> > 
> > 
> > I believe it isn't as clear because it disorients the 
> reader.  The last mile
> > (reader is thinking from the perspective of being the client) has
> > packet-based access (access puts the reader in the 
> perspective of being on
> > the "server" side).
> > 
> > I can't completely re-word it as I'm not totally clear what 
> you are trying
> > to say but I'll take a shot at it.
> > 
> > "In the last mile situation, instead of calls being 
> terminated by analog
> > (CAMA) or digital (ISDN) trunks, they are terminated by 
> high-speed DSL or
> > leased line packet-based solutions."  
> > 
> > Kimberly
> 
_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Feb 2003 17:54:07 -0500

> 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