Skip to main content

Last Call Review of draft-ietf-straw-b2bua-loop-detection-04
review-ietf-straw-b2bua-loop-detection-04-opsdir-lc-kumari-2014-04-18-00

Request Review of draft-ietf-straw-b2bua-loop-detection
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-04-25
Requested 2014-04-14
Authors Hadriel Kaplan , Victor Pascual
I-D last updated 2014-04-18
Completed reviews Genart Last Call review of -04 by Wassim Haddad
Secdir Last Call review of -04 by Chris M. Lonvick
Opsdir Last Call review of -04 by Warren "Ace" Kumari
Assignment Reviewer Warren "Ace" Kumari
State Completed
Request Last Call review on draft-ietf-straw-b2bua-loop-detection by Ops Directorate Assigned
Reviewed revision 04
Result Has nits
Completed 2014-04-18
review-ietf-straw-b2bua-loop-detection-04-opsdir-lc-kumari-2014-04-18-00
Fear not, nor be dismayed; be strong and of good courage; I have
reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
operational area directors.
Document editors and WG chairs should treat these comments just like
any other last call comments.

Overview: I reviewed draft-ietf-straw-b2bua-loop-detection-04 - "Loop
Detection Mechanisms for Session Initiation Protocol (SIP)
Back-to-Back User Agents (B2BUAs)"

Noting that I know slightly less about SIP than I do about obscure
Russian poets from the early 1600's, this document seems reasonable,
and doesn't seem to have any adverse operational implications.

The problem that it tries to solve (Back-to-Back User Agents causing
unending SIP routing loops) sound: a: hilarious, b: serious and c:
worth solving. Fixing these definitely sounds like it would make
operational life for SIP folk better.

>From my (limited) understanding, much of the "implementation" is
clarifying that implementations should a: behave like responsible
citizens and b: not futz with header fields designed to prevent loops.

The OpsDir wiki says "A Check-list of possible questions/topics to
address in an OPS Directorate review may be found in Appendix A of RFC
5706. Only include the questions that apply to your review.", so, here
they are:

5.  Has the impact on network operation been discussed?
Not explicitly, but if this is "implemented" there should be less
B2BUA caused SIP routing loops. Other than for job security, this
cannot be a bad thing from a network operations standpoint.

A.3.  Documentation
Is an operational considerations and/or manageability section part of
the document?
  Nope. Not, IMO, is one needed.

Does the proposed protocol have a significant operational impact on
the Internet?
  Yah, it makes life better.

Is there proof of implementation and/or operational experience?
  Sorry, no idea.

In order to try and make thie OpsDir review at least *somewhat*
useful, here are some (minor) nits.

Intro:
O: "Unbounded SIP request loops have actually occurred in SIP
deployments, numerous times."
P: "Unbounded SIP request loops have actually occurred in SIP
deployments numerous times."
C: An extra comment, makes the flow odd.

O: "...been unbounded/unending is they crossed B2BUAs..."
P: "...been unbounded/unending is that they crossed B2BUAs..."
C: Readability.

O: "...too many times" is very hard to accurately determine;..."
P: "...too many times" is very hard to determine  accurately;..."
C: Same.

I suspect I may have failed in making this "useful".

W