Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information
RFC 4676

Email From DHC Chair

-------- Original Message --------
Subject: dhc WG review of draft-ietf-geopriv-dhcp-civil
Date: Mon, 20 Feb 2006 16:27:39 -0500
From: Ralph Droms <rdroms@cisco.com>
To: Mark Townsley (townsley) <townsley@cisco.com>
CC: <iesg@ietf.org>, Stig Venaas <Stig.Venaas@uninett.no>

Mark - I posted a request for dhc WG review of
draft-ietf-geopriv-dhcp-civil, and got one response that the revised doc is
acceptable.  I took a look at it myself and am OK with the doc that will
result from the application of Ted's latest RFC Editor Notes to
draft-ietf-geopriv-dhcp-civil-09.  The dhc WG is ready for you to clear your
Discuss on the doc.

- Ralph

[Ballot comment]
I have carefully reviewed this document in preparation for an override vote, and I have a couple of questions:

In the section describing the DHCPv6 format, the document says:

  The DHCPv6 [6] civic address option refers generally to the client as
  a whole.

The DHCPv4 section doesn't say this, though...  Are they different in this regard?

The document includes the following description of how addresses in the US will be represented:

  US (United States): The mapping to NENA designations is shown in
      parentheses.  A1 designates the state (STA), using the the two-
      letter state and possession abbreviations recommended by the
      United States Postal Service Publication 28 [20], Appendix B.  A2
      designates the county, parish (Louisiana) or borough (Alaska)
      (CNA).  A3 designates the civic community name, e.g., city or
      town.  It is also known as the municipal jurisdiction.  (MCN) The
      optional element A4 contains the community place name, such as
      "New bope Community" or "Urbanizacion" in Puerto Rico.  The civic
      community name (MCN) reflects the political boundaries.  These
      boundaries may differ from postal delivery assignments, the postal
      community name (PCN), for historical or practical reasons.

Minor nit:  s/. (MCN) The/ (MCN). The/ 

Unfortunately, I can't figure out how I would represent my native home address using this system.

As a child I lived at:

11 Eisenhower Place
Wakefield, RI  02879

However, Wakefield is not a town.  The town is South Kingstown, RI (note that our town doesn't appear in our mailing address).  So, I think that Wakefield must be a Postal Community Name (PCN)?  Is that the same as the "community place name"?

Also, it seems downright silly not to include the U.S. zip code, even the 9-digit version if available, since there are so many systems that know how to map that to an approximate location, especially within a large city with multiple zip codes.

[Ballot comment]
I have carefully reviewed this document in preparation for an override vote, and I have a couple of questions:

In the section describing the DHCPv6 format, the document says:

  The DHCPv6 [6] civic address option refers generally to the client as
  a whole.

The DHCPv4 secion doesn't say this, though...  Are they different in this regard?

The document includes the following description of how addresses in the US will be represented:

  US (United States): The mapping to NENA designations is shown in
      parentheses.  A1 designates the state (STA), using the the two-
      letter state and possession abbreviations recommended by the
      United States Postal Service Publication 28 [20], Appendix B.  A2
      designates the county, parish (Louisiana) or borough (Alaska)
      (CNA).  A3 designates the civic community name, e.g., city or
      town.  It is also known as the municipal jurisdiction.  (MCN) The
      optional element A4 contains the community place name, such as
      "New bope Community" or "Urbanizacion" in Puerto Rico.  The civic
      community name (MCN) reflects the political boundaries.  These
      boundaries may differ from postal delivery assignments, the postal
      community name (PCN), for historical or practical reasons.

Minor nit:  s/. (MCN) The/ (MCN). The/ 

Unfortunately, I can't figure out how I would represent my native home address using this system.

As a child I lived at:

11 Eisenhower Place
Wakefield, RI  02879

However, Wakefield is not a town.  The town is South Kingstown, RI (note that our town doesn't appear in our mailing address).  So, I think that Wakefield must be a Postal Community Name (PCN)?  Is that the same as the "community place name"?

Also, it seems downright silly not to include the U.S. zip code, even the 9-digit version if available, since there are so many systems that know how to map that to an approximate location, especially within a large city with multiple zip codes.

[Ballot comment]
While re-reviewing in detail for the override vote, I found the following issues.  It made people upset for me to register them in what I thought was the correct way, so I will put them here.

HNO is not described in detail.  HNS is described as "House Number Suffix" in the table and "House Number" in the detailed description.  The paragraph talking about Building is labelled as "LMK" (making it the second paragraph labelled "LMK", since the one that's actually talking about "LMK" is also labelled such).

The description for the P.O. Box field says that it should contain the words "P.O. Box" or similar, but the example simply has a number.

[Ballot comment]
I share Margaret's wonder about addresses.  I live in unincorporated San Mateo county; my postal address is Woodside but my home is outside of Woodside city limits.  The area has an informal name, "Sky Londa", but I have no idea if that's what anyone wants to hear.  It's not something that you can put into a mapping service.

[Ballot discuss]
HNO is not described in detail.  HNS is described as "House Number Suffix" in the table and "House Number" in the detailed description.  The paragraph talking about Building is labelled as "LMK" (making it the second paragraph labelled "LMK", since the one that's actually talking about "LMK" is also labelled such).

The description for the P.O. Box field says that it should contain the words "P.O. Box" or similar, but the example simply has a number.

[Ballot discuss]
I have carefully reviewed this document in preparation for an override vote, and I have a couple of questions:

In the section describing the DHCPv6 format, the document says:

  The DHCPv6 [6] civic address option refers generally to the client as
  a whole.

The DHCPv4 secion doesn't say this, though...  Are they different in this regard?

The document includes the following description of how addresses in the US will be represented:

  US (United States): The mapping to NENA designations is shown in
      parentheses.  A1 designates the state (STA), using the the two-
      letter state and possession abbreviations recommended by the
      United States Postal Service Publication 28 [20], Appendix B.  A2
      designates the county, parish (Louisiana) or borough (Alaska)
      (CNA).  A3 designates the civic community name, e.g., city or
      town.  It is also known as the municipal jurisdiction.  (MCN) The
      optional element A4 contains the community place name, such as
      "New bope Community" or "Urbanizacion" in Puerto Rico.  The civic
      community name (MCN) reflects the political boundaries.  These
      boundaries may differ from postal delivery assignments, the postal
      community name (PCN), for historical or practical reasons.

Minor nit:  s/. (MCN) The/ (MCN). The/ 

Unfortunately, I can't figure out how I would represent my native home address using this system.

As a child I lived at:

11 Eisenhower Place
Wakefield, RI  02879

However, Wakefield is not a town.  The town is South Kingstown, RI (note that our town doesn't appear in our mailing address).  So, I think that Wakefield must be a Postal Community Name (PCN)?  Is that the same as the "community place name"?

Also, it seems downright silly not to include the U.S. zip code, even the 9-digit version if available, since there are so many systems that know how to map that to an approximate location, especially within a large city with multiple zip codes.

[Ballot discuss]
The first part of this discussion is intended to understand better why I believe this draft has problems. I will give two different suggestions at the
end that would make me clear my DISCUSS. However, if these will be the only
changes, I will still ABSTAIN as I believe that this draft still needs more
work to make it useful solution for the emergency response case as opposed
to a solution that does no harm.

It seems that one of the intended uses of this document is for
emergency response. The following discussion is intended as background
information to understand better why I believe this draft has problems.


I believe that this draft in it's current incarnation doesn't
adequately support such issues and needs considereable more work for
operational guidelines, more precise location information, a mechanism
to make an educated guess for emergency workers which relayed location
is the most reliable source and very strong advice to use a very
minimal set of relayed addresses as opposed to using a GPS, multiple
locations for different pieces of network gear and postal addresses in
ten languages. In addition one needs to be very careful to configure
DHCP servers correctly and consistently (eg. the ipv6 server should
give the same answer as the v4 one, this is harder than it sounds
since they might not in the same location or even spread over
difference administrative boundaries if one uses certain ipv6
transition tools).

At this point, we give the false impression that we have a mechanism
that can support emergency services while it is inadequate to provide
a reasonable good location fix due to operatiational difficulties in
configuring the DHCP servers properly and interpreting the relayed
information correctly as well. I realize that we can never reach
perfection with solutions like this but I strongly believe that we can
do a lot better and should do a lot better as there are real human
lifes on the line (including my own!).

Detailed comments:

In section '2.  Introduction':

A related document [16] describes a DHCPv4 [2] option for conveying
geospatial information to a device. This draft describes how DHCPv4
and DHCPv6 [5] can be used to convey the civic and postal address to
devices. Both can be used simultaneously, increasing the chance to
deliver accurate and timely location information to emergency
responders.

I have serious doubts about the direction of this document regarding
'more information is better then less'. Emergency response work is
going to be a disaster if we cannot provide responders with a clear
and unambiguous answer: Person X is in location Y with certain GPS
coordinates, instead of Person X might in location Y with certain GPS
coordinates and this person is also at civic address Z even though
these locations might be different.

Basically, using two seperate methods that are used simultaneously is
a recipe for disaster. At the minimum, it is necessary to give out
operational quidelines on how one should use these two in conjunction
instead of just allowing them to be used and claim that it actually
improves the location information. What is comes down to, it is
probably necessary to have a mechanism for a ranking in what locations
are considered to be more reliable (but there might be other
solutions as well).

To make matters worse, this draft makes it possible to use different
lanaguages to convey the same information, yet another way to create
confusion. Normally, in such cases, it is at least indicated which
language is the source of the information which in that case is
usually considered the 'authoritative source' as opposed to
translations. The example of '(Munich, Muenchen and Monaco, for
example).' is actually a beautiful example why language can be an
issue as you managed to confuse quite a lot of people by mentioning
'Monaco'.

Yet another example of a 'MAY', also in section '2.  Introduction':

The DHCP server MAY provide location information for multiple
locations related to the target, for example, both the network
element and the network jack itself. This is likely to help in
debugging network problems, for example.

In '3.1  Overall Format for DHCPv4': what: The 'what' element describes which location the DHCP entry
refers to. Currently, three options are defined: the location of the
DHCP server (a value of 0), the location of the network element
believed to be closest to the client (a value of 1) or the location
of the client (a value of 2). Option (2) SHOULD be used, but may not
be known. Options (0) and (1) SHOULD NOT be used unless it is known
that the DHCP client is in close physical proximity to the server or
network element.

Yet more ambiguity and confusion:

- What is the use of the location of the DHCP server ?

  This would only be useful if it is accompanied with information on
  how close any DHCP managed device is to the DHCP server or an
  operational guideline on what the draft means by close.

  (I don't even want to think about the VPN'ed homeworker where the
  emergency response team shows up at the companies headquarters,
  his/her dsl provider central office or cable headend)

- Same story for value of 1)

Value 2) for the location of the client is clear.

'Value 0 or 1 SHOULD not be used unless the client is 'close'.'

What does close mean ?

Operators are going to have a serious problem determining what close
is when configuring a DHCP server and emergency responders will have
a problem in interpreting the value.

- Mobile nodes:

  There is no guidance how to deal with mobile nodes

- There is no guidance on how one deals with propagation of information
  and interaction between multiple DHCP servers:

  One can have a DHCP address from the users DSL provider, from ones
  company VPN service (maybe even multiple ones), a backup
  (cable/UMTS) network connection and a ipv6 transition service. These
  there are various scenarios that can lead to rather nasty
  interactions and I am quite sure that is not hard to find various
  other ones.

In section '3.4  Civic Address Components':

Mappings and considerations for additional countries should be
written up in documents titled "Civic Addresses for [Country] (XY)",
where "XY" represents the two-letter country code, e.g., "Civic
Address Considerations for France (FR)".

Most IANA problems have been solved. However, this one needs more
work: what kind of document is required and by who.

In section '7.  IANA Considerations':

This document establishes a new IANA registry for CAtypes designating
civic address components. According to RFC 2434 [15], [17], this
registry operates under the "Specification Required" rules.

The CAtypes namespace can get exhausted quite rapidly as anybody can
more or less register whatever they want and this is just a one octet
field. How can IANA make a difference between opportunistic
registrations and critical ones?

----

Please see below for the specific suggestions that I referred to at the top
of this DISCUSS text:

I have most issue with the following parts of the draft:

'Options (0) and (1) SHOULD NOT be used
unless it is known that the DHCP client is in close physical
proximity to the server or network element.'

As an operator, I cannot do anything with this.

There is no definition of close:
- I don't know how to configure this
- when this option is used, I don't know whether this information
  is of any use as I have no idea what criteria for close was used
  by the person configuring the option

My preferred solution would be to do away with the Option 0 and 1 and
instead define a 'radius'. Other solutions would be to be more
specific what 'close' is.

In addition a 'confidence' level or 'source' would make this a lot more useful.
Eg. it is a big difference whether the information is for example derived
and verified by a trusted source who is sure that the client is for example
not on a VPN or on a mobile link (without GPS/triangulation information) or
whether it is derived from a billing record which really doesn't give a lot of
confidence where the client really is.

'Both geospatial and civic formats be used simultaneously,
increasing the chance to deliver accurate and timely location
information to emergency responders.'

Given a finite amount of resources for the emergency responder, this
is actually going to increase the time to find the right location. One
way to make this more reliable is if it is known which information is
more reliable. I don't understand why the authors insist on keeping
this statement. One option is to say exactly the opposite, or even
better to introduce a confidence factor of some sort to get an idea
which information is more trustworthy to give emergency responders
the chance to focus in on the most important information.

[Ballot discuss]
It seems that one of the intended uses of this document is for
emergency response.

I believe that this draft in it's current incarnation doesn't
adequately support such issues and needs considereable more work for
operational guidelines, more precise location information, a mechanism
to make an educated guess for emergency workers which relayed location
is the most reliable source and very strong advice to use a very
minimal set of relayed addresses as opposed to using a GPS, multiple
locations for different pieces of network gear and postal addresses in
ten languages. In addition one needs to be very careful to configure
DHCP servers correctly and consistently (eg. the ipv6 server should
give the same answer as the v4 one, this is harder than it sounds
since they might not in the same location or even spread over
difference administrative boundaries if one uses certain ipv6
transition tools).

At this point, we give the false impression that we have a mechanism
that can support emergency services while it is inadequate to provide
a reasonable good location fix due to operatiational difficulties in
configuring the DHCP servers properly and interpreting the relayed
information correctly as well. I realize that we can never reach
perfection with solutions like this but I strongly believe that we can
do a lot better and should do a lot better as there are real human
lifes on the line (including my own!).

Detailed comments:

In section '2.  Introduction':

A related document [16] describes a DHCPv4 [2] option for conveying
geospatial information to a device. This draft describes how DHCPv4
and DHCPv6 [5] can be used to convey the civic and postal address to
devices. Both can be used simultaneously, increasing the chance to
deliver accurate and timely location information to emergency
responders.

I have serious doubts about the direction of this document regarding
'more information is better then less'. Emergency response work is
going to be a disaster if we cannot provide responders with a clear
and unambiguous answer: Person X is in location Y with certain GPS
coordinates, instead of Person X might in location Y with certain GPS
coordinates and this person is also at civic address Z even though
these locations might be different.

Basically, using two seperate methods that are used simultaneously is
a recipe for disaster. At the minimum, it is necessary to give out
operational quidelines on how one should use these two in conjunction
instead of just allowing them to be used and claim that it actually
improves the location information. What is comes down to, it is
probably necessary to have a mechanism for a ranking in what locations
are considered to be more reliable (but there might be other
solutions as well).

To make matters worse, this draft makes it possible to use different
lanaguages to convey the same information, yet another way to create
confusion. Normally, in such cases, it is at least indicated which
language is the source of the information which in that case is
usually considered the 'authoritative source' as opposed to
translations. The example of '(Munich, Muenchen and Monaco, for
example).' is actually a beautiful example why language can be an
issue as you managed to confuse quite a lot of people by mentioning
'Monaco'.

Yet another example of a 'MAY', also in section '2.  Introduction':

The DHCP server MAY provide location information for multiple
locations related to the target, for example, both the network
element and the network jack itself. This is likely to help in
debugging network problems, for example.

In '3.1  Overall Format for DHCPv4': what: The 'what' element describes which location the DHCP entry
refers to. Currently, three options are defined: the location of the
DHCP server (a value of 0), the location of the network element
believed to be closest to the client (a value of 1) or the location
of the client (a value of 2). Option (2) SHOULD be used, but may not
be known. Options (0) and (1) SHOULD NOT be used unless it is known
that the DHCP client is in close physical proximity to the server or
network element.

Yet more ambiguity and confusion:

- What is the use of the location of the DHCP server ?

  This would only be useful if it is accompanied with information on
  how close any DHCP managed device is to the DHCP server or an
  operational guideline on what the draft means by close.

  (I don't even want to think about the VPN'ed homeworker where the
  emergency response team shows up at the companies headquarters,
  his/her dsl provider central office or cable headend)

- Same story for value of 1)

Value 2) for the location of the client is clear.

'Value 0 or 1 SHOULD not be used unless the client is 'close'.'

What does close mean ?

Operators are going to have a serious problem determining what close
is when configuring a DHCP server and emergency responders will have
a problem in interpreting the value.

- Mobile nodes:

  There is no guidance how to deal with mobile nodes

- There is no guidance on how one deals with propagation of information
  and interaction between multiple DHCP servers:

  One can have a DHCP address from the users DSL provider, from ones
  company VPN service (maybe even multiple ones), a backup
  (cable/UMTS) network connection and a ipv6 transition service. These
  there are various scenarios that can lead to rather nasty
  interactions and I am quite sure that is not hard to find various
  other ones.

In section '3.4  Civic Address Components':

Mappings and considerations for additional countries should be
written up in documents titled "Civic Addresses for [Country] (XY)",
where "XY" represents the two-letter country code, e.g., "Civic
Address Considerations for France (FR)".

Most IANA problems have been solved. However, this one needs more
work: what kind of document is required and by who.

In section '7.  IANA Considerations':

This document establishes a new IANA registry for CAtypes designating
civic address components. According to RFC 2434 [15], [17], this
registry operates under the "Specification Required" rules.

The CAtypes namespace can get exhausted quite rapidly as anybody can
more or less register whatever they want and this is just a one octet
field. How can IANA make a difference between opportunistic
registrations and critical ones?

[Ballot comment]
- the use of country codes seems possibly a bit misplaced as they are
  not really the determining factor on how an address is formed. Eg.
  some countries share the same formats. Basically, the country code
  is part of the address itself. The key should be the addressformat
  as registered with IANA. addressformat as registered with IANA.
  In addition, how does one define an address for a country or
  location that does not have a country code or different codes
  different pars of the country.

- We assume that five levels are sufficient for sub-national above the
  street level.

  Why ? I don't believe that Internet standards should be based on
  assumptions. Has this assumption been investigated and found to be
  correct ?

[Ballot discuss]
To summarize, most of comments, let me go back to the following
statement in '2.  Introduction':

A related document [16] describes a DHCPv4 [2] option for conveying
geospatial information to a device. This draft describes how DHCPv4
and DHCPv6 [5] can be used to convey the civic and postal address to
devices. Both can be used simultaneously, increasing the chance to
deliver accurate and timely location information to emergency
responders.

I have serious doubts about the direction of this document regarding
'more information is better then less'. Emergency response work is
going to be a disaster if we cannot provide responders with a clear
and unambiguous answer: Person X is in location Y with certain GPS
coordinates, instead of Person X might in location Y with certain GPS
coordinates and this person is also at civic address Z even though
these locations might be different (note that DHCPv4 and v6 can also
be used together, increasing the chance for yet another set of
incompatible information)

Basically, using two seperate methods that are used simultaneously is
a recipe for disaster and it is necessary to give out operational
quidelines on how one should use these two in conjunction instead of
just allowing them to be used.
What is comes down to, what is probably necessary is a mechanism for a
ranking in what locations are considered to be more reliable.

To make matters worse, this draft makes it possible to use different
lanaguages to convey the same information, yet another way to create
confusion. Normally, in such cases, it is at least indicated which
language is the source of the information which in that case is
usually considered the 'authoritive source' as opposed to
translations. The example of '(Munich, Muenchen and Monaco, for
example).' is actually a beautiful example why language can be an
issue as you managed to confuse quite a lot of people by mentioning
'Monaco'.

Yet another example of a 'MAY':

The DHCP server MAY provide location information for multiple
locations related to the target, for example, both the network
element and the network jack itself. This is likely to help in
debugging network problems, for example.

In '3.1  Overall Format for DHCPv4':

what: The 'what' element describes which location the DHCP entry
refers to. Currently, three options are defined: the location of the
DHCP server (a value of 0), the location of the network element
believed to be closest to the client (a value of 1) or the location
of the client (a value of 2). Option (2) SHOULD be used, but may not
be known. Options (0) and (1) SHOULD NOT be used unless it is known
that the DHCP client is in close physical proximity to the server or
network element.

Yet again ambiguity and confusion:

- What is the use of the location of the DHCP server ?

  This would only be useful if it is accompanied with information on
  how close any DHCP managed device is to the DHCP server.


- Same story for value of 1)

  Value 2) for the location of the client is clear.

  'Value 0 or 1 SHOULD not be used unless the client is 'close'.'

  What does close mean ?

  Operators are going to have a serious problem determining what close
  is when configuring a DHCP server and emergency responders will have
  a problem in interpreting the value.
- I am missing the opportunity to fill out a a free form notes section.

  For example, the DHCP server address might be quite adequate if I
  can add a small note that specificies that I can be found in Cubicle
  1:440. This kind of information is often available but the current
  formats don't allow any of this kind information.

- IANA considerations:

  'This document establishes a new IANA registry for CAtypes
  designating civic address components.'

  'The initial list of registrations is contained in Section 3.4.'

  Where is the country specification done ? As currently written, IANA
  only deals with specific CAtypes like defining an element as a
  'street', but is does not give clear instruction how one defines a
  civic address for a specific country.

- In '2.  Introduction', introduced by rfc editor note:

  'The reader should also be familiar with the concepts in [14],
  as many of the protocol elements below are designed to dovetail with
  PIDF-LO elements.'

  In the normative reference section it says:

  8.1  Normative References

  [14]  International Organization for Standardization, ISO.,
        "Information and documentation - Codes for the representation
        of names of scripts", February 2004.

  Was this reference really supposed to point to this ISO document or
  to draft-ietf-geopriv-pidf-lo-03.txt instead.

  In any case, ISO documents have numbers I think (I believe this one is
  ISO 15924:2004). This reference is not easy to find and worse, there
  is no free access to this document so how am I supposed to be
  familiar with it's content as a normative reference but I don't have
  access to it ?.

[Ballot comment]
Spelling errors/editorial:

necessearily
formating 
using the the two-letter
(And I agree with Pekka that Monaco was a particular bad choice as a
well known eqivalent for Munich)

Comments from the Ops directorate by Pekka Savola:

editorial
---------

  This document only defines the delivery of location information from
  the DHCP server to the client, due to security concerns related to
  using DHCP to update the database.

==> (also next paragraph) what confused me initially a great deal was
that I didn't grasp the difference between "information from the DHCP
server to the client" and abtract's "civic location of the client or
the DHCP server".  This distinction should be made clearer very early
(see the 10K feet issue above).

It's also not clear what the "security concerns are" either (provide a
pointer).  I guess you are assuming that the only different use for
location information would be updating the DNS, and that would also
not be accurate...


  often shown in Hangul, Latin and Kanji, while some older cities have
  multiple language variants (Munich, Muenchen and Monaco, for
  example).

==> I found it difficult to believe that 'Monaco' is really equivalent
to 'Munich', but live and learn.  Maybe you should add a short note
there to warn others who might get similar disbelief..

[section 4]
  to create a postal address.  If the elments include a post office 

==> s/elments/elements/

2.  Introduction

==> to get Introduction numbered as 1, I'd put terminology as a
subsection 1.1 at the end.

[Ballot discuss]
I received a review by Pekka Savola from the ops directorate that
raises enough questions to place a DISCUSS on this document.

In addition, I have some issues that are independant and
semi-independant from his review. See at the bottom of this mail for
Pekka's review. I will start here with my own issues.

* (related to Pekka's review):

  I think this document needs an applicatibility statement.
  There are a number of recommendations in the document that need more
  explanation on how to use this from an operational point of view:

  Multiple languages can be used causing inconsistencies in the
  response from the server. What language should be preferred ?
 
  It says not to use the (0) (1) option in the 'what' field, yet, the
  field is actually defined and can be used. Why not use a proximity
  field that indicates that the information is approximate within a
  certain range of the address ?

* the use of country codes seems possibly a bit misplaced as they are
  not really the determining factor on how an address is formed.
  Eg. some countries share the same formats. Basically, the country
  code is part of the address itself. The key should be the
  addressformat as registered with IANA.
addressformat as registered with IANA.
* What does one do if an address doesn't fit in one of the standard
  formats ? Even though address formats exist for many countries, it
  doesn't mean that every address inside a given country has a
  standard address format or an address that is actually useful from
  an emergency perspective: example, you can find me in grave tomb X
  in the valley of the kings in Egypt. Especially countries with
  somewhat long histories have really weird addresses that often
  that can only be interpreted by humans.
 
  Since these addresses are mostly intended for human use (emergency
  workers) who know the local context, why not have a completely non
  predescribed field for an adress? This also solves the problem for
  other useful info as: 'room: 1:123', or cubicle 450D.
  In addition, many addresses especially in rural areas are not only
  non-standard, they also can describe a rather large area where the
  user needs a human readable field to make it somewhat more clear to
  where to find the user, for example, when entering the farm, look
  for the building with the red roof.

* the text reads:

  "Since each country has different administrative hierarchies, with
  often the same (English) names, this specification adopts a simple
  hierarchical notation that is then instantiated for each country"
 
  Who defines this specification ? A random person from that
  particular country ?
 
  why are not complete address formats registered with IANA instead of
  components ?

* The document also says:

  'Additional CA types appear in many countries and are simply omitted
    where they are not needed or known:'

  It is not clear to me what this means. Are they omitted by the
  server ? Does the client ignore them when it receives them ? If so,
  is this really smart as they could easily contain quite important 
  information for the human emergency worker.

* We assume that five levels are sufficient for sub-national above the
  street level.

  Why ? I don't believe that Internet standards should be based on
  assumptions. Has this assumption been investigated and found to be
  correct ?

Review from the ops directorate by Pekka Savola:

10,000 feet view issue:

I found it difficult to understand at first *who* is expected to use
this option and how.  The abstract and introduction (see below) talk
about getting DHCP server's and/or client's address.  It would be
useful, IMHO, to give the 10,000ft bits as well, at least:

* DHCP clients cannot tell the server their own address, even if they
knew it, they just have to request it from the server, and trust the
server's DHCP database is configured correctly.

* DHCP servers can give its own, a network element's, or the DHCP
client's address, provided that these are learned and maintained using
out-of-scope, out-of-band mechanisms (though it would probably be a
good idea to give an example).

* Emergency services (e.g., SIP) at the DHCP client's host may use
this location information for XXXXX purposes.

substantial
-----------

  A related document [13] describes a DHCPv4 [2] option for conveying
  geospatial information to a device.  This draft describes how DHCPv4
  and DHCPv6 [5] can be used to convey the civic and postal address to
  devices.  Both can be used simultaneously, increasing the chance to
  deliver accurate and timely location information to emergency 
  responders.

==> when used simultaneously, how does the user of this information
decide which one is better?  This is a generic (and difficult) problem
with multiple inputs, especially if there would be only one output..

  what: The 'what' element describes which location the DHCP entry
      refers to.  Currently, three options are defined:  the location of
      the DHCP server (a value of 0), the location of the network
      element believed to be closest to the client (a value of 1) or the
      location of the client (a value of 2).  Option (2) SHOULD be used,
      but may not be known.  Options (0) and (1) SHOULD NOT be used
      unless it is known that the DHCP client is in close physical
      proximity to the server or network element.

==> 0 and 1 seem to be a disaster waiting to happen.  You clearly
assume that if 2 is not present, but 0 or 1 are, the client just takes
that one instead, and uses it for its emergency location.

If the server doesn't bother to tell the clients what their address
is, why should relying in unreliable (and probably wrong) information
about DHCP server's location be any better?

I could only think of these having any use at all in e.g., SOHO 
environments with an access router which is also a DHCP server, but
even there, the DHCP server could broadcast the same client location   
to all the clients, so there would be no need for 0 or 1.

I think the WG needs to seriously consider whether 0 and 1 are worth
the risks of misconfiguration and misinformation.  I'm personally
doubtful, and I'd maybe just leave the values reserved for now. 

Btw: As the implementation cannot know whether it is in close
proximity of the clients or not (or so I would think, at least
in the general case), "SHOULD NOT be used" is advice to the operators,
and should be in lower case or reworded at the very least, for
example (beware of the passive voice):

  Options (0) and (1) SHOULD NOT be sent except when the network
  administrator knows that the DHCP client is in close physical
  proximity to the server or network element and has configured the   
  server to send the option(s).  (Even then, it woul be better to just
  use (2) options.)


[IANA considerations]
  The initial list of registrations is contained in .

==> as was pointed out, this is missing.  Maybe it meant to point at
section 3.4?  It definitely should be in this doc.

IANA Comments:
Upon approval of this document the IANA will register a new DHCPv4 and DHCPv6
option code for the Civic Address (GEOCONF_CIVIC and OPTION_GEOCONF_CIVIC, respectively).

The IANA will also establish a new IANA registry for CAtypes.

In the document, it says the following:
"Updates to country-specific considerations for previously-defined
CAtypes follow the same procedure.  Such documents may provide the
interpretation of elements A1 through A6 for additional countries.
Approval by a Designated Expert is required.

The initial list of registrations is contained in ."

1) So is the procedure to update country-specific considerations for existing CAtypes follow the "same procedure" as in Specification Required or Approval by designated expert?  This seems confusing...

2) Which section is the initial list of registrations?  In the document it is blank.

3) An expert will need to be appointed.

[Ballot comment]
CAtype 1 (A1) should mention canton (CH)

Joel Halpern foun one error that will need to be fixed, probably in RFC  Editor interaction.  The last sentence of the IANA considerations  reads:
    The initial list of registrations is contained in .
There is a citation missing at the end?

[Ballot discuss]
Sections 3.1 and 3.2 describe length fields as "N: The length of this option is variable.  The minimum length is 3." and "option-len: Length of the Countrycode, 'what' and civic address elements.".  What units are being used to measure the length?  I assume octets are being used, but I think that should be explicitly noted.