Re: [Geopriv] Common Policy Update (-10.txt)

I fully agree with you, Jonathan.

Jonathan Rosenberg wrote:
> I don't see this as a common policy issue at all. Common policy is just 
> a framework and it leaves to other specifications to define any kind of 
> actions. All of this allow/deny/pending stuff is presence-specific 
> actions and belongs there, not common policy.
> 
> Thanks,
> Jonathan R.
> 
> Thomson, Martin wrote:
> 
>> I agree, I think that I got my deny/confirm states back to front.  The 
>> pending state is safe because you end up in terminated AND you present 
>> the option to a user. However, Common Policy is silent on this point 
>> (intentionally?).  I think that it's worth pointing out.
>>
>>
>>> -----Original Message-----
>>> From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]
>>> Sent: Saturday, 6 May 2006 5:45 AM
>>> To: Thomson, Martin
>>> Cc: Hannes Tschofenig; geopriv@ietf.org
>>> Subject: Re: [Geopriv] Common Policy Update (-10.txt)
>>>
>>> Martin,
>>>
>>> I have to disagree with you here. For presence, it is an extremely
>>> common case that a SUBSCRIBE shows up from a watcher for whom the
>>> presentity has not yet given any kind of permission either way. The
>>> purpose of the watcherinfo specification is that the presentity can find
>>> out about this, and then upload a permission document. The entire point
>>> of the 'pending' state in that state machine is to handle this
>>> intermediate period prior to authorization being given (or denied). If,
>>> as you suggest, the subscription is instead immediately denied, the
>>> watcher has no way to know when they should try back to determine when
>>> their subscription is granted (or not). With the pending state, they are
>>> provided an explicit notification informing them of when this happens.
>>>
>>> Thanks,
>>> Jonathan R.
>>>
>>> Thomson, Martin wrote:
>>>
>>>
>>>> With relation to the subscription state machines in RFC 3265 (no
>>>> pretending that this is the context that common policy is targeted
>>>> at) and RFC 3857, it is unclear to me what I am expected to do when
>>>> no rules match.
>>>>
>>>> My gut says that if you don't have a rule, then you are denied, but
>>>> 3265 states that the "no policy" behaviour is to transition to the
>>>> "pending" state.  So my question is: does no rules imply "no policy"
>>>> or "deny"?
>>>>
>>>> I would suggest that the answer is "deny" since simple-pres-rules
>>>> provides an explicit way to move to the "pending" state
>>>> (<sub-handling>confirm</sub-handling>).  I'm guessing that this is a
>>>> _safe_ assumption since the "pending" state ultimately leads to
>>>> "terminated" without any further interaction, but this isn't explicit
>>>> anywhere that I can see.
>>>>
>>>>
>>>> I also noticed that there's a whoops in Section 10.1:
>>>>
>>>> Please note that the <identity> element is a condition whereas the
>>>> <id> element is a parameter of that condition.
>>>> ^^^^
>>>>
>>>> That should be "the <one> element".  Looks like a hangup from a
>>>> previous version.
>>>>
>>>> Cheers, Martin
>>>>
>>>>
>>>>
>>>>> -----Original Message----- From: Hannes Tschofenig
>>>>> [mailto:Hannes.Tschofenig@gmx.net] Sent: Tuesday, 25 April 2006
>>>>> 10:08 PM To: geopriv@ietf.org Subject: [Geopriv] Common Policy
>>>>> Update (-10.txt)
>>>>>
>>>>> Hi all,
>>>>>
>>>>> here is another update to the Common Policy Draft. The changes are:
>>>>>
>>>>>
>>>>> - Fixed reference (RFC 2048 to RFC 4288 in Section 15). Allison
>>>>> spotted it. - Incorporated comments from GEN-ART review by Scott
>>>>> Brim. See the separate mail on this subject.
>>>>>
>>>>> Here is the draft:
>>>>> http://www.tschofenig.priv.at/TEMP/draft-ietf-geopriv-common-policy-10.txt
>>>>>
>>>>> http://www.tschofenig.priv.at/TEMP/draft-ietf-geopriv-common-policy-10.html 
>>>>>
>>>>>
>>>>>
>>>>> Ciao Hannes
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________ 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
>>>
>>>
>>> -- 
>>> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>>> Cisco Fellow                                   Parsippany, NJ 07054-2711
>>> Cisco Systems
>>> jdrosen@cisco.com                              FAX:   (973) 952-5050
>>> http://www.jdrosen.net                         PHONE: (973) 952-5000
>>> http://www.cisco.com
>>
>>
>>
>> ------------------------------------------------------------------------------------------------ 
>>
>> 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