Subject: [Geopriv] First draft - agenda for GEOPRIV at IETF72

From: Robert Sparks <[email-masked]>
Date: Wed, 16 Jul 2008 13:53:21 -0500

Folks -

This is a first cut at the agenda for our time in Dublin. Please bash  
it.

It's in a shorthand form - I will flesh it out with links to draft  
soon, but I wanted
to get the skeletal form out for comment now.

The "location events" item below is for a quick retouch on whether we  
need a
separate event package for some location applications. (See the  
proposals that
have been submitted to the SIP working group). I will start that  
discussion on list
shortly.

I also hope that we can reclaim the time for -retransmission-. I have  
seen no concerns
posted to the list about this draft. If we don't see some soon, we'll  
grab that 15m back
for something else.

This agenda assumes
		We don't need to talk about core held	
		We don't have a new draft for binary-lci/3825
	          (I see the recent exchange between James and John -
                    we'll revise to adjust to this if we need to).
		lis-discovery doesn't need face time	
			
5m		Administrivia						Robert
15m	-retransmission-					Ted
10m	-policy-							Hannes
10m	lbyr-requirements				Roger
15m	deref							James W
10m	3963bis							Richard
20m	held extensions (measurements, 	Martin
		identity, context as impacted by
		the interim)
15m	location events					Robert
20m	pidf extentions					James P
30m	Charter review					Robert
			including "What kind of OBO-like work can we do?"	

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

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 16 Jul 2008 18:28:24 -0500

>10m     3963bis Richard

what's the ID for this topic?

Richard started a list discussion about

         - do we need a 3694bis?
         - do we need a 3693bis?
         - do we combine these into a 3693/4bis effort?

The list discussion clearly had no consensus.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 16 Jul 2008 21:59:04 -0400

James,

At the last IETF 71, there was consensus to look into a 3693bis 
milestone, notionally based on draft-barnes-geopriv-lo-sec.  That is the 
draft that I had in mind to discuss in that time slot.

As you pointed out in our earlier discussion, the goals of this document 
are to update 3693 and 3694 to address scenarios that aren't clearly 
addressed by those documents, not to re-write the requirements.  In 
draft-barnes-geopriv-lo-sec-03, we've tried hard to minimize overlap, 
and focused on three specific issues:
1. How an LS provides privacy protections; how policies are structured 
and enforced
2. How rules should be applied in a store-and-forward context 
(incomplete in lo-sec-03; to be generalized from -lo-retransmission-)
3. How to assure LO integrity, authenticity, and confidentiality end to 
end (between LG and Viewer)

Given that this is yet another significantly new direction for this 
document, comments would be greatly appreciated.

Thanks,
--Richard

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 17 Jul 2008 01:49:35 -0500

At 08:59 PM 7/16/2008, Richard Barnes wrote:
>James,
>
>At the last IETF 71, there was consensus to look into a 3693bis milestone,

I was part of this conversation with Jon, and we talked about RFC3694 
(I remember that Jon forgot the number while talking, and I offered 
the RFC umber and he agreed).

>notionally based on draft-barnes-geopriv-lo-sec.  That is the draft 
>that I had in mind to discuss in that time slot.

As I mentioned in that previous thread, I have no problems with a 
3694bis - but don't yet see the need for a 3693bis.

>As you pointed out in our earlier discussion, the goals of this 
>document are to update 3693 and 3694 to address scenarios that 
>aren't clearly addressed by those documents, not to re-write the 
>requirements.  In draft-barnes-geopriv-lo-sec-03, we've tried hard 
>to minimize overlap, and focused on three specific issues:
>1. How an LS provides privacy protections; how policies are 
>structured and enforced
>3. How to assure LO integrity, authenticity, and confidentiality end 
>to end (between LG and Viewer)

I don't think folks have agreed to this undertaking as a replacement 
for our core requirements doc.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 17 Jul 2008 09:03:13 -0400

James,

The point of this effort is not to replace either 3693 or 3694, just to 
extend them to cover a specific set of new topics (it *updates* these 
documents; it does not *obsolete* them).  In that sense, perhaps 3693bis 
is a misnomer, but we can come up with a new name.  The current title is 
"Additional Location Privacy Considerations", which doesn't suggest 
replacement.

Also, there hasn't been a claim that this document has consensus as 
3693bis -- it remains an individual submission.  Part of the point of 
the discussion to be held is whether this draft is a useful update to 
3693/3694.  So if you have comments on the merits of the draft, this is 
the time to raise them.

Thanks,
--Richard

James M. Polk wrote:
>> milestone,
> I was part of this conversation with Jon, and we talked about RFC3694 (I 
> remember that Jon forgot the number while talking, and I offered the RFC 
> umber and he agreed).
> 
>> document are to update 3693 and 3694 to address scenarios that aren't 
>> clearly addressed by those documents, not to re-write the 
>> requirements.  In draft-barnes-geopriv-lo-sec-03, we've tried hard to 
>> minimize overlap, and focused on three specific issues:
> I don't think folks have agreed to this undertaking as a replacement for 
> our core requirements doc.
> 
>

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 18 Jul 2008 16:15:19 -0500

Richard

Strictly speaking a "bis" is a replacement document, and lacking 
other context (such as you provided below), it's hard not to think of 
the proposal which says "3693bis" as anything other than a replacement.

If either RFCs 3693 or 3694 need updating (which you do say below), 
then I'm find with exploring such an update.

Thanks for clarifying

BTW - I like the title you have.

James

At 08:03 AM 7/17/2008, Richard Barnes wrote:
>James,
>
>The point of this effort is not to replace either 3693 or 3694, just 
>to extend them to cover a specific set of new topics (it *updates* 
>these documents; it does not *obsolete* them).  In that sense, 
>perhaps 3693bis is a misnomer, but we can come up with a new 
>name.  The current title is "Additional Location Privacy 
>Considerations", which doesn't suggest replacement.
>
>3693bis -- it remains an individual submission.  Part of the point 
>of the discussion to be held is whether this draft is a useful 
>update to 3693/3694.  So if you have comments on the merits of the 
>draft, this is the time to raise them.
>
>Thanks,
>--Richard
>
>
>
>
>James M. Polk wrote:
>>I was part of this conversation with Jon, and we talked about 
>>RFC3694 (I remember that Jon forgot the number while talking, and I 
>>offered the RFC umber and he agreed).
>>
>>>notionally based on draft-barnes-geopriv-lo-sec.  That is the 
>>>3. How to assure LO integrity, authenticity, and confidentiality 
>>>end to end (between LG and Viewer)
>>I don't think folks have agreed to this undertaking as a 
>>replacement for our core requirements doc.
>>
>>>Given that this is yet another significantly new direction for 
>>>this document, comments would be greatly appreciated.
>>>
>>>Thanks,
>>>--Richard
>>>
>>>
>>>
>>>
>>>
>>>James M. Polk wrote:

---

From: Richard Barnes <[email-masked]>
Date: Sat, 19 Jul 2008 21:41:59 -0400

Yeah, I don't know that "bis" is defined anywhere, but I'm willing to 
accept that it implies a replacement.

That said, we might want to have some WG discussion about whether we 
really want a "bis" or an "update".  The latest rev of -lo-sec- moves it 
toward the "update" end, but some folks found the "bis" for of -02 
useful.  Something to discuss in Dublin...

Cheers,
--Ricahrd

James M. Polk wrote:
> Richard
> 
> Strictly speaking a "bis" is a replacement document, and lacking other 
> context (such as you provided below), it's hard not to think of the 
> proposal which says "3693bis" as anything other than a replacement.
> 
> If either RFCs 3693 or 3694 need updating (which you do say below), then 
> I'm find with exploring such an update.
> 
> Thanks for clarifying
> 
>> these documents; it does not *obsolete* them).  In that sense, perhaps 
>> 3693bis is a misnomer, but we can come up with a new name.  The 
>> current title is "Additional Location Privacy Considerations", which 
>> doesn't suggest replacement.
>>
>> 3693/3694.  So if you have comments on the merits of the draft, this 
>> is the time to raise them.
>>
>> Thanks,
>> --Richard
>>
>>
>>
>>
>> James M. Polk wrote:

---

From: "Mary Barnes" <[email-masked]>
Date: Sun, 20 Jul 2008 11:13:54 -0500

Richard,

The "bis" (again) terminology is defined in RFC 4677 (IETF TAO):
http://www.ietf.org/rfc/rfc4677.txt
This document is updated over time and really provides an extremely
comprehensive summary of IETF (including processes, etc.).

In the end, the document header for the "bis" documents must also
include the "Obsoletes:" RFCxxxx header.
Whereas, the "update" documents must also include the "Updates:" RFCxxxx
header.

Regards,
Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Richard Barnes
Sent: Saturday, July 19, 2008 8:42 PM
To: James M. Polk
Cc: GEOPRIV
Subject: Re: [Geopriv] First draft - agenda for GEOPRIV at IETF72

Cheers,
--Ricahrd

>> perhaps 3693bis is a misnomer, but we can come up with a new name.  
>> The current title is "Additional Location Privacy Considerations", 
>> which doesn't suggest replacement.
>>

>>>> structured and enforced 2. How rules should be applied in a 
>>>> store-and-forward context (incomplete in lo-sec-03; to be 
>>>> generalized from -lo-retransmission-) 3. How to assure LO 
>>>> integrity, authenticity, and confidentiality end to end (between LG

>>>> and Viewer)

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Jul 2008 09:17:32 -0400

Mary,

Thanks very much for the pointer.  In that case, I suppose that will be 
a major item for discussion in the "3693bis" slot will be whether an 
update or a "bis" is in order.

Thanks again,
--Richard

---

From: "Mary Barnes" <[email-masked]>
Date: Mon, 21 Jul 2008 08:17:21 -0500

Exactly. And that discussion generally depends upon how extensive an
"Update" might be. If it's very extensive - touches many sections and
concepts, then typically a "bis" is a good idea, otherwise there's lots
more confusion for developers.

Mary.

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Monday, July 21, 2008 8:18 AM
To: Barnes, Mary (RICH2:AR00)
Cc: James M. Polk; GEOPRIV
Subject: Re: [Geopriv] First draft - agenda for GEOPRIV at IETF72

Mary,

Thanks again,
--Richard

Mary Barnes wrote:
> Whereas, the "update" documents must also include the "Updates:" 
> RFCxxxx header.
> 
> Regards,
> Mary. 
> 
> 
> really want a "bis" or an "update".  The latest rev of -lo-sec- moves 
> it toward the "update" end, but some folks found the "bis" for of -02 
>> other

>>> of

>>>>> draft

>>>> replacement
>>>>> this