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

[Jonathan Rosenberg <[e-mail]>]

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:[e-mail]]
>>Sent: Saturday, 6 May 2006 5:45 AM
>>To: Thomson, Martin
>>Cc: Hannes Tschofenig; [e-mail]
>>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:[e-mail]] Sent: Tuesday, 25 April 2006
>>>>10:08 PM To: [e-mail] 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 [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
>>
>>--
>>Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>>Cisco Fellow                                   Parsippany, NJ 07054-2711
>>Cisco Systems
>>[e-mail]                              FAX:   [phone]
>>http://www.jdrosen.net                         PHONE: [phone]
>>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]

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

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