Document: draft-ietf-sipping-service-identification-03.txt
Reviewer: Elwyn Davies
Review Date: 10 July 2009
IETF LC End Date: 22 July 2009
IESG Telechat date: (if known) -

Summary: 
It seems that a sub-title of this document could be "SIP Declarative Service Identification consodered harmful". Generally the document is well-written and argued, if a little fervent in parts, and is almost ready for the IESG. However I think that:
- being more explicit about the thesis expressed by 'considered harmful' up front might be useful (even if more fervent), and
-  bringing out the negotiative nature of SIP signaling in the eventual recommendations, requiring elements (especially intermediate elements on the signaling path) to take account of the whole signling exchange when deriving the service identity.
There are also some nits to fix  

Issues: 

Using *all* the signaling to determine the service used:  (This could be considered a bit more than a minor issue.)  The implication of the discussion in ss 4 and 5 is to emphasise importance the negotiative nature of SIP signaling as against the fiat of a declarative service identifier.  Some of the strength of this argument seems a little lost in the eventual recommendations in s7.  In s7.1, it seems appropriate to note that the service needs to be derived from the *complete* signaling exchange rather than determining what is happening based on (say) only an initial INVITE (maybe this is an explicit 'peril' as well).  Similarly s7.2 seems to imply that the initial INVITE should tie down the service totally, rather than there being any possibility of negotiation of an alternative service by the called party. Again in s7.4, it is suggested that a message could carry a service identifier within a domain - one should be very careful even within a single domain to avoid premature  and hence possibly incorrect identification of the service to be invoked eventually.  It would be very easy to read s7.4 as implying that the service implied *can* be identified when the initial request arrives at the domain ingress and then fed across the domain = this would be inappropriate if negotiation was involved and would have all the bad effects of declarative service ids for the 'other elements' if the eventual service settled on was not the one initially identified.  Even the use of presence (s7.3) cannot absolutely guarantee the eventual service used, even if it gives the called party a degree of certainty about the intentions of the caller - there is still the potential for choice by the called party.

Extremity of language in s6.3: Whilst I agree with the argument in this section (Stifling of Service Innovation), the language is perhaps a little fervid. Toning down the language (e.g., stifling -> restriction, anathema -> contrary) might avoid immediate alienation of those less committed to tyranny of the endpoint.  


Nits/editorial comments: 
s3.1, paras 2 and 3: (slightly pedantric) Describing a conference session in which a user receives audio and video as 'listen-only' might or might not be an accurate, if mildly perjorative, description of the user's intention. Although this term is widely and incorrectly used, maybe 'observer mode' is more descriptive of the user service. [Aside: Would the user be confused?  Maybe on some conferences I have attended!]

s3.4, last para: s/app/application/

s3.4, last para: s/would be consumed/might cause a configuration application to be launched or might just be consumed/ 

s4.1, para 2: s/dispatch request/dispatch the request/

s4.2, last para: s/config/configuration/

s4.3, para 1: /The IP network/Some parts of the IP network can allegedly provide/ (differing levels of QoS.. YMMV).

s5.2: s/its/it is/ (several places), s/thats/that is/

s5.2, 'Gaming vs. Voice Chat' section: s/automata/automaton/

s5.2, 'Gaming vs Voice Chat #2' section: expand acronym GRUU.

s6.1, last para: s/If emergency calls where indicated/If emergency calls were indicated/

s6.2, start of para 3: s/declarative/Declarative/

s6.2, last sentence of para 3: s/That is why services need to be derived by signaling/That is why services need to be derived from signaling/

s7.3: s/numerous service URI/numerous service URIs/

s7,5, para 2: Expamd PSTN (?).

s7.5, para 3: s/yielded/yielding/