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 protected]
https://www1.ietf.org/mailman/listinfo/gen-art
