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

From: "geopriv issue tracker" <[email-masked]>
Date: Tue, 30 Nov 2010 15:35:05 -0000

#41: David Harrington's DISCUSS

 David Harrington has entered the following ballot position for draft-ietf-
 geopriv-rfc3825bis-14.

 When responding, please keep the subject line intact and reply to all
 email addresses included in the To and CC lines. (Feel free to cut this
 introductory paragraph, however.)

 Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
 for more information about IESG DISCUSS and COMMENT positions.

 ----------------------------------------------------------------------
 DISCUSS:
 ----------------------------------------------------------------------

 This document is well-written, with clear and unambiguous language.

 When aType=2, numbering starts at ground level. How does one represent an
 underground parking garage level?
 Should 2.4.3 mention how to represent this? Should Appendix B include such
 an example?

 ----------------------------------------------------------------------
 COMMENT:
 ----------------------------------------------------------------------

 1) section 1, paragraph 4 says "The DHCP server could correlate the
 Circuit-ID with the geographic location where the
    identified circuit terminates (such as the location of the wall jack)."
 Would it be the job of the DHCP server to do this correlation? I would
 assume it was a NM application function to do such correlation.
 2) In 2.2.1.2, s/same response. This is not useful since/same response,
 since/

-- 
---------------------------------------+------------------------------------
 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://svn.tools.ietf.org/wg/geopriv/trac/ticket/41>
geopriv <http://tools.ietf.org/geopriv/>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 01 Dec 2010 00:27:10 -0000

Comment(by bernard_aboba@…):

 [James Polk] with a negative number.

 This was in RFC3825, but I cannot find it in this document now, which is
 an oversight on (at least) my part.

 >Should 2.4.3 mention how to represent this?

 probably correct with the section this should be in

 >Should Appendix B include such an example?

 it could

 >    identified circuit terminates (such as the location of the wall
 >jack)." Would it be the job of the DHCP server to do this  correlation?
 >I would assume it was a NM application function to do  such
 >correlation.

 I believe the operative word above is "could". The server could also just
 forward what it was given by a Location Server (probably vs. a NM server)
 towards the client without changing what it was given. Do you believe this
 should be clearer?

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

---

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 01 Dec 2010 00:39:09 -0000

Proposed Resolution:

 In 2.2.1.2, s/same response. 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. Larger values represent floors
    that are above (higher in altitude) floors with lower values.

    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.

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 30 Nov 2010 20:17:30 -0600

At 06:39 PM 11/30/2010, geopriv issue tracker wrote:
>#41: David Harrington's DISCUSS Comment(by 
>bernard_aboba@…): 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:

>could be represented by negative values.

I recommend a change to be definitive here with
s/could be/are

>Larger values represent floors

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."

>represented as values = 4.1 and 4.2 respectively.

I'm fine with the rest as written.

James

>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: 
><http://trac.tools.ietf.org/wg/geopriv/trac/ticket/41#comment:2> 
>_______________________________________________ 
>Geopriv mailing list [email-masked] 
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 01 Dec 2010 03:46:28 -0000

[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:

 I recommend

 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.

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 30 Nov 2010 23:53:35 -0500

Would it be out of place to note that none of the values 1.1, 4.1, or 4.2 are expressible with 8 bits of fraction?  Maybe use 1.25, 4.5, 4.75?

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 1 Dec 2010 12:59:42 +0800

You can get fairly close though: 1.1015625, 4.1015625, 4.19921875

On 2010-12-01 at 15:53:35, Richard L. Barnes wrote:
> Would it be out of place to note that none of the values 1.1, 4.1, or
> 4.2 are expressible with 8 bits of fraction?  Maybe use 1.25, 4.5,
> 4.75?
> 
> --Richard
> 
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 1 Dec 2010 00:20:24 -0500

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

---

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 01 Dec 2010 06:18:46 -0000

Here is the corrected 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.  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:

    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.

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