IETF Logo Mail Archive

Re: [Ecrit] DISCUSS on draft-ietf-ecrit-location-hiding-req

"Winterbottom, James" <James.Winterbottom@andrew.com> Sun, 21 February 2010 07:49 UTC

Return-Path: <James.Winterbottom@andrew.com>
X-Original-To: ecrit@core3.amsl.com
Delivered-To: ecrit@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23473A7B55 for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+BoBYafhGOL for <ecrit@core3.amsl.com>; Sat, 20 Feb 2010 23:49:41 -0800 (PST)
Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id E4E9E3A7B42 for <ecrit@ietf.org>; Sat, 20 Feb 2010 23:49:40 -0800 (PST)
Received: from [10.86.20.103] ([10.86.20.103]:35633 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S12076791Ab0BUHve convert rfc822-to-8bit (ORCPT <rfc822; ecrit@ietf.org>); Sun, 21 Feb 2010 01:51:34 -0600
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 21 Feb 2010 01:51:34 -0600
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sun, 21 Feb 2010 15:51:32 +0800
From: "Winterbottom, James" <James.Winterbottom@andrew.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
Date: Sun, 21 Feb 2010 15:50:12 +0800
Thread-Topic: DISCUSS on draft-ietf-ecrit-location-hiding-req
Thread-Index: Acqya3XpdZhB1FyqT8O5XHqIErjj1gAXeVVwAABJGiA=
Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120DBE5310F@SISPE7MB1.commscope.com>
References: <3D3C75174CB95F42AD6BCC56E5555B450238916D@FIESEXC015.nsn-intra.net>, <EDC652A26FB23C4EB6384A4584434A0401F49B7D@307622ANEX5.global.avaya.com>
In-Reply-To: <EDC652A26FB23C4EB6384A4584434A0401F49B7D@307622ANEX5.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com
X-BCN-Sender: James.Winterbottom@andrew.com
Cc: "ecrit@ietf.org" <ecrit@ietf.org>
Subject: Re: [Ecrit] DISCUSS on draft-ietf-ecrit-location-hiding-req
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Feb 2010 07:49:42 -0000

Holes in Polygons has been waiting for nearly 18 months to actually appear on an IESG telechat.
I don't know what the hold up has been, but hopefully the incoming AD for this area will speed things up a bit.. *hint* hint*

Cheers
James

________________________________________
From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) [dromasca@avaya.com]
Sent: Sunday, February 21, 2010 1:46 AM
To: Tschofenig, Hannes (NSN - FI/Espoo)
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] DISCUSS  on draft-ietf-ecrit-location-hiding-req

> -----Original Message-----
> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:hannes.tschofenig@nsn.com]
> Sent: Sunday, February 21, 2010 9:27 AM
> To: Romascanu, Dan (Dan)
> Cc: ecrit@ietf.org
> Subject: DISCUSS on draft-ietf-ecrit-location-hiding-req
>
> Hi Dan,
>
> You wrote:
> "
> I like the document and I belive that it's ready for
> approval, but I have a rather minor detail to clarify.
>
>  Req-6:  The solution MUST work if PSAP boundaries have holes.  (For a
>       discussion about holes in PSAP boundaries and their encoding the
>       reader is referred to [I-D.ietf-ecrit-specifying-holes].)
>
> I do not see how the requirement can be understood without
> understanding the concept of holes in PSAP or LoST service
> boundaries. This being a MUST requirement it looks to me like
> [I-D.ietf-ecrit-specifying-holes] should be a Normative
> rather than Informative reference.
> "
>
> [I-D.ietf-ecrit-specifying-holes] specifies one specific way
> of encoding holes in PSAP boundaries but the requirement
> itself is independent of the chosen approach.
>
> So, in that sense I would believe there is no normative dependency.
> However, if someone does not know what "a hole in a PSAP
> boundary" means then they should better read a document and
> there is only one document they can read from the IETF ECRIT
> group that explains this aspect.
>
> So, what you you suggest me to do?
>
> Ciao
> Hannes
>

Yes - the problem is that the document lacks a definition of what "a
hole in a PSAP  boundary" means. That 'one document they can read from
the IETF ECRIT group that explains this aspect' should be a normative
reference IMO. What document are we talking about -
[I-D.ietf-ecrit-specifying-holes] or something else? The alternative is
to define the term here.

Regards,

Dan
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit

v2.23.0 | Report a Bug | By Email