Subject: [Geopriv] GEOPRIV Minutes from Virtual Interim, 21 May 2009

From: Richard Barnes <[email-masked]>
Date: Wed, 03 Jun 2009 15:05:46 -0400

Minutes - GEOPRIV - Virtual Interim, 21 May 2009

Summary (prepared by Richard Barnes):

1. The chairs opened the meeting by outlining the goals for this 
meeting.  The intent of this call is to reach agreement on the critical 
technical changes to be made in an update to RFC 3825, which will 
subsequently be confirmed on the list.

2. There was consensus on the call, with no objections, to correct the 
EPSG number for WGS84

3. There was consensus on the call, with no objections, to add a DHCPv6 
option

4. There was consensus on the call, with no objections, not to deprecate 
the 'floors' altitude type

5. With respect to the explicit signaling of the use of the resolution 
fields to represent uncertainty, there was general agreement that this 
should be done, with some remaining disagreement about what processing 
should be required or recommended for the client or server.

6. Richard Barnes proposed that a mapping from the DHCP format to GML be 
added to the document; there was agreement to make this change, with no 
objections

7. With respect to the structure of the draft to be produced, there was 
general agreement that the new document should entirely replace RFC 3825 
(rather than simply listing changes), with some remaining disagreement 
about whether it should include editorial changes, or only technical 
changes.

Raw notes from Matt Lepinski and Richard Barnes follow:

------------------------------------------------------------

About 23 Participants

Alyssa: All decisions on the call will of course be confirmed on the list

James Polk: [Clarification to the Slides] An Update is not a BIS

Richard: This is an independent decision to be made at the end of this 
discussion (once we've figured out what we want to change)

--- Topic 1 EPSG number for WGS84

James Polk: Authors have known that this is bad for about 4 years

Keith D: This is just a fix, no backwards compatibility concern

[No objections]

--- Topic 2 DHCPv6

Richard: This is a more significant change than some of the others (at 
least in terms of text volumes). Is this worth investing time in?

Keith D: Also, no backwards compatibility issues here

[No objections]

--- Topic 3 Deprecating Floors

Alyssa: List concensus not to deprecate this

[No objections to list concensus]

--- Topic 4 Signaling use of uncertainty

Question: Should uncertainty be signaled

Richard: This is a risk evaluation by the working group. Do we want to 
support a soft fail ... is misinterpretation better or worse than a hard 
fail (where client may get nothing)?

There is an equivalence between having a different coordinate system to 
signal vs stealing some bits to use as a version number

Carl Reed: Do we have any idea what the deployed base is of 3825?

[Someone]: Standards-level adoption, but no data to indicate people are 
actually using this

Claim (Bajko?): There are chipset vendors who support the format in 802.11K

Bernard A: I've talked to almost all major chipset vendors (802.11) and 
I know of no one who is implementing this

[Someone]: There are products that use 3825

Hannes: What does backwards-compatibility mean in this context?

Keith: You need to fail gracefully (see ITU recommendation ????)

Richard: Which is a better failure case? [soft fail (misinterpretation) 
or hard fail]?

James P: Some people are trying to push that because there isn't a lot 
of deployment that we don't need to have backwards compatibility

Cullen: [Clarification of Design choices] Choice #1 Client knows there 
is a problem and gets nothing vs Choice #2 Client misinterprets some 
bits but still gets some location

Mary: So now there is no guidence for what to do in the case of a 
signaling failure for coordinate systems

If a new client receives data from an old server, then it will look 
bit-for-bit like a new server signaling the use of "resolution"

Kieth: Document must make it clear that an updated (new) client must be 
able to understand both resolution and uncertainty (not okay to just 
understand uncertainty)

James: We need clear guidence on what to do if you see a coordinate 
system that you don't understand.

Concensus - We do signal, and we provide guidence for how to handle a 
coordinate system that you don't understand. This advice must be easy 
for existing vendors to implement (without actually implementing an 
understanding of uncertainty).

Additionally, it was suggested (with no objections) that a client who 
gets versioning bits it doesn't understand (for a coordinate system that 
it does understand) --- e.g. WGS84 with uncertainty, new uncertainty 
version when it understands WGS84, old resolution version --- then it 
should ignore the versioning (which yields a soft fail as discussed above).

Question: Is new clients working with old servers a "MUST" or a "SHOULD"?

Hannes: What is the harm in not implementing the the old 'resolution' 
format?

Suggestion [Bajko]: Server must support both, but client only supports one

Cullen: In DHCP there isn't much benefit if the server supports both 
versions, it still has to pick one (blindly)

Richard: We have an outline, we can have discussion once we have a draft 
about whether it should be a MUST or a SHOULD

[Draft will have an open issue in the area of whether clients (or 
servers) MUST support both uncertainity and resolution]

--- Other Updates/Wrap Up

Richard: I'd like to see an explicit mapping to GML

Kieth: We should have a separate concensus call for each point that 
might be changed. We don't want to put a package into the draft that 
includes changes that haven't been concesus called

James: Good Idea, I have text in Section 5 of the shapes draft [that 
provides a mapping to GML]

[No Objections]

Marc: This could be a non-normative appendix, right?

Richard: Yes

--- Structure

Spencer: Is there a compelling reason not to do a complete revision 
(single update all-inclusive document) ... The BIS option

Keith: If we produce a BIS, we should be able to do a diff that produces 
only the important changes (that is, we're not doing a wholesale re-write)

Hannes: 3825 isn't HTTP, we shouldn't be so concerned with the size of 
the diff [Note, there are a lot of changes that come just because the 
old RFC was made with word and now everyone uses XMLRFC]

Richard: We have a BIS with an appendix (or section at the top) that 
lists the changes

James: Martin's draft changes every word in 3825, this is unnecessary

James: Someone is going to submit a new BIS that changes only what is 
going to be changed?

Alyssa: Yes, plus adding a section at the bottom [at the top can change 
section numbers that breaks the diff]

Note: Hannes's document might be a starting point for this

[Alyssa summarizes]

James P: Can we have compatibility with 802.11Y and 802.11K? [with 
regards to versioning bits]

Richard: Reserve the bits used as flags in 11K, and we use the two 
remaining bits for version (with 3 bits for Datum, which should be enough).

Cullen: With whatever you chose to do with being compatible or not being 
compatible, please keep IESG in the loop. This will support the IESG 
goal of having a better relationship with other SDOs (IESG doesn't want 
late surprises on this). Might be a non-issue but please keep us in the 
loop.

[Note: We want to play nice with 802.11, but we don't want to encourage 
other SDOs to steal our bits]

Marc: This [802.11 compatibility] will [at the very least] be in shepard 
write-up for the BIS

Richard: For now we will add the reservation of the three bits to the 
list of changes

Alyssa: We will concensus call each item on the list, and we [the 
chairs] will figure out how this draft is going to get written

------------------------------------------------------------

Goals: Which updates, and what form of draft
-- Polk: -bis is different from an update
-- Drage: Agree
-- Barnes: That's the discussion for the format part of the agenda

Fixing EPSG number, any objection?
-- Polk: 3825 authors have known about this for a while
-- Barnes: No objection to this

Adding DHCPv6 option?
-- Hannes: Not a big deal, let's do it
-- Keith: No compatibility issues on this one either
-- Alissa:

Deprecating floors?
-- Alissa: Seems like there's consensus not to do this

Signaling the use of uncertainty in place of resolution:
-- Alissa: Seems to be consensus to have "uncertainty" interpretation of 
res bits
	-- MT has produced truth tables, reproduced on slide
-- Hannes: What about usage of DHCP
-- Bellis: Do we have any idea of the 3825 deployment?
	-- Barnes: Standards
	-- Aboba: Not aware of anyone who supports it in 11k
	-- Thomson: Chip vendors do support 11k, maybe not this
-- Keith: Should fail gracefully
	-- Barnes: Definition of "grace"
	-- Drage: Ideally, you could fall back to the old format
-- AThompson: There are implementations out there
-- Cullen: The interesting case is client=old, server=new
	-- Polk: Not necessarily hard fail, just don't understand datum
	-- Barnes: So you mean that you should just try to interpret if you 
don't understand?
	-- Polk: No MUSTs in 3825 right now, there could already be CRS mismatch
	-- Bellis: Made this point on the list
	-- Polk: No capacity for negotiation in
-- Barnes: Sounds like folks on this call agree that explicit signal is 
appropriate?
	-- Hannes: Prefer different CRS
	-- Bellis: Equivalent
-- Drage: What is the proper action for a new client, old server?
	-- Bellis: They would treat it as 3825 location
	-- Drage: We should specify that new clients should support both versions.
	-- Polk: Agree with that
-- Polk: Problem is updated server with non-updated client
	-- Barnes: Same as an unfamiliar CRS
	-- Polk: We should provide guidance as to what to do with a CRS you 
don't understand
		-- E.g., ignore version bits, might be an easier upgrade
-- Gabor: Don't need to require support for both versions
	-- AThomson: Need that for compatibility with old servers
	-- Hannes: Don't want a MUST for both versions
	-- Drage: Need it for a fully compatible system
	-- Gabor: Require that server support both, client support one
	-- Drage/Cullen: That's exactly backwards
	-- Drage: So the draft will have an open item for this?
		-- Barnes: Yes.

Other updates:
-- Barnes: Mapping to GML?
	-- Hannes/Polk: Good idea?
	-- Linsner: In an appendix?
	-- Barnes: Sure, doesn't need to be normative
-- Drage: We should have some process around which changes are in/out
	-- Barnes: Plan is to have consensus calls on the list on these issues, 
then a draft

Draft format:
-- Dawkins: Is there a compelling reason not to do a single, updated 
document?
-- Drage: Could live with both, but have constraints on both
	-- If a single doc, want rfcdiff to work
	-- If an update, need to be very precise about what in the old doc is 
changed
-- Hannes: Even if it's diff-able, there could still be lots of changes, 
just based on formatting
	-- xml2rfc instead of Word
-- Linsner: If an update, an implementer has to read both
-- Barnes: Diff-able update, with list of changes?
	-- Polk: Thomson's draft changes much more than is necessary
-- Alissa: Minimize changes, state updates at the top
	-- Drage: At the top can cause diff to choke
	-- Bellis: Probably an issue anyway, if we're adding a DHCPv6 section
	
Summary: Fixes:
-- EPSG
-- DHCPv6
-- Not deprecating floors
-- Adding version
	--> With recommendations
-- Adding GML mapping
-- Format: Diff-able, with list of changes
-- Polk: Lateral compatibility with 11y in the datum field
	-- Barnes: Proposing to reserve 3 bits, with 2 version bits?
	-- Polk: Might want to add an aviation datum
	-- Cullen: Could you make sure you keep the IESG informed about this
		-- Sometimes playing nice means saying "No" when people steal bits
		-- For now, just keep people apprised
		-- Aboba: If you want to talk to 802, can also use IAB
		-- Linsner: Consider adding to shepherd write-up
	-- Polk: Most of this is already in my version
	-- Barnes: Objections to reserving 3 bits?  Hearing none.
-- Alissa: We will post these as questions to the list, then find a path 
forward