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

"Peterson, Jon" <jon.peterson@neustar.biz> Tue, 25 February 2003 09:47 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21841 for <sipping-emergency-archive@odin.ietf.org>; Tue, 25 Feb 2003 04:47:04 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1P9u1B13191 for sipping-emergency-archive@odin.ietf.org; Tue, 25 Feb 2003 04:56:01 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9u1p13187 for <sipping-emergency-web-archive@optimus.ietf.org>; Tue, 25 Feb 2003 04:56:01 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21813 for <sipping-emergency-web-archive@ietf.org>; Tue, 25 Feb 2003 04:46:33 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9u0p13171 for <sipping-emergency-web-archive@ietf.org>; Tue, 25 Feb 2003 04:56:00 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1P9q9p13032 for <sipping-emergency@optimus.ietf.org>; Tue, 25 Feb 2003 04:52:09 -0500
Received: from willow.neustar.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21791 for <sipping-emergency@ietf.org>; Tue, 25 Feb 2003 04:42:41 -0500 (EST)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h1P9kFC21790; Tue, 25 Feb 2003 09:46:15 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <ZH2JPQPS>; Tue, 25 Feb 2003 04:46:20 -0500
Message-ID: <15A2739B7DAA624D8091C65981D7DA8101214E3A@stntexch2.va.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: 'Henning Schulzrinne' <hgs@cs.columbia.edu>, Allison Mankin <mankin@psg.com>
Cc: sipping-emergency@ietf.org
Subject: RE: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00
Date: Tue, 25 Feb 2003 04:46:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: sipping-emergency-admin@ietf.org
Errors-To: sipping-emergency-admin@ietf.org
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
List-Id: <sipping-emergency.ietf.org>
List-Post: <mailto:sipping-emergency@ietf.org>
List-Help: <mailto:sipping-emergency-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=subscribe>

>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:hgs@cs.columbia.edu]
> Sent: Saturday, February 22, 2003 3:00 PM
> To: Allison Mankin
> Cc: sipping-emergency@ietf.org
> 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
> Sipping-emergency@ietf.org
> https://www1.ietf.org/mailman/listinfo/sipping-emergency
> 
_______________________________________________
Sipping-emergency mailing list
Sipping-emergency@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-emergency