Anything you want to do with 2a can be done with 2b, and 2b plays nicely with other things.
I think that for 2a to be a serious contender as an option there needs to be a strong case made for it and there needs to be a consistent way to over come the LoST interaction problem I described.
Cheers
James
James Winterbottom
Global Product Manager
Andrew GeoLENs
IP Location Product Portfolio
Email: james.winterbottom@andrew.com
Phone: +61-2-42-212938
Mobile: +61-447-773-560
> -----Original Message-----
> From: Richard L. Barnes [mailto:rbarnes@bbn.com]
> Sent: Wednesday, 27 October 2010 9:11 AM
> To: Brian Rosen
> Cc: Winterbottom, James; geopriv@ietf.org; Thomson, Martin
> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-winterbottom-
> geopriv-local-civic
>
> Ok, good, hope we're converging here. To tighten up the proposal a
> little:
>
> 1. An "official extension" namespace with a single element
> <ext:caElement type="thing">fnord</ext:caElement>
> Values for the 'type' attribute MUST be registered in the standard
> IANA registry. DHCP serialization via standard RFC 4776 use of CAtype
> numbers.
>
> 2.a. A "private extension" namespace with a single element
> <priv:caElement type="other-thing">fnord</priv:caElement>
> (This could actually be done in the same namespace as the "official"
> one). Values for the 'type' attribute SHOULD be registered in a new
> FCFS registry and MUST NOT be in the "official CAType" registry.
> DHCP serialization via a new civic address element
> +-------------+----------+--------+---------+
> | CAType=PRIV | CALength | CAName | CAValue |
> +-------------+----------+--------+---------+
>
> 2.b. A template for private extensions recommending that they have the
> same "list of elements" structure
> <priv:XYZ>fnord</priv:XYZ>
> (Type values == element names are unconstrained.) DHCP serialization
> via a new civic address element
> +-------------+----------+-------------+--------+---------+
> | CAType=PRIV | CALength | CANamespace | CAName | CAValue |
> +-------------+----------+-------------+--------+---------+
>
>
>
>
>
> On Oct 26, 2010, at 5:55 PM, Brian Rosen wrote:
>
> > Agree on both points
> >
> > We could do something gross like have a FCFS registry for local
> > CAtypes whose only purpose really is to allow extCAtype to be used
> > in DHCP and other similar mechanisms, but I think a private
> > namespace is a cleaner approach.
> >
> > Brian
> > On Oct 26, 2010, at 5:36 PM, Richard L. Barnes wrote:
> >
> >> Another wrinkle, just to make sure there's common understanding:
> >> This approach does *not* prevent people from adding "private"
> >> extension elements from other namespaces. It just provides a more
> >> extensible way forward for "official" CAtypes.
> >>
> >> It also kind of disclaims any responsibility for what the private
> >> extensions should look like. I think it might be nice to at least
> >> make some recommendations about that, e.g., suggesting a CAtype-
> >> like type/value list or saying something about DHCP serialization.
> >> (Note, though, that this path kind of leads back toward the -local-
> >> civic DHCP concepts.)
> >>
> >> --Richard
> >>
> >>
> >>
> >> On Oct 26, 2010, at 4:23 PM, Brian Rosen wrote:
> >>
> >>> The better part of valor would be to say that we define extCAtype
> >>> in a new namespace and preserve backwards compatibility.
> >>>
> >>> I actually think there are so few deployments that we could redo
> >>> the schema with a new namespace, which would make it much cleaner
> >>> for the 99.9999% of implementations that come after the handful
> >>> that are around now. You are forcing two namespaces where one
> >>> will do for a very small deployment upgrade.
> >>>
> >>> But I'll go with WG consensus on that. The important parts to me
> >>> are:
> >>> a) Controlled expansion of the CAtypes registry
> >>> b) Common use CAtypes are always named, defined, and used
> >>> consistently
> >>> c) Limited (1 or 2) namespaces for any global address, with
> >>> possible per country tweaks as in 5774
> >>> d) Only one way to encode an extension (from here on in) CAtype,
> >>> not 3.
> >>>
> >>> If I might add a bit of a wrinkle:
> >>> I'd like to add two generic parameters to extCAtype, so that a new
> >>> CAtype could be defined that used them.
> >>> One example of that would be the INT (which had parameters), but
> >>> there are others.
> >>>
> >>> Brian
> >>>
> >>> On Oct 26, 2010, at 3:40 PM, Richard L. Barnes wrote:
> >>>
> >>>> The appropriate question would seem to be in what namespace this
> >>>> <extCAtype> element lives. If it's in a new namespace, then
> >>>> there's no break in backward compatibility. Also, there would be
> >>>> no need to change LoST, since the LoST civic profile is defined
> >>>> by reference to RFC 5139, which accommodates additional namespaces.
> >>>>
> >>>> --Richard
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Oct 26, 2010, at 10:46 AM, Brian Rosen wrote:
> >>>>
> >>>>> If you would please concentrate on what I proposed, we could
> >>>>> perhaps make some more rapid progress.
> >>>>>
> >>>>> I proposed having ONE new element = extensionCAtype, which very
> >>>>> similar to one part of your proposal.
> >>>>> <extCAtype "CAname="STP">Avenue</extCAtype>
> >>>>>
> >>>>> Endpoints have one (or maybe two) namespaces. We don't have to
> >>>>> mint new ones for any new extensions.
> >>>>>
> >>>>> LoST does need to change, once, but not again, although it's
> >>>>> backwards compatible with the current extension point. The only
> >>>>> reason it needs to change is that there are parameters to
> >>>>> extCAtype. I think your proposal has the same issue.
> >>>>>
> >>>>> Endpoints support ONE (or maybe 2) schema(s). If they don't
> >>>>> understand any given CAtype, they can pass it, or ignore it.
> >>>>>
> >>>>> There is ONE way to express any new CA, extCAtype.
> >>>>>
> >>>>> Brian
> >>>>>
> >>>>>
> >>>>> On Oct 25, 2010, at 10:29 PM, Winterbottom, James wrote:
> >>>>>
> >>>>>> I am sorry, but I don't see any rational argument for not
> >>>>>> including just the new elements into a new namespace beyond "oh
> >>>>>> I don't want to have multiple namespace declarations".
> >>>>>>
> >>>>>> Brian, the impacts we are talking about if we continue with
> >>>>>> your approach are:
> >>>>>> 1)No end-point can be sure what namespace received CATypes
> >>>>>> should be put in to ensure they are understood.
> >>>>>> 2) LoST will need to change to support another Civic profile
> >>>>>> 3) All end-points will now need to support multiple civic
> >>>>>> schemas since they cannot be sure which one they will be given
> >>>>>>
> >>>>>> And these just what I can think of without spending any time on
> >>>>>> the problem, yet all this work will need to be done because
> >>>>>> somebody doesn't want to see extra namespace declarations. I am
> >>>>>> sorry but I don't think that this is reasonable, and it leaves
> >>>>>> problems that I don't believe can be solved, without
> >>>>>> significant work by vendors.
> >>>>>>
> >>>>>> Cheers
> >>>>>> James
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> James Winterbottom
> >>>>>> Global Product Manager
> >>>>>> Andrew GeoLENs
> >>>>>> IP Location Product Portfolio
> >>>>>> Email: james.winterbottom@andrew.com
> >>>>>> Phone: +61-2-42-212938
> >>>>>> Mobile: +61-447-773-560
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: geopriv-bounces@ietf.org [mailto:geopriv-
> >>>>>>> bounces@ietf.org] On Behalf
> >>>>>>> Of Brian Rosen
> >>>>>>> Sent: Tuesday, 26 October 2010 11:04 AM
> >>>>>>> To: Thomson, Martin
> >>>>>>> Cc: geopriv@ietf.org
> >>>>>>> Subject: Re: [Geopriv] draft-ietf-geopriv-prefix-00 & draft-
> >>>>>>> winterbottom-
> >>>>>>> geopriv-local-civic
> >>>>>>>
> >>>>>>> While I am happy to hear that deployments of 5139 exist, we
> >>>>>>> live in a
> >>>>>>> world were it's upgrade or die.
> >>>>>>>
> >>>>>>> Nevertheless, as I said, I would like a better way.
> >>>>>>>
> >>>>>>> I agree that people will extend. I am not advocating
> >>>>>>> eliminating the
> >>>>>>> possibility of a "private" namespace. However, I believe it is
> >>>>>>> appropriate that IETF control "official" extensions that have
> >>>>>>> broad
> >>>>>>> applicability. Prefix is one such extension. "relative-
> >>>>>>> location" is
> >>>>>>> another. Adding new "official" CAtypes should be possible,
> >>>>>>> with
> >>>>>>> appropriate review.
> >>>>>>>
> >>>>>>> I understand that to correctly parse an address into fields,
> >>>>>>> or to render
> >>>>>>> fields into human readable text, requires a per-country
> >>>>>>> document, which
> >>>>>>> means per-country code. It's unavoidable. However, we saw
> >>>>>>> value in
> >>>>>>> creating a list of common elements that many countries used in
> >>>>>>> their
> >>>>>>> addresses. I believe that remains a value, and it would be most
> >>>>>>> unfortunate to have "Street Prefix" in one and
> >>>>>>> "ThoroughfareType-Pre" in
> >>>>>>> another that was exactly the same thing, used the same way as
> >>>>>>> "STS" but
> >>>>>>> before the street name. That is the value in having a formal
> >>>>>>> extension
> >>>>>>> path for CAtypes.
> >>>>>>>
> >>>>>>> If we agree on that, then we need a way to create the XML. I
> >>>>>>> really
> >>>>>>> dislike 3 ways to do the same thing. Having a generic
> >>>>>>> extension gives us
> >>>>>>> one way to have an extended CAtype, rather than 3. It avoids
> >>>>>>> adding a
> >>>>>>> slew of namespaces. It continues the use of the CAtype
> >>>>>>> registry, with its
> >>>>>>> current policy for adding CAtypes. Given the example in 5774,
> >>>>>>> that's
> >>>>>>> really all we need.
> >>>>>>>
> >>>>>>> Private extensions can use their own namespace, as they can now.
> >>>>>>>
> >>>>>>> Brian
> >>>>>>>
> >>>>>>> On Oct 25, 2010, at 7:10 PM, Thomson, Martin wrote:
> >>>>>>>
> >>>>>>>> Hi Brian,
> >>>>>>>>
> >>>>>>>> I agree with Hannes. Backwards compatibility is more
> >>>>>>>> important than you
> >>>>>>> seem to think.
> >>>>>>>>
> >>>>>>>> On 2010-10-26 at 01:46:17, Brian Rosen wrote:
> >>>>>>>>> Is there really a good reason why 5139 can create a new
> >>>>>>>>> namespace that
> >>>>>>>>> effectively obsoletes the one in 4119, but -prefix cannot?
> >>>>>>>>
> >>>>>>>> Yes, there are two very good reasons.
> >>>>>>>>
> >>>>>>>> Use: Actual use of 4119 was rare to non-existent. 5139 is in
> >>>>>>>> use.
> >>>>>>>>
> >>>>>>>> Language: There was no allowance for language tags in 4119 -
> >>>>>>>> something
> >>>>>>> that I'm sure you'll agree is handy. Adding language tags in
> >>>>>>> any other
> >>>>>>> way would have been extremely difficult.
> >>>>>>>>
> >>>>>>>>> It has always been possible to add a namespace and add
> >>>>>>>>> elements to a
> >>>>>>>>> PIDF. The obvious problem is that anyone could declare such a
> >>>>>>>>> namespace, and then expect the rest of the world to generate
> >>>>>>>>> PIDFs with
> >>>>>>>>> their namespace. This leads to non-interoperability, a
> >>>>>>>>> point made in
> >>>>>>>>> the comments on earlier versions of -local-civic.
> >>>>>>>>
> >>>>>>>> There's a definite parallel on the apps-discuss list regarding
> >>>>>>> extensions in the discussions on X-. The basic rule is that
> >>>>>>> people will
> >>>>>>> extend. When they do so, they don't necessarily seek
> >>>>>>> interoperability.
> >>>>>>> That comes later as the extension is seen to be useful.
> >>>>>>>>
> >>>>>>>> We need to provide a path toward interoperability. -local-
> >>>>>>>> civic
> >>>>>>> describes how that works. "Interoperability or bust" is not a
> >>>>>>> sentiment
> >>>>>>> that I would like to have conveyed.
> >>>>>>>>
> >>>>>>>>> The current accepted IETF practice in this kind of
> >>>>>>>>> situation is to in fact issue a new namespace, which we all
> >>>>>>>>> agree is
> >>>>>>>>> not very good.
> >>>>>>>>
> >>>>>>>> [citation required]
> >>>>>>>>
> >>>>>>>> Extensions go in new namespaces: yes. Extensions replace the
> >>>>>>>> original
> >>>>>>> namespace: not from what I've seen.
> >>>>>>>>
> >>>>>>>> I'm not sure if I think this is very good or not. It's just
> >>>>>>>> how things
> >>>>>>> are: a trade-off between competing considerations.
> >>>>>>>>
> >>>>>>>>> I think we will discover, from time to time, that new
> >>>>>>>>> CAtypes, which
> >>>>>>>>> have relatively broad applicability, are needed. What we're
> >>>>>>>>> searching
> >>>>>>>>> for is a way to add them without breaking backwards
> >>>>>>>>> compatibility.
> >>>>>>>>
> >>>>>>>> Precisely. This is why my mind boggles when you recommend
> >>>>>>>> that we break
> >>>>>>> backward compatibility.
> >>>>>>>>
> >>>>>>>> --Martin
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> 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
