Subject: [Geopriv] Re: Documents in LC for review

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 13 Jan 2005 17:22:31 -0500

A General Area review during last call.

This document appears to me to be almost ready for publication as a 
proposed standard.  However, I have found some minor items that should be 
addressed when the document is revised after last call completes.

Minor comments:

The country code occurs before the "what" value in the DHCP options.  Is 
there any reason for this placement?  All other CA information is in 
type-length-value tuples.  I think this is because the country code 
qualifies the meaning of the CA types.
The reason this struck me is that it lead me to wonder about the corner 
case of a wireless access near a country border, where possibly the DHCP 
server, the network equipment, and the subscriber could be in three 
different countries.  This can be dealt with by filling in the country code 
after selecting the "what", even though they appear in the other order in 
the message.  Personally, I would simply swap the two fields around.

The Element Format (3.3) description is slightly confusing about 
casing.  The CAlength field indicates that it is the length of the 
CAvalue.  The description of the CAlength then includes the sentence "Data 
SHOULD be encoded in mixed case, following customary selling."  My guess is 
that this sentence belongs somewhere else.  Also, there is confusion 
because the CAvalue description includes text that say "and written in 
uppercase letters where applicable."  So is it mixed case or upper case?

The CAValue text also has a description of the format of the "script 
indication".  This presumably really belongs in the description of 
whichever CAtype is used to carry a script indication (CAtype=128)

Shouldn't the last sentence of the Securiyt Considerations (section 5) say 
more than "one should consider the potential security risks."  Is this 
intended to refer only to the risks in the previous three paragraphs, or 
some undefined set of risks?  Is this supposed to drive some stronger 
actions than those mentioned in the previous three paragraphs?

For CAtypes 1-6, where should the mappings to nations be documented?  5 
specific cases are listed in the document.  Is the expectation that the 
registry will contain multiple entries for CAtypes 1-6, each entry 
providing the definition of a given country?  If so, the description in the 
IANA considerations seems to indicate that an RFC will be needed to 
register the interpretation for a (set of) country (or countries).  Is 
there some other way we will document the meanings for other 
countries?  Whatever is intended ought to be called out explicitly rather 
than leaving it implicit in the document.

Yours,
Joel M. Halpern

At 01:16 AM 1/12/2005, [email-masked] wrote:
>Reviewer: Joel Halpern
>
>- 'Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for
>Civic
>    Addresses Configuration Information '
>    <draft-ietf-geopriv-dhcp-civil-04.txt> as a Proposed Standard
>
>LC ends 2005-01-13.
>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-04.txt

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Jan 2005 23:17:35 -0500

> A General Area review during last call.

Thank you for your helpful and detailed comments. Some initial responses 
below.

> proposed standard.  However, I have found some minor items that should 
> be addressed when the document is revised after last call completes.
> 
> Minor comments:
> 

This was done purely for presentation reasons in the figure (although 
word alignment doesn't much matter here since it's a two-byte character, 
not an integer) and since the country code was considered to be required 
and common. This is clearly arbitrary and it does make sense to reverse 
this, logically speaking. However, before making the change, see the 
discussion below.

> different countries.  This can be dealt with by filling in the country 
> code after selecting the "what", even though they appear in the other 

Each DHCP message can only describe one of these (server, network 
element, client). It would be possible, albeit more complicated, to 
define 'what' as a CAtype as well, and then have all three, as in

CAtype=X  value=0
CAtype=0  country=US
more precise information for the DHCP server, located in the US

CAtype=X  value=1
CAtype=0  country=CA
more precise information for the client, located in Canada

> order in the message.  Personally, I would simply swap the two fields 
> around.

This is not a matter of just swapping, as you would not be able to have 
multiple country codes that way.

You point to another issue, a design decision, that currently only one 
(logical) field of each CAtype, in each language, makes sense. There is 
no provision to say that "This DHCP-provisioned element can be in either 
Elm Street or Main Street", as this would require significantly better 
grouping capabilities, notions of geometry and certainty ("intersection 
of", "between", "unsure if either", etc.). There wasn't much discussion 
on this topic, as I recall, although there was the perception that civic 
location is primarily useful for defining attributes of stationary, not 
mobile, devices, even if this is a wireless access point. Generally, the 
owners of such devices have no difficulty identifying the location.

There was separate discussion on whether to allow representations of 
"near" a point, e.g., on a street corner or other place that is not 
necessarily uniquely identified by a house number and street address. It 
was believed that while this is likely to be useful in some 
circumstances that it significantly complicates the design without 
adding value to most applications (such as user location, element 
management or emergency services).

Thus, my recommendation would be to leave one country code element only. 
I'm amenable to defining country code as a regular element (CAtype, 
CAlength, CAvalue), although it does not increase the expressiveness.

Clearly, both simple and multiple 'what' can be made to work. My 
personal inclination is towards simplicity and fewer error cases, but I 
don't feel particularly strongly about this and would be more than happy 
to allow for greater generality if the WG perceives such need.

> CAvalue.  The description of the CAlength then includes the sentence 
> "Data SHOULD be encoded in mixed case, following customary selling."  My 
> guess is that this sentence belongs somewhere else.  Also, there is 

It sure does, in the CAvalue immediately below. I've adjusted the text.

> confusion because the CAvalue description includes text that say "and 
> written in uppercase letters where applicable."  So is it mixed case or 
> upper case?

History :-)  Should be mixed.

> whichever CAtype is used to carry a script indication (CAtype=128)

Indeed. Made more explicit.

> 
> Shouldn't the last sentence of the Securiyt Considerations (section 5) 
> say more than "one should consider the potential security risks."  Is 
> this intended to refer only to the risks in the previous three 
> paragraphs, or some undefined set of risks?  Is this supposed to drive 
> some stronger actions than those mentioned in the previous three 
> paragraphs?

I stole this from another related document, now RFC 3825. I agree that 
this is a bit wishy-washy. Since this refers to the privacy issue, I 
added a sentence to the second paragraph and drop the last one:

"Since there is no privacy protection for DHCP messages, an
eavesdropper who can monitor the link between the DHCP server and
requesting client can discover the information contained in this
option. Thus, usage of this option on networks without access
restrictions or network-layer or link-layer privacy mechanisms is NOT 
RECOMMENDED."

Please let me know if that adds clarity of intent.

> providing the definition of a given country?  If so, the description in 
> the IANA considerations seems to indicate that an RFC will be needed to 
> there some other way we will document the meanings for other countries?  
> Whatever is intended ought to be called out explicitly rather than 
> leaving it implicit in the document.

Good point. I think the best approach would be to have an RFC update the 
descriptions, thus adding a sentence like

"Updates to country-specific considerations for previously-defined 
CATypes follow the same procedure. Such documents may add the 
interpretation for A1 through A6 for additional countries. Approval by a 
Designated Expert is required."

Would that be sufficiently clear?

(Minor clarification: The IANA consideration does not require an RFC. It 
only mandates "A stable reference
to an RFC or other permanent and readily available reference, in
sufficient detail so that interoperability between independent
implementations is possible.", following the "Specification Required" 
rules of RFC 2434.)

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 14 Jan 2005 07:44:25 -0500

Thank you.  All the proposed resolutions look very effective.

I suspect I got my description of the country code & "what" issue slightly 
muddled.
If I am reading the format correctly, there is one country code (for 
reasons you describe clearly) and one "what".  The order is CC, 
"what".  But in building the message, one should decide "what" is being 
described before filling in the country code, since the different "what" 
can be in different countries.  It is not mathematically wrong to include 
the fields in the message with country code and then what, since this will 
not actually confuse the receiver.  It is just counter-intuitive.

Yours,
Joel

At 11:17 PM 1/13/2005, Henning Schulzrinne wrote:
>This was done purely for presentation reasons in the figure (although word 
>alignment doesn't much matter here since it's a two-byte character, not an 
>integer) and since the country code was considered to be required and 
>common. This is clearly arbitrary and it does make sense to reverse this, 
>logically speaking. However, before making the change, see the discussion 
>below.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 14 Jan 2005 09:44:44 -0500

Agreed. Unless there are objections, I will reverse the order to be more 
logically hierarchical.

Joel M. Halpern wrote:
> I suspect I got my description of the country code & "what" issue 
> slightly muddled.
> reasons you describe clearly) and one "what".  The order is CC, "what".  
> But in building the message, one should decide "what" is being described 
> before filling in the country code, since the different "what" can be in 
> different countries.  It is not mathematically wrong to include the 
> fields in the message with country code and then what, since this will