Subject: Re: [Simple] Review of draft-ietf-simple-view-sharing-01

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 03 Nov 2008 10:46:33 -0500

Richard,

Thanks kindly for the extensive (and excellent) review and comments, and 
I apologize for my tardy response.

See responses below:

Richard Barnes wrote:
> ========================================================================
> Document: draft-ietf-simple-view-sharing-01
> Reviewer: Richard L. Barnes, BBN Technologies
> Date: 5 September 2008
> ========================================================================
> 
> 
> General comments
> ========================================================================
> 
> 1. A seemingly minor but important point: The document is 
> unclearthroughout on whether this mechanism facilitates sharing between 
> "systems" or "domains".  The latter is more consistent with Figure 1, 
> and seems like what you're actually going for.  In particular, if the 
> RLS is associated with a domain, then it might be possible to avoid 
> manual provisioning (see 6. below)

The vagueness is partly on purpose since it can be used with 
intra-domain federation as well as inter-domain. However, the 
intra-domain case is, in many ways, simpler, and ends up being just a 
special case of inter-domain. So I think it makes sense to define it for 
inter-domain and note that it can be used intra-domain too.

I've made this clearer now up front in the intro:

<t>
Presence federation refers to the interconnection of disparate systems
for the purposes of sharing presence information. This interconnection
involves passing of subscriptions from one system to another, and then
the passing of notifications in the opposite direction. Federation can
be occur between different domains, where it is referred to as
inter-domain federation. However, federation can also occur within a
domain, where it is referred to as intra-domain federation
<xref target="I-D.ietf-simple-intradomain-federation"/>.
</t>

and then later:

<t>
This document defines a mechanism called view sharing in support of
those requirements. The key idea with view sharing is that when there
are many watchers in one system to a single presentity in
another system, each of which is actually going to get the
exact same presence document, the watcher's system extends a
single subscription to the system of the presentity, and the
system of the presentity sends a single copy of the presence document
back to the system of the watcher. Though this mechanism can be
applied intra-domain as well as inter-domain, the specification
considers only the inter-domain case.
</t>

> 
> 2. The document does a good job of addressing the risks that the Serving 
> Domain is exposed to through view sharing.  However, it doesn't address 
> the privacy risks that the *presentity* is exposed to.  The Watching 
> Domain is now explicitly responsible for applying the privacy policies 
> that the user has set (providing different views to different watchers), 
> so the presentity now has to trust the Watching Domain to perform that 
> operation as opposed to just passing through NOTIFYs.  The risk is that 
> the Watching Domain fails to apply the Rule Determination Algorithm (as 
> required in 3.2.2), and presence info fromone view leaks into others.
>   You can tell a similar story here to the one you tell for ACLs inthe 
> Security Considerations: Without view sharing, the Watcher already has 
> access to all that presence information, so if it were malicious, it 
> could already leak information between views.  Thus the only real risk 
> is non-compliance, which you can't fix in a standard.  The only 
> recommendation that seems necessary here is another reminder to the RLS 
> to reinforce the importance of the rules determination algorithm being 
> done correctly.

Done. I've split out the security considerations section into a section 
on considerations for the watched domain and considerations for the 
presentity.

> 
> 3. It would be nice to discuss how view sharing interacts with S/MIME 
> protected presence documents.  For signed objects (that aren't 
> encrypted), the usage is probably pretty much the same, except that the 
> PA won't be able to modify the presence documents (unless it's the 
> signer).  For enveloped/encrypted objects, there's some interaction 
> between the set of authorized watchers and the set of keys that can be 
> used to decrypt the object.

Well, this is largely an academic discussion.... but you are of course 
correct. I've added discussion on it.

> 
> 4. It's not clear to me why it's more critical to use TLS with view 
> sharing than otherwise.  As you point out in the Security 
> Considerations, no more information is exposed here than with normal SIP 
> events.  The risks of identity spoofing and interception are the same. 
> It might even be less so if the peers are using direct links to each 
> other (as in layer-2 peering federations).

The main reason is to handle this problem discussed in the security 
considerations section, where we cannot use view sharing until we are 
sure that the RLS supports it as a opposed to the watching user.

> 
> 5. The document doesn't specify whether or not a single ACL can contain 
> members from many domains.  From a privacy perspective, my preference 
> would be to specify that within a single ACL,
> -- All members MUST have the same domain
> -- That domain MUST be the domain of the RLS

This could get a bit more complicated in clearinghouse type of 
arrangements, where a single 'hub' provider could interconnect many 
domains. If you want to use view sharing between the hub and each 
domain, you might see multiple domains in the ACL. I think a 
generalization of your rule is that the set of domains must match the 
set for which that RLS is authorized to operate on behalf of. Normally, 
this is just the domain of the RLS itself.

I beefed up section 5.2 to discuss this.

> 
> 6. Obviously, the requirement for "explicit provisioning" of trusted 
> domains is kind of a turn-off (for scalability, dynamic extension 
> oftrusted enclaves, etc.).  It seems like the critical distinction 
> you're trying to enforce with this requirement is to separate an RLS 
> from a watcher, where an RLS is the entity authorized -- by both domains 
> -- to see all presence transactions between the two domains, and the 
> watcher is only authorized (by either domain) to see its own 
> transactions. 

Right.

> Is there a mechanism other than manual provisioning to 
> make this distinction?   It seems like the RLS is something that might 
> get advertised in the DNS, for example.  Assuming that (1) the PA 
> constrains view-sharing based on the domain of the (supposed) RLS 
> matching an RLS in the DNS and (2) the PA only issues ACLs in which all 
> members are from the same domain (see above), then the privacy risks 
> would be eliminated.  A request from a non-view-sharing domain (as in 
> the current example attack) wouldn't come from an RLS, and an attacker 
> that creates his own domain/RLS would only get information for his fake 
> domain.

Hmm, I'm not sure this works. SInce the DNS entry is never used for 
actual message delivery, but just as a check for existence, could not a 
malicious end user get a DNS entry created for the domain he is in? This 
solution gets intertwined with the question on how DNS provisioning 
works and how secure it is.

Another solution might be to have the serving domain send an OPTIONS 
request to the domain itself (OPTIONS sip:example.com) and see if 
view-sharing is listed in the OPTIONS response.

In practice though, I suspect this will be primarily used in cases of 
pre-arranged trust, which is why I wasn't too worried about a better 
solution. I'd suggest we separate these out. For this document, I can 
change the normative requirement to something like, "MUST make sure that 
the RLS in the watching domain supports this extension" and then discuss 
provisioning as the only way defined in this document to figure that 
out. This way, if we OPTIONS or DNS or something else, it can be added 
later.

Here is the text I put in, replacing the contents of section 4.1:

<t>
The principle concern of the presence agent is to determine the domain
of the RLS, and assess whether the subscribing entity is an RLS
authorized to operate on behalf of that domain. In order to utilize
view sharing, a presence agent MUST determine both. This information is
necessary in order to compute the ACL to be sent to that domain, and
if done incorrectly, may reveal sensitive information to the watching
domain.
</t>

<t>
To determine the domain of the subscribing RLS, TLS with mutual
authentication SHOULD be used. In such a case, the presence agent can
determine the domain of the RLS from the subjectAltName in the
certificate presented from its peer.
</t>

<t>
This specification does not define any automated mechanism for a
presence agent to determine whether the subscribing entity is, in
fact, an RLS authorized to operate on behalf of the watching
domain. <xref target="sec-security"/> discusses why this determination
is important. Absent an automated mechanism, presence agents SHOULD
support a configuration option which allows the administrator to
enumerate a set of domains for which it is known that an entity
holding a certificate for that domain is an authorized RLS. In such a
case, the subject from the certificate can be compared against that
list, and if a match is found, view sharing can be utilized for this
subscription.
</t>

> 
> 7. This document claims in the Abstract and the introduction to be an 
> extension to the general SIP events framework.  However, the entire 
> introduction is presence-centric, and many of the sections that could be 
> general use presence-specific terminology (e.g., S3.2.2 and S4; see 
> comments below).  It should be made clearer which parts are 
> presence-specific, which are more general.

Its general though I think its principal use is presence. I'd like to 
keep the intro presence centric, and will clean up the rest to be more 
generic.

> 
> 8. The document should clarify whether it is allowable for a PA to 
> initiate the use of view sharing?  For example, could you have a PA that 
> only supports view sharing, so that it responds with "Required: 
> view-share", whether or not the SUBSCRIBE asked for it?  It may be best 
> to forbid this, since it strengthens the asymmetry discussed in section 
> 2 (PA decides, RLS pays computational burden).

I will add a sentence to this effect.

> 
> 
> 
> Specific comments
> ========================================================================
> 
> S2
>    Depending on the level of trust, the mechanism trades off inter-
>    domain messaging traffic for increased processing load in the RLS to
>    handle the ACL documents.
> 
> This raised a red flag for me at first, since the load on the RLS is 
> determined by what the PA decides to do.  However, this asymmetry is not 
> so bad because the Serving Domain has to give up potentially sensitive 
> information in order to incur increased processing in the Watching 
> Domain (and presumably, the Watching Domain has to ask for this, see S4 
> below).
> 
> It would also be helpful to the reader here to have a brief description 
> of what the logical structure of an ACL looks like, since that matters a 
> lot for sections 3 and 4.

It is mentioned in S2 already:

The other is an Access Control List (ACL) document. This
document describes the set of other subscribers from the originating
domain, if any, who are authorized to see exactly the same document -
in other words, the set of users that share the same view.

> 
> 
> 
> S3
>    This section defines the procedures that are to be followed by the
>    RLS.  It is important to note that, even though this specification
>    defines an extension to the SIP events framework, that extension is
>    only useful for the back-end subscriptions generated by an RLS.
> 
> I found the ordering of this section confusing.  I would suggest 
> re-organizing according to the temporal order of things, in the 
> following way:
> 3.1.1: Current S3.1.3, Determine whether a suitable subscription exists
> 3.1.2: Current S3.1.2, Establishing a back-end subscription
> (Current 3.1.1 should be folded into 3.1.2, since it deals with how 
> back-end subscription is sent)

actually 3.1.1 is not relevant any more per your comments above on TLS; 
otherwise I've reordered as you suggested.

> 
> 
> 
> S3.1.2
>    Note that it is possible that two watchers, in a short period of
>    time, both subscribe to their resource lists, both of which include
>    presentity P.
> 
> Might it be simpler to RECOMMEND these back-end transactions be done 
> serially?

I wouldn't want to do that because of performance concerns. THat limits 
your subscription rate to 1/RTT which can be really, really slow.

> 
> 
> 
> S3.1.3
>    For each ACL Ai in the current ACL list, the RLS performs the rule
>    determination algorithm of Section 5.4 to compute the rule ID R for
>    the watcher W.
> 
> Since the rule determination algorithm takes an ACL list as an input, 
> shouldn't this say that the RLS performs the rule determination 
> algorithm for W and the current ACL list for the presentity?

good catch, fixed.

> 
> 
> 
> S3.1.2
>    o  If R is null, it means that the ACL doesn't specify the view ...
> 
> Change to "If R is null, it means that no ACL in the list specifies the 
> view..."

fixed

> 
> 
> 
> S3.1.2
>       The RLS SHOULD NOT perform
>       another back-end subscription, and must act as if it had created a
>       back-end subscription which was rejected.
> 
> Why is this a SHOULD and not a MUST? (Likewise for the subsequent bullet.)

because it still works; its just sub-optimal.

> 
> 
> 
> S3.2.1
>    If the contents of the NOTIFY are of type "application/aclinfo+xml",
>    the subscriber processes the body as described here.
> 
> This is really minor, but given that these aren't the only ACLs around, 
> I would prefer a slightly more specific name, e.g. 
> "application/view-sharing-aclinfo+xml"

ok, changed.

> 
> 
> 
> S3.2.1
>    The serving domain can change policies at any time.  When it does, it
>    sends an updated ACL on one or more subscriptions.  The RLS MUST
>    store this ACL.
> 
> Do you mean for this ACL to be simply stored, or to replace the old ACL? 
>  (Not a huge issue because the rule determination algorithm picks the 
> newest.)

update.

> 
> 
> 
> S3.2.1
>    Furthermore, if there are now two back-end subscriptions j1 and j2
>    for which Aj1 = Aj2, the RLS SHOULD terminate one of those two
>    subscriptions.
> 
> The terms "Aj1" and "Aj2" haven't been defined.  Suggest replacing "for 
> which Aj1 = Aj2" with "with equivalent ACLs".

done

> 
> 
> 
> S3.2.2
>    If the contents of the NOTIFY is a presence document, the RLS follows
>    the procedures defined here.
> 
> 
> The details of this section don't seem to have anything in particular to 
> do with presence.  Perhaps this could be re-cast in terms of 
> notifications of event state in general.

done.

> 
> 
> 
> S4
> 4.  Presence Agent Behavior
> 
> The terminology used in this section could better reflect the generality 
> of this mechanism.  Perhaps use the terms "State Agent" from RFC 3265.

changed to 'notifier'.

> 
> 
> 
> S4
>    When a presence agent receives a SUBSCRIBE request containing a
>    Supported header with the value "view-share", and it wishes to
>    utilize view sharing for this subscription, it follows the procedures
>    defined here.
> 
> 
> Is it allowable for a PA to initiate the use of view sharing?  For 
> example, could you have a PA that only supports view sharing, so that it 
> responds with "Required: view-share", whether or not the SUBSCRIBE asked 
> for it?  It may be best to forbid this, since it strengthens the 
> asymmetry discussed in section 2 (PA decides, RLS pays computational 
> burden).

Per above, no.

> 
> 
> 
> S4.1
>    First, the presence agent MUST have received the SUBSCRIBE request
>    over a mutually authenticated TLS connection.  If it had not, view
>    sharing cannot be utilized for this subscription.
> 
> It's not clear to me why it's more to authenticate SUBSCRIBE requests 
> here than in the general case.  As you've argued in the Security 
> Considerations, this extension doesn't grant any more information to the 
> Watching Domain than was already accessible.  So the risk due to a fake 
> RLS with this extension is the same as before.

Right, per above. THIs has been fixed up.

> 
> 
> 
> S4.2
>    If an ACL and a presence document are to be delivered, they MUST be
>    delivered in a separate NOTIFY request...
> 
> Change "a separate NOTIFY request" to "separate NOTIFY requests"
> 

fixed

> 
> 
> S4.3
>    o  There is more than one subscription from the watching domain to
>       this presentity with the same view, but the User-Agent header
>       field in the request differs between them.
> 
> 
> Should this refer to the "sip-instance" parameter instead?  (Likewise in 
> S4.5)

yes, fixed.

> 
> 
> 
> S5.1
>    This contains the list of rules defined by the ACL.  Each rule is
>    represented by the <rule> element.
> 
> Seems like "<view>" would be a more appropriate tag name, since there 
> are no actual rule semantics here, just an identifier for a view of the 
> events.

I kind of like <rule> more since the contents are effectively a whitelist...

> 
> 
> 
> S5.1
>    If two URI are present within <member> elements within the same
>    <rule>, it represents a contract by the presence server that both
>    users MUST get the same view.  Formally, if the presence server were
>    to receive a subscription from each watcher, both subscriptions would
>    be accepted or both would be rejected, and if accepted, each
>    subscription would receive semantically identical presence documents
>    at approximately the same time.
> 
> 
> This is the very first time that the term "view" is defined in the scope 
> of this document.  It should be closer to the beginning, say a paragraph 
> in the introduction of the following character:
> "
> Frequently, several watchers served by an RLS will receive the same 
> "view" of events: If the presence server were to receive a subscription 
> from each watcher, both subscriptions would be accepted or both would be 
> rejected, and if accepted, each subscription would receive semantically 
> identical presence documents at approximately the same time.
> "

good point - I've been using this term for so long I hadnt even realized 
it wasn't defined here or elsewhere. I added a discussion in the intro.

> Also, "indication" or "statement" would be a better word than "contract".

fixed

> 
> 
> 
> S5.4
>    it is possible that inconsistent ACL documents exist.  In that case,
>    R is assigned the value Ri from the ACL Ai which is the most recently
>    received amonst all ACL.
> 
> 
> Change "amonst all ACL" to "amongst all ACLs".
> 
> 

fixed.

Thanks!

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Richard Barnes <[email-masked]>
Date: Mon, 3 Nov 2008 12:08:10 -0500

Jonathan,

Thanks for your responses.  From a quick scan, it looks like my major  
concerns have been addressed.  I'll take a more thorough re-look after  
the I-D deadline :)

Cheers,
--Richard

On Nov 3, 2008, at 10:46 AM, Jonathan Rosenberg wrote:

> Richard,
>
> Thanks kindly for the extensive (and excellent) review and comments,  
> and I apologize for my tardy response.
>
> See responses below:
>
> Richard Barnes wrote:
>> = 
>> = 
>> = 
>> =====================================================================
>> = 
>> = 
>> = 
>> =====================================================================
>> General comments
>> = 
>> = 
>> = 
>> =====================================================================
>> unclearthroughout on whether this mechanism facilitates sharing  
>> between "systems" or "domains".  The latter is more consistent with  
>> Figure 1, and seems like what you're actually going for.  In  
>> particular, if the RLS is associated with a domain, then it might  
>> be possible to avoid manual provisioning (see 6. below)
>
> The vagueness is partly on purpose since it can be used with intra- 
> domain federation as well as inter-domain. However, the intra-domain  
> case is, in many ways, simpler, and ends up being just a special  
> case of inter-domain. So I think it makes sense to define it for  
>> 2. The document does a good job of addressing the risks that the  
>> Serving Domain is exposed to through view sharing.  However, it  
>> doesn't address the privacy risks that the *presentity* is exposed  
>> to.  The Watching Domain is now explicitly responsible for applying  
>> the privacy policies that the user has set (providing different  
>> views to different watchers), so the presentity now has to trust  
>> the Watching Domain to perform that operation as opposed to just  
>> passing through NOTIFYs.  The risk is that the Watching Domain  
>> fails to apply the Rule Determination Algorithm (as required in  
>> 3.2.2), and presence info fromone view leaks into others.
>>  You can tell a similar story here to the one you tell for ACLs  
>> inthe Security Considerations: Without view sharing, the Watcher  
>> already has access to all that presence information, so if it were  
>> malicious, it could already leak information between views.  Thus  
>> the only real risk is non-compliance, which you can't fix in a  
>> standard.  The only recommendation that seems necessary here is  
>> another reminder to the RLS to reinforce the importance of the  
>> rules determination algorithm being done correctly.
>
> Done. I've split out the security considerations section into a  
> section on considerations for the watched domain and considerations  
> for the presentity.
>
>> 3. It would be nice to discuss how view sharing interacts with S/ 
>> MIME protected presence documents.  For signed objects (that aren't  
>> encrypted), the usage is probably pretty much the same, except that  
>> the PA won't be able to modify the presence documents (unless it's  
>> the signer).  For enveloped/encrypted objects, there's some  
>> interaction between the set of authorized watchers and the set of  
>> keys that can be used to decrypt the object.
>
> Well, this is largely an academic discussion.... but you are of  
> course correct. I've added discussion on it.
>
>> Considerations, no more information is exposed here than with  
>> normal SIP events.  The risks of identity spoofing and interception  
>> are the same. It might even be less so if the peers are using  
>> direct links to each other (as in layer-2 peering federations).
>
> considerations section, where we cannot use view sharing until we  
> are sure that the RLS supports it as a opposed to the watching user.
>
>> 5. The document doesn't specify whether or not a single ACL can  
>> contain members from many domains.  From a privacy perspective, my  
>> preference would be to specify that within a single ACL,
> generalization of your rule is that the set of domains must match  
> the set for which that RLS is authorized to operate on behalf of.  
> Normally, this is just the domain of the RLS itself.
>
>> 6. Obviously, the requirement for "explicit provisioning" of  
>> trusted domains is kind of a turn-off (for scalability, dynamic  
>> extension oftrusted enclaves, etc.).  It seems like the critical  
>> distinction you're trying to enforce with this requirement is to  
>> separate an RLS from a watcher, where an RLS is the entity  
>> authorized -- by both domains -- to see all presence transactions  
>> between the two domains, and the watcher is only authorized (by  
>> either domain) to see its own transactions.
>
> Right.
>
>> Is there a mechanism other than manual provisioning to make this  
>> distinction?   It seems like the RLS is something that might get  
>> advertised in the DNS, for example.  Assuming that (1) the PA  
>> matching an RLS in the DNS and (2) the PA only issues ACLs in which  
>> all members are from the same domain (see above), then the privacy  
>> risks would be eliminated.  A request from a non-view-sharing  
>> domain (as in the current example attack) wouldn't come from an  
>> RLS, and an attacker that creates his own domain/RLS would only get  
>> information for his fake domain.
>
> actual message delivery, but just as a check for existence, could  
> not a malicious end user get a DNS entry created for the domain he  
> is in? This solution gets intertwined with the question on how DNS  
> provisioning works and how secure it is.
>
> In practice though, I suspect this will be primarily used in cases  
> of pre-arranged trust, which is why I wasn't too worried about a  
> better solution. I'd suggest we separate these out. For this  
> document, I can change the normative requirement to something like,  
> "MUST make sure that the RLS in the watching domain supports this  
> extension" and then discuss provisioning as the only way defined in  
> this document to figure that out. This way, if we OPTIONS or DNS or  
> something else, it can be added later.
>
>> 7. This document claims in the Abstract and the introduction to be  
>> an extension to the general SIP events framework.  However, the  
>> entire introduction is presence-centric, and many of the sections  
>> that could be general use presence-specific terminology (e.g.,  
>> S3.2.2 and S4; see comments below).  It should be made clearer  
>> which parts are presence-specific, which are more general.
>
> Its general though I think its principal use is presence. I'd like  
> to keep the intro presence centric, and will clean up the rest to be  
> more generic.
>
>> initiate the use of view sharing?  For example, could you have a PA  
>> that only supports view sharing, so that it responds with  
>> "Required: view-share", whether or not the SUBSCRIBE asked for it?   
>> It may be best to forbid this, since it strengthens the asymmetry  
>> discussed in section 2 (PA decides, RLS pays computational burden).
>
>> = 
>> = 
>> = 
>> =====================================================================
>> S2
>> This raised a red flag for me at first, since the load on the RLS  
>> is determined by what the PA decides to do.  However, this  
>> asymmetry is not so bad because the Serving Domain has to give up  
>> potentially sensitive information in order to incur increased  
>> processing in the Watching Domain (and presumably, the Watching  
>> Domain has to ask for this, see S4 below).
>> It would also be helpful to the reader here to have a brief  
>> description of what the logical structure of an ACL looks like,  
>> since that matters a lot for sections 3 and 4.
>
>> I found the ordering of this section confusing.  I would suggest re- 
>> organizing according to the temporal order of things, in the  
>> following way:
> actually 3.1.1 is not relevant any more per your comments above on  
> TLS; otherwise I've reordered as you suggested.
>
>> S3.1.2
>> Might it be simpler to RECOMMEND these back-end transactions be  
>> done serially?
>
> I wouldn't want to do that because of performance concerns. THat  
> limits your subscription rate to 1/RTT which can be really, really  
> slow.
>
>
>> S3.1.3
>> Since the rule determination algorithm takes an ACL list as an  
>> input, shouldn't this say that the RLS performs the rule  
>> determination algorithm for W and the current ACL list for the  
>> presentity?
>
> good catch, fixed.
>
>
>> S3.1.2
>> Change to "If R is null, it means that no ACL in the list specifies  
>> the view..."
>
> fixed
>
>> S3.1.2
>> This is really minor, but given that these aren't the only ACLs  
>> around, I would prefer a slightly more specific name, e.g.  
>> Do you mean for this ACL to be simply stored, or to replace the old  
>> ACL?  (Not a huge issue because the rule determination algorithm  
>> picks the newest.)
>
> update.
>
>> S3.2.1
>> The terms "Aj1" and "Aj2" haven't been defined.  Suggest replacing  
>> "for which Aj1 = Aj2" with "with equivalent ACLs".
>
> done
>
>> S3.2.2
>> The details of this section don't seem to have anything in  
>> particular to do with presence.  Perhaps this could be re-cast in  
>> terms of notifications of event state in general.
>
> done.
>
>> S4
>> The terminology used in this section could better reflect the  
>> generality of this mechanism.  Perhaps use the terms "State Agent"  
>> from RFC 3265.
>
> changed to 'notifier'.
>
>> S4
>> example, could you have a PA that only supports view sharing, so  
>> that it responds with "Required: view-share", whether or not the  
>> SUBSCRIBE asked for it?  It may be best to forbid this, since it  
>> strengthens the asymmetry discussed in section 2 (PA decides, RLS  
>> pays computational burden).
>
> Per above, no.
>
>> S4.1
>> It's not clear to me why it's more to authenticate SUBSCRIBE  
>> requests here than in the general case.  As you've argued in the  
>> Security Considerations, this extension doesn't grant any more  
>> information to the Watching Domain than was already accessible.  So  
>> the risk due to a fake RLS with this extension is the same as before.
>
>> Should this refer to the "sip-instance" parameter instead?   
>> (Likewise in S4.5)
>
> yes, fixed.
>
>> S5.1
>> Seems like "<view>" would be a more appropriate tag name, since  
>> there are no actual rule semantics here, just an identifier for a  
>> view of the events.
>
>> This is the very first time that the term "view" is defined in the  
>> scope of this document.  It should be closer to the beginning, say  
>> a paragraph in the introduction of the following character:
>> "
>> "view" of events: If the presence server were to receive a  
>> subscription from each watcher, both subscriptions would be  
>> accepted or both would be rejected, and if accepted, each  
>> subscription would receive semantically identical presence  
>> documents at approximately the same time.
>> "
>
> good point - I've been using this term for so long I hadnt even  
> realized it wasn't defined here or elsewhere. I added a discussion  
> in the intro.
>