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

Henning Schulzrinne <hgs@cs.columbia.edu> Tue, 25 February 2003 13:20 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 IAA00362 for <sipping-emergency-archive@odin.ietf.org>; Tue, 25 Feb 2003 08:20:00 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1PDT0B28473 for sipping-emergency-archive@odin.ietf.org; Tue, 25 Feb 2003 08:29: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 h1PDT0p28470 for <sipping-emergency-web-archive@optimus.ietf.org>; Tue, 25 Feb 2003 08:29:00 -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 IAA00354 for <sipping-emergency-web-archive@ietf.org>; Tue, 25 Feb 2003 08:19:28 -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 h1PDSxp28460 for <sipping-emergency-web-archive@ietf.org>; Tue, 25 Feb 2003 08:28:59 -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 h1PDPOp28289 for <sipping-emergency@optimus.ietf.org>; Tue, 25 Feb 2003 08:25:24 -0500
Received: from dewberry.cc.columbia.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00230 for <sipping-emergency@ietf.org>; Tue, 25 Feb 2003 08:15:51 -0500 (EST)
Received: from cs.columbia.edu (tallgrass.netlab.uky.edu [204.198.76.66]) (user=hgs10 mech=PLAIN bits=0) by dewberry.cc.columbia.edu (8.12.3/8.12.3) with ESMTP id h1PDJZZU019347 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Feb 2003 08:19:39 -0500 (EST)
Message-ID: <3E5B6D7D.70201@cs.columbia.edu>
Date: Tue, 25 Feb 2003 08:19:57 -0500
From: Henning Schulzrinne <hgs@cs.columbia.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Peterson, Jon" <jon.peterson@neustar.biz>
CC: sipping-emergency@ietf.org
Subject: Re: [Sipping-emergency] Re: [Sipping-emergency] draft-schulzrinne -sipping-emergency-req-00
References: <15A2739B7DAA624D8091C65981D7DA8101214E3A@stntexch2.va.neustar.com>
In-Reply-To: <15A2739B7DAA624D8091C65981D7DA8101214E3A@stntexch2.va.neustar.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

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.

Peterson, Jon wrote:
>>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.

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

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

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

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