I am the assigned Gen-ART reviewer for
draft-roach-sip-http-subscribe-06.txt

For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.

Please resolve these comments along with any other Last Call comments
you may receive.

Summary: This draft is almost ready for publication as Proposed Standard but 
I have a few comments.

Meta
====
* How does the mechanism in the draft relate to say an atom or an RSS 
feed? When would one use the sip subscribe mechanism instead of atom and 
vice versa? Perhaps it is out of scope of this document, but I was 
just curious.

Minor
=====

* Section 3.2

The example using two URLs each in www.example.com and www.example.org is 
too complex. I do not see the value in adding the www.example.org URLs. 
Are these necessary Can you simplify this to

For example: consider the case in which a client wishes to monitor
the resources http://www.example.com/goat,and http://www.example.com/sheep. 
It would use HTTP to perform HEAD and/or GET operations on these resources.  
The responses to these operations will contain link relations for both monitor 
and monitor-type for each of the four resources.  Assume the monitor link for 
http://www.example.com/goat is sip:a94aa000@example.com;
for http://www.example.com/sheep, sip:23ec24c5@example.com. Further, assume 
the monitor-group link for http://www.example.com/goat and 
http://www.example.com/sheep are both sip:httpmon@rls.example.com,

Because they share a common monitor-group link, the client would group 
together http://www.example.com/goat and http://www.example.com/sheep 
in a single subscription.  It sends this subscription to the monitor-group 
URI (sip:httpmon@rls.example.com), with a resource-list containing the 
relevant monitor URIs (sip:a94aa000@example.com and sip:23ec24c5@example.com).

* Section 3.3

This section is very interesting and useful. Why does it need to be removed?

Typo
====

* Section 4.7

s/supress/suppress/