Skip to main content

Specifying Civic Address Extensions in the Presence Information Data Format Location Object (PIDF-LO)
draft-ietf-geopriv-local-civic-10

Yes

(Robert Sparks)

No Objection

(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Wesley Eddy)

Note: This ballot was opened for revision 07 and is now closed.

Robert Sparks Former IESG member
Yes
Yes (for -07) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-10-25 for -09) Unknown
I have no objection to the publication of this document.

I think the Security Considerations section would benefit from a direct
reference to RFC 3694 (rather than relying on the cascaded reference
though RFC 5139 and RFC 4119). In partcular, the addition of new
extensions makes the protection of location information by a user a more
complex matter and sections 4.3.1 and 5.1 of RFC 3694 could be called 
out. Essentially, inventors of new extensions need to told to make very
clear how naive users of geopriv systems will be able to protect their
LI.

I agree with Stewart's Comments.
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2012-10-17 for -09) Unknown
Updated for version -09:

Version -08 addresses my DISCUSS points.
Version -09 addresses my non-blocking comments.

Thanks very much for considering my comments and making changes

Leaving one for amusement value:

-- Section 5.1 --
Excellent ASCII-art lamp post you got there.
Benoît Claise Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-10-25 for -09) Unknown
3.2

Using space as a separator means that local name can have no spaces in it. Is that guaranteed by XML? Is there a reason not to use a leading length byte for each of the elements? Easier to parse.

   The content of a CAtype (after the CAtype code and length) is UTF-8
   encoded Unicode text [RFC3629].

So the URL must be US-ASCII. Probably best to say that. The local name also has some limitations I suppose. Saying the whole thing is UTF-8 is not helpful.

   This conversion only works for elements that have textual content and
   an optional "xml:lang" attribute.

I don't understand why this is the case.
Ralph Droms Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2012-12-05) Unknown
Version -10 fixes up my discuss points. Thanks!

- 3.2: I assume the length field includes the two spaces
so the description below should say "Length is the number of... 
plus 2" or similar. I think you might still usefully clarify that.
Stewart Bryant Former IESG member
No Objection
No Objection (2012-10-22 for -09) Unknown
123 Colorado Boulevard is a real address
123A Main Street is likely a real address, there are enough 123Main Streets that one may well have and "A"

Shouldn't we be using example addresses?

I looked for, but did not see an identifier for a house with no number. Such houses exist:
Wentwood House, Upper Clapton Rd, London, Greater London E5 9BY, UK
High Farm, Farrar Lane Leeds LS16 7AQ
to take two random examples from Google.
Wesley Eddy Former IESG member
No Objection
No Objection (for -09) Unknown