[19:59:45] 8f1e03df0b83e4de joins the room [20:00:02] 8f1e03df0b83e4de has set the subject to: GEOPRIV Interim Meeting, November 30, 2010 [20:01:15] <8f1e03df0b83e4de> Chair Slides [20:01:22] Marc Linsner joins the room [20:02:29] <8f1e03df0b83e4de> Alissa: Will talk about Civic Addressing Extensions. (Presents Note Well). [20:03:29] <8f1e03df0b83e4de> Agenda: Intro/admin, Overview of the problem, Appproach of draft-ietf-geopriv-prefix, Approach of draft-winterbottom-local-civic, 40 minutes for discussion. [20:03:56] <8f1e03df0b83e4de> Brian not present at the moment, will switch agenda slots with J. Winterbottom [20:04:12] <8f1e03df0b83e4de> Richard Barnes slides on Civic Address Extensibility [20:04:30] <8f1e03df0b83e4de> Goal is to get consensus on the problem to solve and introduce solutions and have some discussions. [20:06:25] <8f1e03df0b83e4de> 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... [20:08:01] <8f1e03df0b83e4de> Need to maintain parity in DHCP encoding.... [20:08:24] <8f1e03df0b83e4de> Keith Drage: Schema update should stay on the agenda.... [20:08:43] <8f1e03df0b83e4de> Richard: Don't mean to formally preclude anything.... [20:09:57] <8f1e03df0b83e4de> Keith Drage: Could have a schema for A and a schema for B, rather than A+B.... [20:10:11] <8f1e03df0b83e4de> Richard: That is roughly what James is going to propose. [20:10:24] <8f1e03df0b83e4de> Richard: Another challenge is to remain parity with DHCP representation of addresses. [20:11:58] <8f1e03df0b83e4de> 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.... [20:13:07] <8f1e03df0b83e4de> Richard: Turning it over to James.... [20:13:39] <8f1e03df0b83e4de> James: Local Civic (A wa to extend RFC 5139 civic elements) [20:15:25] <8f1e03df0b83e4de> 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). [20:16:55] <8f1e03df0b83e4de> 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. [20:18:34] <8f1e03df0b83e4de> James: Standard CAtype extensions Define a new namespace...registry of CAtypes defined by RFC 4776... [20:19:12] <8f1e03df0b83e4de> James: If you don't need a registered CAtype... put it in your own namespace! [20:20:14] <8f1e03df0b83e4de> James: Apps that understand it can use it, apps that don't understand it, don't have to worry about it. [20:22:41] <8f1e03df0b83e4de> 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... [20:23:15] <8f1e03df0b83e4de> Martin: DHCP can carry the CAtype extensions.... [20:23:38] <8f1e03df0b83e4de> Mark Linsner: How would you define local civic extensions? Is country local, or enterprise? Government entity? [20:23:53] <8f1e03df0b83e4de> James: Could be done in IETF as an RFC, but they don't have to.... [20:24:01] <8f1e03df0b83e4de> Martin: Depends on how much interoperability you're looking for.... [20:24:57] <8f1e03df0b83e4de> 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.... [20:25:21] <8f1e03df0b83e4de> Martin: Good question.... but equally applicable to new CATypes not in RFC 5139.... [20:26:11] <8f1e03df0b83e4de> 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. [20:27:10] <8f1e03df0b83e4de> Richard: If DHCP extension mechanism isn't understood at all, there could be a problem... could be an argument for a single CAtype.... [20:27:30] <8f1e03df0b83e4de> Richard: Seems like this document takes different approaches for official and private extensions. Why? [20:29:01] <8f1e03df0b83e4de> James: Element type name is not constrained once you move into local stuff... so that was the rationale. [20:29:19] <8f1e03df0b83e4de> Martin: No way to let a local extension use anything in DHCP.... can't get new CAtype.... [20:29:28] <8f1e03df0b83e4de> James: Do you need to? What is the justification? [20:29:43] <8f1e03df0b83e4de> Marc Linsner: Enterprises do use DHCP... [20:30:02] <8f1e03df0b83e4de> Marc Linsner: 802.11 is using equivalent of DHCP.... [20:30:23] <8f1e03df0b83e4de> Marc: They would use a CAtype number (e.g. 244) and would map that to their own namespace. [20:31:07] <8f1e03df0b83e4de> 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.... [20:31:21] <8f1e03df0b83e4de> Marc Linsner: Would need to map out what CAtypes you're talking about, no? [20:31:54] <8f1e03df0b83e4de> 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? [20:32:24] <8f1e03df0b83e4de> James: to come up with a general extensibility mechanism... and not break RFC 5139. [20:33:01] <8f1e03df0b83e4de> Richard: LoST service boundary not an issue of this particular extensibility mechanism... it's an issue with any mechanism. [20:36:05] <8f1e03df0b83e4de> 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.... [20:36:33] <8f1e03df0b83e4de> 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.... [20:37:21] <8f1e03df0b83e4de> Alyssa: Keith's point has been noted.... we have Brian Rosen on the line and will switch over to him. [20:38:49] <8f1e03df0b83e4de> 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.... [20:38:54] <8f1e03df0b83e4de> James: Who is we? [20:39:29] <8f1e03df0b83e4de> 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... [20:39:51] <8f1e03df0b83e4de> James: An enterprise wants to locate areas in a building using their own method would be forbidden... [20:40:11] <8f1e03df0b83e4de> Brian: Just saying there should be a standard way to use a given locator... and everyone should use that same way. [20:40:40] <8f1e03df0b83e4de> 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? [20:40:46] <8f1e03df0b83e4de> Brian Rosen: I agree with that.... [20:41:28] <8f1e03df0b83e4de> 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... [20:41:45] <8f1e03df0b83e4de> Richard: Proposal is to have it in an extension element with type=bridge. Is this a difference only of syntax? [20:41:53] <8f1e03df0b83e4de> Brian: First question is, is there a registry? [20:42:10] <8f1e03df0b83e4de> James: Have a registry in RFC 4667... can write a spec for it, get a CAtype, we have an extension type for that.... [20:42:49] <8f1e03df0b83e4de> 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... [20:43:14] <8f1e03df0b83e4de> Brian Rosen: We're agreeing that you are always able to create a local namespace... not arguing against that... the existing mechanism stays there.... [20:43:26] <8f1e03df0b83e4de> James: Are you happy with the way we do local civic so you can transport DHCP? [20:43:41] <8f1e03df0b83e4de> Brian Rosen: If that was the only answer, I'd be ok..... [20:43:53] <8f1e03df0b83e4de> James: Are CAtype extensions ok? [20:44:10] <8f1e03df0b83e4de> Brian Rosen: Having an explosion of name spaces generates syntactic cruft with no real value.... [20:44:50] <8f1e03df0b83e4de> Brian Rosen: Does every new one have its own namespace? [20:45:01] <8f1e03df0b83e4de> James: One extension name space for standard CAtypes.... [20:46:26] <8f1e03df0b83e4de> 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.... [20:46:58] <8f1e03df0b83e4de> James: My thoughts are that the organization that looks after those apps should be the custodian of that bit of namespace... could be NENA.... [20:47:07] <8f1e03df0b83e4de> James: IETF doesn't need to have a registry... [20:47:27] <8f1e03df0b83e4de> Richard: Other protocols have registries for vendor unique IDs.... different organizations have registered namespaces.... [20:48:24] <8f1e03df0b83e4de> Brian Rosen: you could, but...lots of big orgs have these things called mailstops... will we ever have a global CA type called "mailstop"? [20:48:41] <8f1e03df0b83e4de> James: No, no, no... they are all unique within a namespace, not transferrable.... [20:49:01] <8f1e03df0b83e4de> Brian Rosen: don't want uniqueness, just interoperability.... [20:49:30] <8f1e03df0b83e4de> Martin: In apps area, have provisional registration... not necessarily looking for standardization... [20:49:45] <8f1e03df0b83e4de> Brian: Want first come, first served registry.... [20:49:54] <8f1e03df0b83e4de> James: would you give those people a CAtype? [20:50:23] <8f1e03df0b83e4de> Brian: maybe you give them a number.... [20:50:34] <8f1e03df0b83e4de> James: don't think we have lots of numbers (only 255). [20:50:49] <8f1e03df0b83e4de> Marc Linsner: Using 123, 124 schema would still make it unique, right? [20:51:05] <8f1e03df0b83e4de> James: What are we registering? Provisionally register entire schemas or just name spaces? [20:52:27] <8f1e03df0b83e4de> James: not sure I like provisional aspect.... [20:52:54] <8f1e03df0b83e4de> Brian: If people have the same use, would be useful to have interop... not two variations of the same thing. [20:53:31] <8f1e03df0b83e4de> Brian Rosen: to promote reuse you want the registry to have a low threshold.... [20:54:42] <8f1e03df0b83e4de> 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? [20:54:53] <8f1e03df0b83e4de> Brian Rosen: It's only additive.... you never take something away. [20:54:59] <8f1e03df0b83e4de> James: Not in favor of that.... [20:55:27] <8f1e03df0b83e4de> James: don't want willy-nully attributes that are devoid of namespace.... [20:55:59] <8f1e03df0b83e4de> 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.... [20:56:19] <8f1e03df0b83e4de> Richard: Three questions: First one is: should this WG be doing anything at all about civic address extensibility? [20:56:47] <8f1e03df0b83e4de> Second: Should we create a single extension element so that we don't have to extend the XML? [20:56:53] <8f1e03df0b83e4de> James: can you elaborate? [20:57:11] <8f1e03df0b83e4de> Richard: Should we create a single extension element that can express global extension elements? [20:57:22] <8f1e03df0b83e4de> Third: should we create recommendations for how to create private/local extensions? [20:57:43] <8f1e03df0b83e4de> James: Need to go one step further with last question.... need to define a mechanism that would also allow those private extensions.... [20:58:00] <8f1e03df0b83e4de> Richard: in principle we have a mechanism... can throw junk in at the end of the schema... [20:58:05] <8f1e03df0b83e4de> James: Doesn't work for DHCP.... [20:58:29] <8f1e03df0b83e4de> Richard: maybe the proper thing is to enable private/local extensions, create recommendations for what they look like... point taken. [20:58:36] <8f1e03df0b83e4de> Richard: other comments on those questions? [20:59:15] <8f1e03df0b83e4de> 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? [20:59:30] <8f1e03df0b83e4de> Richard: Meeting adjourned (1 PM Pacific, 4 PM EST). [21:28:18] Marc Linsner leaves the room [22:27:44] 8f1e03df0b83e4de leaves the room