Subject: Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's DISCUSS

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Dec 2010 10:26:36 -0500

Please don't think that by saying "0" is the ground floor that you have made things definitive and interoperable.

There are plenty of buildings that are constructed into a sloped site, such that it is not at all clear which floor is "ground".

By having a numbering system that doesn't match anything else (signage, plans, local knowledge, etc), you pretty much guarantee that no one can actually use it.

I know that fire brigades often designate their main entrance floor 0 or 1, and count (up/down) from there, but they create a reference that everyone understands, and they train their people to use their convention. 

Absent a very detailed plan, and a way to know for sure which floor is "ground", you create a hard to use mechanism that can have ambiguity.

Brian

On Dec 1, 2010, at 12:20 AM, Richard L. Barnes wrote:

> Actually, while we're on this, there's another contradiction lurking here:
> 
> On the one hand, the option definitions say:
> "Altitude:  A 30 bit value defined by the AType field."
> One might read this to mean that the AType value can specify the meaning of all the bits in the field.  So if I define AType=7, I could say that the the 30 bits contain a 3-character ASCII code describing the color of the carpet on the floor in question (with each character padded to 10 bits, natch).  More to the point, for AType=2 (==floors), you might split the field into two integers, one signed and one unsigned, that represent "major" and "minor" floor numbers.  That way, you could actually directly represent 1.1, 4.1, 4.2. 
> 
> On the other hand, Section 2.4 defines the Altitude field as 22/8 fixed point regardless of the AType value -- it's only the semantic of this number that changes.  This rules out all of the creative encodings described above, at the cost of forcing everything into a 22/8 fixed-point mold.  
> 
> I'll leave it to the author to decide which of these to go with (I don't think it really matters much).  If it's the former, then the 22/8 fixed point thing should be moved down into the subsections of 2.4.  If the latter, then it should be moved up to the option definitions, as with the Latitude and Longitude fields.
> 
> --Richard
> 
> 
> 
> On Nov 30, 2010, at 10:46 PM, geopriv issue tracker wrote:
> 
>> #41: David Harrington's DISCUSS
>> 
>> 
>> Comment(by bernard_aboba@…):
>> 
>> [James Polk]
>> 
>>    #41: David Harrington's DISCUSS Comment(by bernard_aboba at ?):
>> Proposed Resolution: In 2.2.1.2, s/same respoonse. This is not useful
>> since/same response, since/ Replace Section 2.4.3 with the following:
>> 
>>    A value of two for Altitude Type indicates that the Altitude value is
>>    measured in floors.  This value is relevant only in relation to a
>>    building; the value is relative to the ground level of the building.
>> 
>>    In this definition, numbering starts at ground level, which is floor
>>    0 regardless of local convention. Floors located below ground level
>>    could be represented by negative values.
>> 
>> I recommend a change to be definitive here with
>> s/could be/are
>> 
>> 
>>    Larger values represent floors
>>    that are above (higher in altitude) floors with lower values.
>> 
>> This sentence is written in one direction; i.e., up.
>> 
>> I recommend
>>  "Larger values represent floors that are farther away from floor 0
>>   such that -
>> 
>>   - if positive, the floor value is farther above the ground floor.
>> 
>>   - if negative, the floor value is farther below the ground floor."
>> 
>> 
>>    Non-integer values can be used to represent intermediate or sub-
>>    floors, such as mezzanine levels.  Example: a
>>    mezzanine between floor 1 and floor 2 could be represented as a value
>>    = 1.1.  Example: (2) mezzanines between floor 4 and floor 5 could be
>>    represented as values = 4.1 and 4.2 respectively.
>> 
>> I'm fine with the rest as written.
>> 
>> James
>> 
>> [Bernard Aboba]
>> 
>> Here is a revised proposal for the text of Section 2.4.3:
>> 
>> 2.4.3.  Altitude in Floors (AType = 2)
>> 
>>   A value of two for Altitude Type indicates that the Altitude value is
>>   measured in floors.  Since altitude in meters may not be known within
>>   a building, a floor indication may be more useful.  This value is
>>   relevant only in relation to a building; the value is relative to the
>>   ground level of the building.
>> 
>>   Numbering starts at ground level, which is floor 0 regardless of
>>   local convention.  Floors located below ground level are represented
>>   by negative values.  Larger values represent floors that are farther
>>   away from floor 0 such that:
>> 
>>      - if positive, the floor value is farther above the ground floor.
>>      - if negative, the floor value is farther below the ground floor.
>> 
>>   Non-integer values can be used to represent intermediate or sub-
>>   floors, such as mezzanine levels.  Example: a mezzanine between floor
>>   1 and floor 2 could be represented as a value of 1.1.  Example:
>>   mezzanines between floor 4 and floor 5 could be represented as values
>>   of 4.1 and 4.2.
>> 
>> -- 
>> ---------------------------------------+------------------------------------
>> Reporter:  bernard_aboba@…            |       Owner:  bernard_aboba@…           
>>    Type:  defect                     |      Status:  new                       
>> Priority:  major                      |   Milestone:  draft-ietf-geopriv-3825bis
>> Component:  rfc3825bis                 |     Version:  1.0                       
>> Severity:  Submitted WG Document      |    Keywords:                            
>> ---------------------------------------+------------------------------------
>> 
>> Ticket URL: <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:3>
>> geopriv <http://tools.ietf.org/geopriv/>
>> 
>> _______________________________________________
>> Geopriv mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/geopriv
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 1 Dec 2010 09:23:04 -0800

Agreed.  

On the campus where I work, there is a building built into a slope whose back entrance is on one level, and whose front entrance (the one with the receptionist) is on another (higher) floor. 

In such a building, it's not obvious whether "0" would be used for the back entrance, or "-1", or whether the front entrance would be "0" or "+1". 

Is there any text we can add that might make this more clear? 

> From: [email-masked]
> Date: Wed, 1 Dec 2010 10:26:36 -0500
> To: [email-masked]
> CC: [email-masked]; [email-masked]
> Subject: Re: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's	DISCUSS
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Dec 2010 13:30:22 -0500

The only thing that works is to use the local signage convention.

If you have a plan, in a standardized form, which we don't, but if you did, then you could use the notation on the plan.

Say that and it works.

Brian

---

From: [email-masked]
Date: Wed, 1 Dec 2010 16:17:21 -0500 (EST)

Very true! I have seen - in different countries - where G, M, 0, or 1 is
the ground floor.

Carl

> Please don't think that by saying "0" is the ground floor that you have
> made things definitive and interoperable.
>
> There are plenty of buildings that are constructed into a sloped site,
> such that it is not at all clear which floor is "ground".
>
> By having a numbering system that doesn't match anything else (signage,
> plans, local knowledge, etc), you pretty much guarantee that no one can
> actually use it.
>
> I know that fire brigades often designate their main entrance floor 0 or
> 1, and count (up/down) from there, but they create a reference that
> everyone understands, and they train their people to use their convention.
>
> Absent a very detailed plan, and a way to know for sure which floor is
> "ground", you create a hard to use mechanism that can have ambiguity.
>
> Brian
>
>
>> One might read this to mean that the AType value can specify the meaning
>> of all the bits in the field.  So if I define AType=7, I could say that
>> the the 30 bits contain a 3-character ASCII code describing the color of
>> the carpet on the floor in question (with each character padded to 10
>> bits, natch).  More to the point, for AType=2 (==floors), you might
>> split the field into two integers, one signed and one unsigned, that
>> represent "major" and "minor" floor numbers.  That way, you could
>> actually directly represent 1.1, 4.1, 4.2.
>>
>> On the other hand, Section 2.4 defines the Altitude field as 22/8 fixed
>> point regardless of the AType value -- it's only the semantic of this
>> number that changes.  This rules out all of the creative encodings
>> described above, at the cost of forcing everything into a 22/8
>> fixed-point mold.
>>
>> I'll leave it to the author to decide which of these to go with (I don't
>> think it really matters much).  If it's the former, then the 22/8 fixed
>> point thing should be moved down into the subsections of 2.4.  If the
>> latter, then it should be moved up to the option definitions, as with
>> the Latitude and Longitude fields.
>>
>> --Richard
>>
>>
>>
>>> Ticket URL:
>>> <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:3>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Dec 2010 05:47:47 +0800

This is all true.  It derives from the fact that floor numbering is entirely nominal.

The absence of a floor 13 and presence of mezzanines are just a few of the problems you might encounter.  In some buildings, floors aren't numbered at all.

But this doesn't really help the issue at hand.  3825 defined a way to convey floor numbers, ill-conceived or not.  We need to decide what to do about that.  As with any other aspect of protocol, we can say ground is 0, but we should also highlight the shortcomings of this convention and state that local conventions dictate what is ground.

After all - it's local context that establishes what "ground" is anyway.  I've been places where even that concept is fuzzy.  It's the coward's way out.  The alternative would be to say that altitude in floors is a bad idea, but we've been over that discussion before.

If you need a text-patch for the problem, here's my suggestion.

    In some buildings it might not be clear which floor is at ground level
    or an intermediate floor might be hard to identify as such.  Determining
    what floor is at ground level and what constitutes a sub-floor as
    opposed to an naturally numbered floor is left to local interpretation.

On 2010-12-02 at 05:30:22, Brian Rosen wrote:
> If you have a plan, in a standardized form, which we don't, but if you
> did, then you could use the notation on the plan.
> 
> Say that and it works.
> 
> Brian
> 
> 	On the campus where I work, there is a building built into a
> slope whose back entrance is on one level, and whose front entrance
> (the
> one with the receptionist) is on another (higher) floor.
> 
> 	In such a building, it's not obvious whether "0" would be used
> for the back entrance, or "-1", or whether the front entrance would be
> "0" or "+1".
> 
> 	> Please don't think that by saying "0" is the ground floor that
> you have made things definitive and interoperable.
> 	>
> 	> There are plenty of buildings that are constructed into a
> sloped site, such that it is not at all clear which floor is "ground".
> 	>
> 	> By having a numbering system that doesn't match anything else
> (signage, plans, local knowledge, etc), you pretty much guarantee that
> no one can actually use it.
> 	>
> 	> I know that fire brigades often designate their main entrance
> floor 0 or 1, and count (up/down) from there, but they create a
> reference that everyone understands, and they train their people to use
> their convention.
> 	>
> 	> Absent a very detailed plan, and a way to know for sure which
> floor is "ground", you create a hard to use mechanism that can have
> ambiguity.
> 	>
> 	> Brian
> 	>
> 	>
> 	> > One might read this to mean that the AType value can specify
> the meaning of all the bits in the field. So if I define AType=7, I
> could say that the the 30 bits contain a 3-character ASCII code
> describing the color of the carpet on the floor in question (with each
> character padded to 10 bits, natch). More to the point, for AType=2
> (==floors), you might split the field into two integers, one signed and
> one unsigned, that represent "major" and "minor" floor numbers. That
> way, you could actually directly represent 1.1, 4.1, 4.2.
> 	> >
> 	> > On the other hand, Section 2.4 defines the Altitude field as
> 22/8 fixed point regardless of the AType value -- it's only the
> semantic
> of this number that changes. This rules out all of the creative
> encodings described above, at the cost of forcing everything into a
> 22/8
> fixed-point mold.
> 	> >
> 	> > I'll leave it to the author to decide which of these to go
> with (I don't think it really matters much). If it's the former, then
> the 22/8 fixed point thing should be moved down into the subsections of
> 2.4. If the latter, then it should be moved up to the option
> definitions, as with the Latitude and Longitude fields.
> 	> >
> 	> > --Richard
> 	> >
> 	> >
> 	> >
> ---------------------------------------+-------------------------------
> -
> ----
> ---------------------------------------+-------------------------------
> -
> ----
> 	> >>
> 	> >> Ticket URL:

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 1 Dec 2010 16:48:51 -0800

Here's the revised text for Section 2.4.3:

   A value of two for Altitude Type indicates that the Altitude value is
   measured in floors.  Since altitude in meters may not be known within
   a building, a floor indication may be more useful.  For AType = 2,
   the Altitude value is expressed as a 30 bit, fixed point, twos
   complement integer with 22 integer bits and 8 fractional bits.

   This value is relevant only in relation to a building; the value is
   relative to the ground level of the building.  Floors located below
   ground level are represented by negative values.  In some buildings
   it might not be clear which floor is at ground level or an
   intermediate floor might be hard to identify as such.  Determining
   what floor is at ground level and what constitutes a sub-floor as
   opposed to an naturally numbered floor is left to local
   interpretation.

   Larger values represent floors that are farther away from floor 0
   such that:

   Non-integer values can be used to represent intermediate or sub-
   floors, such as mezzanine levels.  Example: a mezzanine between floor
   1 and floor 2 could be represented as a value of 1.25.  Example:
   mezzanines between floor 4 and floor 5 could be represented as values
   of 4.5 and 4.75.

> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]
> Date: Thu, 2 Dec 2010 05:47:47 +0800
> Subject: RE: [Geopriv] [geopriv] rfc3825bis #41 (new): David Harrington's	DISCUSS
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 1 Dec 2010 21:20:04 -0500

In a building where I work, the ground floor is called MA or TW, and another floor is called CY. Lore has it that this ensured that the 8th floor occupants could remain on the 8th floor after a move.

The NPR "The World" geo quiz for today: where is this building?

Henning

---

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Dec 2010 21:30:11 -0500

Gee Henning, you know I'm on this list.  I was in that building yesterday as you recall :)

445 12th St SW, Washington, DC

TW is for 12th St.  CY is for Courtyard.  

That building also has two ground floors, as both CY and TW are "ground".

Without being able to know which one was supposed to be 0, the idea doesn't work.

Brian

---

From: Marc Linsner <[email-masked]>
Date: Thu, 02 Dec 2010 08:06:51 -0500

Bernard,

This text works for me.

-Marc-

>    mezzanines between floor 4 and floor 5 could be represented as values

Subject: Re: [Geopriv] On civic extensions
From: "Thomson, Martin" <[email-masked]>
To: Brian Rosen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 2 Dec 2010 07:23:32 +0800
List-Id: Geographic Location/Privacy <geopriv.ietf.org>

                           Extend DHCP?
              |      Yes        |      No
        ------+-----------------+-----------------
 Extend   Yes | -local-civic-03 | -local-civic-02
  XML?    No  |       *C        |      *D

Is this a variation on -local-civic-03 we're discussing?

On 2010-12-02 at 10:19:38, Brian Rosen wrote:
> While I consider it part of my life's mission to always do what you
> expect me to do, I don't expect to be recognized for doing it.
> 
> I did read the email, and didn't see where "tl;dr" was mentioned,
> whatever "tl" and "dr" mean.
> 
> I think we're very close to agreement.  We have an open issue on how to
> represent the namespace in DHCP for a local extension, and we have two
> proposals: two DHCP options or one.
> 
> If you are okay with the second registry, with it's accompanying CAtype
> and DHCP option, then we should be able to close the one or two DHCP
> options issues with a couple of other people expressing their opinions;
> I certainly don't feel very strongly about that, since the result is
> the same: any local extension can be passed through DHCP.
> 
> Since we have mechanisms to pass two new CAtypes with the associated
> registries through DHCP, there is no problem there, and I think we have
> no disagreement (save the one or two registry issue).
> 
> LoST validation is also not in play - we understand how to do that with
> any of the proposals on the table.
> 
> I had the suggestion to have two generic parameters in the one or two
> CAtypes.  You could weigh in on that.
> 
> I'm pretty lost, no pun intended, on why the service boundary is any
> issue at all.   There are 3 entities, and some can either pass data
> without understanding it, or drop it.  If the LoST server gets some LI
> it doesn't understand, it ignores it, which means it doesn't appear in
> a service boundary.  If the LoST client got LI elements it didn't
> understand, and passes them through to LoST, it may get that element
> back in the service boundary if the LoST server does understand the
> extension.  If the server sends something back, it would have to be the
> value it got sent in.  Take bridge: if getting off the bridge is out of
> the service area, then bridge id is part of the service boundary -- the
> client can compare the bridge id it gets from a location update even if
> it doesn't know anything about bridge and requery LoST if it changed.
> If bridge ID is not part of the service boundary, it's not in the
> return and the LoST client won't miss it.  I am missing the problem.
> It appears to me to work, and not be dependent on representation.
> 
> Brian
> 
> On Dec 1, 2010, at 4:52 PM, Thomson, Martin wrote:
> 
> > Thank you Brian for doing exactly what I predicted and de-railing the
> conversation onto registries again.
> >
> > If you didn't read the email, "tl;dr" is an acceptable response, I
> wont be offended.
> >
> > On 2010-12-02 at 00:07:49, Brian Rosen wrote:
> >> My notion is that you have two registries, the existing one, and one
> >> that only attempts to avoid duplication. With registries come two
> >> things: a label and a number.
> >>
> >> The label is what you use with LoST.  The number is what you use
> with
> >> DHCP.  If you are worried about running out of DHCP number space,
> >> create one new number that has the label as it's first parameter.
> >>
> >> For the new namespace, LoST works already.  Create one new DHCP
> option
> >> with the namespace as the first parameter and the label (tag) as the
> >> second.
> >>
> >> Brian
> >>
> >> On Nov 30, 2010, at 8:01 PM, Thomson, Martin wrote:
> >>
> >>> Robert asked a question about how the various extension scheme
> affect
> >>> LoST service boundaries (as opposed to the validation we've already
> >>> discussed).  I think that this is another consideration we need to
> >> deal
> >>> with in designing a solution.
> >>>
> >>> Ultimately, questions of the effect of our decisions on other
> >> protocols
> >>> and users of the civic address format are the most important.
> >>> Discussions on registries and associated concerns is - at this
> stage
> >> -
> >>> an wasteful distraction.
> >>>
> >>> Service boundary evaluation is a simple process that treats each
> >> address
> >>> label as opaque (see draft-thomson-ecrit-civic-boundary for a more
> >>> thorough discussion).  This would make things easy if there were
> only
> >>> one possible way an extension could find its way into the system.
> >>>
> >>> Here are my collected thoughts on the real problem.
> >>>
> >>> --
> >>>
> >>> There are two formats that can be used to introduce an extension:
> >> DHCP
> >>> and XML.
> >>>
> >>> Those two entry points could lead to an increased number of
> >>> representations for extensions.
> >>>
> >>> Most of the problems occur at the point where conversions occur
> >> between
> >>> formats.  If an originator (LG) and ultimate recipient both
> >> understand
> >>> the extension, conversions between different formats are the only
> >>> serious cause of problems.
> >>>
> >>> If all intermediaries understood all extensions, we have no
> problem.
> >>> That's not a reasonable precondition though.  We have to deal with
> >>> certain intermediaries who are ignorant of extensions.
> >>>
> >>> An extension that finds its way into the system by way of DHCP (or
> >>> DHCP-based formats) is going to appear as a new, unknown CAtype to
> >>> recipients.  This can be translated to an XML format in two ways:
> >> when
> >>> the translator understands the DHCP form and the equivalent XML
> form;
> >>> and when the translator does not.  We need to deal with both cases.
> >>>
> >>> An extension that finds its way into the system by way of an XML
> >> format
> >>> has a similar problem.  The specific qualified name that identifies
> >> the
> >>> type of the extension can't be carried by DHCP.  The same concerns
> >> apply
> >>> to this sort of conversion.
> >>>
> >>>  Though a specific piece of location information might not need to
> >> be
> >>>  converted to DHCP format, it's genesis in XML might ultimately
> >>>  dictate that DHCP clients be able to convey this to clients for it
> >> to
> >>>  be represented in XML.  The idea being that data is forced to go
> >> XML
> >>>  -> DHCP -> XML and the goal is not to lose the extension.
> >>>
> >>> This leads to the following truth table for converting
> >> intermediaries:
> >>>
> >>>             | Intermediary | Intermediary
> >>>             | Understands  |   Ignorant
> >>> ------------+--------------+--------------
> >>> DHCP -> XML |      A       |      B
> >>> XML -> DHCP |      C       |      D
> >>>
> >>>  Note: Existing software is forced to discard extensions when
> >>>  translating in either direction.  Thus, it's safe to ignore that
> in
> >>>  this analysis.  I assume that software is compliant with whatever
> >>>  specification we produce.
> >>>
> >>> -local-civic allows for two expressions of the same data in either
> >> basic
> >>> format to deal with the problem cases "B" and "D".  This does add
> two
> >>> different representations of the same information in both XML and
> >> DHCP;
> >>> one representation for each of the four cases.
> >>>
> >>> This could cause a problem for LoST service boundaries (or any
> other
> >>> application that uses civic addresses).  If a particular extension
> >> can
> >>> be represented in different ways, the LoST server that relies on an
> >>> extension for its boundaries has to produce 2^n different service
> >>> boundaries if it wants to be understood (where 2 = the number of
> >>> different representations for each extension, and n = the number of
> >>> extensions).
> >>>
> >>>  In practice, I expect that such reliance on extensions will be
> rare
> >>>  for LoST.  This problem is rendered moot if the extensions are
> >> safely
> >>>  ignored, but it's something we need to consider for the general
> >> case.
> >>>
> >>> If we want to solve the problem of multiple representations - and
> we
> >>> should really evaluate the impact if we do not - then we need to
> >>> legislate to remove one of the options.  Since we can do nothing to
> >>> rectify the ignorance (or not) of translators, the only real option
> >> is
> >>> to restrict where extensions are defined.
> >>>
> >>> Removing the XML extension point would force all civic address
> >>> extensions to acquire a CAtype from the registry.  Extensions are
> >> only
> >>> ever natively defined as one octet CAtypes.  To carry extensions in
> >> XML,
> >>> we'd define an element that can carry unknown CAtypes.  <ext:EXT
> >>> CAtype="192">Value</ext:EXT> as suggested in -local-civic would be
> >>> a representative implementation of this option.
> >>>
> >>> Removing the DHCP extension point was actually something suggested
> in
> >> a
> >>> previous version of -local-civic.  That got some fairly strong
> >>> objections, but it should be tabled again.  In this option
> extensions
> >>> are natively defined in XML and we define a way to convey an XML-
> >> based
> >>> extension in DHCP.  The two new CAtypes in -local-civic are
> >>> representative implementations of this option.
> >>>
> >>> Thus we have the solution matrix:
> >>>
> >>>                           Extend DHCP?
> >>>              |      Yes        |      No
> >>>        ------+-----------------+-----------------
> >>> Extend   Yes | -local-civic-03 | -local-civic-02
> >>>  XML?    No  |       *C        |      *D
> >>>
> >>> *C is what (I think) Brian is advocating (Brian: correct me if I am
> >>> wrong, I've heard you support this).
> >>>
> >>> I don't think that anyone is advocating *D, though it's effectively
> >>> where we are at the moment.
> >>>
> >>> Keith is partly right about a do-over always being a final failsafe
> >>> option: we do always have the option of a complete do-over.
> However,
> >>> the main problem will just carry over into the new format if we
> don't
> >>> resolve it.  A do-over is just a decision we might make in the
> course
> >> of
> >>> implementing one of these four options.
> >>>
> >>> We should resolve this issue before we get into discussions on
> >>> registration policies and so forth.  Those discussions are wasteful
> >> as
> >>> long as we each have different fundamental solutions in mind.  I
> hope
> >>> that we can agree that each of these works with wild west, fcfs,
> >> expert
> >>> review or standards action with similar efficacy, though different
> >>> levels of accessibility and interoperability.
> >>>
> >>> --Martin
> >>>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Sat, 04 Dec 2010 20:44:20 -0000

Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |        Owner:  bernard_aboba@…           
     Type:  defect                     |       Status:  closed                    
 Priority:  major                      |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |      Version:  1.0                       
 Severity:  Submitted WG Document      |   Resolution:  fixed                     
 Keywords:                             |  
---------------------------------------+------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:5>
geopriv <http://tools.ietf.org/geopriv/>