I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
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.
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 prematur
e 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/
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
