Minutes of the GEOPRIV Working Group from IETF 64
1 Session I
Co-chairs: Andrew Newton, Allison Mankin
Scribe: Brian Rosen
1.1 Agenda Basing
1.1.1 Andrew Newton presented the agenda for both sessions of
GEOPRIV and asked if the group if any modifications needed to
be made. James Polk noted that the second session of GEOPRIV
conflicted with SIPPING and therefore many people who whould
like to be part of the HELD discussion would not be present
during the second session. With the permission of James
Winterbottom, Andrew noted that the HELD discussion could
start once all the items scheduled for this session were
finished.
1.1.2 Rohan Mahy reported that his filter draft was updated and
would be resubmitted as a working group draft.
1.1.3 Jonathan Rosenberg asked that the discussion on
draft-ietf-geopriv-common-policy be conducted first because
he had a schedule conflict in the latter part of the session.
The chairs accepted this change to the agenda.
1.2 Common Policy
draft-ietf-geopriv-common-policy-06.txt
Presented by Hannes Tschofenig
1.2.1 Hannes noted that the condition as discussed in
the last meeting had been changed.
1.2.2 Hannes noted open issues with the draft:
1.2.2.1 multiple scheme/sphere attribute
1.2.2.2 internationalization
1.2.2.3 questions regarding the degree of extensibility allowed
by the schema.
1.2.3 Henning Schulzrinne noted that multiple "OR" conditions could
be expressed with multiple rules, and suggested not using
multiple values in scheme/sphere. Jonathan Rosenberg agreed.
1.2.4 Andrew, Henning, and Jonathan discussed collapsing the id
component parts into a single URI. The co-chairs asked for a
hum of the room in support of using a single URI for the id,
and the co-chairs found that the room consented to this
decision.
1.2.5 Andrew noted that the draft has not Internationalization
Considerations section and that internationalization issues
may exist with the URI and specifically the domain when being
used as an identifier. There followed a discussion about the
domain being a pure ASCII domain name or an IDN. It was
concluded that more needed to be known about IDNs before this
decision could be made.
1.2.6 Andrew asked the authors of the draft if the domain attribute
was semantically only a domain name or more like an authority
in a URI, such as with a port number. Jonathan noted that
the comparison would match if the ports differ, so it is only
suppose to be a domain name. Andrew noted that this needed
to be clearly stated in the draft.
1.2.7 Andrew asked if the sphere values required registration.
Henning and Jonathan stated that the values only had to be
consitent within a document or using community but not
globally.
1.2.8 The chairs asked if any other issues existed with the draft.
None were raised.
1.2.9 The chairs asked if any issues existed with the related
document, draft-ietf-geopriv-policy-07. None were raised.
1.3 Provided-By
draft-thompson-geopriv-provided-by-00.txt
Presented by James Polk
1.3.1 James asserted that the current provided-by in PIDF-LO was
not well defined and a more usable schema is presented in the
draft.
1.3.2 Allison Mankin stated that it duplicates what is currently in
PIDF-LO and is in conflict with the basic extensibility
mechanism PIDF-LO uses to define multiple provided-by
namespaces. James said he did not know how to address this
issue.
1.3.3 The chairs asked the room if the presentation needed to
continue, and the consensus of the room is that it did not.
1.4 NENA Provided-By
1.4.1 While on the subject of provided-by, the chairs noted that
they needed a response from NENA regarding the schema
question raised by the RFC Editor. Nadine Abbott, speaking
as a participant of NENA, had been told that the truncation
for historical reasons and was unnecessary. The chairs noted
that they would instruct the RFC Editor to remove the
truncation and the length limitation from the schema.
1.5 Carrying Location Objects in RADIUS
draft-ietf-geopriv-radius-lo-04.txt
Presented by Allison Mankin
1.5.1 Allison presented the status of this proposal in context of
the work being done in both GEOPRIV and RADEXT. She stated
that most of the issues are being cleared up with the RADEXT
working group, and the current proposal going forward is to
not use a generalized capabilities function but persue a
"supported-loc" method. Issues with this approach regarding
an Access-Challenge remain.
1.5.2 Some participants discussed dropping the use of LO with
RADIUS and using DIAMETER for security reasons. The chairs
noted that the working group had covered that territory when
this work was adopted by the working group, and that the
working group would not go back to revisit this decision. It
was suggested that the draft contain text describing the
privacy considerations that must be made.
1.5.3 The chairs noted they did not intend to let a GEOPRIV last
call on this document block on RADEXT, but would not send the
document to the IESG until RADEXT had cleared all its issues
with this document.
1.6 HELD
draft-winterbottom-http-location-delivery-02.txt
Presented by James Winterbottom
1.6.1 James presented the changes made between the current version
and the previous version of the draft.
1.6.2 There was some discussion about the described feature of
"talked to an LG". It was noted that an LG just generates an
LO, but anything that passes an LO is an LS. So talking to
an LG makes a network element an LS. Since HELD already was
an LS, this didn't make sense. James agreed.
1.6.3 Andrew questioned the appropriateness of using an IP address
as a security credential. James replied that "return
routability" gauranteed that the IP address was not spoofed
and that the access network was secure enough for such a
mechanism.
1.6.4 It was suggested by Henning Schulzrine that the document be
split into multiple documents, each targetting a specific
function.
1.6.5 Henning also suggested using an RPC mechanism like SOAP
instead of multiple HTTP protocols.
1.6.6 John Schnizlein noted that the function of passing around a
location URI does not qualify as a Location Server. James
Winterbottom noted that he didn't understand the basis for
this objection.
1.6.7 Many participants discussed the discovery of HELD server when
no layer to mechanism was available. They noted concern that
HELD has being described a service for use with DHCP was not
available, but that it requried DHCP for discovery and
therefore a dependecy on a protocol it is described to not
need. James noted that there were other mechanisms, such as
DNS, for situations when DHCP was not available. Marc Lisner
noted that DNS may not be within the sphere of control of the
access network operator.
1.6.8 The chairs noted that the HELD discussion would be continued
in the next session.
2 Session 2
Co-chairs: Andrew Newton, Randall Gellens
Scribe: Nadine Abbot
2.1 Agenda Bashing
2.1.1 The chairs presented the agenda and asked if there were any
requests to modify it. None were raised.
2.2 PIDF-LO Profile
draft-ietf-geopriv-pdif-lo-04.txt
Presented by James Winterbottom
2.2.1 James presented the changes between the current version of
the draft and the previous version of the draft.
2.2.2 James noted that Martin Thompson was working on a schema that
would supplement this document, but that Martin's work would
not be completed until the next IETF meeting.
2.2.3 The room then discussed how to move forward. Henning
suggested that perhaps the working group out to consider an
RFC 4119bis. James suggested that the group get this
document completed, and once there was enough implementation
experience that an RFC 4119bis would make sense. The chairs
put the question to the paritipants of the room, and the
consensus was to proceed according to the proposal described
by James.
2.2.4 Andrew Daviel inquired about the inclusion of conves holes.
James asked for an example to be provided, but noted that
routing and location determination would likely not need this
information.
2.3 Revised Civic LO
draft-thomson-revised-civic-lo-01.txt
Presented by James Winterbottom
2.3.1 James presented this draft, noting that it was intended to
replace the current fields defined by Henning in the DHCP
civic draft.
2.3.2 There was a discussion regarding the use of placetype values.
It was the agreement of the participants that place type
values should not be freeform but should aligned with the
IANA place types registry.
2.3.3 Andrew Daviel suggested the inclusion of a URI pointing to a
validation service. Henning noted that such a service would
be highly application dependent and should be outside the
PIDF-LO document. Ted Hardie noted that such a service would
require protocol definition and not just a URI inserted into
the civic fields.
2.3.4 A discussion followed regarding new fields. Andrew Newton
noted that the current schemas do not account for road
section numbers found in Tiawan. Henning believed a field
could be added to the A hierarchy. James suggested
overloading the Ad code field. Henning objected to this. It
was noted that more information was needed regarding
Tiawanese road section numbers before a determination
regarding its place in a schema could be determined.
2.3.5 The chairs asked the room if this document should be accepted
as a working group item, and the consensus of the room held
that it should be adopted and moved along as fast as possible.
2.4 Facilitated HELD Discussion
draft-winterbottom-http-location-delivery-02.txt
Presented by Andrew Newton in the capacity as co-chair
2.4.1 Andrew presented is observations on the discussion on HELD
from Session 1.
2.4.2 James Winterbottom offered to have a conference call to
discuss the different functions described by HELD. Andrew
requested that use cases for the various functions be sent to
the mailing list so that GEOPRIV might get a better
understanding.
2.4.3 There was a discussion regarding the use of terminology in
the HELD draft with regard to the terms as they are defined
in RFC 3693. It was noted that some of the terms are
mismatched with the functions being applied.
2.4.4 There was a discussion about sighting protocols and the
applicability of this function with regard to RFC 3693. Ted
Hardie noted that sighting procotols and location object
using protocols have different requirements.
2.4.5 John Schnizlein criticized the use case of being able to
associate location with IP addresses. James Winterbottom
noted that the IP address is not the only key to determining
location.
2.4.6 James Winterbottom agreed to examine BCP 56 to see how it
applies to HELD.
2.4.7 Security issues were raised with regard to using an IP
address as a credential. James noted that return
routability, or the handshake of TCP, offered a good enough
gaurantee against spoofing. It was noted that the use of IP
addresses as a credential might open the service up to DoS
attack as IP addresses are well known values within an
operating environment.
2.4.8 John Schnizlein requested that James provide answers to many
of the issues on the mailing list so that they may be
discussed in more detail.
2.4.9 Brian Rosen asked the chairs if they would consider a hum
with regard to accepting HELD and expressed concern that the
working group was spending too much time discussing this item
considering it was not a working group document. James
Winterbottom objected to this and asked for any hum to be
conducted on the mailing list. The chairs noted that all
IETF consensus decisions had to be sent to the mailing list.
The chairs also noted that while many issues exist with HELD
that there was a considerable constituency interested in the
work and therefore the working group would continue
evalutaing the proposal until all aspects were well
understood.
2.4.10 James Winterbottom noted that he would discuss breaking HELD
up into multiple documents with the co-authors of the
document.
2.5 Any Other Business
2.5.1 Particpants of the ENUM working group asked that GEOPRIV
participants review the ENUM validation work and offer
suggestions or improvements on the civic schema.
|
