Considerations for Civic Addresses in the Presence Information Data Format Location Object (PIDF-LO): Guidelines and IANA Registry Definition
draft-ietf-geopriv-civic-address-recommendations-03

[Ballot comment]
Section 6173, paragraph 36:
>    The element A5 holds the Katastralgemeindename (cadastral
>    municipality), the Katastralgemeindekennziffer (the identifier), or

  This is the only place where Katastralgemeindekennziffer appears in
  the document - do you mean Katastralgemeindenummer?

[Ballot discuss]
Section 5139, paragraph 0:
>    For some countries Section 3.4 of [RFC4776] already contains
>    considerations on the use of administrative sub-division elements.
>    It's important to note that those examples are outdated, because RFC
>    5139 [RFC5139] disallows the use of the 'A6' elements for street
>    names.

  DISCUSS: Then this document should formally "Update" RFC4776 and
  include a subsection that makes Section 3.4 obsolete. (Since RFC5139
  doesn't do so.) And also do what Tim's comment suggests (mark them in
  the IANA registry).


Appendix A., paragraph 0:
> Appendix A.  Civic Address Considerations Registration for the Austrian
>              building and habitation registry

  DISCUSS-DISCUSS: Is this given as an example, i.e., as an informative
  appendix or is this appendix in fact normative, i.e, is it the
  RFC4776-required "civic address consideration document" for Austria?

[Ballot comment]
Updated to add a forgotten comment...

from section 1:

  For some countries Section 3.4 of [RFC4776] already contains
  considerations on the use of administrative sub-division elements.
  It's important to note that those examples are outdated, because RFC
  5139 [RFC5139] disallows the use of the 'A6' elements for street
  names.

I suggest that this document register these examples in the new IANA registry
as "obsolete" for completeness.

[Ballot discuss]
I had a hard time deciding whether this should be a weak discuss or strong comment, but decided to err towards the discuss this time...

  In addition to that, it has to be considered that data from
  certain data sources (on which the described mapping process is
  based) are possibly not public, so restrictions as imposed on the
  original data set MUST also be imposed on the resulting PIDF-LO
  document.

I agree with this statement, but believe it should be addressed directly
in the body of the document, with a bullet of its own in section 3.

[Ballot discuss]
I had a hard time deciding whether this should be a weak discuss or strong comment, but decided to err towards the discuss this time...

  In addition to that, it has to be considered that data from
  certain data sources (on which the described mapping process is
  based) are possibly not public, so restrictions as imposed on the
  original data set MUST also be imposed on the resulting PIDF-LO
  document.

I agree with this statement, but believe it should be addressed directly
in the body of the document, with a bullet of its own in section 3.

IANA questions/comments:


- QUESTION: where/how should we post the XML in section A.6?

- IESG Note: Expert Reviewer required

Upon approval of this document, IANA will create the following registry at
http://www.iana.org/assignments/TBD

Registry Name: PIDF-LO Civic Address Consideration Registry
Registration Procedure: Expert Review
Initial contents of this registry will be:

Country Serial
Code Number Requestor Status Reference
------- ------ ----------- ------ ---------
AT 0 Alexander Mayrhofer Karl Heinz Wolf active
[RFC-geopriv-civic-address-recommendations-02]


We understand the above to be the only IANA Action for this document.

(1.a) The Document Shepherd for
draft-ietf-geopriv-civic-address-recommendations is Richard Barnes. I
have reviewed this version of the document and believe it is ready for
IESG consideration.

(1.b) The document appears to have had adequate review from people that
both deal with civic addresses in different countries and are familiar
with the RFC 4776/5139 civic address format.

(1.c) I don't believe the document requires focused review from a
different perspective. The focus of the document is mapping local data
sources (often in different languages) into a common XML format. Calling
attention to it from the XML and internationalization communities during
IETF last call would be appropriate.

(1.d) I am not aware of any special concerns the IESG needs to take into
consideration. No IPR disclosures have been filed against this document.

(1.e) There seems to be solid WG consensus behind this document.
Comments on the mailing list have been consistently supportive, and when
it was last presented at a GEOPRIV meeting (at IETF 72), several
participants spoke in favor.

(1.f) I am not aware of any extreme discontent over this document.

(1.g) The document satisfies the idnits requirements.

(1.h) References are split into normative and informative. All
normative references are RFCs.

(1.i) The IANA considerations section requests the creation of a
registry to store pointers to local civic address standards, consistent
with the discussion in the main body of the document. The document does
not specify protocol extensions. The IANA registry to be created is
clearly identified and described. The shepherd has discussed the expert
review requirement with Cullen Jennings, the responsible AD.

(1.j) The only formal language used in the document is XML. The
shepherd has validated the one complete document (a PIDF-LO example)
using the tools at validate.openlaboratory.net, and the snippets given
as examples illustrate correct syntax.

(1.k) Announcement Text

Technical Summary

This document provides a guideline for creating civic address
consideration documents for individual countries, as required by RFC
4776. Since civic addresses may have a different format in individual
countries, such address considerations are necessary in order to map the
civic address fields to the PIDF Location Object (PIDF-LO) elements.

Working Group Summary

This document was reviewed by the GEOPRIV working group, where it has
reached consensus for publication as an IETF RFC.

Document Quality

XML examples in the document validate against relevant schemas.

The document itself defines one implementation of its recommendations:
In addition to defining guidelines for mappings between local civic
address standards and the format of RFC 4776, the document describes
such a mapping for addresses within Austria.