Subject: [Gen-art] Gen-art review of draft-allen-sipping-poc-p-answer-state-header-04.txt

From: Elwyn Davies <[email-masked]>
Date: Thu, 30 Nov 2006 14:16:54 +0000

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-allen-sipping-poc-p-answer-state-header-04.txt
Reviewer: Elwyn Davies
Review Date: 30 November 2006
IETF LC End Date: 6 December 2006

Summary:
This document must hold some sort of record for long titles! (Maybe 
omitting the abbreviation(s) from the title would keep it down to just 
two lines).

Generally the document is in good shape to go for IESG approval.  I 
identified a few minor issues/nits that ought to be addressed plus some 
editorial nits.

Comments:
=========

There are a couple of points which I felt might need to be addressed 
(but not being a SIP expert these may not be relevant):
- Noting whether or not the provisional responses need to be transmitted 
reliably.
- Discussing what happens to the state created at PTT servers in the 
event that something doesn't happen as expected. The sorts of things I 
am thinking of are:
  * A race condition where the terminating UA changes from Auto to 
Manual Answer mode and
    the INVITE arrives at the PTT Server (just) before the PTT Server 
finds out about the
    client's change of mind.  If the user answers the only risk to the 
system is buffer
    overflow but the user may lose some media.  If the user doesn't 
answer: what happens
    then?  Does there need to be timeout on the state in the PTT Server 
or will it be
    cleared down by one or other end?
  * Similarly if the terminating UA has gone offline - how does the 
state get cleared 
    down?

s6, para 1: 'receiving PTT Server may send a SIP 200 OK response'  I 
think this is a 'MAY'.

s6, para 1: 'If the response containing the P-Answer-State header
   field with the value "Unconfirmed" also contains an answer the PTT
   Server that included the P-Answer-State header field and answer in
   the response is also indicating that it is willing to buffer the
   media until a final "Confirmed Indication" is received.'

This seems a little vague:  If I understand the rest of the para 
correctly, this is describing a situation where the response traverses 
multiple PTT servers.  The quoted sentence (and the one before) appear 
to be considering the case where two or more of the servers might be 
able to do buffering on behalf of the inviting UA.  The previous 
sentence seems to be clear that if the PTT Server that knows about the 
destination answer mode isn't offering to do buffering then one of the 
previous ones may do so.  I am not sure if the quoted sentence says that 
a previous PTT server  can *also* do buffering or that it *shouldn't* do 
buffering if the response indicates that buffering has been offered 
nearer to the destination.  Serial buffering doesn't seem particularly 
clever but anyway this should be clarified I think.

s6, para 2: 'If the P-Answer-State header field with value
   "Unconfirmed" is included in a provisional response that contains an
   answer the PTT Server is leaving the decision where to do buffering
   to other PTT Servers upstream ...'

Doesn't this contradict the previous paragraph?  I thought the previous 
para says *not* containing an answer means deferring the buffering decision?

s9: s1 states that there is an assumption of transitive trust through 
the network on which PoC is likely to be deployed.  Shouldn't this be 
played out/discussed in the security considerations?  It is not 
mentioned (explicitly) currently.

s9, para 3: [6] is TLS 1.0 - should we be using TLS 1.1 now?

Editorial:
==========

Generally should have:
- Capitalisation of all substantive words in section headings
- Consistent use of 'Push-to-talk' vs 'Push to talk'
- Consistent use of 'Push-to-talk over [Cc]ellular'
- Consistent use of 'provisional' vs 'Provisional'

s1: 'availability(?) of transitive trust': 'existence' might be a better 
word.

s1: Useful to quote section number for Applicability cross reference.

s2: Useful to state up front that this doc is defining a private 
(P-header) under the terms of RFC 3427 to achieve the stated aims.

s3: reference(s) to documents where SIP proxy and B2BUA are defined 
would be useful.  Similarly for SIP response numbers.

s4, para 2: A (normative) reference to an (OMA) document containing the 
PoC architecture specification is needed here.

s5, para 1, sentence2: s/short in the order of 10-30 seconds/short, and 
typically in the order of 10-30 seconds,/

s5, para2: It would be helpful to remind us that the P-Answer-State 
header is what is being defined in this doc before para 5 since the new 
header is mentioned here. This might be best achieved by moving para 5 
ahead of paras 2-4 and giving the name of the new header in the new para 2.

s3, para 2: It would be good to remind the uninitiated that a 183 
response *is* a Provisional response and that this is a defined term 
from the SIP RFC.

s5, para 4: s/un-buffering/de-buffering/ (or maybe batter 'playing out 
the buffered media') - presumably the server has to carry on buffering?

s6, para 1: s/to transmit/permitting it to transmit/

s6.3, bullet 2: s/manual acceptance/user intervention/

s6.4.1, para 2: s/his received/has received/

s7.2: 'Table 1 extends the headers defined in this document to ...'
This doesn't really make sense (although I admit it is copied from 
existing RFCs which say the same thing).  I would suggest 'Table 1 
provides the additional table entries for the P-Answer-State header 
needed to extend ...'.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art