Subject: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

From: Andrew Newton <[email-masked]>
Date: Tue, 17 Apr 2007 23:34:15 -0400

All,

Hopefully everybody has recovered from the IETF 68 meeting, where a  
lot of resolutions were put forward.  As is the policy of the IETF,  
all work must be conducted on the mailing list.  This means that all  
the hums taken during the meeting must be ratified on this mailing  
list.  Because so many consensus calls were taken at IETF 68, we will  
attempt to cover these in two separate messages.  This is being done  
because so many of the latter decisions are predicated on earlier  
ones.  We'd appreciate responses to this first set consensus calls no  
later than Tuesday, 24 April.

For reference, you may consult the raw minutes sent to this list by  
Robert Sparks.  Additionally, you may consult the recorded audio  
here: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/ 
ietf68-ch1-thur-am.mp3 . The questions in this email are taken from  
the audio using the raw minutes as a guide.  Because none of the  
consensus call questions were written down when presented to the  
working group, they may be slightly reworded for better readability  
in the written form.  Each question will appear with its approximate  
time in the audio recording for your reference.

The first part of the meeting focused on the future direction of the  
working group, mostly with respect to LCPs and LbyR de-referencing  
protocols.  Some of these consensus calls were validations of past  
decisions of the working group or uncontroversial issues.  These  
verifications were requested by Cullen Jennings acting as AD to the  
group.

The first question put to the group was (around 23:00 ):
   Who is in favor of having an additional IETF specified location  
configuration protocol?  (It would be additional to DHCP and would  
not deprecate DHCP). [ Note that the raw minutes say "LCP" instead of  
"DHCP". ]

The second question put to the group was (around 34:00):
   Do we want to specify a protocol profile or protocol extensions or  
protocol usage or event package within the SIP context to allow a  
subscription by a target to its location?  This would apply to both  
direct and indirect methods of obtaining subscription.

The third question put to the group was (around 39:30):
   Who is in favor of proceeding with an indirect mechanism, where  
the URL is being obtained from somewhere else, for a target to  
acquire its own location?

The fourth question put to the group was (around 40:10):
   Who would like to see the working group pursue an approach for  
direct acquisition via a subscription mechanism, meaning that the  
subscription contain sufficient information based on lower-level  
network identifiers?

The fifth question put to the group was (around 44:50):
   Who is in favor of extending protocols like DHCP for the purpose  
of carrying a URL that would be used for indirect, subscription LCP?  
[ Note that the raw minutes mention the original question. However,  
the questioned was restated before it was put to the room. ]

The sixth question put to the group was (around 46:10):
   Who is in favor of pursuing work in GEOPRIV on a solution for  
indirect LCP subscription URIs through layer 7 mechanisms?

The seventh question put to the group was (around 47:40):
   Who is in favor of pursuing an HTTP-based LCP?

The eighth question put to the group was (around 56:20):
   Is the working group ready and interested in pursuing at least  
HTTP-for-retrieval and SIP-for-subscription dereferencing mechanism  
to dereference location by references?

Again, if you wish to respond to these questions, we'd appreciate  
responses from you no later than Tuesday, 24 April.

-andy, GEOPRIV co-chair

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

---

From: Andrew Newton <[email-masked]>
Date: Wed, 18 Apr 2007 15:16:40 -0400

Just an addendum, please send ALL responses to this mailing list and  
not privately to the co-chairs.

Thanks.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 18 Apr 2007 17:30:30 -0400

I've often wondered exactly what "ratified on the list" really means, and
specifically whether it is a call for another (via email) hum, or an
agreement to accept the consensus as reported in the minutes.  I am also
confused as to whether people in the room should refrain from expressing
opinions on the list, having already participated in the meeting hum.

I am strongly in favor of accepting the consensus as called in the Prague
meeting, despite the fact that I did not hum on the side of declared
consensus in all cases.

> not deprecate DHCP). [ Note that the raw minutes say "LCP" instead of
I am in favor

> direct and indirect methods of obtaining subscription.
I am in favor

> acquire its own location?
I am in favor.  This is presence: you get a URL, you subscribe, you get
location.

> subscription contain sufficient information based on lower-level
I am opposed.  This would be a new sip based LCP.  We don't need that.

> the questioned was restated before it was put to the room. ]
I am non committal.  I don't think we really need to do this, but it causes
no harm other than complexity in the implementation

> indirect LCP subscription URIs through layer 7 mechanisms?
I am in favor

>    Who is in favor of pursuing an HTTP-based LCP?
I am in favor

> to dereference location by references?
I am in favor

Brian

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 05:52:11 -0500

[[MCD]] HUM - in favour - in particular for an additional one that works
over the IP layer.

The second question put to the group was (around 34:00):
   Do we want to specify a protocol profile or protocol extensions or  
protocol usage or event package within the SIP context to allow a  
subscription by a target to its location?  This would apply to both  
direct and indirect methods of obtaining subscription.
[[MCD]] Abstained - I'd prefer to see this defined as specifically for
tracking/triggered purposes, by the target or by separate application
client. I think this question can be deferred as an implementation
aspect following the resolution of the final question in this list.

The third question put to the group was (around 39:30):
   Who is in favor of proceeding with an indirect mechanism, where  
the URL is being obtained from somewhere else, for a target to  
acquire its own location?
[[MCD]] HUM - Against - the target should be able to obtain its location
directly as opposed to *having* to get a reference from one place then
dereferencing it at another.

The fourth question put to the group was (around 40:10):
   Who would like to see the working group pursue an approach for  
direct acquisition via a subscription mechanism, meaning that the  
subscription contain sufficient information based on lower-level  
network identifiers?
[[MCD]] HUM - in favour - in the sense that the request for location may
contain additional optional identifiers which may be used in addition to
or instead of the target IP address.

The fifth question put to the group was (around 44:50):
   Who is in favor of extending protocols like DHCP for the purpose  
of carrying a URL that would be used for indirect, subscription LCP?  
[ Note that the raw minutes mention the original question. However,  
the questioned was restated before it was put to the room. ]
[[MCD]] HUM - against - DHCP mechanism should be left as the simple
definition that it currently has - on par with LLDP-MED.

The sixth question put to the group was (around 46:10):
   Who is in favor of pursuing work in GEOPRIV on a solution for  
indirect LCP subscription URIs through layer 7 mechanisms?
[[MCD]] HUM - in favour - in the sense that location by reference should
be supported for a location server working over IP.

The seventh question put to the group was (around 47:40):
   Who is in favor of pursuing an HTTP-based LCP?
[[MCD]] HUM - in favour - for location requests by value and for
dereferencing with an immediate response form.

The eighth question put to the group was (around 56:20):
   Is the working group ready and interested in pursuing at least  
HTTP-for-retrieval and SIP-for-subscription dereferencing mechanism  
to dereference location by references?
[[MCD]] HUM - in favour - with the HTTP mechanism providng the immediate
response form and the SIP subscription providing deferred and periodic
response forms.

-andy, GEOPRIV co-chair

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 19 Apr 2007 13:18:08 -0500

>not deprecate DHCP). [ Note that the raw minutes say "LCP" instead of

JMP - against

>acquire its own location?

JMP - confused -- LbyR is indirect by definition, so I don't 
understand the difference between this question and having LbyR 
(unless this is asking if an LbyR should be retained - which I agree with)

>indirect LCP subscription URIs through layer 7 mechanisms?

JMP - opposed

>   Who is in favor of pursuing an HTTP-based LCP?

JMP - opposed

>to dereference location by references?

JMP - confused -- this question isn't worded in a way I can 
parse.  Here's a rewording I do understand:

         Is the Geopriv WG interested in creating a (SIP and
         HTTP-based) subscription solution for location
         dereference?

If this rewording means the same as the above, then I am for it, if 
not, I at least abstain and might oppose it.

---

From: John Schnizlein <[email-masked]>
Date: Thu, 19 Apr 2007 15:54:23 -0400

answers embedded in context below:

On Apr 17, 2007, at 11:34 PM, Andrew Newton wrote:

> all work must be conducted on the mailing list.

It is gratifying that a GeoPriv WG chair has embraced this  
fundamental concept.

> This means that all the hums taken during the meeting must be  
> ratified on this mailing list.  Because so many consensus calls  
> were taken at IETF 68, we will attempt to cover these in two  
> separate messages.  This is being done because so many of the  
> latter decisions are predicated on earlier ones.  We'd appreciate  
> responses to this first set consensus calls no later than Tuesday,  
> 24 April.

An arbitrary partitioning of the sequence of questions called in the  
meeting, where the questions appear to have depended on the previous  
in-the-room answers, is not consistent with the open process that is  
expected.

While ratification of a clear question at a meeting might be a  
reasonable substitute for clearly calling the question on the list,  
simple ratification is not appropriate where a succession of many  
questions was determined in the meeting.  Instead, what is required  
for an open process is that each question on which the direction of  
the WG depends should be stated clearly, with a summary of the  
arguments that have been presented.  Each question deserves its own  
thread.  Questions that do not determine the direction of the WG, but  
were only guiding the development of the arguments, need not be  
called because they will not establish consensus positions.

> in the written form.

Rewording questions while pretending that they are ratifications of  
what transpired in the meeting demonstrates that the process is flawed.

> Each question will appear with its approximate time in the audio  
> recording for your reference.
>
> The first part of the meeting focused on the future direction of  
> the working group, mostly with respect to LCPs and LbyR de- 
> referencing protocols.  Some of these consensus calls were  
> validations of past decisions of the working group or  
> uncontroversial issues.  These verifications were requested by  
> Cullen Jennings acting as AD to the group.
>
> not deprecate DHCP). [ Note that the raw minutes say "LCP" instead  
> of "DHCP". ]

The form of this question is not consistent with the way the IETF  
acts.  Questions should not be matters of preference but of technical  
analysis, or at least opinion.  A reasonable question that might  
reflect what is listed here might be this:

"Who agrees that the need for additional protocol specification  
beyond those the WG has adopted has been technically justified?"

My answer would be No.

>   Do we want to specify a protocol profile or protocol extensions  
> or protocol usage or event package within the SIP context to allow  
> a subscription by a target to its location?  This would apply to  
> both direct and indirect methods of obtaining subscription.

This question appears to combine different issues (possibly laying a  
hidden foundation for some other agenda in the vague "indirect  
methods") without clearly asking the technical question:

"Who agrees that the SIP presence subscription protocols provide a  
sufficient mechanism for the use cases not covered by hosts  
controlling their own location information?"

My answer would be Yes - excluding the insidious "indirect methods".

> acquire its own location?

This question is the epitome of vagueness, appearing to open the door  
to some unspecified indirection with unknown implications.

My answer would be No.

> subscription contain sufficient information based on lower-level  

This question confounds questions about subscription methods with low- 
level network identifiers, which are not specified and the subject of  
extensive discussion.  Furthermore the subscription question is not  
clearly distinct from question 2.

My answer to subscription mechanism would be Yes; to unspecified  
lower-level identifiers, No.

> of carrying a URL that would be used for indirect, subscription  
> LCP? [ Note that the raw minutes mention the original question.  
> However, the questioned was restated before it was put to the room. ]

Since there has been no justification for any change to the DHCP  
options adopted by the WG, this question should have been never been  
called.  Adding extensions to the part of its work that the WG has  
finished without justification rather than completing other work that  
has languished would be a mistake.

> indirect LCP subscription URIs through layer 7 mechanisms?

This begs the question of any real requirement for indirect  
mechanisms.  Burying a question - on which the WG has established a  
Design Team that has not reached consensus - somewhere in the middle  
of a sequence of other questions looks like sleight of hand.

>   Who is in favor of pursuing an HTTP-based LCP?

Since the WG has a long history of debate of "using" and "carrying"  
protocols, the apparent simplicity of this question appears to be a  
stalking horse for an unstated agenda.  The individual-submission  
HELD proposals, for which fundamental technical questions remain  
unanswered since its first introduction, seems (from comments on the  
mailing list) to be that stalking horse.  Here again, the technical  
requirement should be established before questions about superficial  
aspects of a proposed solution are called.

My answer would be No.

> to dereference location by references?

Again, the requirement for location-by-reference, which is at the  
kernel of this question, has not been established.  The Design Team  
failed to address whether there was a real need for this, and instead  
described the requirements for a protocol as if that protocol were  
necessary.  That people attending the meeting - and on the instant- 
messaging - want to pursue specification of mechanisms without a  
requirement should not drive an IETF WG.

My answer would be No.

> responses from you no later than Tuesday, 24 April.

It is amazing that such a short deadline would be imposed on an  
omnibus set of decisions when many of these issues have been  
discussed - and could have been closed - for years.  For example, the  
Chair refused to ask for the sense of the room when requested by  
multiple participants at IETF 64, then refused to call for consensus  
on the mailing list.  A request to identify the "considerable  
constituency" that opposed calling the question in January 2006 was  
set aside because the Chair asked for separation into discrete  
proposals.

Short deadlines now when interminable delays and resubmissions were  
the norm for years adds to the irregularities already identified with  
this WG in Prague.

John

---

From: Andrew Newton <[email-masked]>
Date: Thu, 19 Apr 2007 16:45:48 -0400

On Apr 19, 2007, at 3:54 PM, John Schnizlein wrote:

> An arbitrary partitioning of the sequence of questions called in  
> the meeting, where the questions appear to have depended on the  
> previous in-the-room answers, is not consistent with the open  
> process that is expected.

It's not arbitrary, really.  Simply put, these constitute the first  
half of the questions.  If I've missed your point, then can you  
please restate this aspect of your concern.

> thread.  Questions that do not determine the direction of the WG,  
> but were only guiding the development of the arguments, need not be  

Again, I'm probably missing your point.  However, if there are others  
in the working group supportive of separate threads, we can break  
each of these questions out into separate threads.

>> For reference, you may consult the raw minutes sent to this list  
>> by Robert Sparks.  Additionally, you may consult the recorded  
>> audio here: http://limestone.uoregon.edu/ftp/pub/videolab/media/ 
>> ietf68/ietf68-ch1-thur-am.mp3 . The questions in this email are  
>> taken from the audio using the raw minutes as a guide.  Because  
>> none of the consensus call questions were written down when  
>> presented to the working group, they may be slightly reworded for  
>> better readability in the written form.
>

Again, I'm not understanding your point.  However, if you find any of  
differences of importance to you between what is being asked in  
email, what appears in the audio recordings, and what appears in the  
raw minutes, I urge you to point them out.  For your reference, a  
link to the audio recording has been provided, and each question  
lists the time within the recording where it can be found.

> the norm for years adds to the irregularities already identified  
> with this WG in Prague.

If others are supportive of moving the deadline out by another week  
(i.e moving it to Tuesday, 1 May 2007), then we will do so.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 16:20:48 -0500

Well, John, these questions have been discussed for two years now. DHCP
is not adequate because it doesn't meet multiple sets of requirements as
documented multiple times (doesn't work for most forms of broadband
access, isn't suitable for wireless, requires changes to residential and
enterprise CPE which obviates the ability to location enable Internet
access in anything but the very long term, doesn't support the integrity
mechanisms requested by the North American emergency service
community...).

You can talk about "stalking horses" and the like all you want - this is
another example of ad hominem rhetoric - preferring to cast aspersions
on forum participants than engage in the actual technical discussions.

I don't think that there's any point in continuing the debates within
Geopriv for another two years since presumably you'll continue to
dismiss the requirements that have been articulated and continue to make
vague accusations about agendas.

We have the opportunity to progress the discussion toward something
which many stakeholders in the industry feel a genuine need for. I felt
optimistic after the plenary that we could finally put the BS behind us
get something functional completed. It seems your preference is to undo
all that?

Cheers,
Martin

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 5:54 AM
To: Andrew Newton
Cc: GEOPRIV WG; Allison Mankin
Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group
Hums

My answer would be No.

My answer would be No.

My answer would be No.

My answer would be No.

John

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 19 Apr 2007 16:30:38 -0500

At 04:20 PM 4/19/2007, Dawson, Martin wrote:
>"DHCP is not adequate because it doesn't meet multiple sets of 
>requirements as documented multiple times ..."

bologna

"documented multiple times" means in individual submissions

of which, zero facts were presented to substantiate

If DHCP were so inadequate, why is the DSL forum now going to specify 
it? Why does PacketCable define it?  These were fairly recent moves...

And, how many times has HELD been presented as if it were a product 
of an IETF WG?

James

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 16:34:29 -0500

Does DHCP require a change to the residential CPE James? How long is it
going to take to change every residential router in the world? Do you
think it is an unreasonable requirement to not have to do this?

You can't just object to HELD on the basis that you think it's been
misrepresented. I don't accept that it has - but in any case, it's not a
technical rationale.

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 7:31 AM
To: Dawson, Martin; John Schnizlein; Andrew Newton
Cc: GEOPRIV WG; Allison Mankin; [email-masked]
Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group
Hums

bologna

James

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 19 Apr 2007 16:43:08 -0500

Martin

Exactly what products support HELD right now?

If you want location verification and location signing - are these 
deployed today?

Doesn't all these mean something has to be changed or upgraded?

Broadband providers in the US have given away FREE home routers to 
enable a service as recently as a year ago.  So, taking the stance 
that this won't happen is looking facts to the contrary in the eye 
and saying "that didn't happen" *or* "that's not going to happen"....

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 16:49:44 -0500

Pretty close to as many as support 3825 I'd expect.

The point of an "L7 LCP" is that it doesn't require changes to the CPE,
amongst other things.

So your agenda is to make carriers buy new residential routers for
everyone in the world? And you think that's a reasonable requirement? I
guess that could make sense... considering the source.

I think that broadband carriers in any given national jurisdiction could
introduce a functional L7 LCP service in less than twelve months. They'd
need to do pretty much what they need to do for DHCP except change all
their subscribers' CPE - and do all the interop with multiple vendors of
residential CPE.

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 7:43 AM
To: Dawson, Martin; John Schnizlein; Andrew Newton
Cc: GEOPRIV WG; Allison Mankin; [email-masked]
Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group
Hums

Martin

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Apr 2007 20:46:07 -0400

In the example you gave the Hilton is EXACTLY the network that MUST give you
your location, and Verisign, if they tried, would give a valid, but very
wrong location.

That is the point of using DHCP for location, you need the closest possible
server to get the right location.  You need a server that understands the L2
to which you are connected.  Anything L3 and farther has a big problem of
where, exactly, are you?  The proposals for L7 versions of location
configuration protocols suffer mightily from the problem of figuring out
where you are in the L2.  They have to go to great lengths to determine some
kind of identifier that they can unambiguously use to figure that out.  I
think we have (painfully) figured out a way though that morass that will
work in enough circumstances to be interesting, but it remains hard, very
hard, to identify the L2 when your server is sitting at L7.

So, make sure that when you go to the Hilton that you use it's location
server, or you may have a big problem if you have to make an emergency call
(or even order a pizza).

DHCP is an excellent choice for a location server for networks where the
DHCP infrastructure is present, and can reasonably be upgraded.  The L7 guys
point out, correctly, that that's a tall order in a lot of interesting
networks.  I think that is right.  I do think they believe L7 works on every
network.  I'm certain it doesn't.  

That's why the compromise of BOTH is probably required.  I know it's the
only way we are going to get anything done in the next year.

Brian

> From: Hallam-Baker, Phillip [mailto:[email-masked]]
> Sent: Thursday, April 19, 2007 6:39 PM
> To: James M. Polk; Dawson, Martin; John Schnizlein; Andrew Newton
> Cc: GEOPRIV WG; [email-masked]; Allison Mankin
> Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
> 
> DHCP is a layer 3 technology that talks directly to layer 2.
> 
> This is entirely acceptable, useful and right for NETWORK configuration.
> DHCP is an entirely sensible means of obtaining an IP address and
> _proposals_ for domain name prefixes and DNS servers.
> 
> DHCP should not be used for any other purpose. In particular to make use
> of DHCP for application configuration is a layer violation. Layer 7 should
> NEVER communicate with Layer 2 directly. When that happens we lose all the
> power and flexibility built into the IP stack.
> 
> 
> To give a concrete example of the problems caused. I am currently typing
> on a VeriSign machine in an office in VeriSign corporate HQ. In that
> environment the local DHCP server could provide me with useful and valid
> suggestions for all manner of services. But its still the wrong
> technology.
> 
> The problem is that when I take the machine to the Hilton Garden Inn down
> the road where I am staying I explicitly DO NOT want the hotel network to
> provide any more than an IP address. I am not going to use their DNS
> server and I certainly don't want to make use of any email server, DNS
> prefix, GEOPRV or any other application layer feature they might want to
> foist onto me.
> 
> I am using the Hilton Garden Inn LAN, I am not joining their network. The
> machine is remaining on the VeriSign network.
> 
> 
> DHCP is a fine technology for the task DHCP is designed to do. It is an
> inappropriate technology for application or service configuration. The
> proper infrastructure to support those needs is DNS, supplemented if
> necessary by HTTP or LDAP backing store (i.e. either discover the services
> via DNS directly or use DNS to discover where the directory service is to
> be found).
> 
> Looking at the history of UPnP and Zero Config it strikes me that
> attempting to manage networks through peer to peer broadcast or multicast
> have been a bust precisely because of this layer violation.
> 
> 
> > Sent: Thursday, April 19, 2007 5:31 PM
> > Cc: GEOPRIV WG; [email-masked]; Allison Mankin
> > Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68
> > Working Group Hums
> >
> > If DHCP were so inadequate, why is the DSL forum now going to
> > specify it? Why does PacketCable define it?  These were
> > fairly recent moves...
> >
> > And, how many times has HELD been presented as if it were a
> > product of an IETF WG?
> >
> > James
> >
> >
> > Ietf mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ietf
> >
> 
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Apr 2007 09:21:02 +0200

DHCP is not a great choice in a mobile environment and also not when it 
comes to more complex location representations.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Apr 2007 09:37:31 +0200

Hi Andy,

here is my response. I was not at the IETF#68 GEOPRIV meeting.

Andrew Newton wrote:
> Robert Sparks.  Additionally, you may consult the recorded audio here: 
> http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/ietf68-ch1-thur-am.mp3 
> . The questions in this email are taken from the audio using the raw 
> minutes as a guide.  Because none of the consensus call questions were 
> written down when presented to the working group, they may be slightly 
> reworded for better readability in the written form.  Each question 
> will appear with its approximate time in the audio recording for your 
> reference.
>
> configuration protocol?  (It would be additional to DHCP and would not 
> deprecate DHCP). [ Note that the raw minutes say "LCP" instead of 
> "DHCP". ]
>
YES

> direct and indirect methods of obtaining subscription.
YES
>   Who is in favor of proceeding with an indirect mechanism, where the 
> URL is being obtained from somewhere else, for a target to acquire its 
> own location?
>
YES

> subscription contain sufficient information based on lower-level 
YES; this is the LocationRef mechanism.

>   Who is in favor of extending protocols like DHCP for the purpose of 
> carrying a URL that would be used for indirect, subscription LCP? [ 
> Note that the raw minutes mention the original question. However, the 
> questioned was restated before it was put to the room. ]
Ok. Why not.
YES

> indirect LCP subscription URIs through layer 7 mechanisms?
YES

>   Who is in favor of pursuing an HTTP-based LCP?
YES

> HTTP-for-retrieval and SIP-for-subscription dereferencing mechanism to 
> dereference location by references?
>
YES

Ciao
Hannes

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 20 Apr 2007 08:03:09 -0500

3825 can actually only represent uncertainty to the extent that it can
be conveyed by precision. This makes it unsuitable for the sort of
arbitrary uncertainty around arbitrary location values you refer to.

Cheers,
Martin

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 10:59 PM
To: Hannes Tschofenig
Cc: Brian Rosen; 'GEOPRIV WG'; Dawson, Martin; [email-masked]; 'Allison
Mankin'; 'John Schnizlein'
Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group
Hums

> comes to more complex location representations.

Why can't a mobile system have a locally valid DHCP record (+/- the
length
of a wireless link)? For that matter, why couldn't a DHCP server have
real-time triangulation data, if it exists at all?

Do you mean more complex than can be expressed by RFC 4776 and RFC 3825
together?

     Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Apr 2007 09:25:21 -0400

Agree that 3825 doesn't have the ability to express uncertainty and
confidence.  I don't wish to enhance it to do so at this time.

However, a triangulated WiFi location may have sufficiently low uncertainty
that it could be used for many purposes, including emergency calling,
without reporting what the actual uncertainty was.

In order to actually be useful if the endpoint was mobile, the endpoint
would have to implement a location update, since only it can requery DHCP to
get a new location.  The device that does the triangulation may not be
connected to the DHCP infrastructure.  In these circumstances, HELD may be a
better choice

Also, the most common initial deployments of WiFi will be that the clients
of an AP are given the location of the AP they are connected to as their
location, and that will often be civic.  RFC4776 would work well there.  I
expect that will be a very common deployment model.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Friday, April 20, 2007 9:03 AM
> To: Brian E Carpenter; Hannes Tschofenig
> Cc: Brian Rosen; GEOPRIV WG; [email-masked]; Allison Mankin; John
> Schnizlein

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Apr 2007 15:34:47 +0200

Hi Brian,

I quickly respond to your question but I do not plan to restart the last 
2 years of GEOPRIV discussions.
(I personally got the impression that the work on a GEOPRIV Layer 7 LCP 
solution was not really subject for discussion anymore. I acknowledge 
the fact that some folks still don't agree but most of the GEOPRIV 
working group members do. The main issue was which solution proposal to 
pick as a baseline for future work.)

Brian E Carpenter wrote:
>> DHCP is not a great choice in a mobile environment and also not when 
>> it comes to more complex location representations.
>
I should have written "RFC 3825 is not a great choice in a cellular 
environment". It is fine for a WLAN hotspot and an enterprise environment.
where it also competes with other layer 2 location configuration 
mechanisms and LLDP-MED.

> Do you mean more complex than can be expressed by RFC 4776 and RFC 
> 3825 together?
>
RFC 3825 describes a point.
Civic address formats (RFC 4776) have good applicability in fixed and 
some selected wireless environments (WLAN  hotspot).
They haven't been considered in the cellular space.

Location determination techniques produce other shape types. Please look at
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Apr 2007 09:43:30 -0400

The cable systems use the MAC address of the DOCSIS modem to determine which
subscriber is asking for location.  It's not perfect, because it is possible
to move a DOCSIS cablemodem from one house to another within some area
(often the service area of the CMTS, but in many systems, less than that).
The ability to move without detection is a problem the have for other
revenue sources and there is some effort being put into systems to detect
that kind of thing.  The incidence of moving the cablemodem without notice
is apparently very small.

You don't get the location of the server, you get the location of the
client.

Brian

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, April 20, 2007 9:39 AM
> To: Brian E Carpenter
> Cc: 'GEOPRIV WG'; 'Dawson,Martin'; [email-masked]; 'Allison Mankin'; 'John
> Schnizlein'
> Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
> 
> Brian E Carpenter wrote:
> If you look at DOCSIS cable, a single head end can subtend a huge amount
> of cable in a single bridged domain. I seem to recall that in a rural
> Canadian
> MSO I worked with it was 10's if not 100's of miles. I have no clue how
> accurate GEOPRIV tries to be, but it sure seems that if the location of
> the
> headend/dhcp relay is only piece of information you have, your accuracy is
> going to be pretty lousy in many cases. If this information is intended
> for
> first responders, it seems that all you're doing is pointing to the
> right haystack
> to start searching for the needle.
> 
>        Mike, who probably shouldn't open his mouth here
>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Apr 2007 10:29:57 -0400

Yup.

There are no mechanisms that work when the Pringles cans come out other than
actual endpoint measuring mechanisms (like GPS), which have their own
limitations.  The standards recommend methods for users to override the
automatic mechanisms when they do things like Pringle can extensions.  There
are a set of security issues on THAT, but it's still a workable notion.

The Cablelabs guys and individual MSOs have looked at this, and most believe
they can deploy a DHCP based location infrastructure that works pretty well.
The "pretty" part is mostly the problem of cablemodem moving.  Nothing is
perfect, nor does it need to be.  I think it's good enough, although I'd
really like them to be advancing on detecting cablemodem moves.  At least
that error source is a deliberate user action which is really already
prohibited by contract.

This whole area is complex because there isn't anything that works always.
There have to be options, both for access network operators, device
manufacturers and even end users to deal with all the variations in reality
that occur.

And again, nothing is going to be perfect.

Brian

> Sent: Friday, April 20, 2007 10:14 AM
> To: Brian Rosen
> Cc: 'Brian E Carpenter'; 'GEOPRIV WG'; 'Dawson,Martin'; [email-masked];
> 'Allison Mankin'; 'John Schnizlein'
> That's only because there's an out of band arrangement with the MSO
> and the subscriber. DHCP itself gives no such information. Wireless
> substantially confuses the matter too. All it takes is two Pringle's cans
> to cast that relationship in doubt.
> 
>        Mike
> > Brian
> >
> >

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 20 Apr 2007 13:49:42 -0400

My responses are below, but I first wanted to thank the area directors
and chairs for the job they've been doing. Trying to herd cats is very
difficult.

I, for one, believe that all that was done, was done in attempt to do
what is right, for all the people who find themselves needing emergency
services and for the industry as a whole. I also think they're human and
imperfect, and thus, are no better than I am, with one major exception:
I've always been unwilling to accept the job of chair or leader in any
standards body that I've participated in. I've found that it's so much
easier and less stressful to criticize the leadership when I don't like
what they're doing, rather than to be one myself. 

So, I just wanted to say "Thanks" to Jon, Cullen, and all the chairs. I
think you're getting the right things done, and I appreciate your
suffering through all this to get it done.
Barbara

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 11:34 PM
To: GEOPRIV WG
Cc: Allison Mankin
Subject: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

All,

Hopefully everybody has recovered from the IETF 68 meeting, where a lot
of resolutions were put forward.  As is the policy of the IETF, all work
must be conducted on the mailing list.  This means that all the hums
taken during the meeting must be ratified on this mailing list.  Because
so many consensus calls were taken at IETF 68, we will attempt to cover
these in two separate messages.  This is being done because so many of
the latter decisions are predicated on earlier ones.  We'd appreciate
responses to this first set consensus calls no later than Tuesday, 24
April.

For reference, you may consult the raw minutes sent to this list by
Robert Sparks.  Additionally, you may consult the recorded audio
here: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/
ietf68-ch1-thur-am.mp3 . The questions in this email are taken from the
audio using the raw minutes as a guide.  Because none of the consensus
call questions were written down when presented to the working group,
they may be slightly reworded for better readability in the written
form.  Each question will appear with its approximate time in the audio
recording for your reference.

[BHS] Yes

[BHS] No opinion

The third question put to the group was (around 39:30):
   Who is in favor of proceeding with an indirect mechanism, where the
URL is being obtained from somewhere else, for a target to acquire its
own location?
[BHS] Yes -- To me this sounded like an LCP responding with a reference,
that the target could then try to dereference. The device and the
protocol don't care what the reference points to, so long as it works. I
suspect part of the delay that was seen in responding to this question
(which caused hums to appear to be in response to the next question) was
due to the fact that this question's meaning wasn't completely clear.
People had to think about what it meant to them. I think it still isn't
clear. Brian, Martin Dawson, and I all seem to interpret it differently.
This direct vs. indirect stuff is confusing. 

The fourth question put to the group was (around 40:10):
   Who would like to see the working group pursue an approach for direct
acquisition via a subscription mechanism, meaning that the subscription
contain sufficient information based on lower-level network identifiers?
[BHS] I didn't understand what this was asking the first time (listening
to audio and reading the jabber scribe), and I still don't -- no
opinion. I guess this goes back to not really understanding the previous
question, either.

The fifth question put to the group was (around 44:50):
   Who is in favor of extending protocols like DHCP for the purpose of
carrying a URL that would be used for indirect, subscription LCP?  
[ Note that the raw minutes mention the original question. However, the
questioned was restated before it was put to the room. ]
[BHS] I don't care. But I hope that doing this wouldn't interfere with
other work.

[BHS] Yes

[BHS] Yes

[BHS] Yes

-andy, GEOPRIV co-chair

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: Ralph Droms <[email-masked]>
Date: Fri, 20 Apr 2007 13:57:05 -0400

Huh?  DHCP is carried in UDP and IP.  There is a little funkiness in the
DHCPv4 transport, which we wouldn't have need if IPv4 link-local addresses
had been defined when RFC 2131 was published.  DHCPv6 uses link-local
addresses and garden-variety IPv6.

- Ralph

On 4/20/07 1:48 PM, "Hallam-Baker, Phillip" <[email-masked]> wrote:

>  
> 
>> From: David W. Hankins [mailto:[email-masked]]
> 
>> On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote:
>> DHCP is a technology that dynamically configures hosts.
> 
> That's not the point, the point here is that DHCP is not an Internet protocol.
> It is an IETF protocol but not an Internet protocol. It does not layer on the
> IP stack.
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 14:01:02 -0400

Please consult RFC 2131:

DHCP uses UDP as its transport protocol.  DHCP messages from a client
    to a server are sent to the 'DHCP server' port (67), and DHCP
    messages from a server to a client are sent to the 'DHCP client'  
port
    (68). A server with multiple network address (e.g., a multi-homed
    host) MAY use any of its network addresses in outgoing DHCP  
messages.

I don't know if UDP counts as an Internet protocol in your book.

On Apr 20, 2007, at 1:48 PM, Hallam-Baker, Phillip wrote:

> That's not the point, the point here is that DHCP is not an  
> Internet protocol. It is an IETF protocol but not an Internet  
> protocol. It does not layer on the IP stack.
>
>

---

From: Ralph Droms <[email-masked]>
Date: Fri, 20 Apr 2007 14:02:18 -0400

Set up the relay agent in your router to point at my DHCP server.

- Ralph

On 4/20/07 1:59 PM, "Hallam-Baker, Phillip" <[email-masked]> wrote:

> OK how do I DHCP to the server on your network from my desk here?
> 
> (assuming that there are no NATs or firewalls)
> 
> If it was pure IP it would work.
> 
>> From: Ralph Droms [mailto:[email-masked]]
>> Sent: Friday, April 20, 2007 1:57 PM
>> To: Hallam-Baker, Phillip; David W. Hankins; [email-masked]
>> Cc: GEOPRIV WG
>> DHCPv4 transport, which we wouldn't have need if IPv4
>> link-local addresses had been defined when RFC 2131 was
>> published.  DHCPv6 uses link-local addresses and garden-variety IPv6.
>> 
>> - Ralph
>> 
>> 
>> Internet protocol.
>>> It is an IETF protocol but not an Internet protocol. It
>> does not layer 
>>> on the IP stack.
>>> 
>>>

---

From: <[email-masked]>
Date: Fri, 20 Apr 2007 17:01:29 -0400

Hi Andy,

Please find below my position on the questions posed.

Best regards,

Guy Caron

-----Message d'origine-----
De : Andrew Newton [mailto:[email-masked]] 
Envoyé : 17 avril 2007 23:34
À : GEOPRIV WG
Cc : Allison Mankin
Objet : [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

[GC] In favour.

[GC] I'm technically supportive but it would be very helpful that both direct and indirect methods referred in this question be better explained by the author to make sure we all have a common understanding.

[GC] In favour (based on my understanding)

[GC] No opinion

[GC] I have no use for it but can see the global benefit

[GC] In favour (again, based on my understanding of indirect)

[GC] In favour

[GC] In favour

-andy, GEOPRIV co-chair

---

From: <[email-masked]>
Date: Fri, 20 Apr 2007 18:21:46 -0400

Patricia Berry

Regional Manager 9-1-1 Ontario

100 Dundas Street

Flr 7 Red

London, Ontario

519-663-7619

https://www.interaction.bell.ca/

NOTICE:

The information contained in this message is proprietary to Bell Canada
and may not be used, reproduced or disclosed to others except as
specifically permitted in writing by the originator of the information
as it contains restricted information which is not to be disclosed. The
recipient of this information, by its retention and use, agrees to
protect the same and the information contained therein from loss, theft
or compromise. If you are not the intended recipient of this message or
their authorized representative, please contact the author and destroy
this message.

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: April 17, 2007 11:34 PM
To: GEOPRIV WG
Cc: Allison Mankin
Subject: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

All,

HUM
ABSTAIN

HUM

ABSTAIN
ABSTAIN

HUM

HUM

HUM

-andy, GEOPRIV co-chair

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 20 Apr 2007 15:37:26 -0700

Please find my responses inline.

-roger marshall. 

>Sent: Tuesday, April 17, 2007 8:34 PM
>To: GEOPRIV WG
>Cc: Allison Mankin
>Hopefully everybody has recovered from the IETF 68 meeting, 
>where a lot of resolutions were put forward.  As is the policy 
>of the IETF, all work must be conducted on the mailing list.  
>ratified on this mailing list.  Because so many consensus 
>calls were taken at IETF 68, we will attempt to cover these in 
>two separate messages.  This is being done because so many of 
>the latter decisions are predicated on earlier ones.  We'd 
>appreciate responses to this first set consensus calls no 
>For reference, you may consult the raw minutes sent to this 
>list by Robert Sparks.  Additionally, you may consult the 
>recorded audio
>ietf68-ch1-thur-am.mp3 . The questions in this email are taken 
>from the audio using the raw minutes as a guide.  Because none 
>of the consensus call questions were written down when 
>presented to the working group, they may be slightly reworded 
>for better readability in the written form.  Each question 
>will appear with its approximate time in the audio recording 
>for your reference.
>
>The first part of the meeting focused on the future direction 
>of the working group, mostly with respect to LCPs and LbyR 
>de-referencing protocols.  Some of these consensus calls were 
>   Who is in favor of having an additional IETF specified 
>location configuration protocol?  (It would be additional to 
>DHCP and would not deprecate DHCP). [ Note that the raw 
>minutes say "LCP" instead of "DHCP". ]

[RM - Support.]

>   Do we want to specify a protocol profile or protocol 
>extensions or protocol usage or event package within the SIP 
>context to allow a subscription by a target to its location?  
>This would apply to both direct and indirect methods of 
>obtaining subscription.

[RM - Support.]

>   Who is in favor of proceeding with an indirect mechanism, 
>where the URL is being obtained from somewhere else, for a 
>target to acquire its own location?

[RM - Support.]

>   Who would like to see the working group pursue an approach 
>for direct acquisition via a subscription mechanism, meaning 
>that the subscription contain sufficient information based on 
>lower-level network identifiers?

[RM - Support.]

>   Who is in favor of extending protocols like DHCP for the 
>purpose of carrying a URL that would be used for indirect, 
>subscription LCP?  
>[ Note that the raw minutes mention the original question. 

[RM - Not opposed to.]

>   Who is in favor of pursuing work in GEOPRIV on a solution 
>for indirect LCP subscription URIs through layer 7 mechanisms?

[RM - Support.]

>   Who is in favor of pursuing an HTTP-based LCP?

[RM - Support.]

>   Is the working group ready and interested in pursuing at 
>least HTTP-for-retrieval and SIP-for-subscription 
>dereferencing mechanism to dereference location by references?

[RM - Support.]

>
>Again, if you wish to respond to these questions, we'd 
>appreciate responses from you no later than Tuesday, 24 April.
>
>-andy, GEOPRIV co-chair
>

The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 19 Apr 2007 15:38:40 -0700

This is entirely acceptable, useful and right for NETWORK configuration. DHCP is an entirely sensible means of obtaining an IP address and _proposals_ for domain name prefixes and DNS servers.

DHCP should not be used for any other purpose. In particular to make use of DHCP for application configuration is a layer violation. Layer 7 should NEVER communicate with Layer 2 directly. When that happens we lose all the power and flexibility built into the IP stack. 

To give a concrete example of the problems caused. I am currently typing on a VeriSign machine in an office in VeriSign corporate HQ. In that environment the local DHCP server could provide me with useful and valid suggestions for all manner of services. But its still the wrong technology.

The problem is that when I take the machine to the Hilton Garden Inn down the road where I am staying I explicitly DO NOT want the hotel network to provide any more than an IP address. I am not going to use their DNS server and I certainly don't want to make use of any email server, DNS prefix, GEOPRV or any other application layer feature they might want to foist onto me. 

I am using the Hilton Garden Inn LAN, I am not joining their network. The machine is remaining on the VeriSign network.

DHCP is a fine technology for the task DHCP is designed to do. It is an inappropriate technology for application or service configuration. The proper infrastructure to support those needs is DNS, supplemented if necessary by HTTP or LDAP backing store (i.e. either discover the services via DNS directly or use DNS to discover where the directory service is to be found).

Looking at the history of UPnP and Zero Config it strikes me that attempting to manage networks through peer to peer broadcast or multicast have been a bust precisely because of this layer violation.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 19 Apr 2007 16:47:26 -0700

If a host has a configuration knob that might reasonably and
properly be set by the systems administrator or the network you
are presently attached to, then it is reasonable and proper to
configure it via DHCP.

DHCP would be the wrong tool to configure how, in what frequency,
or in what manner an application would directly contact a specific
remotely administered service, such as a distant web server.  DNS
would be the correct tool for that sort of job, having as it does
a global reach, and fate sharing.

If GEOPRIV is truthfully a global service the client communicates
with directly without the local network operator's involvement,
then I think it should be configured by whatever global distribution
means is reasonable.

My impression is that GEOPRIV is a service that is provided by
the local network to which the client is attached, and as such
under the purview of that network's operator and DHCP, but I admit
to not following it very closely.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Apr 2007 14:58:37 +0200

> comes to more complex location representations.

Why can't a mobile system have a locally valid DHCP record (+/- the length
of a wireless link)? For that matter, why couldn't a DHCP server have
real-time triangulation data, if it exists at all?

Do you mean more complex than can be expressed by RFC 4776 and RFC 3825 together?

     Brian

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Apr 2007 06:38:55 -0700

If you look at DOCSIS cable, a single head end can subtend a huge amount
of cable in a single bridged domain. I seem to recall that in a rural 
Canadian
MSO I worked with it was 10's if not 100's of miles. I have no clue how
accurate GEOPRIV tries to be, but it sure seems that if the location of the
headend/dhcp relay is only piece of information you have, your accuracy is
going to be pretty lousy in many cases. If this information is intended for
first responders, it seems that all you're doing is pointing to the 
right haystack
to start searching for the needle.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Apr 2007 07:14:27 -0700

Mike

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 20 Apr 2007 10:48:14 -0700

> DHCP is a technology that dynamically configures hosts.

That's not the point, the point here is that DHCP is not an Internet protocol. It is an IETF protocol but not an Internet protocol. It does not layer on the IP stack.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 20 Apr 2007 10:59:31 -0700

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 20 Apr 2007 12:03:50 -0700

> Set up the relay agent in your router to point at my DHCP server.

There are also DHCPINFORM (v4) and Information-Request (v6) messages
which can transit the public Internet.  I think however, v4 fails
with NAT.

They are also not widely used for this purpose at the moment.

I was thinking about this while swimming yesterday.

Phillip's abstract problem is that multiple administrative domains
exist.

There is the physically attached network, which represents one
administrative domain which reaches to every place the broadcast
domain touches.  Someone is responsible for that network, and
the services it provides which facillitate access.

There is his 'home' network, which represents a second administrative
domain.

There is his 'work' network, which represents a final third domain
(or more).

It is likely that each of these three domains will wish to present
dynamic configuration contents.

One subset of them are only contextually useful when the physical and
administrative domains match (such as "what's the default gateway?"
and "where on earth is the network port I'm attached to?").

A second subset of them are contextually useful no matter where on the
Internet Phillip's laptop is connected (such as "where is my Inbox?"
or "where should I send my lat/long to?").

Right now, DHCP(v4|v6) has only been used to solve for the case where
the physical and administrative domains match.  Operationally.

DHCPv6 could easily be used for the case where the administrative
domain is extra to the physical broadcast domain by making use
of the Information-Request, and sorting values fetched this way
ahead of values got off the link.

DHCPv4 could potentially also be used for the same case, as the same
message exists, but we would need to introduce a signal for alternative
server behaviour ("reply to source address and port") to work around
NAT if that were desirable.

Both would require a single manual configuration element - the
address(es) of the DHCP servers the laptop wishes to acquire
super-administrative configuration from.  Probably delivered as
a domain name, possibly also advertised eg via DHCP while the
client is on the administrative domain's physical links.

Firewalls or NAT, even if a problem, really aren't, since software can
cache old values until it can freely observe the system again.  This
is just the same as network partition or packet loss problems.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 20 Apr 2007 12:38:14 -0700

I'm sorry this reply is late.  I suspect you were stuck in ISC's
greylisters.

On Fri, Apr 20, 2007 at 10:48:14AM -0700, Hallam-Baker, Phillip wrote:
> That's not the point, the point here is that DHCP is not an Internet
> protocol. It is an IETF protocol but not an Internet protocol. It does
> not layer on the IP stack.

You're right, I muddled the point.

The point is that the ISO L(x) is not what one considers when judging
wether or not a certain configuration value "would make a good band
name.  I mean DHCP option."

What we (strive to) consider instead is the administrative scope
of the configuration information, and wether it matches common and
practical use of DHCP.

---

From: "GOLDMAN, STUART O \(STUART\)" <[email-masked]>
Date: Sat, 21 Apr 2007 03:19:17 -0500

Barbara,

I am a bit disappointed that you used "herding cats" before I had a
chance to make the comment. I agree.

Stuart Goldman
Alcatel-Lucent 
[email-masked]
602 493 8438

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Friday, April 20, 2007 10:50 AM
To: Andrew Newton; GEOPRIV WG
Cc: Allison Mankin
Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group
Hums

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 11:34 PM
To: GEOPRIV WG
Cc: Allison Mankin
Subject: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

All,

-andy, GEOPRIV co-chair

*****

The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential, proprietary, and/or
privileged material. Any review, retransmission, dissemination or other
use of, or taking of any action in reliance upon this information by
persons or entities other than the intended recipient is prohibited. If
you received this in error, please contact the sender and delete the
material from all computers. GA623

---

From: <[email-masked]>
Date: Sat, 21 Apr 2007 11:53:30 -0400

Andy,

Please find my position shown in red into your note.

Regards,

Hélène Côté 

-----Message d'origine-----
De : Andrew Newton [mailto:[email-masked]] 
Envoyé : 17 avril 2007 23:34
À : GEOPRIV WG
Cc : Allison Mankin
Objet : [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

All,

group.

"DHCP". ]

HC : Yes, in favour

HC : Yes

HC : Yes, in favour

network identifiers?

HC : Hum ... yes

HC : Abstained

HC : Yes, in favour

HC : Yes, In favour

HC : Yes, in favour

-andy, GEOPRIV co-chair

Geopriv mailing list

[email-masked]

---

From: <[email-masked]>
Date: Sun, 22 Apr 2007 14:11:38 -0400

Hi Andy,

Please find my response below.

Jérôme

-----Message d'origine-----

All,

HUM, in favor

HUM, in favor

HUM, in favor

Abstained. This would be interesting to have (and I'm guessing this has already been discussed long ago), but I think the focus of this working group should remain on the other items.

Abstained

HUM, in favor

HUM, in favor

HUM, in favor

-andy, GEOPRIV co-chair

---

From: John Schnizlein <[email-masked]>
Date: Sun, 22 Apr 2007 18:41:11 -0400

The reason that DHCP is appropriate for information about the  
location of the host is that the scope of DHCP administration usually  
does match the local network to which the host is attached.  Location  
is local information.

John

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 22 Apr 2007 19:57:30 -0500

General comment:  These appear to be an attempt to sound out general opinion rather than achieve any basis for progress.  Many of the questions are too esoteric to answer correctly.

> not deprecate DHCP). [ Note that the raw minutes say "LCP" instead of

In favour.
 
> direct and indirect methods of obtaining subscription.

In favour...ish.  At a minimum, some guidance would be good.  Especially if we want to avoid initiatives such as those being proposed in other fora (a recent proposal in the OMA asks for a SIP-based MLP).  There are probably other things to address first.

> acquire its own location?

Against.  A direct LIS request is adequate.

> subscription contain sufficient information based on lower-level

Against.  At least until I can see a concrete proposal.
 
> the questioned was restated before it was put to the room. ]

Against.

> indirect LCP subscription URIs through layer 7 mechanisms?

In favour.

>    Who is in favor of pursuing an HTTP-based LCP?

In favour.

> to dereference location by references?

In favour.

---

From: <[email-masked]>
Date: Mon, 23 Apr 2007 08:03:39 -0400

See response in email   (DA>>>>>>>>>>>>>X>>>>>>>>)

Dominique Asselin

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: April 17, 2007 11:34 PM
To: GEOPRIV WG
Cc: Allison Mankin
Subject: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

All,

DA>>>>>>>>>1>>>>>>>>>>>>>I'm in favor

DA>>>>>>>>>>2>>>>>>>>>>>>I'm also in favor

DA>>>>>>>>>>>3>>>>>>>>>>>HUM!

DA>>>>>>>>>>>4>>>>>>>>>>>HUMHUM

DA>>>>>>>>>>>5>>>>>>>>>>>Neutral

DA>>>>>>>>>>>6>>>>>>>>>>>Yes, in favor

DA>>>>>>>>>>>7>>>>>>>>>>>Yes, in favor

DA>>>>>>>>>>>8>>>>>>>>>>>Yes, HUM and in favor

-andy, GEOPRIV co-chair

---

From: "Crewe, Glenn" <[email-masked]>
Date: Mon, 23 Apr 2007 10:15:38 -0300

Here are my responses:

I'm in favour

Yes

I'm in favour

Abstain

Abstain

I'm in favour

I'm in favour

I'm in favour

Glenn Crewe
Product Manager,
Aliant Consumer Marketing,
Office: (902)-487-3890
Cell: (902)-497-1139

---

From: <[email-masked]>
Date: Mon, 23 Apr 2007 09:26:35 -0400

My response:

All,

I'm in favor

I'm in favor

I'm in favor

I'm in favor

I'm in favor

I'm in favor

I'm in favor

-andy, GEOPRIV co-chair

Martin Langlois

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 23 Apr 2007 16:38:50 +0200

I attended the meeting. Here are my hums again.

> not deprecate DHCP). [ Note that the raw minutes say "LCP" instead of  

In favor.

> direct and indirect methods of obtaining subscription.

abstain.

> acquire its own location?

in favor.

> subscription contain sufficient information based on lower-level  

in favor.

> the questioned was restated before it was put to the room. ]

in favor.

> indirect LCP subscription URIs through layer 7 mechanisms?

in favor.

>   Who is in favor of pursuing an HTTP-based LCP?

in favor.

> to dereference location by references?

in favor.

/ol
-- 
/ Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 \
| nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H |
\ http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg /

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 23 Apr 2007 10:41:25 -0400

As one of the participants in the meeting, I'd better confirm my views on the list.

Andrew Newton wrote:
...

> deprecate DHCP). [ Note that the raw minutes say "LCP" instead of "DHCP". ]
> 
I am in favour.

> direct and indirect methods of obtaining subscription.
No. I accept Henning's arguments that this is SIP configuration work.

> URL is being obtained from somewhere else, for a target to acquire its 
I am in favour.

> contain sufficient information based on lower-level network identifiers?
I would not like to see this. SIP configuration again.

> carrying a URL that would be used for indirect, subscription LCP? [ Note 
> that the raw minutes mention the original question. However, the 
Not in favour. SIP configuration. DHCP pointer to LS would be OK.

>   Who is in favor of pursuing work in GEOPRIV on a solution for indirect 
> LCP subscription URIs through layer 7 mechanisms?
> 
I am in favour.

> dereference location by references?
HTTP-for-retrieval yes. SIP-for-subscription no.

---

From: <[email-masked]>
Date: Mon, 23 Apr 2007 10:47:23 -0400

My responses are below.

Jonathan Agaliotis

-----Message d'origine-----
De : Andrew Newton [mailto:[email-masked]] 
Envoyé : April 17, 2007 11:34 PM
À : GEOPRIV WG
Cc : Allison Mankin
Objet : [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

All,

---in favor---

-andy, GEOPRIV co-chair

---

From: "Carl Reed OGC Account" <[email-masked]>
Date: Mon, 23 Apr 2007 09:38:41 -0600

My comments below. Also, does anyone have a clear statement on what LCP
would entail, what the requirements are, and what the use cases might be? My
apologies if this has been discussed and I missed the discussion. What
happens when I run one standards process and participate in 3 others :-)

Also, at our OGC meetings last week, Google and others expressed a
requirement for the ability to search for location as easily as other types
of content are searched. There are obvious implications - depending on the
situation and type of search. There are also potential implications for this
group with regard to privacy and location.

Cheers

Carl

----- Original Message ----- >
> deprecate DHCP). [ Note that the raw minutes say "LCP" instead of

In favor. One question (maybe answered in Prague). Is this a binary or
text/XML/http protocol?

In favor.

>   Who is in favor of proceeding with an indirect mechanism, where  the URL
> is being obtained from somewhere else, for a target to  acquire its own
> location?

In favor

Abstain

Abstain

Abstain

>   Who is in favor of pursuing an HTTP-based LCP?

Non-committal. Would such an http based LCP be discoverable by a search
engine?

> dereference location by references?

Abstain.

---

From: "Richard Bzdega" <[email-masked]>
Date: Mon, 23 Apr 2007 09:44:28 -0600

My responses are embedded below:

Richard Bzdega 
Senior Product Manager
TELUS Communications 
403 530 4063 

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, April 17, 2007 9:34 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

All, 

here: http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/ <http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/>  

FOR 

 ABSTAIN

 ABSTAIN  

ABSTAIN  

 ABSTAIN

 ABSTAIN  

FOR 

FOR  

-andy, GEOPRIV co-chair 

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

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 24 Apr 2007 10:02:21 -0400

In-line.... 

> minutes say "LCP" instead of "DHCP". ]

No

Yes

> target to acquire its own location?

No

Yes

> However, the questioned was restated before it was put to the room. ]

No

> for indirect LCP subscription URIs through layer 7 mechanisms?

No

>    Who is in favor of pursuing an HTTP-based LCP?

No

> dereferencing mechanism to dereference location by references?

No

---

From: <[email-masked]>
Date: Tue, 24 Apr 2007 16:19:03 -0400

#1 HUM
#2.HUM
#3.HUM
#4.Abstain
#5.abstain
#6.HUM
#7. HUM
#8. HUM

Fadi Dabliz
Québec/Ontario Regional
9-1-1 Product Manager &
Subject Matter Expert
Bell Canada
905-949-9169

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: April 17, 2007 11:34 PM
To: GEOPRIV WG
Cc: Allison Mankin
Subject: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

All,

-andy, GEOPRIV co-chair

---

From: Robert Sparks <[email-masked]>
Date: Fri, 27 Apr 2007 14:48:39 -0500

Hello folks -

All the responses to the feedback solicited to confirm the hums at  
IETF68 are in the archives of this list for your review.

Points 1 through 3 and 6 through 8 reconfirm the sentiments expressed  
during the IETF68 meeting. We have consensus on these points and will  
move forward with them.  (And many thanks to everyone who took the  
time to reply).

Point 4 (supporting direct acquisition through subscription) was  
opposed in the room, but supported on the list. We'll revisit this  
soon. I do note that this question was different from the others in  
this sample in that the others were confirming positive hums. If that  
introduced confusion, let me know.

Point 5 (pursuing extending protocols like DHCP to carry a URL for  
subscriptions) was favored in the room. The majority of the responses  
to the list were either "don't care" or "abstain". I plan to take  
this as a general indication of interest in pursuing this work.

I'm going through the recent list archives and spinning up on our  
current efforts and goals. Thanks for your patience with me as I go  
through this process.

RjS

On Apr 17, 2007, at 10:34 PM, Andrew Newton wrote:

> all work must be conducted on the mailing list.  This means that  
> all the hums taken during the meeting must be ratified on this  
> mailing list.  Because so many consensus calls were taken at IETF  
> 68, we will attempt to cover these in two separate messages.  This  
> is being done because so many of the latter decisions are  
> predicated on earlier ones.  We'd appreciate responses to this  
> first set consensus calls no later than Tuesday, 24 April.
>
> in the written form.  Each question will appear with its  
> approximate time in the audio recording for your reference.
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 27 Apr 2007 18:04:08 -0500

This is a response to the thread: RE: [Geopriv] Confirmation of GEOPRIV
IETF 68 Working Group  Hums

As requested by our chair, I've assigned it a more descriptive subject.

Hi Brian,

There's a symmetry problem in your statements about L7 LCP having
problems with respect to location determination cf DHCP.

If I said that DHCP is unable to provide an updated location for, say, a
scenario where the user is moving between multiple wireless access
points attached to multiple Ethernet switch ports serving the same
subnet, you would (very correctly) say "That's not true, the DHCP server
could invoke a number of underlying network mechanisms (SNMP bridge MIB
query for example) to dynamically determine location". You'd be
absolutely right.

The reason you'd be right is that the process of determining location is
quite decoupled from the protocol used by a client to acquire the
location information from the server. DHCP can only relate a MAC address
to the client IP address as part of its inherent operation. Now you
might say "Oh - but DHCP relay" - so now a DHCP server can also possibly
relate a switch port to the MAC address. Of course, DHCP relay works
outside of the subnet so I've already left the layer 2 domain anyway
but, in any case, all that says is that there is some state information
in a DHCP server that can be used to calculate location - you still need
the wiremap database. I can add an "L7 LCP" server on top of that same
state data (teach the DHCP server to talk the LCP protocol as it were,
or use a DHCP lease query to extract the information - or go directly to
the underlying database) and the client can talk to that instead of
talking DHCP. The protocol used by the client to acquire location from
the location server does not in any way define the capabilities
available to that server for determining location.

Any broadband operator that opts to deliver location information to
subscribers via DHCP will have to implement all the same machinery as
one that implements a HELD service *plus* they will have to deal with
getting the DHCP implementation in the CPE modified to provide the
service.

I'm sure I will get flamed for this message but there's a dead horse in
the room and it needs to be pointed out before it gets too smelly. I
note that some others are getting a whiff of it too...

The problems with DHCP can be divided into two key areas

i) The semantics are too simple. Two years of discussion have revealed
just how sophisticated a location server needs to be. The simple
semantics of 3825 are seductive but it yields horrendous complexity when
it comes to trying to meet requirements by dictating the behaviour of
multiple network elements when the necessary functionality can be
contained within the location server (e.g. LbyR, location dependability
aka signing, LIS-LIS communication, OBO). DHCP ends up just providing a
splinter of the required functionality - as, for example, defined by
NENA and as has been slowly emerging in the IETF.

ii) [This is the most significant problem] - Obviously DHCP semantics
could be continually reworked and extended (until they bear very little
resemblance to DHCP at all) any semantic issues could always be fixed.
The problem is, however, that DHCP as a service already exists. Again,
the seductive argument is that by adding the location service to DHCP
then some benefit in simplicity is gained because it's only a matter of
extending the functionality of the existing service. As any decent
software engineer will tell you, you don't add this sort of coupling
unless there's a very good reason to do so. A Java programmer, seeking
to add a new feature to their software, will not just say "let's add it
to this already existing class - that will save me defining a new
class." Software architects know that the minimal saving in time and
effort will be heavily outweighed by the cost in maintenance and
undesirable side effects if this was an unsuitable coupling to begin
with. In order to get the new piece of functionality, I now have to
invoke an object of the pre-existing class. I may not want that
pre-existing functionality or the side effects associated with creating
an instance of it. It's likely to cause me problems in my
implementation. DHCP is exactly like this - If I want a location server
it has to be a DHCP server.

In my house, my DHCP server runs on an old Socket-A PC running Ubuntu
Linux. The DHCP service is wonderfully configurable and produces much
more comprehensive logs and useful information than the crappy DHCP
implementation in my residential router. Any off-the-shelf rez-gateway
(not including crippled firmware often associated with ISP provided
modems) allows the DHCP server to be turned off - and for good reason.
Bearing in mind that we are talking about the network provider being the
source of the location information, how is that location information
supposed to get into my DHCP server? The question I ask myself is "why
am I being forced to use a DHCP server controlled by my broadband
provider - just so it can push location information by TR-069, DOCSIS,
PPoE or whatever?" The same issue applies to enterprises - it's no
wonder people don't want to talk about LbyR, location signing etc. in a
DHCP context. How does any of this get bridged through an enterprise's
DHCP server?

Yes, back at home, I suppose I could run my DHCP server for the standard
DHCP functions and the rez-gateway DHCP server just to respond to the
location requests. But that's assuming that the rez-gateway allows only
part of the DHCP functionality to be turned off... and it also means
that the DHCP server that's doing my location requests isn't the one
that relates my MAC/IP address information together. It may or may not
be a problem in a residential context but it certainly raises the
question of why on earth we have to deal with this sort of guff at all.

If my broadband provider had a HELD server, then I could put a location
enabled SIP client on my PDA tomorrow and use it from my home WLAN
without any modification to my existing LAN infrastructure. I could go
across town to my friend's place that has the same Internet provider and
it would work just as well from there. My broadband provider would not
need to put any more infrastructure in place in order to work out my
location than if it was delivered with DHCP - it just wouldn't have had
to worry about how it was going to get through the DHCP servers in the
CPE at each of the residences.

I'm currently on vacation, writing this in Portugal (just to underscore
that my interest and opinions are personal and not driven by corporate
agenda as has been suggested). The pension we are staying in, almost
bizarrely, has the best WiFi connection that I've encountered on the
entire trip so far - even better than the airports. Now the proprietor
clearly doesn't know how the Internet connection works - I think
somebody must have done them a favour in setting it up (the WEP key is
just provided to anyone who wants to use it). I don't know who their ISP
is but, being Portugal, there's a good chance it's P-TMN. Now, if P-TMN
had a HELD service, then my client could very reliably acquire its
location as being:

Pensao Residencial Sintra
Qunita Visconde de Tajal
Travessa dos Avelares
No 12 - Sao Pedro
2710-506 Sintra
Portugal

It could do this without our host having to have done anything with the
LAN infrastructure in the Pensao. (BTW - this place is great; the coffee
is excellent as are the restaurants, the wines, the scenery and sights -
and the WiFi :) I thoroughly recommend it).

The fact is that, about a year ago now I guess, once we got past the FUD
about getting location from a server over IP being unworkable and
dangerous - the moment it was accepted that in fact it was quite
workable - there hasn't really been any need for the DHCP solution. If
you want a location server in the enterprise then you can run a HELD
server in the enterprise. Further, the specification provides the
functionality for how that server can link to the Internet provider and
accomplish functions such as assertion, location integrity and so forth.

As it stands, DHCP is actually an impediment to the deployment of a
reliable, consistent, and ubiquitous location service in broadband
Internet access networks. Using DHCP as the location delivery mechanism
in broadband access will lead to an unreliable patchwork of limited
functionality. Ideally devices would be able to get their location
information in the same manner, and in the same form, regardless of the
IP network they connect to. ATIS is already starting liaison efforts
with 3GPP/2 to see if we can get agreement on defining a model for front
ending existing 3G location infrastructure and protocols with a LIS
function. Having some other broadband networks using DHCP is going to
make this ideal unrealizable.

As I say, I'm sure a lot of people won't be happy with what I've said. I
think a lot of that will be due to considerations such as sunk cost,
sheer momentum and reluctance to change, and probably a degree of
ownership. In any case - fire away - constructive comments would be
preferable to personal abuse however... :)

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 10:46 AM
To: 'Hallam-Baker, Phillip'; 'James M. Polk'; Dawson, Martin; 'John
Schnizlein'; 'Andrew Newton'
Cc: 'GEOPRIV WG'; [email-masked]; 'Allison Mankin'
Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group
Hums

In the example you gave the Hilton is EXACTLY the network that MUST give
you
your location, and Verisign, if they tried, would give a valid, but very
wrong location.

That is the point of using DHCP for location, you need the closest
possible
server to get the right location.  You need a server that understands
the L2
to which you are connected.  Anything L3 and farther has a big problem
of
where, exactly, are you?  The proposals for L7 versions of location
configuration protocols suffer mightily from the problem of figuring out
where you are in the L2.  They have to go to great lengths to determine
some
kind of identifier that they can unambiguously use to figure that out.
I
think we have (painfully) figured out a way though that morass that will
work in enough circumstances to be interesting, but it remains hard,
very
hard, to identify the L2 when your server is sitting at L7.

So, make sure that when you go to the Hilton that you use it's location
server, or you may have a big problem if you have to make an emergency
call
(or even order a pizza).

DHCP is an excellent choice for a location server for networks where the
DHCP infrastructure is present, and can reasonably be upgraded.  The L7
guys
point out, correctly, that that's a tall order in a lot of interesting
networks.  I think that is right.  I do think they believe L7 works on
every
network.  I'm certain it doesn't.  

Brian

Hums