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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 30 Nov 2010 23:02:14 +0200

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.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 Nov 2010 13:11:44 -0800

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: [email-masked]
> Date: Tue, 30 Nov 2010 23:02:14 +0200
> To: [email-masked]
> CC: [email-masked]
> Subject: [Geopriv] My Meeting Notes for the Virtual GEOPRIV Interim Meeting	(Nov. 30)
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv