[martini] gin #68 (new): Ops-Dir Review

["martini issue tracker" <[e-mail]>]

#68: Ops-Dir Review

 I have performed an Operations Directorate review of draft-ietf-martini-
 gin-12.

 ---
 Operations directorate reviews are solicited primarily to help the area
 directors improve their efficiency, particularly when preparing for IESG
 telechats, and allowing them to focus on documents requiring their
 attention
 and spend less time on the trouble-free ones.

 Improving the documents is important, but clearly a secondary purpose.
 A third purpose is to broaden the OpsDir reviewers' exposure to work going
 on in other parts of the IETF.

 Reviews from OpsDir members do not in and of themselves cause the IESG to
 raise issue with a document. The reviews may, however, convince individual
 IESG members to raise concern over a particular document requiring further
 discussion. The reviews, particularly those conducted in last call and
 earlier, may also help the document editors improve their documents.

 ---

 Review Summary:
 This Proposed Standard document that defines a mechanism whereby a SIP
 PBX can register a block of AORs.

 I see no major operational issues with a: the concept or b: the
 mechanisms described in the document.
 Bulk registration may simplify operations by doing away with
 complexity and may simplify debugging.
 Standardization of this approach should improve interoperability,
 addressing operational concerns.

 I found the document to be easy for an operator with no real SIP
 knowledge (such as myself :-p) to understand.

 One (minor) thing that I would have liked to see would be a bit of
 text suggesting a method in which an operator can tell how an AOR was
 registered (explicitly or implicitly through gin) -- as I said, I'm
 not a SIP expert, so this may a: not make sense or b: be a solved
 problem.

 --------------
 Nits (some of these nits contributed by Ryan Shea, who is not subscribed).
 These are truly minor, but will save the Editor from having to find them:

 Abstract:
 In the abstract many acronyms are expanded (SIP, SIP-PBX, UA), but AOR
 is not. Having them all expanded (or none expanded) would be nice.

 Section 4:
 Globally Routable UA URI's (GRUU) are first mentioned, but the
 reference to the RFC is in section 7.1.


 Section 5.1:
 Acronym "UAC" not expanded / defined.


 Section 6:
 s/An SSP using this mechanism/A SSP using this mechanism/


 Section 7.1.2.1 (indented):
 s/The registrar maintains a counter, I. this counter is/The registrar
 maintains a counter, I. This counter is/ (Capitalization of 't').


 -------------------------------------------------------------------------------------------
 Operations and Management Review Checklist
 A.1.  Operational Considerations
    1.  Has deployment been discussed?
     Yes / N/A

    2.  Has installation and initial setup been discussed?
     N/A

    3.  Has the migration path been discussed?
      Yes -- checks for support of the mechanism are included to
 address coexistence / compatibility with implementations that do not
 support this.
       See sections 5.1, section "Security Considerations" and Appendix
 A, Req 8, Req 9 (and many others).

    4.  Have the Requirements on other protocols and functional
        components been discussed?
       Yes, as much is appropriate.

    5.  Has the impact on network operation been discussed?
         N / A.

    6.  Have suggestions for verifying correct operation been discussed?
        Not really. A little more text on this would be nice, but it
 appears that "normal" SIP debugging techniques will be adequate.

    7.  Has management interoperability been discussed?  See Section 3.1.
       N/A

    8.  Are there fault or threshold conditions that should be reported?
        No.

    9.  Is configuration discussed?
      N/A

 A.2.  Management Considerations
    1-6:
      N/A

    7.  Is security management discussed?
      A little bit more text on key management / rotation for GRUU's
 would have been nice, but I don't think needed, and probably out of
 scope.

 A.3.  Documentation

    Is an operational considerations and/or manageability section part of
    the document?
      No, not specifically. Operational considerations appear to have
 been considered in design and addressed well enough thought the doc.

    Does the proposed protocol have a significant operational impact on
    the Internet?
       Don't think so.

    Is there proof of implementation and/or operational experience?
       I personally do not know of any, but then again there is no
 reason that I *would*, as I do not play in this space.
       The Introduction section states:
         "this approach has seen significant deployment in
          certain environments.  In particular, deployments in which small
 to
          medium SIP-PBX servers are addressed using E.164 numbers have
 used
          this mechanism to avoid the need to maintain DNS entries or
 static IP
          addresses for the SIP-PBX servers."
      and I see no reason to doubt this :-)

-- 
-----------------------------------+----------------------------------------
 Reporter:  wkumari@…              |       Owner:            
     Type:  defect                 |      Status:  new       
 Priority:  minor                  |   Milestone:  milestone1
Component:  gin                    |     Version:  1.0       
 Severity:  Submitted WG Document  |    Keywords:            
-----------------------------------+----------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/martini/trac/ticket/68>
martini <http://tools.ietf.org/martini/>