Last Call Review of draft-holmberg-dispatch-iotl-02
review-holmberg-dispatch-iotl-02-opsdir-lc-brownlee-2014-12-28-00

Request Review of draft-holmberg-dispatch-iotl
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-01-08
Requested 2014-12-15
Authors Christer Holmberg, Jan Holm, Roland Jesske, Martin Dolly
Draft last updated 2014-12-28
Completed reviews Genart Last Call review of -03 by Robert Sparks (diff)
Secdir Last Call review of -03 by Paul Hoffman (diff)
Opsdir Last Call review of -02 by Nevil Brownlee (diff)
Assignment Reviewer Nevil Brownlee
State Completed
Review review-holmberg-dispatch-iotl-02-opsdir-lc-brownlee-2014-12-28
Reviewed rev. 02 (document currently at 06)
Review result Has Nits
Review completed: 2014-12-28

Review
review-holmberg-dispatch-iotl-02-opsdir-lc-brownlee-2014-12-28

Hi all:

I have performed an Operations Directorate review of
    draft-holmberg-dispatch-iotl-03

  "This document defines a new SIP URI parameter, 'iotl'.  The parameter
   can be used in a SIP URI to indicate that the entity associated with
   the address, or an entity responsible for the host part of the
   address, represents the end of a specific traffic leg (or multiple
   traffic legs)."

- - - -

This draft is intended to be the reference RFC for the SIP iotl
parameter. It clearly defines what this parameter is intended to do,
and specifies what's needed for SIP implementations to use it.
The diagram showing SIP connections (Figure 1) and the detailed
explanations in its Appendix seem to explain it very clearly.

Readers are expected to have a good understanding of SIP, I had to look
up the meanings of B2BUA and S-CSCF - I guess reference to RFC 3261 (SIP
protocol) is sufficient here.

The last few paragraphs of section 5.1 (Usage) indicate to me that the
authors have considered how newer SIP implementations (i.e. those that
support the iotl parameter) should interact with older implementations.

Section 6 gives an ABNF description of allowed values for iotl.
The first four values are the ones explained in this draft, the
remaining one is other-itol, which may be any string of
other-iotl-char, i.e. any string of alphanum or - characters.
However, the draft does not say anything about how an other-iotl value
may be used.  Surely the draft should say what this is intended for, or
just leave it out completely?

Just one typo:



The last paragraph of section 1 is repeated as section 2 


(Applicability).  It should be deleted.





Cheers, Nevil
Co-chair, IPFIX and EMAN WGs

--
---------------------------------------------------------------------
 Nevil Brownlee                          Computer Science Department
 Phone: +64 9 373 7599 x88941             The University of Auckland
 FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand