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

[Ballot comment]

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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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 419). 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.

[Ballot comment]
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.

[Ballot discuss]

I disagree that there are no new security considerations but
these ought be easily fixed. 

- First, this introduces (namespace) URLs into DHCP messages,
and it could be that DHCP clients or servers or relays might
de-reference those as part of translating between DHCP messages
and XML, and that might result in bad things happening. I think
you ought say to not do that.

- Second, extensions could be defined that are more sensitive
than those that exist in 4776, (room-function=HIV-testing-lab
or similar perhaps) which notes that DHCP offers no protection
whatsoever for such information, so I think you ought to again
say to not do that and that the designated expert should take
that into account if someone proposed some particularly
sensitive information be included as an extension to civic
addresses.

[Ballot comment]


- Can't we use canals.example.com rather than canals.org.uk?
(And same for other examples)

- 3.2: I assume the length field includes the two spaces
so the description below should say "Length is the number of...
plus 2" right?

- 3.2: I don't get this bit: "This conversion only works for
elements that have textual content and an optional "xml:lang"
attribute." What is an element doesn't allow an xml:lang
attribute - why would that not work? And if there is an
xml:lang attribute, then how come that doesn't need to
appear in Figure 3?

- I also like Figure 6, thanks.

IANA has reviewed the recent version of draft-ietf-geopriv-local-civic-09 and has the following comments and question:

IANA understands that, upon approval of this document, there are five
actions that IANA needs to complete. IANA has question inline below.

Updated Actions:

ACTION 1:
In the CAtypes subregistry of the Civic Address Types Registry
located at:

http://www.iana.org/assignments/civic-address-types-registry/civic-address-types-registry.xml

a new CAtype is to be added as follows

CAtype: [ tbd ]
Local Name: CAtype ???
Description Civic Address Extension
Namespace URI: ???
Contact: ???
Schema: ???
Type: ???
Example: [ blank ]
Reference: [ RFC-to-be ]

IANA Question -> What are the values for these columns, "Local Name",
"Namespace URI", "Contact", "Schema" and "Type" for the registration of
this new CAtype? If they have no values, please clarify that in
the document.

ACTION 2:
Approval of this document changes the information in the CAtypes
sub-registry of the Civic Address Types Registry located at:

http://www.iana.org/assignments/civic-address-types-registry/civic-address-types-registry.xml
.
The column called "NENA" is removed.

The column called "PIDF" is renamed to "Local Name".

New columns are added named "Namespace URI", "Contact", "Schema" and "Type".

The Registration Policy and Reference are changed as follows:

OLD:
Registration Procedures: Specification Required, Expert Review
Experts: Martin Thomson
Reference: [RFC4776]

NEW:
Registration Procedures: IETF Review (if Type=A), Expert Review (if Type=B)
Experts: Martin Thomson
Reference: [RFC4776][ RFC-to-be ]

Note: As specified in [ RFC-to-be], new registrations are only
accepted for CAtype XX, using the template specified in
Section 8.3.

No registrations of new CAtype numbers in the Civic Address Types
Registry are permitted, except by IESG Approval [RFC5226] under
unusual circumstances.

ACTION 3:
The following four new CATypes are registered in the CAtypes subregistry
of the Civic Address Types Registry located at:

http://www.iana.org/assignments/civic-address-types-registry/civic-address-types-registry.xml

CAtype: XX
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: PN
Description: Post number that is attributed to a lamp post or
utility pole.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: [[this RFC]], Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A

CAtype: XX
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: MP
Description: Mile Post a marker indicating distance to or from a
place (often a town).
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: [[this RFC]], Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A

CAtype: XX
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: STP
Description: Street Type Prefix.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: [[this RFC]], Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A

CAtype: XX
Namespace URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Local Name: HNP
Description: House Number Prefix.
Contact: The IESG (iesg@ietf.org); the GEOPRIV working group
(geopriv@ietf.org)
Specification: [[this RFC]], Section 5
Schema: urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Type: A


ACTION 4:
A new namespace is registered in the IANA maintained registry of XML
documents located at:

http://www.iana.org/assignments/xml-registry/ns.html

ID: pidf:geopriv10:civicAddr:ext
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Registration template: pidf:geopriv10:civicAddr:ext
Reference: [ RFC-to-be ]

ACTION 5:
a new schema is registered in the IANA maintained registry of XML
documents located at:

http://www.iana.org/assignments/xml-registry/schema.html

ID: pidf:geopriv10:civicAddr:ext
URI:urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Filename: pidf:geopriv10:civicAddr:ext
Reference: [ RFC-to-be ]

IANA understands that these five actions are the only ones that need
to be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

[Ballot comment]
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.

[Ballot comment]
Updated for version -08:
Version -08 addresses my DISCUSS points, and thanks very much for the changes.

My remaining comments are non-blocking, but please consider them seriously, and feel free to chat with me about them:

Because this document massively changes the registration procedures that were defined in 4776, I strongly recommend that this document "Updates" 4776, as well as 5222.  You really want people who are reading 4776 to look here.

You seem to use "conversion" and "translation" interchangeably in talking about going between DHCP and XML formats.  It would probably help if you picked one and used it consistently.

-- Section 1 --
  Extension elements do not readily fit existing elements, as
  recommended in [RFC5774].

I don't understand this sentence; the "as recommended" doesn't have a clear antecedent.  Maybe you can rephrase it?  Where in RFC 5774 does it recommend what?  Are you talking about the part of Section 4.1 that begins "Fields that do not fit into an existing CAtype"?

-- Section 3.2 --
  The extension CAtype (CAtype code XX) [Note to IANA/RFC-Editor:
  please replace XX here and in the figure below with the assigned
  code]

That RFC Editor note needs to cover not just Figure 3 ("the figure below"), but also Figure 5.

The bit counts at the top of Figure 3 make it appear that Namespace URI, XML element local name, and Extension type value each have fixed lengths (6 bytes, 3 bytes, and 3 bytes, respectively).  Maybe no one will actually be confused by it... but perhaps it might be better to find another way to depict it.  It's also not specified what the Length field covers -- is it the total length of the CAtype, or just the length of the data after the Length field?  (I'll note that the diagrams in RFC 4776 have neither of these problems.)

-- Section 4 --
  Type A civic elements require IETF review, while Type B elements only
  require an expert review.

We've encountered the following situation a lot: a working group creates a registry with Expert Review or Specification Required registration policy.  The same working group then produces another document that wants to register something in that registry, in a WG document that's becoming a Standards Track RFC.  And that document needs to go through Expert Review, because that's how the registry was defined, even though the working group full of experts, the IETF community, and the IESG approved it.

If that's what you want, that's fine; carry on.  But do you, perhaps, want to say it this way?:
NEW
  Type A civic elements require IETF Review, while Type B elements can
  be registered with IETF Review or Expert Review [RFC5226].

If you choose to do this it would also require corresponding small changes to Sections 8.2 (3rd bullet) and 8.5 (first paragraph).

-- Section 5.1 --
Excellent ASCII-art lamp post you got there.

[Ballot discuss]
I'm very confused:
-- Section 3 --
  Unsupported civic address elements can be carried without consequence
  only as long as the format of the address does not change.  When
  converting between the XML and DHCP formats, these unsupported
  elements are necessarily discarded: the entity performing the
  translation has no way to know the correct element to use in the
  target format.

Wait... Section 1 says this:
  These mechanisms ensure that any translation between formats can be
  performed consistently and without loss of information.  Translation
  between formats can occur without knowledge of every extension that
  is present.

And the example in 1.1 makes it clear that the ability to do these format conversions is exactly why we're doing this.  So what does that first paragraph of Section 3 say?

===================================================

-- IANA Considerations --
Some of the IANA Considerations are underspecified and unclear, and IANA has not correctly understood them.  See Pearl Liang's comment in the document history, http://datatracker.ietf.org/doc/draft-ietf-geopriv-local-civic/history/

The bits that appear to be wrong:

-- Section 8.1 has IANA confused.  They think they will be adding a single entry to the CAtypes table with the assigned value XX (tbd).  In fact, 8.1 is not asking for any entries to be added, but only for the value of XX to be selected.

-- IANA doesn't understand that Section 8.5.1 is asking for four entries to be added to the CAtypes table with CAtype value XX.  This is where the entries are added.

-- It's not clear that IANA fully understands Section 8.5, and knows how to populate the new columns in the table and the Specification column for the existing values.

-- IANA has not noted that the registration policy for CAtypes has changed, based on the value of the Type column.

I also think it's confusing to say that "no further registration of numeric CAtypes" is permitted.  What you really mean is that no further registration of CAtypes with new numbers is permitted, and that all future registrations must use CAtype XX (which still makes them registrations of numeric CAtypes).

I think a major revision of the IANA Considerations section is in order, to make sure that these critical changes get done correctly when IANA gets hold of it.  I'm happy to work off-list with the authors to help with that, if you'd like.

[Ballot comment]
These are non-blocking, but please consider them seriously, and feel free to chat with me about them:

Because this document massively changes the registration procedures that were defined in 4776, I strongly recommend that this document "Updates" 4776, as well as 5222.  You really want people who are reading 4776 to look here.

You seem to use "conversion" and "translation" interchangeably in talking about going between DHCP and XML formats.  It would probably help if you picked one and used it consistently.

-- Section 1 --
  Extension elements do not readily fit existing elements, as
  recommended in [RFC5774].

I don't understand this sentence; the "as recommended" doesn't have a clear antecedent.  Maybe you can rephrase it?  Where in RFC 5774 does it recommend what?  Are you talking about the part of Section 4.1 that begins "Fields that do not fit into an existing CAtype"?

-- Section 3.2 --
  The extension CAtype (CAtype code XX) [Note to IANA/RFC-Editor:
  please replace XX here and in the figure below with the assigned
  code]

That RFC Editor note needs to cover not just Figure 3 ("the figure below"), but also Figure 5.

The bit counts at the top of Figure 3 make it appear that Namespace URI, XML element local name, and Extension type value each have fixed lengths (6 bytes, 3 bytes, and 3 bytes, respectively).  Maybe no one will actually be confused by it... but perhaps it might be better to find another way to depict it.  It's also not specified what the Length field covers -- is it the total length of the CAtype, or just the length of the data after the Length field?  (I'll note that the diagrams in RFC 4776 have neither of these problems.)

-- Section 4 --
  Type A civic elements require IETF review, while Type B elements only
  require an expert review.

We've encountered the following situation a lot: a working group creates a registry with Expert Review or Specification Required registration policy.  The same working group then produces another document that wants to register something in that registry, in a WG document that's becoming a Standards Track RFC.  And that document needs to go through Expert Review, because that's how the registry was defined, even though the working group full of experts, the IETF community, and the IESG approved it.

If that's what you want, that's fine; carry on.  But do you, perhaps, want to say it this way?:
NEW
  Type A civic elements require IETF Review, while Type B elements can
  be registered with IETF Review or Expert Review [RFC5226].

That would also require a change to Section 8.6, but see the DISCUSS above about the IANA Considerations anyway.

-- Section 5.1 --
Excellent ASCII-art lamp post you got there.

IANA has reviewed draft-ietf-geopriv-local-civic-06 and has the following comments:

IANA understands that, upon approval of this document, there are five
actions that IANA needs to complete.

First, in the CAtypes subregistry of the Civic Address Types Registry
located at:

http://www.iana.org/assignments/civic-address-types-registry/civic-address-types-registry.xml

a new CAtype is to be added as follows

CAtype: [ tbd ]
NENA: [ blank ]
PIDF: CAtype
Description Civic Address Extension
Example: [ blank ]
Reference: [ RFC-to-be ]

Second, approval of this document changes the information in the CAtypes
subregistry of the Civic Address Types Registry located at:

http://www.iana.org/assignments/civic-address-types-registry/civic-address-types-registry.xml
.

The column called "NENA" is removed.

The column called "PIDF" is renamed to "Local Name".

New columns are added named "Namespace URI", "Contact", "Schema" and "Type".

Third, approval of this document changes the registration rules in the
CAtypes subregistry of the Civic Address Types Registry located at:

http://www.iana.org/assignments/civic-address-types-registry/civic-address-types-registry.xml

New registrations use the registration template in Section 8.5 of [ RFC-to-be ].

No further registration of numeric CAtypes is permitted.

Fourth, a new namespace is registered in the IANA maintained registry of XML
documents located at:

http://www.iana.org/assignments/xml-registry/ns.html

ID: pidf:geopriv10:civicAddr:ext
URI: urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr:ext
Registration template: pidf:geopriv10:civicAddr:ext
Reference: [ RFC-to-be ]

Fifth, a new schema is registered inthe IANA maintained registry of XML
documents located at:

http://www.iana.org/assignments/xml-registry/schema.html

ID: pidf:geopriv10:civicAddr:ext
URI:urn:ietf:params:xml:schema:pidf:geopriv10:civicAddr:ext
Filename: pidf:geopriv10:civicAddr:ext
Reference: [ RFC-to-be ]

IANA understands that these five actions are the only ones that need
to be completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Specifying Civic Address Extensions in PIDF-LO) to Proposed Standard


The IESG has received a request from the Geographic Location/Privacy WG
(geopriv) to consider the following document:
- 'Specifying Civic Address Extensions in PIDF-LO'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-10-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  New fields are occasionally added to civic addresses.  A backwardly-
  compatible mechanism for adding civic address elements to the Geopriv
  civic address format is described.  A formal mechanism for handling
  unsupported extensions when translating between XML and DHCP civic
  address forms is defined for entities that need to perform this
  translation.  Intial extensions for some new elements are also
  defined.  The LoST (RFC5222) protocol mechanism that returns civic
  address element names used for validation of location information is
  clarified and is normatively updated to require a qualifying
  namespace identifier on each civic address element returned as part
  of the validation process.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-local-civic/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-geopriv-local-civic/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1829/

The GEOPRIV working group requests publication of draft-ietf-geopriv-local-civic-06 as a Proposed
Standard.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational,
Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the
title page header?

A Proposed Standard is being requested. This is the proper type because this document describes
extensions and an extension mechanism for data formats described in other standards track RFCs,
and it normatively updates RFC 5222, which is also a standards track RFC.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide
such a Document Announcement Write-Up. Recent examples can be found in the "Action"
announcements for approved documents. The approval announcement contains the following
sections:

Technical Summary:

This document provides a number of updates to existing IETF civic addressing standards.  A
backwardly-compatible mechanism for adding civic address elements to the Geopriv civic address
format is described.  A formal mechanism for handling unsupported extensions when translating
between XML and DHCP civic address forms is defined for entities that need to perform this
translation.  Intial extensions for some new elements are also defined.  The LoST (RFC5222) protocol
mechanism that returns civic address element names used for validation of location information is
clarified and is normatively updated to require a qualifying namespace identifier on each civic address
element returned as part of the validation process.

Working Group Summary:

There was a great deal of WG energy spent on the question of how to balance extensibility of civic
addressing (including extensions for local use only) with the need for backwards compatability with
existing implementations. In the end we arrived at a solution that the key interested parties are
satisfied with.

Document Quality:

The National Emergency Number Association (NENA) has a technical standard dependent on this
work, and several implementations of it are in progress or exist already. There were not any special
reviews of this document, although it received substantial attention throughout the process from many
core working group members.

Personnel:

Alissa Cooper is the document shepherd. Robert Sparks in the responsible area director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this
version of the document is not ready for publication, please explain why the document is being
forwarded to the IESG.

I reviewed the document thoroughly and consulted with the authors to clarify several points and
generate a corresponding revision. This document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that
have been performed?

No, this document received significant attention from relevant experts.

(5) Do portions of the document need review from a particular or from broader perspective, e.g.,
security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the
review that took place.

This document received significant attention from experts with relevant experience in civic addressing
and XML.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that
the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she
is uncomfortable with certain parts of the document, or has concerns whether there really is a need
for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

After somewhat lengthy WG discussion, this document represents an agreed extension mechanism
that preserves backwards compatability while allowing for further extensions as necessary. The
trade-offs involved were contentious but have been resolved and the WG is happy with the result.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full
conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

They have all confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG
discussion and conclusion regarding the IPR disclosures.

An IPR disclosure was filed in reference to this document: . I
have confirmed with the working group that its participants wish to proceed to publication in any case.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence
of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The WG is behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please
summarise the areas of conflict in separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is publicly available.)

There have been no expressions of extreme discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org
/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to
be thorough.

This document passes all ID nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor,
media type, and URI type reviews.

No formal reviews are necessary for this document.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are
otherwise in an unclear state? If such normative references exist, what is the plan for their
completion?

No such normative references exist.

(15) Are there downward normative references references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

No. XMLNS is not an IETF reference but it is not downward.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed
on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.

This document updates RFC 5222. This is mentioned in the introduction and the abstract.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with
regard to its consistency with the body of the document. Confirm that all protocol extensions that the
document makes are associated with the appropriate reservations in IANA registries. Confirm that
any referenced IANA registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name for the new registry has been
suggested (see RFC 5226).

The shepherd has done a thorough review of the IANA considerations section as compared to the
body of the document. They are consistent and the details of the IANA considerations are clear.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public
guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The CATypes registry currently operates under both Expert Review and Specification Required rules.
This policy is being altered by this document, which creates two types of CATypes, A and B. Going
forward, CATypes of Type A will require IETF review. Those of Type B will continue to require Expert
Review with an option for Specification Required.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate
sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The XML syntax in this document has been validated.