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

From: Richard Barnes ^lt;rbarnes@bbn.com>
Date: Mon Jul 21 2008 - 09:17:32 EDT

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

Mary Barnes wrote:
> 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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] 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
>
> 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
>>
>> 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.
>>>
>>> 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:
>>>> 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 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)
>>>> 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:
>>>>>> At 01:53 PM 7/16/2008, Robert Sparks wrote:
>>>>>>> 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.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Geopriv mailing list
>>>>>> Geopriv@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>>> _______________________________________________
>>>>> Geopriv mailing list
>>>>> Geopriv@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Mon, 21 Jul 2008 09:17:32 -0400

This archive was generated by hypermail 2.1.8 : Mon Jul 21 2008 - 09:17:45 EDT