Last Call Review of draft-ietf-straw-sip-traceroute-02

Request Review of draft-ietf-straw-sip-traceroute
Requested rev. no specific revision (document currently at 03)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-07-04
Requested 2014-06-26
Authors Hadriel Kaplan
Draft last updated 2014-07-10
Completed reviews Genart Last Call review of -02 by Meral Shirazipour (diff)
Genart Last Call review of -02 by Meral Shirazipour (diff)
Secdir Last Call review of -02 by Yoav Nir (diff)
Assignment Reviewer Meral Shirazipour
State Completed
Review review-ietf-straw-sip-traceroute-02-genart-lc-shirazipour-2014-07-10
Reviewed rev. 02 (document currently at 03)
Review result Ready with Nits
Review completed: 2014-07-10


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



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


Document: draft-ietf-straw-sip-traceroute-02

Reviewer: Meral Shirazipour

Review Date: 2014-07-02

IETF LC End Date:   2014-07-04

IESG Telechat date: 2014-07-10




This draft is ready to be published as Standards Track RFC, but I have some comments.


Nits/editorial comments:

- Abstract Suggestion to spell out SIP and B2BUA (Back-to-Back User Agent).

Also not clear in abstract and in section 1 if hop by hop traceroute for SIP means sequence of B2BUAs. The analogy to IP traceroute is good but it would be better to clarify the difference with SIP traceroute. Please take a look at this.


-[Page 3] "be used to directly to test"---->"be used directly to test"


-[Page 4]  Section 3.1 references to RFC3261, which is not listed in the references section. Also it would be preferable to cite this RFC the first time Max-Forwards header field  is mentioned on Section 1.


-[Page 6] [draft-loop-detection] does not refer to the latest version (to be replaced by RFC number since it is in RFC queue?).


-Just wondering if the proposed mechanism does not violate Section of RFC3261


   A UAC MUST insert a Max-Forwards header field into each request it

   originates with a value that SHOULD be 70.  This number was chosen to

   be sufficiently large to guarantee that a request would not be

   dropped in any SIP network when there were no loops, but not so large

   as to consume proxy resources when a loop does occur.  **Lower values

   should be used with caution and only in networks where topologies are

   known by the UA.**






Best Regards,



Meral Shirazipour

Ericsson Research