RE: [Sipping-emergency] RE: Civil location syntax validation - wa s RE: How to handle Validation failures

"Peterson, Jon" <jon.peterson@neustar.biz> Wed, 29 September 2004 00:30 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08877 for <sipping-emergency-web-archive@ietf.org>; Tue, 28 Sep 2004 20:30:52 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCSUs-0007k2-3d for sipping-emergency-web-archive@ietf.org; Tue, 28 Sep 2004 20:39:06 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCS3V-0001Tw-Lu; Tue, 28 Sep 2004 20:10:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CCRl9-0003Mc-Pp for sipping-emergency@megatron.ietf.org; Tue, 28 Sep 2004 19:51:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05824 for <sipping-emergency@ietf.org>; Tue, 28 Sep 2004 19:51:48 -0400 (EDT)
Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CCRsv-0006eC-9u for sipping-emergency@ietf.org; Tue, 28 Sep 2004 20:00:03 -0400
Received: from stntimc1.va.neustar.com (stntimc1.neustar.com [10.31.13.11]) by oak.neustar.com (8.12.8/8.11.0) with ESMTP id i8SNoCPm001792; Tue, 28 Sep 2004 23:50:12 GMT
Received: by stntimc1.cis.neustar.com with Internet Mail Service (5.5.2657.72) id <T32LKTSV>; Tue, 28 Sep 2004 19:50:12 -0400
Message-ID: <7927C67249E4AD43BC05B539AF0D129801AF41E8@stntexch04.cis.neustar.com>
From: "Peterson, Jon" <jon.peterson@neustar.biz>
To: 'Brian Rosen' <br@brianrosen.net>, 'Marc Linsner' <mlinsner@cisco.com>, sipping-emergency@ietf.org
Subject: RE: [Sipping-emergency] RE: Civil location syntax validation - wa s RE: How to handle Validation failures
Date: Tue, 28 Sep 2004 19:50:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
X-BeenThere: sipping-emergency@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: sipping-emergency.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-emergency>, <mailto:sipping-emergency-request@ietf.org?subject=unsubscribe>
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>
Sender: sipping-emergency-bounces@ietf.org
Errors-To: sipping-emergency-bounces@ietf.org
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 200d029292fbb60d25b263122ced50fc

So, just to make sure I understand, validation uses the same network
operation, basically, that would be used for a route query?

Agreed that it should be possible for a route query to return 'I didn't
understand your address format', 'I understand your address and it isn't
actually valid', and so on beyond just the sunny-day case of returning the
route. Also, plus or minus some authorization and operational issues, I
agree that an ordinary user should be able to launch this sort of query
outside the context of an emergency call.

To be clear, what I want to avoid is specifying exactly what happens in the
backend of the server that causes responses like 'your address isn't
actually valid'. I don't think we have the expertise to address that.

Provided that the essence of the proposed requirement is that it be possible
to use the route query mechanism as a validation mechanism, I have no
problem with this. The question is, are there any differences in
architecture/network messaging/security model/etc that I'm missing, here,
which result from this requirement? If not, is this requirement inert (i.e.,
does it fail to have any impact on our protocol design)?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Tuesday, September 28, 2004 6:02 AM
> To: 'Marc Linsner'; 'Peterson, Jon'; sipping-emergency@ietf.org
> Subject: [Sipping-emergency] RE: Civil location syntax 
> validation - was
> RE: How to handle Validation failures
> 
> 
> Yeah, that's the way I see it. 
> 
> Validation is a requirement.
> Validation is the first part of determining a route:
> A query using the location information as the key.
> 
> Any answer is validation.  The answer is the route.
> 
> You can do the validation query without needing the route.
> You do that as an independent verification that the
> location information is valid.  Validation is
> automatically performed when you determine the route,
> either during a test operation as Henning describes,
> or for the actual call (not implying whether route
> determination is done prior to or at the time of 
> an emergency call).
> 
> Jon, is that sufficient information to consider validation
> within the charter?
> 
> Brian
> 
> > -----Original Message-----
> > From: Marc Linsner [mailto:mlinsner@cisco.com]
> > Sent: Tuesday, September 28, 2004 8:54 AM
> > To: 'Peterson, Jon'; 'Brian Rosen'; sipping-emergency@ietf.org
> > Subject: Civil location syntax validation - was RE: How to handle
> > Validation failures
> > 
> > Changed the subject line to more correctly describe the function.
> > 
> > Civil location syntax validation could be considered as a 
> requirement when
> > determining the routing design.  If routing is designed properly,
> > validation
> > will simply be a routing query that utilizes the response 
> differently.
> > Validation, in this context, does not include the 
> verification that the
> > device is actually located where it claims to be, it is 
> simply a process
> > that verifies that the syntax/value of the location 
> provided describes a
> > valid location known by all.  A simple routing query that produces a
> > routing
> > result is validation in this context.
> > 
> > 
> > -Marc Linsner-
> > 
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> > > Sent: Monday, September 27, 2004 7:42 PM
> > > To: 'Brian Rosen'; 'Marc Linsner'; sipping-emergency@ietf.org
> > > Subject: RE: How to handle Validation failures was RE:
> > > [Sipping-emergency] proposed charter, new wg on emergency
> > >
> > >
> > >
> > > > I changed the subject, as we are off the subject of a new
> > > charter, as
> > > > we agree validation should be in that charter.
> > > >
> > >
> > > Brian,
> > >
> > > I'm not sure that everyone on this distribution agrees that
> > > validation should be in the scope of this proposed working
> > > group. In fact, until I read your mail, I had gotten the
> > > sense that several voices (including James, Marc and Nate)
> > > were questioning this idea.
> > >
> > > I think validation as such is probably outside of the core
> > > expertise of the IETF, whereas routing is more likely to be a
> > > place where we can do some solid work. The expertise of the
> > > IETF does not lie in subjects like whether Conrad St is in
> > > Butler County or Pine Township, nor in recommending how you
> > > might figure something like that out. Moreover, this seems to
> > > be a back-end application issue, not a protocol issue, as I
> > > think a number of people have already pointed out.
> > >
> > > I think that validation is a separable operation from
> > > routing, even if it is a prerequisite in some operational
> > > models. An umbrella specification that described everything
> > > you needed to do in order to provide emergency services might
> > > include validation, but that doesn't mean that the routing
> > > protocol should change in any way because validation was or
> > > was not performed. But I don't think the IETF has the breadth
> > > to tackle that whole umbrella.
> > >
> > > Jon Peterson
> > > NeuStar, Inc.
> > >
> > 
> > 
> 
> 
> 
> 
> _______________________________________________
> 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