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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
