Subject: [Geopriv] draft minutes from IETF 64

From: Andrew Newton <[email-masked]>
Date: Fri, 9 Dec 2005 15:41:27 -0500

The minutes for the GEOPRIV sessions at IETF 64 are posted here:
http://www3.ietf.org/proceedings/05nov/minutes/geopriv.txt

Please send corrections/modifications/revised comments no later than  
12/22.

Thanks.

-andy

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: John Schnizlein <[email-masked]>
Date: Fri, 9 Dec 2005 17:12:50 -0500

> Please send corrections/modifications/revised comments no later than 

         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.

I do not believe I said what you reported.  My objection was that the 
proposal was based on the assumption that an arbitrary Location Server 
could translate an IP address into a location.  Since the 
in-feasibility of that operation has been raised and not answered, the 
elaborations in the new version do not justify advancing the proposal.

I do not recall if it was at this point or later that I explained that 
the proposed mechanism for discovery of Location Servers is not 
feasible, and that postulating complicated transactions between 
Location Servers does not resolve that problem.

         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.

I object to your characterization of this essential flaw as a "use 
case".  The proposal assumes that the Location Server is able to 
determine (through interaction with a Location Generator) the location 
of the target based on the source address of the initial transaction.  
The counter-example that was raised (at earlier IETF meetings) against 
the feasibility of this is a host with a tunneled address.  That this 
is fundamental to the proposal seems clear in the following excerpt:

    The Location Server identifies the Target based on its IP address.
    The Location Server then identifies a Location Generator for the
    Target, which determines the location of the Target.  The Location
    Server will take the generated location and produce a PIDF-LO
    document that is subsequently returned to the requesting Target.

I do not recall if it was Henning or someone else who suggested that 
the HELD proposal set out the conditions necessary for its operation in 
an Applicability Section, which could transform the in-feasibility I 
identified into limitations on applicability.  Such an applicability 
document would indicate that hosts must register with the local 
Location Server prior to establishing any tunnel, that the Location 
Generator must have undocumented means of determining location based on 
this address, and that the Location Server for any target be included 
in the Location URI.  What I describe as infeasible in general might be 
feasible in a sufficiently constrained operation.  Since my impression 
was that this was acceptable to the author, it should be included in 
the minutes.

         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.

I heard Brian's request a little differently - that we get a sense of 
the room if we wanted to pursue this effort after three versions of the 
proposal with similar concerns remaining.  While WG consensus should be 
established on its mailing list, refusal to take a sense of the room 
when requested is unusual in the IETF.   The chairs should request 
identification of the "considerable constituency" on the mailing list 
as soon as possible. It has been 4 weeks since IETF 64 ended and 
year-end holidays will be upon us soon.

John

---

From: Andrew Newton <[email-masked]>
Date: Mon, 12 Dec 2005 11:43:12 -0500

On Dec 9, 2005, at 5:12 PM, John Schnizlein wrote:
>         1.6.6 John Schnizlein noted that the function of passing  
> around a
> I do not believe I said what you reported.  My objection was that  
> the proposal was based on the assumption that an arbitrary Location  
> Server could translate an IP address into a location.  Since the in- 
> feasibility of that operation has been raised and not answered, the  
> I do not recall if it was at this point or later that I explained  
> that the proposed mechanism for discovery of Location Servers is  
> not feasible, and that postulating complicated transactions between  

That was the point you made in 2.4.5.

> case".

You can disagree with the feasibility.  But it is a use case, flawed  
or not.

> I do not recall if it was Henning or someone else who suggested  
> that the HELD proposal set out the conditions necessary for its  
> operation in an Applicability Section, which could transform the in- 
> feasibility I identified into limitations on applicability.  Such  
> an applicability document would indicate that hosts must register  
> with the local Location Server prior to establishing any tunnel,  
> that the Location Generator must have undocumented means of  
> determining location based on this address, and that the Location  
> Server for any target be included in the Location URI.  What I  
> describe as infeasible in general might be feasible in a  
> sufficiently constrained operation.  Since my impression was that  
> this was acceptable to the author, it should be included in the  
> minutes.

This was not captured by our scribes.  Can you tell me during which  
discussion of HELD this was mentioned, so that I can properly add it  
to the minutes.  Also, I'd like confirmation from James Winterbottom  
that he did agree to this proposal.

> I heard Brian's request a little differently - that we get a sense  
> of the room if we wanted to pursue this effort after three versions  
> of the proposal with similar concerns remaining.

This is a more specific statement.  If Brian doesn't object, I see no  
reason why the minutes should not be modified to reflect this more  
specific statement.

>   While WG consensus should be established on its mailing list,  
> refusal to take a sense of the room when requested is unusual in  
> the IETF.

That's your opinion.  I don't see how it relates to the minutes of  
the meeting.

>   The chairs should request identification of the "considerable  
> constituency" on the mailing list as soon as possible.

This is not a bad idea.  But I also don't see how it relates to the  
minutes of the meeting.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 13 Dec 2005 08:45:41 -0500

John correctly reflects the request I made to the chairs, and I ask that the
minutes be modified as suggested.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Andrew Newton
Sent: Monday, December 12, 2005 11:43 AM
To: John Schnizlein
Cc: GEOPRIV WG
Subject: Re: [Geopriv] draft minutes from IETF 64

-andy