Last Call Review of draft-mohali-dispatch-cause-for-service-number-12
review-mohali-dispatch-cause-for-service-number-12-genart-lc-halpern-2016-12-15-00

Request Review of draft-mohali-dispatch-cause-for-service-number
Requested revision No specific revision (document currently at 14)
Type IETF Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-01-18
Requested 2016-12-14
Authors Marianne Mohali , Mary Barnes
I-D last updated 2017-03-15 (Latest revision 2017-01-30)
Completed reviews Secdir IETF Last Call review of -12 by Robert Sparks (diff)
Genart IETF Last Call review of -12 by Joel M. Halpern (diff)
Opsdir IETF Last Call review of -12 by Lionel Morand (diff)
Assignment Reviewer Joel M. Halpern
State Completed
Request IETF Last Call review on draft-mohali-dispatch-cause-for-service-number by General Area Review Team (Gen-ART) Assigned
Reviewed revision 12 (document currently at 14)
Result Ready w/issues
Completed 2016-12-15
review-mohali-dispatch-cause-for-service-number-12-genart-lc-halpern-2016-12-15-00
Major:
    This document defines a new code for use in SIP, and specifies new behavior
    both for the code itself and for its use in history-info.  I am thus
    confused as to how this can be an informational RFC.  It looks like it
    either Proposed Standard or experimental.  Yes, I see that RFC 4458, which
    this updates is Informational.  But just because we did it wrong before
    does not make that behavior correct now.  In addition to my understanding
    of the roles of different RFCs, I note that RFC 3969 and the IANA registry
    both state that this assignment must be made by a standards track RFC.

Minor:
   Given our emphasis on IPv6 over IPv4, would it not make sense for the
   examples to use IPv6 addresses?  (Inspired by the Id-Nits alert.)