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
