Skip to main content

Last Call Review of draft-ietf-ecrit-psap-callback-10
review-ietf-ecrit-psap-callback-10-genart-lc-gurbani-2013-09-20-00

Request Review of draft-ietf-ecrit-psap-callback
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-09-27
Requested 2013-09-19
Authors Henning Schulzrinne , Hannes Tschofenig , Christer Holmberg , Milan Patel
I-D last updated 2013-09-20
Completed reviews Genart Last Call review of -10 by Vijay K. Gurbani (diff)
Genart Telechat review of -13 by Vijay K. Gurbani
Assignment Reviewer Vijay K. Gurbani
State Completed
Request Last Call review on draft-ietf-ecrit-psap-callback by General Area Review Team (Gen-ART) Assigned
Reviewed revision 10 (document currently at 13)
Result Ready w/issues
Completed 2013-09-20
review-ietf-ecrit-psap-callback-10-genart-lc-gurbani-2013-09-20-00
[Resending ... had the wrong address for Roger Marshall.  Sorry. ]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-ecrit-psap-callback-10
Reviewer: Vijay K. Gurbani
Review Date: Sep-20-2013
IETF LC End Date: Sep-27-2013
IESG Telechat date: Unknown

This draft is basically ready for publication, but has a couple of
minor issues that should be fixed (or at least looked at) before
publication.

Major: 0
Minor: 2
Nits:  4 (to improve readability)

Minor:
- S5.2: Maybe I am missing something here, but I did not see any
 proposed requirement as I read the text until this point.  At least I
 do not see a explicit requirement.

 The text in S5.1 constitutes an implicit requirement in that it asks
 the SIP UA to override user interface configurations when an incoming
 call has "Priority: psap-callback" header AND the SIP UA has recently
 placed a call to an emergency service.  Is this the requirement you
 allude to in the first sentence of S5.2?  If so, may be better to
 explicitly pose this as a requirement.

 The second paragraph of S5.2 constitutes a separate requirement.

 Is it worth spelling these out explicitly as requirements?

- S5.3, last paragraph: It seems to me that the SIP UA is the authority
 insofar as it can maintain state that an emergency call was made a
 short while ago.  Consequently, it would seem beneficial to couple the
 presence of the callback marking with this state and override local UA
 behaviour.

 At least, this alleviates the eventuality that somehow the VoIP
 provider forgot to scrub the marking AND the UA never made an emergency
 call (thereby allowing spam through).

 Now, if it is your intent to keep the UA as stateless as possible, then
 overriding local UA behaviour based on solely the callback marking is
 fine.  But I do not know what your assumptions are here with respect to
 state maintained in the UA.  So please determine if this approach of
 asking UA to couple state information with the marking makes sense or
 not.  If not, feel free to disregard, but I did want to point it out.

Nits:
- S3, first paragraph: "As explained in Section 1 a SIP entity examines
 an incoming PSAP callback by comparing the domain of the PSAP with the
 destination domain of the emergency call."

 Here, I would suggest adding a small phrase as follows:

 s/destination domain of the emergency call./destination domain of the
 outbound emergency call placed earlier./

- S3.1: s/synchronized as to state/synchronized,/
 This improves readability since the text as it currently stand is hard
 to parse.

- S3.3, second paragraph: s/Similarly to/Similar to/

- S3.5, first paragraph: s/later does leave/later leaves/

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg at {bell-labs.com,acm.org} / vijay.gurbani at alcatel-lucent.com
Web: 

http://ect.bell-labs.com/who/vkg/

  | Calendar: 

http://goo.gl/x3Ogq