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

From: Claudio Allocchio <[email-masked]>
Date: Wed, 1 Dec 2010 10:26:25 +0100 (CET)

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          [email-masked]
                         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

---

From: Claudio Allocchio <[email-masked]>
Date: Wed, 1 Dec 2010 10:30:26 +0100 (CET)

ANOTHER NIT:

                         The Postfix program

<[email-masked]>: host
     winse-6216-mail6.customer.frontbridge.com[131.107.115.215] said: 550
5.1.1
     User unknown (in reply to RCPT TO command)

you should Fix the Author's Addresses section, too.

On Wed, 1 Dec 2010, Claudio Allocchio wrote:

> 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:
>
>
> value. However in thr "AType = 2" (Floors) section I would suggest adding a 
> sentence also to cover clearly "undel Ground Level" floors (... my main 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>