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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 25 Feb 2003 04:46:18 -0500

>From what I took away from our phone call, one concern was that the
last-mile work needs to block until the geopriv work has become more fully
specified. The short-term issues seemed like they might warrant a separate
document precisely because that document is achievable (and passable by the
IESG) in the short term. 

I also note that the document really doesn't seem to talk about the
trunking-replacement architecture we discussed on the telephone call at all,
except as a component of the end-to-end solution. If that this realistically
the only architecture that will be deployed in the next few years, perhaps
the document should give it more attention.

One nit: if (following I-6) integrity properties of responses from an IECC
are REQUIRED, this entails that authentication of the IECC to the caller is
also REQUIRED (which would seem to contradict I-3). You cannot provide
integrity properties without authentication.

- J

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, February 22, 2003 3:00 PM
> To: Allison Mankin
> Cc: [email-masked]
> Subject: Re: [Sipping-emergency] Re: [Sipping-emergency]
> draft-schulzrinne-sipping-emergency-req-00
> 
> 
> The last-mile requirements are in a separate section, so I'm 
> not sure I 
> see the problem. (Besides, quite frankly, I'm not sure what 
> needs to be 
> done, SIP-wise, for the short-term issues. As I said, this is 
> effectively an ACD with conference recording. It might be 
> useful to say 
> that, but I think we might make some progress if we can identify, at 
> least within the design team, the likely areas needing work for the 
> last-mile case. There are, to be sure, other useful ways to 
> apply IP in 
> the last-mile case, but those are effectively geopriv 
> territory, namely 
> the authorized retrieval of location information given an 
> E.164 identifier.)
> 
> Allison Mankin wrote:
> > Henning,
> > 
> > The problem with expressing all the requirements is that it
> > will not guide the work and discussion on the shorter-term goals
> > properly.
> > 
> > Allison
> 
> _______________________________________________
> Sipping-emergency mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/sipping-emergency
> 
_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 25 Feb 2003 08:19:57 -0500

Maybe this is due to the lack of precision on my part, but the 
'last-mile' section (Section 4) is exactly that. Indeed, the very first 
sentence says

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

> the document should give it more attention.

I'm afraid I don't see this. Section 4 draws largely from the NENA TID, 
which only talks about trunk replacement.

> integrity properties without authentication.

Depends on what you're protecting. If you're protecting the integrity of 
the request from caller to IECC (e.g., including the location 
information), the IECC doesn't have to be authenticated.

Also, I don't see why this has to wait until geopriv is done. While the 
details on how this works will obviously be affected by the concrete 
output of geopriv, the requirements remain the same.

Henning