geopriv@ietf.org: November 2010

Tuesday, November 30, 2010

Re: [Geopriv] [geopriv] rfc3825bis #42 (new): Altitude format (from Richard Barnes)

#42: Altitude format (from Richard Barnes)

Comment(by bernard_aboba@…):

Here is the proposed text for Sections 2.4, 2.4.1 and 2.4.2 (text for
Section 2.4.3 is covered in Issue 41).

2.4. Altitude

How the Altitude value is interpreted depends on the Altitude Type
(AType) value and the selected datum. Three Altitude Type values are
defined in this document: unknown (0), meters (1) and floors (2).

2.4.1. No Known Altitude (AType = 0)

In some cases, the altitude of the location might not be provided.
An Altitude Type value of zero indicates that the altitude is not
given to the client. In this case, the Altitude and Altitude
Uncertainty fields can contain any value and MUST be ignored.

2.4.2. Altitude in Meters (AType = 1)

If the Altitude Type has a value of one, Altitude is measured in
meters, in relation to the zero set by the vertical datum. For AType
= 1, the Altitude value is expressed as a 30 bit, fixed point, twos
complement integer with 22 integer bits and 8 fractional bits.

--
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner: bernard_aboba@…
Type: defect | Status: new
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
Severity: Submitted WG Document | Keywords:
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/42#comment:2>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS

#41: David Harrington's DISCUSS

Comment(by bernard_aboba@…):

Here is the corrected text for Section 2.4.3:

2.4.3. Altitude in Floors (AType = 2)

A value of two for Altitude Type indicates that the Altitude value is
measured in floors. Since altitude in meters may not be known within
a building, a floor indication may be more useful. For AType = 2,
the Altitude value is expressed as a 30 bit, fixed point, twos
complement integer with 22 integer bits and 8 fractional bits.

This value is relevant only in relation to a building; the value is
relative to the ground level of the building. Numbering starts at
ground level, which is floor 0 regardless of local convention.
Floors located below ground level are represented by negative values.
Larger values represent floors that are farther away from floor 0
such that:

- if positive, the floor value is farther above the ground floor.
- if negative, the floor value is farther below the ground floor.

Non-integer values can be used to represent intermediate or sub-
floors, such as mezzanine levels. Example: a mezzanine between floor
1 and floor 2 could be represented as a value of 1.25. Example:
mezzanines between floor 4 and floor 5 could be represented as values
of 4.5 and 4.75.

Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:4>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] rfc3825bis #42 (new): Altitude format (from Richard Barnes)

#42: Altitude format (from Richard Barnes)

Comment(by bernard_aboba@…):

Proposed Resolution: Move the 22/8 fixed point thing down into the
subsections of 2.4.

Ticket URL: <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/42#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] [geopriv] rfc3825bis #42 (new): Altitude format (from Richard Barnes)

#42: Altitude format (from Richard Barnes)

Actually, while we're on this, there's another contradiction lurking here:

On the one hand, the option definitions say:
"Altitude: A 30 bit value defined by the AType field."
One might read this to mean that the AType value can specify the meaning
of all the bits in the field. So if I define AType=7, I could say that
the the 30 bits contain a 3-character ASCII code describing the color of
the carpet on the floor in question (with each character padded to 10
bits, natch). More to the point, for AType=2 (==floors), you might split
the field into two integers, one signed and one unsigned, that represent
"major" and "minor" floor numbers. That way, you could actually directly
represent 1.1, 4.1, 4.2.

On the other hand, Section 2.4 defines the Altitude field as 22/8 fixed
point regardless of the AType value -- it's only the semantic of this
number that changes. This rules out all of the creative encodings
described above, at the cost of forcing everything into a 22/8 fixed-point
mold.

I'll leave it to the author to decide which of these to go with (I don't
think it really matters much). If it's the former, then the 22/8 fixed
point thing should be moved down into the subsections of 2.4. If the
latter, then it should be moved up to the option definitions, as with the
Latitude and Longitude fields.

Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/42>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS

Actually, while we're on this, there's another contradiction lurking here:

On the one hand, the option definitions say:
"Altitude: A 30 bit value defined by the AType field."
One might read this to mean that the AType value can specify the meaning of all the bits in the field. So if I define AType=7, I could say that the the 30 bits contain a 3-character ASCII code describing the color of the carpet on the floor in question (with each character padded to 10 bits, natch). More to the point, for AType=2 (==floors), you might split the field into two integers, one signed and one unsigned, that represent "major" and "minor" floor numbers. That way, you could actually directly represent 1.1, 4.1, 4.2.

On the other hand, Section 2.4 defines the Altitude field as 22/8 fixed point regardless of the AType value -- it's only the semantic of this number that changes. This rules out all of the creative encodings described above, at the cost of forcing everything into a 22/8 fixed-point mold.

I'll leave it to the author to decide which of these to go with (I don't think it really matters much). If it's the former, then the 22/8 fixed point thing should be moved down into the subsections of 2.4. If the latter, then it should be moved up to the option definitions, as with the Latitude and Longitude fields.

--Richard

On Nov 30, 2010, at 10:46 PM, geopriv issue tracker wrote:

> #41: David Harrington's DISCUSS
>
>
> Comment(by bernard_aboba@…):
>
> [James Polk]
>
> #41: David Harrington's DISCUSS Comment(by bernard_aboba at ?):
> Proposed Resolution: In 2.2.1.2, s/same respoonse. This is not useful
> since/same response, since/ Replace Section 2.4.3 with the following:
>
> A value of two for Altitude Type indicates that the Altitude value is
> measured in floors. This value is relevant only in relation to a
> building; the value is relative to the ground level of the building.
>
> In this definition, numbering starts at ground level, which is floor
> 0 regardless of local convention. Floors located below ground level
> could be represented by negative values.
>
> I recommend a change to be definitive here with
> s/could be/are
>
>
> Larger values represent floors
> that are above (higher in altitude) floors with lower values.
>
> This sentence is written in one direction; i.e., up.
>
> I recommend
> "Larger values represent floors that are farther away from floor 0
> such that -
>
> - if positive, the floor value is farther above the ground floor.
>
> - if negative, the floor value is farther below the ground floor."
>
>
> Non-integer values can be used to represent intermediate or sub-
> floors, such as mezzanine levels. Example: a
> mezzanine between floor 1 and floor 2 could be represented as a value
> = 1.1. Example: (2) mezzanines between floor 4 and floor 5 could be
> represented as values = 4.1 and 4.2 respectively.
>
> I'm fine with the rest as written.
>
> James
>
> [Bernard Aboba]
>
> Here is a revised proposal for the text of Section 2.4.3:
>
> 2.4.3. Altitude in Floors (AType = 2)
>
> A value of two for Altitude Type indicates that the Altitude value is
> measured in floors. Since altitude in meters may not be known within
> a building, a floor indication may be more useful. This value is
> relevant only in relation to a building; the value is relative to the
> ground level of the building.
>
> Numbering starts at ground level, which is floor 0 regardless of
> local convention. Floors located below ground level are represented
> by negative values. Larger values represent floors that are farther
> away from floor 0 such that:
>
> - if positive, the floor value is farther above the ground floor.
> - if negative, the floor value is farther below the ground floor.
>
> Non-integer values can be used to represent intermediate or sub-
> floors, such as mezzanine levels. Example: a mezzanine between floor
> 1 and floor 2 could be represented as a value of 1.1. Example:
> mezzanines between floor 4 and floor 5 could be represented as values
> of 4.1 and 4.2.
>
> --
> ---------------------------------------+------------------------------------
> Reporter: bernard_aboba@… | Owner: bernard_aboba@…
> Type: defect | Status: new
> Priority: major | Milestone: draft-ietf-geopriv-3825bis
> Component: rfc3825bis | Version: 1.0
> Severity: Submitted WG Document | Keywords:
> ---------------------------------------+------------------------------------
>
> Ticket URL: <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:3>
> geopriv <http://tools.ietf.org/geopriv/>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS

You can get fairly close though: 1.1015625, 4.1015625, 4.19921875

On 2010-12-01 at 15:53:35, Richard L. Barnes wrote:
> Would it be out of place to note that none of the values 1.1, 4.1, or
> 4.2 are expressible with 8 bits of fraction? Maybe use 1.25, 4.5,
> 4.75?
>
> --Richard
>
>
> On Nov 30, 2010, at 7:39 PM, geopriv issue tracker wrote:
>
> > #41: David Harrington's DISCUSS
> >
> >
> > Comment(by bernard_aboba@…):
> >
> > Proposed Resolution:
> >
> > In 2.2.1.2, s/same response. This is not useful since/same response,
> > since/
> >
> > Replace Section 2.4.3 with the following:
> >
> > A value of two for Altitude Type indicates that the Altitude value
> is
> > measured in floors. This value is relevant only in relation to a
> > building; the value is relative to the ground level of the
> building.
> >
> > In this definition, numbering starts at ground level, which is
> floor
> > 0 regardless of local convention. Floors located below ground
> level
> > could be represented by negative values. Larger values represent
> floors
> > that are above (higher in altitude) floors with lower values.
> >
> > Non-integer values can be used to represent intermediate or sub-
> > floors, such as mezzanine levels. Example: a
> > mezzanine between floor 1 and floor 2 could be represented as a
> value
> > = 1.1. Example: (2) mezzanines between floor 4 and floor 5 could
> be
> > represented as values = 4.1 and 4.2 respectively.
> >
> > --
> > ---------------------------------------+-----------------------------
> -------
> > Reporter: bernard_aboba@… | Owner: bernard_aboba@…
> > Type: defect | Status: new
> > Priority: major | Milestone: draft-ietf-
> geopriv-3825bis
> > Component: rfc3825bis | Version: 1.0
> > Severity: Submitted WG Document | Keywords:
> > ---------------------------------------+-----------------------------
> -------
> >
> > Ticket URL:
> <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:2>
> > geopriv <http://tools.ietf.org/geopriv/>
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS

Would it be out of place to note that none of the values 1.1, 4.1, or 4.2 are expressible with 8 bits of fraction? Maybe use 1.25, 4.5, 4.75?

--Richard

On Nov 30, 2010, at 7:39 PM, geopriv issue tracker wrote:

> #41: David Harrington's DISCUSS
>
>
> Comment(by bernard_aboba@…):
>
> Proposed Resolution:
>
> In 2.2.1.2, s/same response. This is not useful since/same response,
> since/
>
> Replace Section 2.4.3 with the following:
>
> A value of two for Altitude Type indicates that the Altitude value is
> measured in floors. This value is relevant only in relation to a
> building; the value is relative to the ground level of the building.
>
> In this definition, numbering starts at ground level, which is floor
> 0 regardless of local convention. Floors located below ground level
> could be represented by negative values. Larger values represent floors
> that are above (higher in altitude) floors with lower values.
>
> Non-integer values can be used to represent intermediate or sub-
> floors, such as mezzanine levels. Example: a
> mezzanine between floor 1 and floor 2 could be represented as a value
> = 1.1. Example: (2) mezzanines between floor 4 and floor 5 could be
> represented as values = 4.1 and 4.2 respectively.
>
> --
> ---------------------------------------+------------------------------------
> Reporter: bernard_aboba@… | Owner: bernard_aboba@…
> Type: defect | Status: new
> Priority: major | Milestone: draft-ietf-geopriv-3825bis
> Component: rfc3825bis | Version: 1.0
> Severity: Submitted WG Document | Keywords:
> ---------------------------------------+------------------------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:2>
> geopriv <http://tools.ietf.org/geopriv/>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] CONSENSUS CALL: Civic address extensibility

Right, basically, "something that I don't care if anyone understands, just the people I have arranged things with".

--Richard

On Nov 30, 2010, at 7:02 PM, Thomson, Martin wrote:

> On 2010-12-01 at 10:02:56, Ted Hardie wrote:
>> I think you need to clarify whether "private" means "unknowable to
>> others" or something
>> else. Relaxing the CAtype registry to fcfs would make it possible to
>> use it for local
>> extensions, but it would not be private. What value of "private" is
>> required here?
>
> I think that Richard intended "private" to be "local" or "constrained scope". That is, interoperability is not widely sought, just within a specific community.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS

#41: David Harrington's DISCUSS

Comment(by bernard_aboba@…):

[James Polk]

#41: David Harrington's DISCUSS Comment(by bernard_aboba at ?):
Proposed Resolution: In 2.2.1.2, s/same respoonse. This is not useful
since/same response, since/ Replace Section 2.4.3 with the following:

A value of two for Altitude Type indicates that the Altitude value is
measured in floors. This value is relevant only in relation to a
building; the value is relative to the ground level of the building.

In this definition, numbering starts at ground level, which is floor
0 regardless of local convention. Floors located below ground level
could be represented by negative values.

I recommend a change to be definitive here with
s/could be/are

Larger values represent floors
that are above (higher in altitude) floors with lower values.

This sentence is written in one direction; i.e., up.

I recommend
"Larger values represent floors that are farther away from floor 0
such that -

- if positive, the floor value is farther above the ground floor.

- if negative, the floor value is farther below the ground floor."

Non-integer values can be used to represent intermediate or sub-
floors, such as mezzanine levels. Example: a
mezzanine between floor 1 and floor 2 could be represented as a value
= 1.1. Example: (2) mezzanines between floor 4 and floor 5 could be
represented as values = 4.1 and 4.2 respectively.

I'm fine with the rest as written.

James

[Bernard Aboba]

Here is a revised proposal for the text of Section 2.4.3:

2.4.3. Altitude in Floors (AType = 2)

A value of two for Altitude Type indicates that the Altitude value is
measured in floors. Since altitude in meters may not be known within
a building, a floor indication may be more useful. This value is
relevant only in relation to a building; the value is relative to the
ground level of the building.

Numbering starts at ground level, which is floor 0 regardless of
local convention. Floors located below ground level are represented
by negative values. Larger values represent floors that are farther
away from floor 0 such that:

- if positive, the floor value is farther above the ground floor.
- if negative, the floor value is farther below the ground floor.

Non-integer values can be used to represent intermediate or sub-
floors, such as mezzanine levels. Example: a mezzanine between floor
1 and floor 2 could be represented as a value of 1.1. Example:
mezzanines between floor 4 and floor 5 could be represented as values
of 4.1 and 4.2.

Ticket URL: <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:3>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] HR 5777

I cannot remember if this House bill (draft) was shared with the Geopriv community

http://energycommerce.house.gov/documents/20100720/HR5777_introduced.pdf

Geolocation is mentioned in section 8

Carl Reed, PhD
CTO
Open Geospatial Consortium

The OGC: Making Location Count

Re: [Geopriv] CONSENSUS CALL: Civic address extensibility

Yes, yes, and yes.

Carl

----- Original Message -----
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: <geopriv@ietf.org>
Sent: Tuesday, November 30, 2010 2:05 PM
Subject: [Geopriv] CONSENSUS CALL: Civic address extensibility

> Hey all,
>
> As a follow-up to our virtual interim this afternoon, the chairs would
> like to make a consensus call on the following questions:
>
> A. Should this working group do something about civic address
> extensibility?
>
> B. Should we create a single extension element that can express
> registered, "global" elements?
>
> C. Should we create a mechanism for private/local extensions in the DHCP
> civic address format, and recommendations about how to create
> private/local extensions in DHCP and XML?
>
> Please send responses to the list no later than Friday, 3 December 2010.
>
> Thanks,
> --Richard
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS

At 06:39 PM 11/30/2010, geopriv issue tracker wrote:
>#41: David Harrington's DISCUSS Comment(by
>bernard_aboba@…): Proposed Resolution: In
>2.2.1.2, s/same respoonse. This is not useful
>since/same response, since/ Replace Section 2.4.3 with the following:

>A value of two for Altitude Type indicates that the Altitude value is
>measured in floors. This value is relevant only in relation to a
>building; the value is relative to the ground level of the building.
>
>In this definition, numbering starts at ground level, which is floor
>0 regardless of local convention. Floors located below ground level
>could be represented by negative values.

I recommend a change to be definitive here with
s/could be/are

>Larger values represent floors
>that are above (higher in altitude) floors with lower values.

This sentence is written in one direction; i.e., up.

I recommend
"Larger values represent floors that are farther away from floor 0
such that -

- if positive, the floor value is farther above the ground floor.

- if negative, the floor value is farther below the ground floor."

>
>Non-integer values can be used to represent intermediate or sub-
>floors, such as mezzanine levels. Example: a
>mezzanine between floor 1 and floor 2 could be represented as a value
>= 1.1. Example: (2) mezzanines between floor 4 and floor 5 could be
>represented as values = 4.1 and 4.2 respectively.

I'm fine with the rest as written.

James

>--
>---------------------------------------+------------------------------------
>Reporter: bernard_aboba@… |
>Owner: bernard_aboba@… Type:
>defect | Status: new
> Priority: major
> | Milestone:
>draft-ietf-geopriv-3825bis
>Component: rfc3825bis |
>Version: 1.0 Severity:
>Submitted WG
>Document | Keywords:
> ---------------------------------------+------------------------------------
>Ticket URL:
><http://trac.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:2>
>geopriv <http://tools.ietf.org/geopriv/>
>_______________________________________________
>Geopriv mailing list Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] On civic extensions

Robert asked a question about how the various extension scheme affect
LoST service boundaries (as opposed to the validation we've already
discussed). I think that this is another consideration we need to deal
with in designing a solution.

Ultimately, questions of the effect of our decisions on other protocols
and users of the civic address format are the most important.
Discussions on registries and associated concerns is - at this stage -
an wasteful distraction.

Service boundary evaluation is a simple process that treats each address
label as opaque (see draft-thomson-ecrit-civic-boundary for a more
thorough discussion). This would make things easy if there were only
one possible way an extension could find its way into the system.

Here are my collected thoughts on the real problem.

There are two formats that can be used to introduce an extension: DHCP
and XML.

Those two entry points could lead to an increased number of
representations for extensions.

Most of the problems occur at the point where conversions occur between
formats. If an originator (LG) and ultimate recipient both understand
the extension, conversions between different formats are the only
serious cause of problems.

If all intermediaries understood all extensions, we have no problem.
That's not a reasonable precondition though. We have to deal with
certain intermediaries who are ignorant of extensions.

An extension that finds its way into the system by way of DHCP (or
DHCP-based formats) is going to appear as a new, unknown CAtype to
recipients. This can be translated to an XML format in two ways: when
the translator understands the DHCP form and the equivalent XML form;
and when the translator does not. We need to deal with both cases.

An extension that finds its way into the system by way of an XML format
has a similar problem. The specific qualified name that identifies the
type of the extension can't be carried by DHCP. The same concerns apply
to this sort of conversion.

Though a specific piece of location information might not need to be
converted to DHCP format, it's genesis in XML might ultimately
dictate that DHCP clients be able to convey this to clients for it to
be represented in XML. The idea being that data is forced to go XML
-> DHCP -> XML and the goal is not to lose the extension.

This leads to the following truth table for converting intermediaries:

Note: Existing software is forced to discard extensions when
translating in either direction. Thus, it's safe to ignore that in
this analysis. I assume that software is compliant with whatever
specification we produce.

-local-civic allows for two expressions of the same data in either basic
format to deal with the problem cases "B" and "D". This does add two
different representations of the same information in both XML and DHCP;
one representation for each of the four cases.

This could cause a problem for LoST service boundaries (or any other
application that uses civic addresses). If a particular extension can
be represented in different ways, the LoST server that relies on an
extension for its boundaries has to produce 2^n different service
boundaries if it wants to be understood (where 2 = the number of
different representations for each extension, and n = the number of
extensions).

In practice, I expect that such reliance on extensions will be rare
for LoST. This problem is rendered moot if the extensions are safely
ignored, but it's something we need to consider for the general case.

If we want to solve the problem of multiple representations - and we
should really evaluate the impact if we do not - then we need to
legislate to remove one of the options. Since we can do nothing to
rectify the ignorance (or not) of translators, the only real option is
to restrict where extensions are defined.

Removing the XML extension point would force all civic address
extensions to acquire a CAtype from the registry. Extensions are only
ever natively defined as one octet CAtypes. To carry extensions in XML,
we'd define an element that can carry unknown CAtypes. <ext:EXT
CAtype="192">Value</ext:EXT> as suggested in -local-civic would be
a representative implementation of this option.

Removing the DHCP extension point was actually something suggested in a
previous version of -local-civic. That got some fairly strong
objections, but it should be tabled again. In this option extensions
are natively defined in XML and we define a way to convey an XML-based
extension in DHCP. The two new CAtypes in -local-civic are
representative implementations of this option.

Thus we have the solution matrix:

Extend DHCP?
| Yes | No
------+-----------------+-----------------
Extend Yes | -local-civic-03 | -local-civic-02
XML? No | *C | *D

*C is what (I think) Brian is advocating (Brian: correct me if I am
wrong, I've heard you support this).

I don't think that anyone is advocating *D, though it's effectively
where we are at the moment.

Keith is partly right about a do-over always being a final failsafe
option: we do always have the option of a complete do-over. However,
the main problem will just carry over into the new format if we don't
resolve it. A do-over is just a decision we might make in the course of
implementing one of these four options.

We should resolve this issue before we get into discussions on
registration policies and so forth. Those discussions are wasteful as
long as we each have different fundamental solutions in mind. I hope
that we can agree that each of these works with wild west, fcfs, expert
review or standards action with similar efficacy, though different
levels of accessibility and interoperability.

--Martin

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS

#41: David Harrington's DISCUSS

Comment(by bernard_aboba@…):

Proposed Resolution:

In 2.2.1.2, s/same response. This is not useful since/same response,
since/

Replace Section 2.4.3 with the following:

In this definition, numbering starts at ground level, which is floor
0 regardless of local convention. Floors located below ground level
could be represented by negative values. Larger values represent floors
that are above (higher in altitude) floors with lower values.

Non-integer values can be used to represent intermediate or sub-
floors, such as mezzanine levels. Example: a
mezzanine between floor 1 and floor 2 could be represented as a value
= 1.1. Example: (2) mezzanines between floor 4 and floor 5 could be
represented as values = 4.1 and 4.2 respectively.

Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:2>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS

#41: David Harrington's DISCUSS

Comment(by bernard_aboba@…):

[James Polk] with a negative number.

This was in RFC3825, but I cannot find it in this document now, which is
an oversight on (at least) my part.

>Should 2.4.3 mention how to represent this?

probably correct with the section this should be in

>Should Appendix B include such an example?

it could

>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>1) section 1, paragraph 4 says "The DHCP server could correlate the
>Circuit-ID with the geographic location where the
> identified circuit terminates (such as the location of the wall
>jack)." Would it be the job of the DHCP server to do this correlation?
>I would assume it was a NM application function to do such
>correlation.

I believe the operative word above is "could". The server could also just
forward what it was given by a Location Server (probably vs. a NM server)
towards the client without changing what it was given. Do you believe this
should be clearer?

>2) In 2.2.1.2, s/same response. This is not useful since/same response,
>since/

Ticket URL: <https://svn.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] CONSENSUS CALL: Civic address extensibility

On 2010-12-01 at 10:02:56, Ted Hardie wrote:
> I think you need to clarify whether "private" means "unknowable to
> others" or something
> else. Relaxing the CAtype registry to fcfs would make it possible to
> use it for local
> extensions, but it would not be private. What value of "private" is
> required here?

I think that Richard intended "private" to be "local" or "constrained scope". That is, interoperability is not widely sought, just within a specific community.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] CONSENSUS CALL: Civic address extensibility

On Tue, Nov 30, 2010 at 1:05 PM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> Hey all,
>
> As a follow-up to our virtual interim this afternoon, the chairs would like to make a consensus call on the following questions:
>
> A. Should this working group do something about civic address extensibility?
>

Yes, provided "clarify how to do it within the existing mechanisms".

> B. Should we create a single extension element that can express registered, "global" elements?
>

No.

> C. Should we create a mechanism for private/local extensions in the DHCP civic address format, and recommendations about how to create private/local extensions in DHCP and XML?
>

I think you need to clarify whether "private" means "unknowable to
others" or something
else. Relaxing the CAtype registry to fcfs would make it possible to
use it for local
extensions, but it would not be private. What value of "private" is
required here?

regards,

Ted

> Please send responses to the list no later than Friday, 3 December 2010.
>
> Thanks,
> --Richard
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] My Meeting Notes for the Virtual GEOPRIV Interim Meeting (Nov. 30)

Here are my notes:

[12:01 pm] GEOPRIV Interim Meeting, November 30, 2010
[12:02 pm] Chair Slides
[12:03 pm] Alissa: Will talk about Civic Addressing Extensions. (Presents Note Well).
[12:04 pm] Agenda: Intro/admin, Overview of the problem, Appproach of draft-ietf-geopriv-prefix, Approach of draft-winterbottom-local-civic, 40 minutes for discussion.
[12:05 pm] Brian not present at the moment, will switch agenda slots with J. Winterbottom
[12:05 pm] Richard Barnes slides on Civic Address Extensibility
[12:05 pm] Goal is to get consensus on the problem to solve and introduce solutions and have some discussions.
[12:07 pm] Problem statement: There are things people want to add to the RFC 5139 address structure.... need to maintain interop... changing the structure requires schema changes, breaking backward compat...
[12:09 pm] Need to maintain parity in DHCP encoding....
[12:09 pm] Keith Drage: Schema update should stay on the agenda....
[12:09 pm] Richard: Don't mean to formally preclude anything....
[12:11 pm] Keith Drage: Could have a schema for A and a schema for B, rather than A+B....
[12:11 pm] Richard: That is roughly what James is going to propose.
[12:11 pm] Richard: Another challenge is to remain parity with DHCP representation of addresses.
[12:13 pm] Richard: LoST has a validation function... server can tell client which elements are valid/invalid/unchecked.... so server needs to refer to civic address elements....
[12:14 pm] Richard: Turning it over to James....
[12:14 pm] James: Local Civic (A wa to extend RFC 5139 civic elements)
[12:16 pm] Reasons: need new standard CAtypes, local apps need local extensions... can't brea the existing schema.... need to map from TLV form to XML (and vnice versa).
[12:18 pm] James: NENA interop event ongoing that is testing interop of existing schemas.... references from NENA, EENA, etc. changes will cause a lot of work elsewhere.
[12:19 pm] James: Standard CAtype extensions Define a new namespace...registry of CAtypes defined by RFC 4776...
[12:20 pm] James: If you don't need a registered CAtype... put it in your own namespace!
[12:21 pm] James: Apps that understand it can use it, apps that don't understand it, don't have to worry about it.
[12:23 pm] James: Conclusion: Local civic defines way to extend RFC 5139 without breaking it... allows new CAtypes to be defined... allows local extensions for local apps...
[12:24 pm] Martin: DHCP can carry the CAtype extensions....
[12:24 pm] Mark Linsner: How would you define local civic extensions? Is country local, or enterprise? Government entity?
[12:25 pm] James: Could be done in IETF as an RFC, but they don't have to....
[12:25 pm] Martin: Depends on how much interoperability you're looking for....
[12:26 pm] Richard Sparks: Looking at the service boundary and service list boundary from LoST.... if you have a private extension... how does that reconcile with a device that doesn't understand the extension... how could it determine if it's left a boundary with an extension in it....
[12:26 pm] Martin: Good question.... but equally applicable to new CATypes not in RFC 5139....
[12:27 pm] Richard: Civic address containment largely basedon matching... can still compare even if you don't understand a new element... existing code may treat extensions transparently.
[12:28 pm] Richard: If DHCP extension mechanism isn't understood at all, there could be a problem... could be an argument for a single CAtype....
[12:28 pm] Richard: Seems like this document takes different approaches for official and private extensions. Why?
[12:30 pm] James: Element type name is not constrained once you move into local stuff... so that was the rationale.
[12:30 pm] Martin: No way to let a local extension use anything in DHCP.... can't get new CAtype....
[12:30 pm] James: Do you need to? What is the justification?
[12:30 pm] Marc Linsner: Enterprises do use DHCP...
[12:31 pm] Marc Linsner: 802.11 is using equivalent of DHCP....
[12:31 pm] Marc: They would use a CAtype number (e.g. 244) and would map that to their own namespace.
[12:32 pm] James: Would define two new standard CAtypes.... CA123 would use to transfer the namespace prefix and URI... the one after that CA 124, used to transfer values... could do more or less what you're talking about, can put extensions directly in....
[12:32 pm] Marc Linsner: Would need to map out what CAtypes you're talking about, no?
[12:33 pm] Keith Drage: What is the purpose of this discussion? Is it to define a general mechanism... or just to prove that James' document doesn't have compat issues?
[12:33 pm] James: to come up with a general extensibility mechanism... and not break RFC 5139.
[12:34 pm] Richard: LoST service boundary not an issue of this particular extensibility mechanism... it's an issue with any mechanism.
[12:37 pm] James: Suppose DHCP server and LoST server thinks I'm using the latest version of the namespace... by upping the schema you have changed the meaning of CAtypes....
[12:37 pm] Keith Drage: Normally you send something most implementations will understand... then send a new one which not everyone will understand, but doesn't require a new schema definition....
[12:38 pm] Alissa: Keith's point has been noted.... we have Brian Rosen on the line and will switch over to him.
[12:40 pm] Brian Rosen: We don't want to promote new namespaces.... we want interoperability.... want a standard for a given place and application.... don't want every server to expect a different from of PIDF....
[12:40 pm] James: Who is we?
[12:40 pm] Brian: We is the IETF. This is what we've done historically.... There is a definition of an address in a country... document is listed in a registry...
[12:41 pm] James: An enterprise wants to locate areas in a building using their own method would be forbidden...
[12:41 pm] Brian: Just saying there should be a standard way to use a given locator... and everyone should use that same way.
[12:41 pm] Richard: Company may not care if a staff locator is intelligible to the world... why should they write an RFC if only your app cares about it?
[12:41 pm] Brian Rosen: I agree with that....
[12:42 pm] Brian Rosen: Want to talk about the way we do prefixes and relative locations.... they way you represent a bridge if it has an identifier... lots of people have bridges... bridge id should be in a CAtype that everyone understands...
[12:42 pm] Richard: Proposal is to have it in an extension element with type=bridge. Is this a difference only of syntax?
[12:43 pm] Brian: First question is, is there a registry?
[12:43 pm] James: Have a registry in RFC 4667... can write a spec for it, get a CAtype, we have an extension type for that....
[12:44 pm] James: Second extension mechanism is extension namespaces... only thing we're arguing about is what constitutes local or things we should be putting into this edition of CAtypes...
[12:44 pm] Brian Rosen: We're agreeing that you are always able to create a local namespace... not arguing against that... the existing mechanism stays there....
[12:44 pm] James: Are you happy with the way we do local civic so you can transport DHCP?
[12:44 pm] Brian Rosen: If that was the only answer, I'd be ok.....
[12:45 pm] James: Are CAtype extensions ok?
[12:45 pm] Brian Rosen: Having an explosion of name spaces generates syntactic cruft with no real value....
[12:46 pm] Brian Rosen: Does every new one have its own namespace?
[12:46 pm] James: One extension name space for standard CAtypes....
[12:47 pm] Brian Rosen: you can create an extension name, I agree with that... bar for a globally useful new CAtype was fairly high and remains fairly high, and I don't want to change it... when you have a name that doesn't rise to that level, you really have a circumstance that more than one app will use it... you wonder whether there should at least be a list of those....
[12:48 pm] James: My thoughts are that the organization that looks after those apps should be the custodian of that bit of namespace... could be NENA....
[12:48 pm] James: IETF doesn't need to have a registry...
[12:48 pm] Richard: Other protocols have registries for vendor unique IDs.... different organizations have registered namespaces....
[12:49 pm] Brian Rosen: you could, but...lots of big orgs have these things called mailstops... will we ever have a global CA type called "mailstop"?
[12:49 pm] James: No, no, no... they are all unique within a namespace, not transferrable....
[12:50 pm] Brian Rosen: don't want uniqueness, just interoperability....
[12:50 pm] Martin: In apps area, have provisional registration... not necessarily looking for standardization...
[12:50 pm] Brian: Want first come, first served registry....
[12:51 pm] James: would you give those people a CAtype?
[12:51 pm] Brian: maybe you give them a number....
[12:51 pm] James: don't think we have lots of numbers (only 255).
[12:52 pm] Marc Linsner: Using 123, 124 schema would still make it unique, right?
[12:52 pm] James: What are we registering? Provisionally register entire schemas or just name spaces?
[12:53 pm] James: not sure I like provisional aspect....
[12:54 pm] Brian: If people have the same use, would be useful to have interop... not two variations of the same thing.
[12:54 pm] Brian Rosen: to promote reuse you want the registry to have a low threshold....
[12:55 pm] Marc Linsner: If you create this registry, you'll assign a single namespace to it, right? How do you maintain backward compat when someone adds something to it?
[12:56 pm] Brian Rosen: It's only additive.... you never take something away.
[12:56 pm] James: Not in favor of that....
[12:56 pm] James: don't want willy-nully attributes that are devoid of namespace....
[12:57 pm] Richard: we need to cut this off due to time... I think we have made some progress on this call... would like to propose a few consensus calls... we won't do this on the phone, but on the list. Would like to run the questions by the group....
[12:57 pm] Richard: Three questions: First one is: should this WG be doing anything at all about civic address extensibility?
[12:57 pm] Second: Should we create a single extension element so that we don't have to extend the XML?
[12:58 pm] James: can you elaborate?
[12:58 pm] Richard: Should we create a single extension element that can express global extension elements?
[12:58 pm] Third: should we create recommendations for how to create private/local extensions?
[12:58 pm] James: Need to go one step further with last question.... need to define a mechanism that would also allow those private extensions....
[12:59 pm] Richard: in principle we have a mechanism... can throw junk in at the end of the schema...
[12:59 pm] James: Doesn't work for DHCP....
[12:59 pm] Richard: maybe the proper thing is to enable private/local extensions, create recommendations for what they look like... point taken.
[12:59 pm] Richard: other comments on those questions?
[1:00 pm] Richard: will put these questions to the list? sounds like we have some agreement at least about what to do with things in the official registry... my clock shows 4 PM even... any last comments?
[1:00 pm] Richard: Meeting adjourned (1 PM Pacific, 4 PM EST).

> From: hannes.tschofenig@gmx.net
> Date: Tue, 30 Nov 2010 23:02:14 +0200
> To: geopriv@ietf.org
> CC: hannes.tschofenig@gmx.net
> Subject: [Geopriv] My Meeting Notes for the Virtual GEOPRIV Interim Meeting (Nov. 30)
>
> Virtual Interim Meeting -- November 2010 ¶
> Date: Tuesday, November 30, 2010  Time: 3:00 pm, Eastern Daylight Time
>
> Agenda:
>
> - Intro/admin (chairs) Alissa gave a short intro to the meeting.
>
> - Overview of the problem (R. Barnes)
> Richard goes through his slides and explains the requirements.
> Requirements are:
> 1) Maintain backwards compatibility
> Keith noted that he wants to ensure that backwards compatibility is maintained.
> 2) Need to maintain parity with DHCP encoding.
> 3 Interaction with LoST maintained.
>
> - Approach of draft-winterbottom-local-civic (J. Winterbottom)
> draft-ietf-geopriv-prefix (B. Rosen)  James goes through his slide set explaining one way to extend RFC 5139 civic elements.
> Richard: Do we need a namespace URI?
> James: Yes.
> Martin provides an example:
> a…cdc=http://example.com/bridge
> b...cdc:bridge=471
> Martin: If someone defines a new DHCP code it can be carried The XML and the DHCP form
>
> Marc: How would I define "local"? Country, Enterprise
>
> James: It depends on those
>
> Martin: It depends on how much interoperability you would like to have.
>
> Robert: A LoST question. How would a response from a LoST server with these new CA types allow a LoST client to determine whether it is within a service region.
>
> Martin+James: A good question
>
> Richard: Not a big issue. It is purely a matching issue.
>
> Martin: The only wrinkle with that. The only issue if the server understands it but the client has received it through DHCP and uses the tunneling mechanism then it wouldn't work with blind matching.
>
> Richard: If it does not understand the DHCP extension then this may argue for a single CA type… this is getting a bit too detailed.
> One question I have: The document two different directions for official extensions vs. the CA type extensions.
>
> James: We only had to define one element for the CA type extension instead of defining a new element for every one.
>
> Marc: There is no way for local extension to extend to DHCP.
>
> James; Yes, there is.
>
> Martin: No, there is no.
>
> James: You are right.
>
> Marc: You describe local extension as enterprise usage cases and DHCP is used there. And the same is true for IEEE 802.11 where DHCP is used.
>
> James: Correct. One way to deal with this is to define 2 new CA types:
> 123 = namespace prefix & namespace
> 124 = transfer the values
> These could carry everything you want.
>
> Keith: Is this to define a general extensibility mechanism for Geopriv or just a discussion of whether James's document does not break backward bankability.
>
> James: The document is to come up a general extensibility mechanism in order not to cause problems with backwards compatibility.
>
> Richard: The LoST serviceBoundary issue is not a problem with this specific extensibility mechanism but with any.
>
> Keith: You have to cover it since you cannot come up with another extensibility mechanism to cover the LoST case.
>
> James; We could take the approach Richard suggested (with the qualification of Martin). The alternative is not to make any extension at all. That's not really doable either.
>
> Keith: I understand that.
> I was assuming a stepwise approach and defining a new schema is the last resort.
>
> James: I would like to have that issue off the table.
>
>
> Keith: I think you cannot take it away.
>
> James: The problem is that my DHCP (and associated LoST server) use the latest version of the schema you essentially changed the meaning of the CA types.
>
> Keith: Normally, you send something that most implementations understand. Then, in addition you send something that is new that some of the devices do not understand.
>
> You send both of them. This is standard protocol interoperability issues.
>
> Alissa: Keith, your point had been noted. Since Brian is now on the line we should give him a time to talk.
>
> Brian: Sorry for being late.
>
> Brian starts his talk. There is no protocol police -- you can always send new elements. We want things that are interoperability. We want to have a small number of standards and we don't want to deal with different servers to deal with different PIDFs.
>
> James: Who is "we"?
>
> Brian: The IETF
>
> James: I disagree.
>
> Brian: This is what we always have been doing with the registries.
>
> James: An enterprise cannot create new extensions, such as staff locator.
>
> Brian: If it
>
> Richard: I think that this is where the notion of 'local' vs. 'global' comes to existence. Only it's applications need to care about. You should have to write an RFC if your own application cares about it.
>
> Brian: Adding a namespace is always possible. I am talking about the way we do prefixes, a way we do bridges (a bridge has an identifier), etc.
>
> Richard: The proposal with local civic is to have a type = bridge and the difference seems to be only about the syntax.
>
> Brian: The question is whether we have a registry.
>
> Richard: We had a registry already previously.
>
> Brian: We agree that one can always create a new namespace.
>
> James: Are you happy with the way we do it in our document?
>
> Brian: I think that there are other ways.
>
> James: Let us just focus on the CA-types.
> It requires only one namespace extension for all of them.
>
> Brian: I thought that every new one had it's own namespace.
>
> James: No. We put that after our discussion.
> I don't think that there is any discussion on this issue.
>
> Brian: Well. OK.
> The bar for a globally useful new CA type was fairly high and should remain high. If you have a name that rises to that level then you are creating more than one application is using it.
>
> Martin: 4776: Referring to RFC 2434 [14], this registry
> operates under both "Expert Review" and "Specification Required"
> rules.
>
> James: If the OMA wants to put some extension in there then they have to ensure their quality. The IETF does not need to have a registry of this.
>
> Richard: Other protocol have vendor-specific extensions as well. We can have the same here as well. We can have these OIDs as well.
>
> Brian: Lots of big organizations have the 'mail stop' and I don't think we have a new CA type for mail stop. All these enterprises would define their own version and that's not good.
>
> Martin: There is experience in the applications area: "Provisional registration" here is what I do.
>
> Brian: This is what I am asking.
>
> Martin: Would you give those people a CA type?
>
> Brian: I would give folks a chance to comment and to give them a number.
> We have lots of numbers.
>
> Martin: We don't have too many numbers. We only have
>
> Marc: We could use the stuff that James talked about previously.
>
> James: yes.
> I am still not sure what are we registering? Schema and values?
>
> Brian: If the number space is not big enough then define an extension.
>
> James: I don't like this provisional aspect.
>
> Brian: If there is a use for it and if other people find it useful as well then I want other people to use it as well (rather than defining a variation of it).
>
> James: You could use the schema extension and you would just use someone else's namespace (if you like it).
>
> Brian: YOu need a registry with a low threshold; easy to look it up.
> If you have that registry then you do not need the namespace since the registry already gives you the uniqueness from the registry.
>
> James: I am not in favor of this mechanism.
> I would be OK with a reference to the namespace and people can fetch information based on the information from the namespace ('here is the XML')
>
> Brian: What does the namespace get you in addition to the uniqueness?
>
> Richard: Let's stop here. I believe we made progress.
> Let's make some consensus calls.
>
> Three questions:
>
> 1) Should this working group doing anything about extensibility?
>
> 2) Should we create a single extension mechanism that can express registered global values?
>
> 3) Should we create recommendations for how to create private/local extensions?
>
> James: We need to go one step further. We need to have a mechanism to allow these private extensions to be defined.
>
> Richard: We already have that. Through XML at the end
>
> James: Works only for XML - not DHCP
> Richard: True.
>
> I put these to the list.
>
>
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] CONSENSUS CALL: Civic address extensibility

YES

>
> B. Should we create a single extension element that can express
> registered, "global" elements?

YES

>
> C. Should we create a mechanism for private/local extensions in the DHCP
> civic address format, and recommendations about how to create
> private/local extensions in DHCP and XML?

YES

>
> Please send responses to the list no later than Friday, 3 December 2010.
>
> Thanks,
> --Richard
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] CONSENSUS CALL: Civic address extensibility

Hey all,

As a follow-up to our virtual interim this afternoon, the chairs would like to make a consensus call on the following questions:

A. Should this working group do something about civic address extensibility?

B. Should we create a single extension element that can express registered, "global" elements?

C. Should we create a mechanism for private/local extensions in the DHCP civic address format, and recommendations about how to create private/local extensions in DHCP and XML?

Please send responses to the list no later than Friday, 3 December 2010.

Thanks,
--Richard
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] My Meeting Notes for the Virtual GEOPRIV Interim Meeting (Nov. 30)

Virtual Interim Meeting -- November 2010 ¶
Date: Tuesday, November 30, 2010  Time: 3:00 pm, Eastern Daylight Time

Agenda:

- Intro/admin (chairs) Alissa gave a short intro to the meeting.

- Overview of the problem (R. Barnes)
Richard goes through his slides and explains the requirements.
Requirements are:
1) Maintain backwards compatibility
Keith noted that he wants to ensure that backwards compatibility is maintained.
2) Need to maintain parity with DHCP encoding.
3 Interaction with LoST maintained.

- Approach of draft-winterbottom-local-civic (J. Winterbottom)
draft-ietf-geopriv-prefix (B. Rosen)  James goes through his slide set explaining one way to extend RFC 5139 civic elements.
Richard: Do we need a namespace URI?
James: Yes.
Martin provides an example:
a…cdc=http://example.com/bridge
b...cdc:bridge=471
Martin: If someone defines a new DHCP code it can be carried The XML and the DHCP form

Marc: How would I define "local"? Country, Enterprise

James: It depends on those

Martin: It depends on how much interoperability you would like to have.

Robert: A LoST question. How would a response from a LoST server with these new CA types allow a LoST client to determine whether it is within a service region.

Martin+James: A good question

Richard: Not a big issue. It is purely a matching issue.

Martin: The only wrinkle with that. The only issue if the server understands it but the client has received it through DHCP and uses the tunneling mechanism then it wouldn't work with blind matching.

Richard: If it does not understand the DHCP extension then this may argue for a single CA type… this is getting a bit too detailed.
One question I have: The document two different directions for official extensions vs. the CA type extensions.

James: We only had to define one element for the CA type extension instead of defining a new element for every one.

Marc: There is no way for local extension to extend to DHCP.

James; Yes, there is.

Martin: No, there is no.

James: You are right.

Marc: You describe local extension as enterprise usage cases and DHCP is used there. And the same is true for IEEE 802.11 where DHCP is used.

James: Correct. One way to deal with this is to define 2 new CA types:
123 = namespace prefix & namespace
124 = transfer the values
These could carry everything you want.

Keith: Is this to define a general extensibility mechanism for Geopriv or just a discussion of whether James's document does not break backward bankability.

James: The document is to come up a general extensibility mechanism in order not to cause problems with backwards compatibility.

Richard: The LoST serviceBoundary issue is not a problem with this specific extensibility mechanism but with any.

Keith: You have to cover it since you cannot come up with another extensibility mechanism to cover the LoST case.

James; We could take the approach Richard suggested (with the qualification of Martin). The alternative is not to make any extension at all. That's not really doable either.

Keith: I understand that.
I was assuming a stepwise approach and defining a new schema is the last resort.

James: I would like to have that issue off the table.

Keith: I think you cannot take it away.

James: The problem is that my DHCP (and associated LoST server) use the latest version of the schema you essentially changed the meaning of the CA types.

Keith: Normally, you send something that most implementations understand. Then, in addition you send something that is new that some of the devices do not understand.

You send both of them. This is standard protocol interoperability issues.

Alissa: Keith, your point had been noted. Since Brian is now on the line we should give him a time to talk.

Brian: Sorry for being late.

Brian starts his talk. There is no protocol police -- you can always send new elements. We want things that are interoperability. We want to have a small number of standards and we don't want to deal with different servers to deal with different PIDFs.

James: Who is "we"?

Brian: The IETF

James: I disagree.

Brian: This is what we always have been doing with the registries.

James: An enterprise cannot create new extensions, such as staff locator.

Brian: If it

Richard: I think that this is where the notion of 'local' vs. 'global' comes to existence. Only it's applications need to care about. You should have to write an RFC if your own application cares about it.

Brian: Adding a namespace is always possible. I am talking about the way we do prefixes, a way we do bridges (a bridge has an identifier), etc.

Richard: The proposal with local civic is to have a type = bridge and the difference seems to be only about the syntax.

Brian: The question is whether we have a registry.

Richard: We had a registry already previously.

Brian: We agree that one can always create a new namespace.

James: Are you happy with the way we do it in our document?

Brian: I think that there are other ways.

James: Let us just focus on the CA-types.
It requires only one namespace extension for all of them.

Brian: I thought that every new one had it's own namespace.

James: No. We put that after our discussion.
I don't think that there is any discussion on this issue.

Brian: Well. OK.
The bar for a globally useful new CA type was fairly high and should remain high. If you have a name that rises to that level then you are creating more than one application is using it.

Martin: 4776: Referring to RFC 2434 [14], this registry
operates under both "Expert Review" and "Specification Required"
rules.

James: If the OMA wants to put some extension in there then they have to ensure their quality. The IETF does not need to have a registry of this.

Richard: Other protocol have vendor-specific extensions as well. We can have the same here as well. We can have these OIDs as well.

Brian: Lots of big organizations have the 'mail stop' and I don't think we have a new CA type for mail stop. All these enterprises would define their own version and that's not good.

Martin: There is experience in the applications area: "Provisional registration" here is what I do.

Brian: This is what I am asking.

Martin: Would you give those people a CA type?

Brian: I would give folks a chance to comment and to give them a number.
We have lots of numbers.

Martin: We don't have too many numbers. We only have

Marc: We could use the stuff that James talked about previously.

James: yes.
I am still not sure what are we registering? Schema and values?

Brian: If the number space is not big enough then define an extension.

James: I don't like this provisional aspect.

Brian: If there is a use for it and if other people find it useful as well then I want other people to use it as well (rather than defining a variation of it).

James: You could use the schema extension and you would just use someone else's namespace (if you like it).

Brian: YOu need a registry with a low threshold; easy to look it up.
If you have that registry then you do not need the namespace since the registry already gives you the uniqueness from the registry.

James: I am not in favor of this mechanism.
I would be OK with a reference to the namespace and people can fetch information based on the information from the namespace ('here is the XML')

Brian: What does the namespace get you in addition to the uniqueness?

Richard: Let's stop here. I believe we made progress.
Let's make some consensus calls.

Three questions:

1) Should this working group doing anything about extensibility?

2) Should we create a single extension mechanism that can express registered global values?

3) Should we create recommendations for how to create private/local extensions?

James: We need to go one step further. We need to have a mechanism to allow these private extensions to be defined.

Richard: We already have that. Through XML at the end

James: Works only for XML - not DHCP
Richard: True.

I put these to the list.

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS

#41: David Harrington's DISCUSS

David Harrington has entered the following ballot position for draft-ietf-
geopriv-rfc3825bis-14.

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document is well-written, with clear and unambiguous language.

When aType=2, numbering starts at ground level. How does one represent an
underground parking garage level?
Should 2.4.3 mention how to represent this? Should Appendix B include such
an example?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

1) section 1, paragraph 4 says "The DHCP server could correlate the
Circuit-ID with the geographic location where the
identified circuit terminates (such as the location of the wall jack)."
Would it be the job of the DHCP server to do this correlation? I would
assume it was a NM application function to do such correlation.
2) In 2.2.1.2, s/same response. This is not useful since/same response,
since/

Ticket URL: <https://svn.tools.ietf.org/wg/geopriv/trac/ticket/41>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Monday, November 29, 2010

[Geopriv] IETF 79 draft minutes

Hey all,

Draft minutes from IETF 79 have been posted to the IETF web site:
<http://tools.ietf.org/wg/geopriv/minutes?item=minutes79.html>

Please send any comments to the list no later than Friday, 3 Dec.

Thanks,
--Richard
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Virtual interim Webex info

Topic: GeoPriv Interim
Date: Tuesday, November 30, 2010
Time: 3:00 pm, Eastern Standard Time (New York, GMT-05:00)

Meeting Number: 201 706 883
Meeting Password: ietf

-------------------------------------------------------
To join the online meeting
-------------------------------------------------------
1. Go to
https://ciscosales.webex.com/ciscosales/j.php?ED=154214442&UID=0&PW=NODczMm
U2YTFj&RT=MiMxMQ%3D%3D
2. Enter your name and email address.
3. Enter the meeting password: ietf
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://ciscosales.webex.com/ciscosales/j.php?ED=154214442&UID=0&PW=NODczMm
U2YTFj&ORT=MiMxMQ%3D%3D

----------------------------------------------------------------
Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San
Jose/Milpitas area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or
Access
Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Virtual interim agenda

Our virtual interim is scheduled for Tuesday, November 30, 15:00-16:00
EDT. Here's the draft agenda:

5m Intro/admin (chairs)
5m Overview of the problem (R. Barnes)
5m Approach of draft-ietf-geopriv-prefix (B. Rosen)
5m Approach of draft-winterbottom-local-civic (J. Winterbottom)
40m Discussion

Webex info will be sent to the list and posted to the wiki (http://trac.tools.ietf.org/wg/geopriv/trac/wiki
) shortly.

Alissa

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Sunday, November 28, 2010

Re: [Geopriv] geopriv-policy requirements

This is the only sensible approach at this stage. I suspect that there will be myriad "attacks" on any solution that is put forward and the only option is to spend a lot time in analysis.

The basic stationary scheme seems reasonable. Add a random offset, increase uncertainty to obscuring distance.

I'd like to at least provide some limited protection for movement. By suppressing reports where the known location has moved less than the obscuring distance (or something like that) a lot is gained. This might reveal average speed with increasing accuracy, but it prevents simple interpolation.

This does nothing for C, but that's the point where things start to get complicated anyhow.

--Martin

On 2010-11-28 at 06:28:46, Richard L. Barnes wrote:
> I'm concerned that we're trying to solve every possible fuzzing problem
> with geopriv-policy. Three that I remember off the top of my head:
> A. Stationary targets
> B. Moving targets
> C. Patterns of motion (repeated visits averaged over time)
>
> As earlier versions of geopriv-policy show, "class A" algorithms that
> only address the first can be pretty simple. As you try to address the
> other two, you end up with something like the most recent version of -
> policy or draft-thomson-geopriv-location-obscuring.
>
> I would like to suggest that the base policy document doesn't need to
> address all of these problems. Advanced "class B/C" algorithms are
> clearly an active area for research and development, and the algorithm
> that the server applies is not a requirement for interoperability. The
> policy document format only describes the user's preferences; the
> server can reject policies or warn the user, but that's related to the
> policy *protocol* and the server's local policies.
>
> A more concrete proposal:
> 1. Roll back the fuzzing algorithm to a simple "class A" algorithm
> 2. Document how this algorithm can fail in "class B/C" situations
> 3. Provide informative references to more advanced strategies, such as
> draft-thomson-geopriv-location-obscuring or a new draft with Jorge's
> algorithm.
>
> Thoughts?
>
> --Richard
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Saturday, November 27, 2010

[Geopriv] I-D Action:draft-ietf-geopriv-rfc3825bis-14.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Geographic Location/Privacy Working Group of the IETF.

Title : Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information
Author(s) : J. Polk, et al.
Filename : draft-ietf-geopriv-rfc3825bis-14.txt
Pages : 32
Date : 2010-11-27

This document specifies Dynamic Host Configuration Protocol Options
(both DHCPv4 and DHCPv6) for the coordinate-based geographic location
of the client. The Location Configuration Information (LCI) includes
Latitude, Longitude, and Altitude, with resolution or uncertainty
indicators for each. Separate parameters indicate the reference
datum for each of these values.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-14.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Re: [Geopriv] [geopriv] rfc3825bis #40 (closed): GEN-Art Review

#40: GEN-Art Review

Changes (by bernard_aboba@…):

* status: new => closed
* resolution: => fixed

Comment:

Recommended resolution:

Change Section 2.2.1.2 to the following:

2.2.1.2. Server Version Selection

DHCPv6 servers implementing this specification MUST send
version 1 responses. A DHCPv4 server implementing this specification
MUST support sending version 1 responses and SHOULD support sending
version 0 responses. A DHCPv4 server that provides location
information cannot provide options with both version 0 and version 1
formats in the same response. This is not useful since receiving two
copies of the same Option (either in the same response or a separate
response) causes a DHCPv4 client to replace the information in the
old Option with the information in the new Option.

A DHCPv4 server uses configuration to determine which version to send
in a response. For example, where a mixture of version 0 and version
1 clients are expected, the DHCPv4 server could be configured to send
version 0 or version 1 depending on configuration (possibly making
the choice based on information such as the client MAC address).
Where few version 0 clients are expected, the DHCPv4 server could be
configured to send only version 1 responses. Version 0 options will
provide resolution, while version 1 options will provide an area of
uncertainty.

An RFC 3825 DHCPv4 client that receives a version 1 option
defined in this document will either reject the Option, or will not
understand the additions to the Datum field and will misinterpret the
LongUnc, LatUnc, and AltUnc values. If the RFC 3825 DHCPv4 client
does not reject the option and utilizes the location data it will
most likely assume a datum. Assuming one of the RFC 3825 datums
causes correct interpretation of Latitude/Longitude/Altitude values.
The values for LongUnc/LatUnc/AltUnc are mistakenly interpreted as
representing significant digits. The resultant location value will
be in error up to a full degree of latitude and longitude, and a full
increment of altitude.

This results in a version 0-only DHCPv4 client either not obtaining
location information (with no ability to indicate to the server that
version 1 was unsupported), or misinterpreting the option.
Therefore, if it is not known whether all DHCPv4 clients support
version 1,
and it is not possible for the DHCPv4 server to distinguish between
version 0
and version 1 DHCPv4 clients by some means, by default the DHCPv4
server
SHOULD send a version 0 response.

--
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner: bernard_aboba@…
Type: defect | Status: closed
Priority: minor | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
Severity: Submitted WG Document | Resolution: fixed
Keywords: |
---------------------------------------+------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/40#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] [geopriv] rfc3825bis #40 (new): GEN-Art Review

#40: GEN-Art Review

Document: draft-ietf-geopriv-rfc3825bis-12
Dynamic Host Configuration Protocol Options for
Coordinate-based Location Configuration Information
Reviewer: Joel M. Halpern
Review Date: 16-Oct-2010
IETF LC End Date: 2010-10-25
IESG Telechat date: N/A

Summary: This document is ready for publication as a Proposed Standard

Major issues:

Minor issues:
I wonder if the recommendation at the end of section 2.2.1.2
on Server Version Selection should be strengthened (and the v4 usage
weakened) a little. The text current says that when there are known
to be some v0-only DHCP v4 clients, the v0 should be sent. It seems to
me that unless it is known that all clients that use geolocation will
support
v1, then v0 should be sent. I do understand that this version problem
is difficult to resolve.

Nits/editorial comments:

--
---------------------------------------+------------------------------------
Reporter: bernard_aboba@… | Owner: bernard_aboba@…
Type: defect | Status: new
Priority: minor | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version: 1.0
Severity: Submitted WG Document | Keywords:
---------------------------------------+------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/40>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] geopriv-policy requirements

I'm concerned that we're trying to solve every possible fuzzing problem with geopriv-policy. Three that I remember off the top of my head:
A. Stationary targets
B. Moving targets
C. Patterns of motion (repeated visits averaged over time)

As earlier versions of geopriv-policy show, "class A" algorithms that only address the first can be pretty simple. As you try to address the other two, you end up with something like the most recent version of -policy or draft-thomson-geopriv-location-obscuring.

I would like to suggest that the base policy document doesn't need to address all of these problems. Advanced "class B/C" algorithms are clearly an active area for research and development, and the algorithm that the server applies is not a requirement for interoperability. The policy document format only describes the user's preferences; the server can reject policies or warn the user, but that's related to the policy *protocol* and the server's local policies.

A more concrete proposal:
1. Roll back the fuzzing algorithm to a simple "class A" algorithm
2. Document how this algorithm can fail in "class B/C" situations
3. Provide informative references to more advanced strategies, such as draft-thomson-geopriv-location-obscuring or a new draft with Jorge's algorithm.

Thoughts?

--Richard
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] RIPE 61: Reverse DNS and local service discovery

Hey all,

Thought you would be interested in a panel session that was held at RIPE 61 the week after IETF 79. The topic was reverse DNS for IPv6; I described some of the emerging requirements from GEOPRIV and ALTO, and some folks from the DNS community discussed some other requirements and ways of dealing with them in the DNS. Slides and transcripts here:
<http://ripe61.ripe.net/programme/meeting-plan/dns-agenda/>

I also gave a presentation in the RIPE Database working group discussing the addition of LIS URIs to the WHOIS database, which could be a better approach to the "third-party" LIS discovery problem than using the reverse DNS tree:
<http://ripe61.ripe.net/programme/meeting-plan/database-agenda/>
For those of you in the APNIC region, a colleague of mine gave a similar presentation at the last APNIC meeting:
<http://meetings.apnic.net/30/program/apops>
I don't think the WHOIS is a good solution to the "first party" LIS discovery problem, if only because the databases aren't really designed to handle the sort of load that would entail.

If you think the Geo-WHOIS stuff would be useful, please get in touch with me off-list. This is something that is continuing to develop, and I would be glad to have some collaborators.

--Richard
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Wednesday, November 17, 2010

[Geopriv] GEOPRIV Teleconference Interim Meeting, November 30, 2010

On Tuesday, November 30, 15:00-16:00 EDT, GEOPRIV will be having a
teleconference interim meeting on the topic of civic addressing
extensions. The full agenda will be announced shortly.

Dial-in information for this meeting will be posted to the GEOPRIV wiki
page at: http://trac.tools.ietf.org/wg/geopriv/trac/wiki
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

[Geopriv] Virtual interim

On Tuesday, November 30, 15:00-16:00 ET, GEOPRIV will be having a teleconference interim meeting on the topic of civic addressing extensions. The full agenda will be announced shortly.

Dial-in information for this meeting will be posted to the GEOPRIV wiki
page at: http://trac.tools.ietf.org/wg/geopriv/trac/wiki

Monday, November 15, 2010

Re: [Geopriv] Extending PIDF (-local-civic) - FYI on ISO activity.

There is an ISO TC 211 activity looking at addressing. Part of the activity
is a review of addressing standards. As you can see from the list below, the
work is quite international. I am an observer for this activity. Ram Kumar
(on the list) is the editor of the OASIS xAL (address encoding) standard.
xAL is the address encoding standard used in KML.

There are two primary activities that this group is involved in:

1. Investigate and formulate requirements in relation to addressing.
2. Make recommendations on whether standards should be developed and if so,
how this should be done.

Address standards review (see list under refinement of scope above)
according to identified requirements:
Goal is to prepare section 5 (see Table of Contents); the section is split
into three parts, i.e. three teams; review the list of standards for each
identified requirement; for example, identify the terminology in the
standards and compare it.
Team 1:
Requirements: Scope of the standard; terminology; classifications of
addresses (address types); identification of possible components of an
address; conceptual model (relationship between components)
Team leader: Rob Walker (UK)
Team members: Piotr Piotrowski (UPU), Patrick Dousseaud (FR), Boris Gutkin
(CA), Morten Lind (DK), Antony Cooper (ZA), Li Li (CN), Karen Owens (US),
Teruko Usui (JP), Koichi Hirata (JP), Hidenori Fujimara (JP), Arjen van
Zwieten (ZA), Serena Coetzee (ZA)

Team 2:
Requirements: Transfer and exchange of address data; address rendering
(print/write/display) of address data; multilingual addresses; managing
address aliases
Team leader: Piotr Piotrowski (UPU)
Team members: Boris Gutkin (CA), Joe Lubenow (UPU), Morten Lind (DK),
Pierre Rossouw (ZA), Ram Kumar (Australia), Serena Coetzee (ZA)

Team 3:
Requirements: Definitive address datasets (reference dataset); quality
management; life cycle; metadata for addresses
Team leader: Randy Fusaro (US)
Team members: Karen Owens (US), Boris Gutkin (CA), Antony Cooper (ZA), Li
Li (CN), Carsten Roensdorf (UK and Germany), Piotr Piotrowski (UPU), Marius
van der Merwe (ZA), Serena Coetzee (ZA)
So, two thoughts.

1. I can provide input from this WG into the ISO process.
2. Perhaps this group needs to consider the work being done in the ISO
activity. Much of the recent address discussion has been a bit US centric.

The ISO work involves not just the countires lists above but others as well.

Regards

Carl
OGC

----- Original Message -----
From: "Brian Rosen" <br@brianrosen.net>
To: "Marc Berryman" <mberryman@ddti.net>
Cc: <geopriv@ietf.org>
Sent: Monday, November 15, 2010 7:45 AM
Subject: Re: [Geopriv] Extending PIDF (-local-civic)

> Sure.
>
> You could also parse 100% of the U.S. addresses by having "Address Line 1"
> instead of all those pesky prefix/suffix/directional/... fields. But when
> you parse "A Avenue" into two elements, and "Avenue A" into one, something
> is wrong. Either the suffix is extraneous, or the prefix is needed.
> Mostly, this is English bias. If you looked at Spanish street names, you
> would have a bigger problem than with U.S. names. I believe the same is
> true of French street naming and several other languages.
>
> Brian
>
> On Nov 15, 2010, at 9:19 AM, Marc Berryman wrote:
>
>> Brian,
>> Re: However, I am unhappy about promising that we will never update the
>> schema for PIDF-LO or LoST. We are not that good. Mistakes have been
>> made.
>>
>> I have tested RFC 5139 on millions of street names across the US. I
>> challenge you or anyone to illustrate to me a single street name, or
>> complete street name, that I cannot parse into the street name elements
>> within RFC 5139.
>>
>> Your example of
>> <newns:extCAtype name="STP">Avenue</newns:extCAtype>
>> seems to me a fix to something that is not a problem.
>>
>> Granted there is a very small fraction of a single percent of house
>> numbers that I cannot parse into the namespace, but your example was
>> implying a "fix" was needed due to the street name elements.
>>
>> Marc B.
>>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of Brian Rosen
>> Sent: Thursday, November 11, 2010 7:47 PM
>> To: geopriv@ietf.org
>> Subject: [Geopriv] Extending PIDF (-local-civic)
>>
>> As I wait for the geopriv meeting to start, I wanted to summarize my
>> thoughts on extending PIDF (-local-civic).
>>
>> First of all, I agree that we need to do something. The current
>> mechanisms we have for extending are not adequate. The fundamental
>> problem is that to add a CAtype (or anything else), one needs to create a
>> new namespace, which effectively wipes out backwards compatibility.
>>
>> -local civic correctly points out that one can add a new namespace, and
>> define any new element in that namespace. It proposes to do that without
>> any constraint - anyone who wants to add an element would be free to
>> define a new namespace and create a new element. The issue several of us
>> have with that is that it will be very difficult to maintain
>> interoperability. Since the threshold to add new namespaces with
>> uncontrolled elements will be low, we would expect a great many such
>> namespaces, with all kinds of elements that may have a local name which
>> is very similar to another element in another namespace, but be
>> different, or alternatively have two (local) names for the same thing.
>> While this is not strictly speaking a problem, because of the uniqueness
>> of the namespace, it seems very hard to do something like create a parser
>> which could parse "Address Line 1" into a PIDF that would be likely to be
>> acceptable to a server.
>>
>> The basic idea that Martin and James want to push out is that 5139, which
>> added CAtypes and fixed some problems with 4119 contains the LAST
>> official IETF PIDF-LO namespace, and the schema is hereby considered
>> inviolate. Now, that's probably an overstatement, but they really do
>> want to lock down any further changes, and confine them to some new
>> namespace, and never change the schema in 5139.
>>
>> There is a compromise proposal on the table, which would work as follows:
>> We would create a new namespace in a new RFC. In that namespace, we
>> would define two new CAtypes: extCAtype and localExtCAtype. These
>> CAtypes would have a parameter "name". There would be two registries,
>> the existing CAtype registry created by 5139 and a new one. New entries
>> in the existing registry would be used with extCAtype as:
>> <newns:extCAtype name="STP">Avenue</newns:extCAtype>
>> The intention is that address elements with general use (like a street
>> type prefix) would be defined in the existing registry with the existing
>> management policy.
>>
>> Entries in the new registry would be used with localExtCAtype. The
>> management for the policy with localExtCAtype would be expert review,
>> with the instructions to seek to avoid clear duplication or spelling but
>> otherwise to be liberal in allowing new definitions. The registry ONLY
>> intends to foster re-use, not become a barrier to actual new address
>> elements. The option to define a new namespace would remain as is.
>>
>> There is a problem with validation of location information using LoST.
>> The proposal on the table is to extend the definition of the items in the
>> <valid>, <invalid> and <unchecked> lists to allow a name like
>> newns:extCAtype+STP (ie behave as if newns defined an element
>> extCAtype+STP.
>>
>> I am not thrilled with the LoST hack. I would prefer to actually fix the
>> problem, but I recognize that means updating the schema, and thus the
>> namespace for LoST, and we're back to the same issue. I can live with it
>> if that is the consensus of the work group.
>>
>> However, I am unhappy about promising that we will never update the
>> schema for PIDF-LO or LoST. We are not that good. Mistakes have been
>> made. New features will arise that won't be able to be done with new
>> namespaces. For example, I would like to change the part of the schema
>> that contains the CAtype elements from what is now SEQUENCE, because
>> SEQUENCE implies a fixed order, and there have been suggestions for
>> things where SEQUENCE is problematic (INT). Now, actually, if INT was
>> done with extCAtype, SEQUENCE would work, because there is only repeated
>> instances of extCAtype (and localExtCAtype), and they are in a different
>> namespace from the 5139 namespace, so just consider this an example. I
>> don't know what problems we will find, only that history suggests that
>> will happen.
>>
>> We should not make such promises. We may be able to avoid updating the
>> schema this time, we might not the next time.
>>
>> Brian
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Tuesday, November 30, 2010

Monday, November 29, 2010

Sunday, November 28, 2010

Saturday, November 27, 2010

Wednesday, November 17, 2010

Monday, November 15, 2010

Followers

Blog Archive

Contributors