[apps-discuss] apps-team review of draft-ietf-geopriv-rfc3825bis

Claudio Allocchio <Claudio.Allocchio@garr.it> Wed, 01 December 2010 09:25 UTC

DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=L6JoTctj9ApaD/fY600acTk3kcEWpJ11AshtdsiCjQMprvNSNYN2z1WGfQ9vLBkQJ s94HHAT3Z00JYXcfNhaVMkamuEIrs8FlMZTdHY8DiTOzGMKbA7hU5/AGtxmYIASM/zT xk/1OcQT2BTbZVGvBDP7dZi9rlpfUPSqjcmSSnk=
Date: Wed, 01 Dec 2010 10:26:25 +0100
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
To: apps-discuss@ietf.org, jmpolk@cisco.com, john@schnizlein.org, marc.linsner@cisco.com, martin.thomson@andrew.com, bernarda@microsoft.com, iesg@ietf.org
Message-ID: <Pine.OSX.4.64.1011301428440.5587@mac-allocchio3.elettra.trieste.it>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Subject: [apps-discuss] apps-team review of draft-ietf-geopriv-rfc3825bis
Precedence: list

I have been selected as the Applications Area Review Team reviewer for this
draft (for background on apps-review, please see
http://www.apps.ietf.org/content/applications-area-review-team).

Please resolve these comments along with any other Last Call comments you
may receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.

Document: draft-ietf-geopriv-rfc3825bis
Reviewer: Claudio Allocchio (GARR, Italian Research and Academic Network)
Review Date: 2010-11-30
IETF Last Call Date: 2010-10-11
IESG Telechat Date: 2010-12-02

Summary: This draft specifies quite well and clearly the problem to solve, 
and all its impications and scenarios. Examples in appendixes are useful 
to understand real cases and help implementors to avoid misunderstandings 
(even if at first sight the lenght balance of "normative text section" vs 
"appendix/examples sections" might look unfair). It looks ok for 
publication and it seems to clarfy all points raised. Just see the Minor 
issues and Nits below.

Major Issues: None.

Minor Issues:


Section 2.2.1.2.  Server Version Selection

The sentence

    "A DHCPv4 server that provides location
    information cannot provide options with both version 0 and version 1
    formats in the same response."

does not use a normative language... it says "cannot"... Given also the 
explanation in the following of the text, I would suggest using normative 
language here, to avoid implementation problems, e.g.:

    "A DHCPv4 server that provides location
    information MUST NOT provide options with both version 0 and version 1
    formats in the same response."

Section 2.4.3.  Altitude in Floors (AType = 2)

The Altitude value is a 30bits fixed point, thus it can have a negative 
value. However in thr "AType = 2" (Floors) section I would suggest adding 
a sentence also to cover clearly "undel Ground Level" floors (... my main 
GigaPop is at -2 ... for example).

   "For instance, and undeground Servers room could be represented as -2.0"

  Nits:

   Boilerplate required by RFC 5378 and the IETF Trust (see
   http://trustee.ietf.org/license-info):

   You're using the IETF Trust Provisions' Section 6.b License Notice
   from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
   http://trustee.ietf.org/license-info/)

:-)

go ahead!

best regards,

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

[apps-discuss] apps-team review of draft-ietf-geo… Claudio Allocchio
Re: [apps-discuss] apps-team review of draft-ietf… Claudio Allocchio