Thank you very much for the review, Meral. Hadriel - any thoughts on these comments? And Meral, which part of 3261 section 8.1.1.6 are you thinking that is violated? The MUST? The SHOULD? The should? I thought it violated only the SHOULD and should parts… which I think should be fine… but looking at Hadriel for confirmation...
Jari On 02 Jul 2014, at 18:59, Meral Shirazipour <[email protected]> wrote: > 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-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 > > > Summary: > 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 8.1.1.6 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 > --- > Meral Shirazipour > Ericsson Research > www.ericsson.com > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
