RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70

"James M. Polk" <jmpolk@cisco.com> Wed, 21 November 2007 21:52 UTC

Return-path: <geopriv-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxUa-00051r-6M; Wed, 21 Nov 2007 16:52:20 -0500
Received: from geopriv by megatron.ietf.org with local (Exim 4.43) id 1IuxUZ-0004zT-04 for geopriv-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:52:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxUY-0004zL-Mi for geopriv@ietf.org; Wed, 21 Nov 2007 16:52:18 -0500
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuxUU-0006xV-II for geopriv@ietf.org; Wed, 21 Nov 2007 16:52:18 -0500
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2007 13:52:14 -0800
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lALLqD9n002405; Wed, 21 Nov 2007 13:52:13 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lALLqDus003817; Wed, 21 Nov 2007 21:52:13 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 13:52:13 -0800
Received: from jmpolk-wxp.cisco.com ([10.21.92.162]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 13:52:13 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 21 Nov 2007 15:52:11 -0600
To: "Winterbottom, James" <James.Winterbottom@andrew.com>, Marc Linsner <mlinsner@cisco.com>, "Stark, Barbara" <bs7652@att.com>, rjsparks@nostrum.com, geopriv@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
Subject: RE: [Geopriv] draft agenda: GEOPRIV @ IETF 70
In-Reply-To: <E51D5B15BFDEFD448F90BDD17D41CFF1039E5707@AHQEX1.andrew.com >
References: <7582BC68E4994F4ABF0BD4723975C3FA04F176CC@crexc41p> <007101c82c67$87ebf2a0$2f0d0d0a@cisco.com> <E51D5B15BFDEFD448F90BDD17D41CFF1039E56D8@AHQEX1.andrew.com> <XFE-SJC-212GDrPixj6000013af@xfe-sjc-212.amer.cisco.com> <E51D5B15BFDEFD448F90BDD17D41CFF1039E5707@AHQEX1.andrew.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Message-ID: <XFE-SJC-212HkidcDjo000013b5@xfe-sjc-212.amer.cisco.com>
X-OriginalArrivalTime: 21 Nov 2007 21:52:13.0123 (UTC) FILETIME=[C6202930:01C82C88]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8424; t=1195681934; x=1196545934; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20<jmpolk@cisco.com> |Subject:=20RE=3A=20[Geopriv]=20draft=20agenda=3A=20GEOPRIV=20@=20IETF=20 70 |Sender:=20; bh=obN19EWHjGUVQATWnw8nWj451glqL49R2P/p2rktS+U=; b=M0C4WiWNs7t9AdqtXimwlJRtF2P7qoC9lOrdiT+b2MDMz6pJZB+fSei+RNqQ0In92KA+jGKR E577hbruRbstCllYg/hyQv2U/jQzVR5zcuQMM7yCM1bJ2DSy+Q6YwxMU;
Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1
Cc:
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Errors-To: geopriv-bounces@ietf.org

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:jmpolk@cisco.com]
> > Sent: Thursday, 22 November 2007 8:26 AM
> > To: Winterbottom, James; Marc Linsner; Stark, Barbara;
> > rjsparks@nostrum.com; geopriv@ietf.org
> > 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-held
>-
> > 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:mlinsner@cisco.com]
> > >Sent: Thursday, 22 November 2007 4:54 AM
> > >To: 'Stark, Barbara'; rjsparks@nostrum.com; geopriv@ietf.org
> > >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:identifier@accessprovider.net>identifier@accessprovider.net
> > >
> > >Thanks,
> > >
> > >-Marc-
> > >
> > >
> > >
> > >
> > >----------
> > >From: Stark, Barbara [mailto:bs7652@att.com]
> > >Sent: Wednesday, November 21, 2007 12:17 PM
> > >To: rjsparks@nostrum.com; geopriv@ietf.org
> > >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 <rjsparks@nostrum.com>
> > >To: GEOPRIV <geopriv@ietf.org>
> > >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
> > >Geopriv@ietf.org
> >
> ><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
> > >Geopriv@ietf.org
> > >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
>Geopriv@ietf.org
>https://www1.ietf.org/mailman/listinfo/geopriv


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv