----------
Minutes - GEOPRIV - IETF74

Summary (prepared by Richard Barnes):

1. Discussion of draft charter
The chairs presented a proposal for a new charter for GEOPRIV, adding
milestones for several current and upcoming work items.  There was no
objection to adding a milestone for HELD dereferencing, as had been
agreed at an earlier meeting.

2. LIS Discovery
   draft-ietf-geopriv-lis-discovery
Martin Thomson gave an overview of the latest version of the draft,
which adds a mechanism for carrying one or more certificate fingerprints
for a LIS in the LIS discovery DHCP option.  Several in the group felt
that this mechanism added unneeded complexity.  Martin will work with
the Security area to determine whether this mechanism can be simplified
or removed, then request a WGLC on a revised draft.

3. DHCP LbyR URI Option
   draft-ietf-geopriv-lbyr-uri-option
James Polk reviewed the latest version of this draft, which changes the
format of the option to set of TLVs (like RFC 4776).  Several
participants commented that privacy concerns (mainly related to access
control policies associated with URIs, or lack thereof) are not
adequately addressed in this document.  James will produce another draft.

4. URI format for expressing location
   draft-mayrhofer-geopriv-geo-uri
Alexander Mayrhofer presented a draft describing a URI encoding of a GML
point.  There was strong agreement from the room that the creation of a
short, human-readable location format was an important goal, and that
this draft was a good starting point.  The chairs will work with the ADs
to add a milestone for this work.

5. Geopriv privacy architecture update
   draft-barnes-geopriv-lo-sec
John Morris and Alissa Cooper presented the new version of this draft.
There was some debate in the room over whether the terminology used in
the draft is appropriate, but nonetheless strong consensus that an
update to RFC 3693 is necessary, and that this document is a good
starting point.

6. Updates to DHCP geodetic location format
   draft-polk-geopriv-dhc-geoelement-shape-option
   draft-tschofenig-geopriv-dhcp-circle
   draft-thomson-geopriv-3825bis
Three proposals were presented for how to update the RFC 3825 geodetic
location format, each presented by its author.  Two consensus calls were
made, one on whether the WG should produce a minor, backward-compatible
fix to RFC 3825 (strong consensus in favor), and one on whether the WG
should produce an additional DHCP location format to be preferred over
RFC 3825 in the future (consensus in favor, with a few against).  It was
noted that any changes to this format will have to be coordinated with
other SDOs (e.g., IEEE, TIA) that have adopted it.



Raw notes from Steve Norreys and Brian Rosen follow:

------------------------------------------------------------
IETF74 geopriv meeting  Notes by Brian Rosen

1. Administrivia
Alyssa Cooper introduced as new co-chair.  Jon Peterson out, Robert
Sparks in as AD
2. Document progress as noted on slides
3. Recharter discussion was held
Revised charter published to list
MT : loc-filters will take longer
BR: thinks it might be faster, we'll see
TH: Where is geo uri?
Chairs: Coming
MT: HELD de-ref?
RM: Yes, please
Chairs: We will do so

4. LIS Discovery
Big changes in DHCP option format, certificate fingerprints

Secdir found problems with the fingerprint mechanisms with expired and
replaced certs, alternative hosts with certs, etc.
Added a sub option to include serial number of cert
RB: Don't know why you need a serial number plus the hash
MT: Options for hash, need serial number to identify cert

If secdir is happy,

TH: Ask Leslie Daigle to re-review U-NAPTR portion
<missed a couple of comments>
HT: Do we really need the fingerprint stuff?
BH: Significant complication
CJ: Although it looks nice, will need lots of review, and add a year
BA: Agree, lots of people need to review
HS: Hard to implement new things like this.  Bigger discussion, more
general problem


MT: Okay, I'll delete it and release -09 for WGLC

5. James Polk on dhcp-lbyr
Have a DHCP server provide an LbyR URI

Made consistent with 4776, added an IPv6 option
Would be okay with
RB: Keep it
HT: Don't care about format, but what about security?
JPo: What is the model for 4776 (civic loc)?
HT: Should be closer to HELD context policy.  Doc needs to be clear
about security
HT: Need to state what the model is
MT: When you get the URI, can I publish it on the net?
JPo: It's YOUR URI, you can do anything you want to do it!
MT: Thats unreasonable.  Need a policy of some kind
JoP: Equivalent of being given a value
MT: Say that, it's a possession model
TH: Steal text from my doc about URIs
HT: That would be great.  Also need to state URI always returns the same
location (what you got when you recieved URI from DHCP server)
JPo: No, URI stays the same, location can change
HT: Then its not the same as LbyV
JPo: If I give you my loc or my URI, it;s the same thing
HT: There is no policy mechanism to control the URI return results

Chairs: move on.  Doc must describe what the security policy


Mayrofer geo-uri
Simple, human readable, but defined way to give a simple geo point
Possible additional options, URI parameters (privacy related)
TH: Worthwhile to do, but needs more work.  Is this really a URI, or a
human readable format to know its WGS84?

Wants WG adoption
MT: Need to do something like this.  Consider the parameters, possibly a
registry
JM: Have concerns on privacy.  Want some parameters required.  Needs to
be "content", not "address".
JPo: What do you do if the datum isn't WGS84.
AM: Haven't thought about it
JPe: More of a format than an object.  WG started without defining
formats, but it's doing it (civic).  We can encapsulate this, and
provide the protections.  Pragmatism is hard to argue against
MT: Simplicity is a good thing here, use WGS84
HS: Want few options, push complexity to sender, not receiver.

Show of hands for WG interest?  Significant majority yes, no objection
Show of hands for this doc as basis?  Significant majority yes, one objection

loc-sec John Morris
W3C doing location conveyance, have trouble getting them to accept
geopriv work on privacy; not aimed at web, too hard to understand.
Doc attempts to provide easier into to geopriv, and address issues and
tensions that developed over time.

ML: Scope creep here, which you have explained, but WG needs to decide
if that is what they want to do
RB: Yes, thats one reason we wanted to spend time on it here
ML: But needs to be taken to list

<Overview of the doc>
BR: Configuration is way different from general distribution
MT: Disagree, it's distribution with different policy
ML: Leave the term "LCP"
HS: It's a special case of distribution, that's all.  Protocols may get
more complex, but it's special case of distribution.
JPo: <wiggles fingers> LCPs are different.
JM: Document not intended to change the WG approach, but the doc has to
be clear to an outside audience.

JPo: Lost the concept of a "seeker"
AC: If you get it you are an LR, if you don't get it, we don't care
MT: Yes, let's get rid of terms we don't use, tightening definition is good.
JPe: Consolidation of entities is good.  Mapping to web includes
query/response, but thinks doc handles it
JPo:  Have docs with seeker, can't just drop it
MT: No seeker in 3693
JM: LSa/LSi needed because some sites have embedded privacy rules
(Facebook) some don't (Pizza Hut)

Discussion on differentiation of "ultimate recipient" (who does not
retain or retransmit)
MT: Don't go there
JM: Disagree.  Most LS would have to have two hats (LR and LS)
HS: Most web serves keep logs, need to deal sensibly with that issue

Show of hands for: Is this worthwhile work?  Many yes, no against
Show of hands for: Is this doc a good basis for it?  6-7 yes, no against

James Polk on DHCP geo shapes (point/circle/polygon)
<projector dies>
BA: Which IEEE groups
JPo: LLDP-MED will follow us. 802.11k is resisting, no deployment of
that yet

Can't move a draft standard to historic
TH: I have done this (sinned) and will do it (sin) again

Okay, lets's do it
TH: Is the goal deprecate use or reclaim option code

Deprecate use primary

RG: It has to be possible to move proposed to historic
BA: 11k will follow us

Propose 4776 like TLVs with 2D/3D points/circles/polygon, datums, ...

Hannes presents DHCP circle

ML: Is lack of implementation a format problem or a lack of interest in
location
BA: In 11k it's too complex in low level stuff, too much chance of bugs, etc

Martin Thomson describes 3825bis

Chairs: Do we want to fix 3825 or create a new doc with shapes and a new
way to define point
MT: Fix only, use a reference if you need more
JPo: Replace, fix is okay
HS: Second system syndrome.  Don't want a third format between binary
and XML (by reference).  For 3825, just remove the resolution field.

Show of hands for fixing 3825: strongly in favor
Show of hands for any new format: 2 for, 10 against





MT: Martin Thompson
BR: Brian Rosen
TH: Ted Hardie
RM: Roger Marshall
RB: Richard Barnes
HT: Hannes Tschoefenig
BA: Bernard Aboba
CJ: Cullen Jennings
HS: Henning Schulzrinne
JPo: James Polk
Jpe: Jon Peterson
RB: Ray Bellis
JM: John Morris
ML: Marc Linsner
AC: Alyssa Cooper
RG: Randy Gellens

------------------------------------------------------------
1    Administrivia/Charter discussion (Chairs)

Nothing to report from the agenda except for the continued ruiation of
Jon's liver and the start of the ruination of Roberts's

On the charter

Roger Marshell request to submit lbyr requirements to IESG supported by
Martin Thomson

James Polk questioned the draft charter version displayed - resolved by
chair

Martin Thomson not sure the filters is going to that quick

Brian Rosen went the other way dependent on reaction of the WG

Chair

Hannes T promised to get work to Brian this week

Ted Hardy [missed this]

Martin T d reference to the list

Roger M support t and add that this WG needs to progress this quicker.

2    Lis discovery (Thomson)

Richard B Q why is the certificates fingerprints and serial number
required? - in order to id what cert needs to be kept etc.

Ted H Raised a issue on the xxxx portion of this draft  assumption that
the domain name of the device is used and this needs to be clear

Martin T - this is not what is intended so this will be clarified

Hannes T - when did this draft add the sec association with the
discovery mech and removing the fingerprint

Martin-

Hannes service discovery need to security association needs to be some
kind of trust similar to browser is this not sufficient

Martin not sure

Hannes

Cullen do we need this additional mech or not and this seemed to be
complicated, predict this will add a yr or two to publication so
consider if needed

Bernard agree

Henning +1

Chair suggest to go to the sec ad prior to WGLC

Martin not on slide discovery lis based on ip addresses draft needs to
be reviewed

3    Dhcp lbyr uri opCon (Polk)

Ray

Hannes doesn't care for format point

James d=worried by statement

Hannes What sec authorisation model deployed what assumptions made here?


James what d the policy model for civic addresses 0n 4776

Hannes claimed difference is no you get new information on each request
needs to be clear on assumptions made

J DHCP does not load new policies

H this needs to be said

J dereference the uri is independent of dhcp this draft is a dhcp
extension.

Martin T supported Hannes assumption that the receiver cannot /can
deference the uri

J out of scope

M this is crazy so the sender needs to send the info that the receiver
understands use terminology

Ted H properties of uri are documented and can be copied in this text.

Hannes different uri required for different location?

J no this is what we don't want to happen a

J loc by values and loc by referen is the same

H this is not the same

J this is not a dhcp issue - uri from presence server lbyr is the same

Chair = needs to be discussed on the list the privacy and security needs
to be discussed

4    Loc filters (Rosen)

No slides - released with 4661

5    Lo sec (Cooper)

Marc L scope creep in this draft and this needs to be reviewed

John M valid point

Richard B this is why it is being looked today

Marc L needs to be taken to the list

John M this is a significant shift and needs to assessed if this is the
direction to go or may require further docs

Brian R life cycle different from the slides distribution we have worked
on

James P break this into two separate sections

Martin T disagree with BR as this is at the sending stage sec
implications are the same and this makes sense and if this separated
then this could be

Mart T needs more treatment in this draft

Marc L early on term LCP was done but not change them

Agree

Henning S logically speaking it  LCp is a a special case the lo dis as
it goes to the target itself and this has tied this group in knots

James P disagree with HS and MT and these are convergence protocols and
must have privacy considerations

John M this draft is not intended to change any thong that has been done
in this wg just to clarify what has been done and not add every special
case

Sect 6

James P concept of a seeker has been left out who can ask for your
location which is in the conveyance

Why do we care

Martin T right to remove concepts that we are not using

And this not added as it is a small part and not a clarifying aspects

Martin T comments on the list as this is more complicated than is
necessary

John P support this objective for less agents involved but this should
map onto the seeker requirement and it does. so it shows that tour model
is rational

James P this is good work losing terms/entities needs to be explained as
this draft could be used as the geopriv architecture,

Agreed o add that the missing entities are in a appendix.

Martin T no mention of seeker at all in 3693//

John M real distinction which has a robustness in the web world but
people like pizza hut do not

Henning S by omitting names the arch becomes more fuzzy but we having
difficulty selling this work outside so complicating thing s does not
help.

O/Standing issues

Martin T using LR as a term is going to fail ultimately fail as every
one who receive lo is a LR what does the server do that has no intention
of becoming a lo server the distributing is a LS

John Disagree maybe clarify the LR section so every server has to have
be a LR and LS

Henning need to clarified as to what do you do as a LR and how long lo
info is retained.

Not out of quest if  you are a LR then this is retained in

Henning S Real hard to do

Search engines have started to do this

None against this work

None against seven for using this draft a



6    Geo uri (Mayrhofer)

Ted H valuable for WG to work approach this draft is not necessary
correct way to do this esp on the privacy angles, could use other
formats

Keith D using invalid IPR statement.

Martin T encouraged to consider the parameters needs to consider 3693 if
this comes to complex it will ignored

Mayh

John M concerns on the privacy front as they are option should be
required. US is looking into location protection and this could fall
between the tracks as this is n the address of the signalling

James P what done if WGS84 is not the data model e.g. now o does not use
this model and what they are not easily convertible.

May what does GPS not thought about it

Jon P on privacy on what implications are not sure if this format issue
is are we going to create lo formats to deal with privacy -n need to be
practible as people will use this type of format and we need to deal wit
it. Putting priv in the uri is tricky

Mayh agreed

Martin T answer to JP can be doen using //////////

Henning S completacte use xml use this if wnant simpel so adding
complexity will made this a niche market

Chairs do we want to to make this a WG charte item significant in favour

It this doc a good stating point one obljection to using this draft.


7    Straw man strategy for DHCP geodeCc locaCon (Polk)

Bernard Comment on which standard are we discussing here and to suggest
on format over another from TIA

Cullen maybe but he does not know this procedure

Ted H did not this procedure and has sinned against it

Cullen is willing to sin again

JP is happy with the sinning

Ted H if we do this do we loss the option

JP no reclaim opts all the time

Randy E not only permitted but expected to happen.


8    Dhc geoelement shape opCon (Polk)

Gabor B Where is the to define polygon formats

JP from cisco customers not from this wg

9    Dhcp circle (Tschofenig)

Marc L not being deployed

Martin T format is bad enough and this is the wrong way for dhcp

Bernhard this creates a lot of complexity at this his layer

10    RFC 3825bis (Thomson)
a
Marc L deprecate the floors for altitude

MT is this a problem if don't know what floor u on are on don't ask

11    Discussion of DHCP geodeCc locaCon (Chairs)

Martin T view for replacement is to use the lbyr option

James P biased for replacing 3825 open to fixing the rfc

Henning S second sys syndrome so replacing with a relatively simple
format not in favour in creating a  binary format that will create
interop probs lbyr is available the resolutions field could be
deprecated and the world wont end.

JP what about polygons

Henning use Lbyr + henning, hannes, matin t

Fixing  15 in favour 2 against

New rfc that gives another lo format  for dhcp option 2 in favour 10
against

12    Include exclude filters (Polk)



13    trustworthy locaCon (Tschofenig)



14    pidf lo dynamic (Schulzrinne)





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