[Geopriv] In response to..

["Winterbottom, James" <[e-mail]>]

James,

You are spot in when you say I don't believe that DHCP is a suitable
mechanism for providing location information. I don't! That aside, there
are specifications that provide this, and some require corrections.

None of this stops the legitimacy of needing identity extensions in
HELD, both for the Device to assist the LIS, and for proxies to specify
a Target identity to the LIS. Clear use cases exist and requirements for
this are specified. What is the big deal?

I don't believe that I have suggested that your draft be removed form
the agenda to make way for presenting identity extensions, so I am not
sure that I understand your overly defensive response. Perhaps we don't
need 30 minutes for LIS Discovery, I am hoping that there isn't a lot of
contention in this draft at all.

I would point that LbyR over DHCP was not the only new thing to come out
of the Prague meeting, LIS to LIS requirements came out of the L7 LCP
problem statement to be specified in their own document as this was
something that the WG was interested in. Steve Norreys and I wrote this
draft, and it has had very little feedback or air time.

Given the volume of drafts in georpiv, I have personally co-authored 13,
I would suggest that an Interim meeting is in order to address some of
these issues (late January in Australia is lovely).

Cheers
James 


> -----Original Message-----
> From: James M. Polk [mailto:[e-mail]]
> Sent: Thursday, 22 November 2007 8:52 AM
> To: Winterbottom, James; Marc Linsner; Stark, Barbara;
> [e-mail]; [e-mail]
> Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70
> 
> Well then, this WG voted in Prague for a layer 3 LbyR delivery
> mechanism, yet you voiced strong opposition for my draft which
> proposes this in DHCP, which is a protocol Geopriv already has 2
> Standards Track RFCs supporting.  I personally heard your loud hum
> against moving this ID forward as a WG item, because you want a more
> detailed architecture supporting how DHCP can deliver a URI to an
> endpoint. This is something neither RFC 3825 or RFC 4776 have in
> place, yet this ID is burdened with this responsibility in your
> mind.  I don't think there's precedent for that opinion.
> 
> You even said you don't think anything in DHCP should progress in
> another email.
> 
> So, we're left to this little problem of the WG agreeing in Prague a
> DHCP solution is necessary for this WG, and you acting against
> anything DHCP (contrary to the WG's existing wishes).
> 
> I say all this, because the WG thinks there is a use-case for DHCP to
> do this, and I have this document  (just like you mention below)
> http://www.ietf.org/internet-drafts/draft-polk-geopriv-dhcp-lbyr-uri-
> option-02.txt
> with one remaining open issue (I added your request for a "Valid-for"
> timer) - it's your mandate it include an architecture (unlike the
> other DHCP RFCs have from this group) that doesn't involve a DHCP
> Protocol, so what's the difference? Should I take this personal too?
> As a force of habit with this WG?
> 
> BTW - wrt this revised ID -- I know I have to work specifying how to
> prevent less trustworthy URI types from being allowed.  I'm working
> with the APPS AD on this.
> 
> James
> 
> At 03:33 PM 11/21/2007, Winterbottom, James wrote:
> >Hi James,
> >
> >Sorry, I was just trying to present the use-case and document the
> >existing requirements. Comes about as a force of habit with this
WG...
> >*8)
> >
> >Cheers
> >James
> >
> >
> >
> > > -----Original Message-----
> > > From: James M. Polk [mailto:[e-mail]]
> > > Sent: Thursday, 22 November 2007 8:26 AM
> > > To: Winterbottom, James; Marc Linsner; Stark, Barbara;
> > > [e-mail]; [e-mail]
> > > Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70
> > >
> > > James
> > >
> > > You can reply without being so incredibly defensive, can't you?
> > >
> > > At 02:42 PM 11/21/2007, Winterbottom, James wrote:
> > > >Content-class: urn:content-classes:message
> > > >Content-Type: multipart/alternative;
> > > >         boundary="----_=_NextPart_001_01C82C7E.FAF514D5"
> > > >
> > > >Marc,
> > > >
> > > >Suppose the identifier is a MAC address, since this has no formal
> > > >URI representation  then what?
> > > >Suppose HELD is bound to a transport other than HTTP, such as in
> > > ><http://tools.ietf.org/html/draft-thomson-geopriv-held-beep->
> > 01>http://tools.ietf.org/html/draft-thomson-geopriv-held-beep-01,
> > > >how are the parameters simply added to the URI? Does it even make
> > > >sense to do so?
> > > >
> > >
><http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps->
>
>06.txt>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-l7-lcp-ps
-
> > > 06.txt
> > > >indicates that identifiers other than IP address will be required
in
> > > >some scenarios.
> > > >
> > > ><http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp->
> >
03.txt>http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-
> > > 03.txt
> > > >identifies the need, in some situations, for an outbound proxy to
> > > >insert location on-behalf-of the calling device. In this
situation
> > > >using HELD requires a formal way to express how the Device is
being
> > > >identified, and what the identifier represents.
> > > >
> > > >Please read the draft
> > >
><http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-
> >
>
>extensions-04>http://tools.ietf.org/html/draft-winterbottom-geopriv-hel
d
> >-
> > > identity-extensions-04
> > > >before jumping on to the attack.
> > > >
> > > >There are several architectures and deployments well underway
that
> > > >require this work. The ABNF definitions in the extensions draft
have
> > > >applicability beyond just HELD. I don't see a need to delay this
work
> > > further.
> > > >
> > > >Cheers
> > > >James
> > > >
> > > >
> > > >----------
> > > >From: Marc Linsner [mailto:[e-mail]]
> > > >Sent: Thursday, 22 November 2007 4:54 AM
> > > >To: 'Stark, Barbara'; [e-mail]; [e-mail]
> > > >Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70
> > > >
> > > >Barbara,
> > > >
> > > >Remind me again why this can't be accomplished by putting the
> > > >identifier in the uri?  ex:
> > >
><mailto:[e-mail]>[e-mail]
> > > >
> > > >Thanks,
> > > >
> > > >-Marc-
> > > >
> > > >
> > > >
> > > >
> > > >----------
> > > >From: Stark, Barbara [mailto:[e-mail]]
> > > >Sent: Wednesday, November 21, 2007 12:17 PM
> > > >To: [e-mail]; [e-mail]
> > > >Subject: Re: [Geopriv] draft agenda: GEOPRIV @ IETF 70
> > > >
> > > >Robert,
> > > >I think the HELD identity extensions is important. It's needed
for
> > > >LIS to LIS communication, which is critical where the entity who
> > > >assigns the public IP address is not the same as the access
provider.
> > > >Barbara
> > > >
> > > >----- Original Message -----
> > > >From: Robert Sparks <[e-mail]>
> > > >To: GEOPRIV <[e-mail]>
> > > >Sent: Tue Nov 20 15:09:03 2007
> > > >Subject: [Geopriv] draft agenda: GEOPRIV @ IETF 70
> > > >
> > > >Folks -
> > > >
> > > >We have 2.5 hrs in Vancouver (Friday morning). Based on our
chartered
> > > >work, list discussions, and agenda requests, here's the agenda
I'm
> > > >planning to follow:
> > > >
> > > >15m     Administrivia   Chairs
> > > >30m     http-location-delivery  Mary (<- Lets finish this one!)
> > > >20m     Finishing geopriv-policy        Hannes/Cullen
> > > >30m     LIS Discovery   James W
> > > >10m     l7lcp-ps        Hannes
> > > >20m     pidf-lo-dynamic Henning
> > > >15m     dhcp-lbyr-uri-option    James P
> > > >10m     civicaddresses-austria  Karl
> > > >20m     Uncertainty and Confidence      James W
> > > >10m     HELD Dereference        James W
> > > >
> > > >As usual, we have many other requests to talk about other things
-
> > > >please take those to the list for now.
> > > >
> > > >This is a draft agenda and we can change it. Let me know if you
think
> > > >I've missed something important.
> > > >
> > > >RjS
> > > >
> > > >
> > > >_______________________________________________
> > > >Geopriv mailing list
> > > >[e-mail]
> > >
> >
><https://www1.ietf.org/mailman/listinfo/geopriv>https://www1.ietf.org/m
> >ai
> > > lman/listinfo/geopriv
> > > >
> > > >*****
> > > >
> > > >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
> > > >
> > > >
> > > >
> > > >
> > >
> >
>-----------------------------------------------------------------------
> >--
> > > -----------------------
> > > >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]
> > > >_______________________________________________
> > > >Geopriv mailing list
> > > >[e-mail]
> > > >https://www1.ietf.org/mailman/listinfo/geopriv
> >
>
>-----------------------------------------------------------------------
--
> -----------------------
> >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]
> >
> >
> >
> >_______________________________________________
> >Geopriv mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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]



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