Minutes for GEOPRIV at IETF-interim-2010-geopriv-1
minutes-interim-2010-geopriv-1-00

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.
[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).