[Ecrit] AD Evaluation: draft-ietf-ecrit-lost-servicelistboundary-04

Robert Sparks <rjsparks@nostrum.com> Tue, 23 November 2010 18:57 UTC

Return-Path: <rjsparks@nostrum.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 C72DC3A6987 for <ecrit@core3.amsl.com>; Tue, 23 Nov 2010 10:57:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 0dMy8WiOrIWN for <ecrit@core3.amsl.com>; Tue, 23 Nov 2010 10:57:04 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 686BF3A693E for <ecrit@ietf.org>; Tue, 23 Nov 2010 10:57:04 -0800 (PST)
Received: from [192.168.2.105] (pool-173-71-48-4.dllstx.fios.verizon.net [173.71.48.4]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oANIw0Ut089564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <ecrit@ietf.org>; Tue, 23 Nov 2010 12:58:01 -0600 (CST) (envelope-from rjsparks@nostrum.com)
From: Robert Sparks <rjsparks@nostrum.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 23 Nov 2010 12:58:00 -0600
Message-Id: <F3D762E3-28B4-48A1-BAA8-33ECCD1F9B46@nostrum.com>
To: ecrit@ietf.org
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Received-SPF: pass (nostrum.com: 173.71.48.4 is authenticated by a trusted mechanism)
Subject: [Ecrit] AD Evaluation: draft-ietf-ecrit-lost-servicelistboundary-04
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: Tue, 23 Nov 2010 18:57:06 -0000

I've requested IETF Last call of this document.

A question:

The examples use a civic address boundary (of Lower Austria). Do you expect automata to be able to recognize when they have
left these regions? (Would a phone be able to turn "Lower Austria" into a polygon so that it would know when it left?). Would it have
made more sense to have constructed these examples with geospatial regions?

----
Some suggestions:

Since the introduction is long, it would help to move the main point of the introduction (currently in the last paragraph) to the front of the section.

On page 4, 2nd to last paragraph, the sentence "Nevertheless, the client does not detect this, because only the mapping of the initially discovered services (police, ambulance, fire) are refreshed." is hard to parse.
I suggest "Since the client is only required to refresh the mappings for the initially discovered services, the new service is not detected."

At the top of page 10, the phrase "so no boundary information is reasonable" is ambiguous. Is it trying to say
"there is no boundary information that is reasonable to send" or "it is reasonable to send no boundary information"?