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 ...'.