Management Information Base for the Session Initiation Protocol (SIP)
draft-ietf-sip-mib-12

[Ballot comment]
I'm curious. If this is used to manage a session end to end, what is going to
happen to the following items when there is a NAT on the path?

      sipUACfgServerAddr OBJECT-TYPE
          SYNTAX    InetAddress
          MAX-ACCESS read-only
          STATUS    current
          DESCRIPTION
              "This object reflects the address of a SIP server
                this user agent will use to proxy/redirect calls."
         
        sipServerHostAddr OBJECT-TYPE
            SYNTAX    InetAddress
            MAX-ACCESS read-only
            STATUS    current
            DESCRIPTION
                  "This is the host portion of a SIP URI that is
                  assigned to the SIP server.  It MAY contain a fully
                  qualified domain name, or an IP address.  The length
                  of the value will depend on the type of address
                  specified.
                  sipServerHostAddrType formalizes the type of address
                  given by this object.  It is the user's
                  responsibility to maintain consistency between this
                  object and the type specified by
                  sipServerHostAddrType."

IANA Last Call Comment:

Uppon approval of this document the IANA will make the following assignents
in the "NETWORK MANAGEMENT PARAMETERS" registry located at
http://www.iana.org/assignments/smi-numbers

Under:
Prefix: iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)

XXX1 | sipTC | SIP Textual Conventions | [RFCTOBE-sip-mib]
XXX2 | sipCommonMIB | SIP Common MIB Module | [RFCTOBE-sip-mib]
XXX3 | sipUAMIB | SIP User Agent | [RFCTOBE-sip-mib]
XXX4 | sipServerMIB | SIP Server MIB Module | [RFCTOBE-sip-mib]

[Ballot discuss]
Besides the initial comments that I made off-line and were incorporated in the proposed RFC Editor notes there are some new comments resulted from a review by Bert Wijnen and discussions on the MIB doctors list. I believe that the amount justifies a new version of the draft. I will gladly clear the DISCUSS if at least the more critical issue of sipServiceNotifEnable DESCRIPTION clause suggesting to return a badValue and some of the more obvious non-critical issues were addressed.

---------

--- SIP-TC module

None of this is blocking or a fatal flaw. But pls DO consider my well-intended comments to try and help make this MIB module better and easier to understand by MIB implementers and NM application developers.

When I see:
      SipTransportProtocol ::= TEXTUAL-CONVENTION
              STATUS current
              DESCRIPTION
                  "This convention is a bit map.  Each bit represents a
                    transport protocol.  If a bit has value 1, then that
                    selected transport protocol is in some way dependent
                    on the context of the object using this convention.
                    If a bit has value 0, then that transport protocol
                    is not selected.  Combinations of bits can be
                    set when multiple transport protocols are selected.

                    bit 0 : a protocol other than those defined here
                    bit 1 : User Datagram Protocol
                    bit 2 : Transmission Control Protocol
                    bit 3 : Stream Control Transmission Protocol
                    bit 4 : Transport Layer Security Protocol over TCP
                    bit 5 : Transport Layer Security Protocol over SCTP"
              SYNTAX    BITS {
                              other(0),  -- none of the following
                              udp(1),

                              tcp(2),
                              sctp(3),  -- RFC4168
                              tlsTcp(4),
                              tlsSctp(5) -- RFC 4168
              }
  --        REFERENCE "RFC 3261, Section 18"
  --        REFERENCE "RFC 4168"

Then I wonder why the REFERENCE is done with ASN.1 comments instead of using a real REFERENCE clause. The following would achive that:
      SipTransportProtocol ::= TEXTUAL-CONVENTION
              STATUS current
              DESCRIPTION
                  "This convention is a bit map.  Each bit represents a
                    transport protocol.  If a bit has value 1, then that
                    selected transport protocol is in some way dependent
                    on the context of the object using this convention.
                    If a bit has value 0, then that transport protocol
                    is not selected.  Combinations of bits can be
                    set when multiple transport protocols are selected.

                    bit 0 : a protocol other than those defined here
                    bit 1 : User Datagram Protocol
                    bit 2 : Transmission Control Protocol
                    bit 3 : Stream Control Transmission Protocol
                    bit 4 : Transport Layer Security Protocol over TCP
                    bit 5 : Transport Layer Security Protocol over SCTP"
              REFERENCE "RFC 3261, Section 18 and RFC 4168""
              SYNTAX    BITS {
                              other(0),  -- none of the following
                              udp(1),

                              tcp(2),
                              sctp(3),  -- RFC4168
                              tlsTcp(4),
                              tlsSctp(5) -- RFC 4168
              }

Similar comment for: SipOptionTagHeaders

Would be good to have a REFERENCE for the SipEntityRole and SipMethodName as well.

It is interesting to see that the DESCRIPTION clause of the MODULE-IDENTITY in the SIP-COMMON-MIB has all the details about the different roles of SIP entities, while the SIP-TC MIB module, not the specific SipEntityRole TC do NOT have such a nice/good description. I think that all that text would be much better provided in the SipEntityRole TC.

Specifically for SipMethodName I seem unable to find what values exactly this SYNTAX (i.e. ASCII? UTF-8 ?? any octet
value?) can take and why its range is (1-128).
The 128 max length causes a warning from SMI SYNTAX checkers because it can cause OIDs with ore than 128 subIDs when used as an index (which is done in for example the SIP-COMMON-MIB).
I see the RFC-Editor notes suggesting to change it to max 119 octets, but I see no base as to why that would be a reasonable limit. In the SIP-COMMON-MIB I see sipMethodName for the ??same??
methodName, and the use of SnmpAdminString for that occurrence seems to indicate it IS UTF-8 and max 32 octets !!??

(note DR - 119 is the max value that prevents the smilint complaining. Anything less than 119 would be fine for the parser. Certainly some consistency here would be useful)


----- SIP-COMMON-MIB

First some comments that are flawed (item 3 below, the badValue error code is (in my view) even fatally flawed in that it breaks the SNMPv2 protocol operations of RFC3416).In any event, I think these should be SERIOUSLY considerede for a fix/change

1. SYNTAX checking:

  C:\bwijnen\smicng\work>smicstrict
  C:\bwijnen\smicng\work>smicng SIP-COMMON-MIB.inc
  W: f(rfc2788.mi2), (562,3) OBJECT-GROUP "applGroup" is not
    used in a MODULE-COMPLIANCE in current module
  W: f(SIP-COMMON-MIB), (1026,7) Row "sipMethodStatsEntry" has
    indexing that may create variables with more than 128 sub-ids
  W: f(SIP-COMMON-MIB), (1098,7) Row "sipStatusCodesEntry" has
    indexing that may create variables with more than 128 sub-ids
  W: f(SIP-COMMON-MIB), (1206,7) Row "sipStatusCodeNotifEntry" has
    indexing that may create variables with more than 128 sub-ids
  W: f(SIP-COMMON-MIB), (1405,7) Row "sipCommonStatsRetryEntry" has
    indexing that may create variables with more than 128 sub-ids

  *** 0 errors and 5 warnings in parsing

  The first warning is from another MIB-module, so we can ignore it.

  W.r.t. the last 4 warnings, I think it would be good (as recommended
  by RFC4381 sect 4.6.6.) to add some words in teh DESCRIPTION clauses
  about OID length limitations.

2.sipServiceNotifEnable is a writable object, but I see not details
  about the expected persistenmce behaviour! I strongly recommend to
  add that.

3.sipServiceNotifEnable DESCRIPTION clause suggests to return a badValue
  error. a badValue is NOT a value to be returned by SNMPv2c/v3. It is
  only there for backward SNMPv1 compatibility. So suggesting that as
  an error value in an SMIv2 MIB module is not correct!

  Not sure I completely understand DESCRIPTION. It seems like a SIP entity can
  choose to support notifications or not. In the former case it must support
  all of them, in the latter case it would support none at all. So it seems
  one would not see an entity that supports only 2 uut of 3 or some other
  mix?

  If my interpretation/understanding is correct (in any event, it would be
  good to make it clear in the DESCRIPTION clause) I think the correct
  approach would be that the object is allowed to be supported in read-only
  mode in case the entity does NOT support any notifications. This is done
  via a MIN-ACCESS in the MODULE-COMPLIANCE.
  Another approach (which also allows a mix of supported/non-supported
  noticifcations, and so is the prefered way in my view) would be to
  return a error of "inconsistentValue".
  It cannot return badValue (see Elements of Procedure pages 19/20 of
  RFC3416). It could return inconsistentValue (step 10 on page 19/20
  of RFC3416) to achieve what you seem to want.

  So the simplest fix is to: s/badValue/inconsistentValue/
  and to clarify the DESCRIPTION clause as to what is exactly intended
  (no support for ALL notifications, or an option to support only
  a subset)

(note DR - this would be my preference as well. I would add thhe following: 'This error code is specific to SNMP, if the MIB module is used with other protocols different error codes would apply').

4.I see no mention of which discontinuity timer applies to the counters
  in sipSummaryStatsTable. Same for sipStatusCodesTable,
  sipCommonStatsRetryTable and sipOtherStatsTable.

5.I see no persistency behaviour defined for created entries in the
  sipStatusCodesTable


None of the following is blocking and none of it causes a fatal flaw.
I think they would be good editorial changes though:

- I find the use of MAY in the DESCRIPTION clause of the MODULE-IDENTITY
  not correct. I would just use lowercase "may". It is not specifying
  any compliance requirements here (or so I think/perceive).

- I personally would rename sipCommonMIBNotifs into sipCommonMIBNotifications
  Most other MIB modules use the longer "Notifications" instead of abbreviations
  so I think it helps in overall MIB-wide naming consistency.

- Simliarly I would rename sipCommonMIBConform into sipCommonMIBConformance
  as is done in most otehr MIB modules.

- it seems to me that sipServiceNotifEnable could have a DEFVAL clause as
  follows:
    DEFVAL { { sipServiceColdStart, sipServiceWarmStart } }
  At least, that is also what the DESCRIPTION clause tells me. Would
  be good to specify that in machine redable form, i.e. using a DEFVAL
  clause.

- for sipPort, the DESCRIPTION clause should indicate what a value of zero
  means. Probably a value of zero makes no sense here, and so the
  SYNTAX would probably best be specified as
        SYNTAX    InetPortNumber (1..65535)

- In terms of naming consistency, I would rename
      SipCommonCfgEntry ::=
          SEQUENCE {
                  sipProtocolVersion        SnmpAdminString,
                  sipServiceOperStatus      INTEGER,
                  sipServiceStartTime      TimeTicks,
                  sipServiceLastChange      TimeTicks,
                  sipOrganization          SnmpAdminString,
                  sipMaxTransactions        Unsigned32,
                  sipServiceNotifEnable    BITS,
                  sipEntityType            SipEntityRole
          }
  into:
      SipCommonCfgEntry ::=
          SEQUENCE {
                  sipCommonCfgProtocolVersion        SnmpAdminString,
                  sipCommonCfgServiceOperStatus      INTEGER,
                  sipCommonCfgServiceStartTime      TimeTicks,
                  sipCommonCfgServiceLastChange      TimeTicks,
                  sipCommonCfgOrganization          SnmpAdminString,
                  sipCommonCfgMaxTransactions        Unsigned32,
                  sipCommonCfgServiceNotifEnable    BITS,
                  sipCommonCfgEntityType            SipEntityRole
          }
  and I would also rename:
      SipPortEntry ::=
          SEQUENCE {
                  sipPort                InetPortNumber,
                  sipTransportRcv        SipTransportProtocol
          }
  into something like:
      SipPortEntry ::=
          SEQUENCE {
                  sipPort                InetPortNumber,
                  sipPortTransportRcv    SipTransportProtocol
          }
  maybe that while table should even have sipCommon as a prefix.

  That is, I would have all SIP-COMMON-MIB descriptors start with sipCommon
  It is easy to ensure that there are no naming conflicts today, but if
  changes/additions/extensions are made in the future, it becomes all
  so much easier if one has started with a very clear naming scheme;
  specifically with using a consistent prefix for descriptor-names
  within the same MIB module.

  So this also applies to several other tables. For example,
  I would rename sipOptionTagTable to sipCommonOptionTagTable and
  have all objects there also start with sipCommonOption prefix.

- NIT: sipOptionTagEntry
  in description clause: s/at reboot/over a reboot or restart/

- consider sipOptionTagEntry
    SHOULD be non-volatile
  So an NM application has to do a trial and error to figure ity out?
  Why could this not be made a: MUST be non-volatile
  But then checking further, I see that the whole table is read-only,
  so no need to talk about persistency of the entries.

- sipOptionTag
  I would recommend to add a REFERENCE clause to point to sect 27.1
  of RFC3261. That helps understand what the actual values can be.
  Because acording to the SYNTAX, it could contain chinese, but according
  to sect 27.1 of RFC3261 it cannot.

  I kind of like that you use SnmpAdminString (i.e. UTF-8 based), so that
  you recognize that at some time there might be non US ASCII tags?
  But the SYNTAX does not represent the actual allowed content of the
  TAG. If that content is fixed to ALPHA/DIGIT from US ASCII set, then
  maybe it would be better to define your own TC as ipposed to using
  a TC that is intened for internationalized human readable strings.

  It might also be helfull to add some text that explains what to do
  if the length of the sipOptionTag exceed the max length of
  SnmpAdminString which seems allowed (MAY text in 27.1 of RFC3216).

- sipMethodSupportedTable
  Seems to have only read-only objects/columns, so I do not see
  a need or the usefullness to talk about persistyency (non-volatile)
  in the DESCRIPTION claise of sipMethodSupportedEntry

- sipMethodSupportedTable
  Maybe it is just me. But I am confused by the use of MAY (2 times).
  It gives me the impression that you do not HAVE TO include anything.
  But I would think that one MUST include ALL METHODS that the
  represented SIP instance supports, no?

- sipMethodName
  I think I have already spoken about this better be named
  sipCommonMethodSupportedMethodName.

(Note DR - this recommendation would overwrite the one in the current RFC Editor Notes)

  But the SYNTAX is SnmpAdminString and I wonder why it would not
  be SipMethodName as from your own SIP-TC mib module.
 
- I would rename
      SipCommonCfgTimerEntry ::=
          SEQUENCE {
                  sipCfgTimerA              Unsigned32,
                  sipCfgTimerB              Unsigned32,
                  sipCfgTimerC              Unsigned32,
                  sipCfgTimerD              Unsigned32,
                  sipCfgTimerE              Unsigned32,
                  sipCfgTimerF              Unsigned32,
                  sipCfgTimerG              Unsigned32,
                  sipCfgTimerH              Unsigned32,
                  sipCfgTimerI              Unsigned32,
                  sipCfgTimerJ              Unsigned32,
                  sipCfgTimerK              Unsigned32,
                  sipCfgTimerT1              Unsigned32,
                  sipCfgTimerT2              Unsigned32,
                  sipCfgTimerT4              Unsigned32
          }
  into (for naming consistency):
      SipCommonCfgTimerEntry ::=
          SEQUENCE {
                  sipCommonCfgTimerA              Unsigned32,
                  sipCommonCfgTimerB              Unsigned32,
                  sipCommonCfgTimerC              Unsigned32,
                  sipCommonCfgTimerD              Unsigned32,
                  sipCommonCfgTimerE              Unsigned32,
                  sipCommonCfgTimerF              Unsigned32,
                  sipCommonCfgTimerG              Unsigned32,
                  sipCommonCfgTimerH              Unsigned32,
                  sipCommonCfgTimerI              Unsigned32,
                  sipCommonCfgTimerJ              Unsigned32,
                  sipCommonCfgTimerK              Unsigned32,
                  sipCommonCfgTimerT1              Unsigned32,
                  sipCommonCfgTimerT2              Unsigned32,
                  sipCommonCfgTimerT4              Unsigned32
          }

  Further, I cannot say that I find the naming of Timers with A, B, C,D etc
  verty intuitive or user friendly.

- In the sipCommonCfgTimerTable I find it strange to see DEFVALs for
  read-only objects.  Specifically strange if I see for example:
      sipCfgTimerD OBJECT-TYPE
          SYNTAX      Unsigned32 (0..300000)
          UNITS      "milliseconds"
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION
              "This object reflects the amount of time that the server
                transaction can remain in the 'Completed' state when
                unreliable transports are used. The default value MUST
                be greater than 32000 for UDP transport and its value

                MUST be 0 for TCP/SCTP transport."
          REFERENCE
                "RFC 3261, Section 17.1.1.2"
              DEFVAL { 32000 }
  where the DESCRIPTION clause suggests that the value might in fact
  be EITHER >32000 or 0. So how can there be a DEFVAL that covers both?

- I see:
      sipStatusCodeMethod OBJECT-TYPE
          SYNTAX      SipMethodName
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION
              "This object uniquely identifies a conceptual row
                in the table and reflects an assigned number used
                to identifier a specific SIP method."
  s/to identifier/to identify/ !!??

-    sipStatusCodeRowStatus OBJECT-TYPE
        SYNTAX      RowStatus
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
              "The row augmentation in sipStatusCodeNotifTable
              will be governed by the value of this RowStatus.

              This object is REQUIRED to create or delete rows
              by a manager.

              The values 'createAndGo' and 'destroy' are the
              only valid values allowed for this object.
              If a row exists, it will reflect a status of
              'active' when queried."
        ::= { sipStatusCodesEntry 5 }

  You are missing a statement that explains if writable columns
  (they would be columns in the augmenting sipStatusCodeNotifTable)
  can be changed if the value of this object is 'active'. I would
  think the answer is YES< they can be modified, and RFC2579
  in RowStatus TC DESCRIPTION clause mandates that you specify
  this in the DESCRIPTION clause of an object that uses the
  RowStatus TC as its SYNTAX.

  The 2nd para in the DESCRIPTION clause seems redundant. But is
  acceptable. I would remove it though.

  The last para seems material that needs to go into the
  MODULE-COMPLIANCE. you are basically stating that a createAndWait
  and notInService are not required. I find it strange that you
  would want to PROHIBIT support for those. If the latter, than
  you would normally do that by a SYNTAX of:
      sipStatusCodeRowStatus OBJECT-TYPE
          SYNTAX      RowStatus {
                        active(1),
                        createAndGo(4),
                        destroy(6)
                      }
  If the former (I think I would prefer the former), in which case
  you leave the SYNTAX as is, but in the MODULE-COMPLIANCE, you add
  an OBJECT clause, as follows.
  I would replace (i.e. add):
      sipCommonCompliance MODULE-COMPLIANCE

          STATUS    current
          DESCRIPTION
              "The compliance statement for SIP entities."

          MODULE -- this module
              MANDATORY-GROUPS { sipCommonConfigGroup,
                                  sipCommonStatsGroup }
  with:
      sipCommonCompliance MODULE-COMPLIANCE

          STATUS    current
          DESCRIPTION
              "The compliance statement for SIP entities."

          MODULE -- this module
              MANDATORY-GROUPS { sipCommonConfigGroup,
                                  sipCommonStatsGroup }

          OBJECT sipStatusCodeRowStatus
          SYNTAX RowStatus { active(1) }
          WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
          DESCRIPTION
            "Support for createAndWait and notInService is not required."

- I would think that the DEFVAL for sipStatusCodeNotifEmitMode would
  better be oneShot so as to minimize network load. In any event, it seems
  wierd to me that the value would be "triggered" by default (I see that
  the DESCRIPTION clause says that this is also possibly the default value).


- The way the MODULE-COMPLIANCE is defined means that IF you claim
  compliance, then for all writable objects you DO support them in
  read-write or read-create (as the case may be). As long as the
  WG and authors are aware of that and if that is what they want,
  then fine. I am assuming so, but did want to point it out during
  my review.


------ SIP-UA-MIB

I see no blocking issues or fatal flwas. However, pls consider:

- I would rename sipUAMIBConform to sipUAMIBConformance for consistency
  with many otehr MIB modules.

- I see:
      sipUACfgServerEntry OBJECT-TYPE
          SYNTAX    SipUACfgServerEntry
          MAX-ACCESS not-accessible
          STATUS    current
          DESCRIPTION
              "A row of server configuration.

                Each row represents those objects for a particular SIP
                user agent present in this system.  applIndex is used to
                uniquely identify these instances of SIP user agents and
                correlate them through the common framework of the
                NETWORK-SERVICES-MIB (RFC 2788). The same value of
                applIndex used in the corresponding SIP-COMMON-MIB is
                used here.
                The objects in this table entry SHOULD be non-volatile
                and their value SHOULD be kept at reboot."
 
  But the whole table is read-onlyu, so the last 2 lines seem useless
  and so not needed to me.

- I see:
    sipUACfgServerAddr OBJECT-TYPE
        SYNTAX    InetAddress
        MAX-ACCESS read-only
        STATUS    current
        DESCRIPTION
              "This object reflects the address of a SIP server
              this user agent will use to proxy/redirect calls."
        REFERENCE "INET-ADDRESS-MIB (RFC 4001)"
        ::= { sipUACfgServerEntry 3 }
 
  RFC4001, requires (MUST language) that every object with syntax InetAddress
  specifies WHICH object of SYNTAX InetAddressType controls the format of the
  InetAddress. It is simple. Add this text:

        The type of this address is determined by the value of the
        sipUACfgServerAddrType
        object.  Note that implementations must limit themselves

- real NIT.
  from a user-friendlyness/intuitiveness point of view, I think I would
  rename
  -  sipUACfgServerAddrType to sipUACfgServerAddressType
  -  sipUACfgServerAddr    to sipUACfgServerAddress
  -  sipUACfgServerFunction to sipUACfgServerRole.


------- SIP-SERVER-MIB

maybe in need of a fi:
1.sipNumProxyRequireFailures does not specify which (if any)
  discontinuity timer applies.
  Same for: sipUserAuthenticationFailures
  Same for counters in sipRegStatsTable

Editorial concerns (includes naming concern)

- I would rename sipServerMIBConform to sipServerMIBConformance for
  naming consistency with so many other MIB modules

- sipServerCfgEntry talks about "SHOULD be non-volatile"
  but the whole table is read-only, so I see no use/need for that text.

- In the DESCRIPTION clause of sipServerHostAddr, I see:
                  sipServerHostAddrType formalizes the type of address
                  given by this object.  It is the user's
                  responsibility to maintain consistency between this
                  object and the type specified by
                  sipServerHostAddrType."

  It does explain how the format is controlled (by value of
  sipServerHostAddrType). But it is unclear who the "user" is who is made
  responsible for consitency here. I think it is an implementation
  responsibility, since both objects are read-only.

- I would rename sipProxyCfg to sipServerProcyCfg (and all descriptors
  with same prefix too).
  I would rename sipProxyStats to sipServerProxyStats (and all
  descriptors with same prefix as well).

- sipProxyCfgEntry talks about "SHOULD be non-volatile" while the whole
  table is read-only. So that text is meaningless/not-needed.

- I personally would rename sipProxyAuthRealm to sipProxyAuthDefaultRealm
  to make the descriptor better cover the content.

More comments, to text not part of the MIB modules themselves:

- page 8 shows:

          SIP-COMMON-MIB sipCommonCfgTable might be populated as:

      +---------------+----------------------------+--------------------------------+-----+
      | applIndex | sipProtocolVersion | sipServiceOperStatus | ... |
      +---------------+----------------------------+--------------------------------+-----+
      |    1        |      "SIP/2.0"          |        up(1)                |  2  |
      | "SIP/2.0"  |    restarting(4)        |                                |    |
      +---------------+----------------------------+-------------------------------+-----+

  I suspect that it should be depicted as follows:

      +---------------+----------------------------+--------------------------------+-----+
      | applIndex | sipProtocolVersion | sipServiceOperStatus | ... |
      +---------------+----------------------------+--------------------------------+-----+
      |    1        |      "SIP/2.0"          |        up(1)                |    |
      |    2        |      "SIP/2.0"          |    restarting(4)            |    | 
      +---------------+----------------------------+-------------------------------+-----+

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The Document Shepherd for draft-ietf-sip-mib-11.txt is Dean Willis,
co-chair of the SIP Working Group. He has reviewed this document and
believes it is ready for forwarding to the iESG for publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been widely reviewed within the working group and
within the wider community, including discussion at several standards
organizations. It has also been reviewed by Dan Romascanu as the
specified MIB doctor. The document shepherd has no concerns about the
depth or breadth of the reviews that have been performed.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

The document shepherd has no concerns that the draft needs broader
review.



(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the
document, or
has concerns whether there really is a need for it. In any
event, if those issues have been discussed in the WG and the
WG has indicated that it still wishes to advance the
document,
detail those concerns here.


The document shepherd has personal concerns about whether there is
any need for a SIP MIB given ongoing evolution in the systems
management environment, but there is a reasonable consensus in the
working group and broader community to advance the document despite
these concerns.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document enjoys a strong consensus of all working group
participants known to the document shepherd who care about a MIB at all.



(1.f) Has anyone threatened an appeal or otherwise indicated
extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director.
(It
should be in a separate email because this questionnaire will
be entered into the ID Tracker.)

There are no known indications of extreme discontent.


(1.g) Has the Document Shepherd verified that the document
satisfies
all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough.

The document shepherd read through the document, executed the
current idnits against it, and worked through the checklist at http://
www.ietf.org/ID-Checklist.html and found no issues. The MIB data in
the document was verified by a third party using the usual tools.



(1.h) Has the document split its references into normative and
informative? Are there normative references to documents
that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative
references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are correctly divided, and all normative references
are to completed standards-track documents.


(1.i) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Working Group Summary
Was there anything in WG process that is worth noting?
For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Document Quality
Are there existing implementations of the protocol?
Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues?



Document Announcement Writeup for SIP MIB, draft-ietf-sip-mib

Technical Summary:

This document defines a portion of the Management Information Base (a
MIB) including a set of objects used to manage Session Initiation
Protocol (SIP) entities, including SIP User Agents, Proxies, Redirect
(aka Location) Servers, and Registrars. Note that this MIB is
restricted to management and monitoring activities. Following
extended discussion, the working group chose not to pursue device
configuration using the SIP MIB, and will rely instead on the SIP
Configuration Framework being developed in the SIPPING working group.

Working Group Summary:

The SIP Working Group developed this document over a greater than six-
year period, with the first draft appearing in March of 2000. One of
the key decisions in its development was the choice to exclude device
configuration functions from the MIB. This decision was reached after
the SIP community decided to pursue a SIP-specific configuration
model as outlined in "A Framework for Session Initiation Protocol
User Agent Profile Delivery", draft-ietf-sipping-config-
framework-08.txt. This decision significantly reduced the scope and
complexity of the SIP MIB. While not all participants in the working
group are convinced of the need for a SIP MIB, there seems to be a
very strong consensus on the technical detail of the draft and a
general agreement on its applicability.

Document Quality:

The document shepherd is aware of at least one pre-specification
implementation of the SIP MIB developed by a major equipment
provider. The SIPIT interoperability events have not included SIP MIB
testing in their events, and the coordinator of those events reports
that he stopped asking about SIP MIB implementations some years ago
because of the general lack of interest in the development community.
However, the industry is beginning to see requirements for SIP MIB
compliance appear in large-scale Requests For Information and
Requests For Proposal. The document has also received considerable
attention from related standards development organizations, including
PacketCable. Development of this specification was assisted greatly
by the support of Dan Romascanu acting as the designated "MIB
Doctor", with additional commentary received from David Harrington..
The document's "Contributors" section also cites review by Tom
Taylor, Kavitha Patchayappan, Dan Romascanu, Cullen Jennings, Orit
Levin, AC Mahendran, Mary Barnes, Rohan Mahy, Bob Penfield, Charles
Eckel and Dean Willis. Both Allison Mankin and Cullen Jennings
oversaw the development as Area Directors, with Cullen Jennings
serving as the Responsible Area Director at the time of publication
request. Dean Willis served as the WG Chair Shepherd.

State Change Notice email list have been change to sip-chairs@tools.ietf.org, klingle@cisco.com, fluffy@cisco.com, dromasca@avaya.com, jf.mule@cablelabs.com from sip-chairs@tools.ietf.org, fluffy@cisco.com, dromasca@avaya.com, jf.mule@cablelabs.com

This latest draft looks great - thank you. All I am missing now is a PROTO write up for this and I will put in on the Agenda. Dean and Keith, can you figure out which of you will be the shepherd for this one and send me a PROTO write up. If I got it on this thursday, it would go on agenda for the call on the 22nd. Given how much review this has had, this can be a pretty brief write up, but I do want to have a Shepherd for the document.

Thanks, Cullen

(I think the reason we do not have one is only due to how long we have been working on this draft :-)

This latest draft looks great - thank you. All I am missing now is a PROTO write up for this and I will put in on the Agenda. Dean and Keith, can you figure out which of you will be the shepherd for this one and send me a PROTO write up. If I got it on this thursday, it would go on agenda for the call on the 22nd. Given how much review this has had, this can be a pretty brief write up, but I do want to have a Shepherd for the document.

Thanks, Cullen

(I think the reason we do not have one is only due to how long we have been working on this draft :-)

State Change Notice email list have been change to sip-chairs@tools.ietf.org, mankin@psg.com, fluffy@cisco.com, dromasca@avaya.com from dean.willis@softarmor.com,  rohan@ekabal.com, mankin@psg.com, bwijnen@lucent.com, dromasca@avaya.com

[Note]: 'About to declare this MIB dead since the authors have not revised based on the MIB Doctor
review that they received in Jun 2005.  I gave them multiple pings, and spoke in person to
J-F Mule at IETF 63 and IETF 64.  The MIB Doctor review was very long in coming, but the SIP MIB
authors need to care and have cycles. ' added by Allison Mankin

MIB Doctor review comments posted to WG mailing list:

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Wednesday, June 01, 2005 14:48
To: sip@ietf.org
Cc: Wijnen, Bert (Bert); j.schoenwaelder@iu-bremen.de
Subject: draft-ietf-sip-mib-09.txt - 'MIB Doctor' review



Here are my review comments. I apologize for the delay, but unfortunately the document is not yet completely problems free, and it generated some discussions 'in the doctors room':

A few issues were found related to the definition of the SipMethodIdentifier TC and its usage:

1.  The way it is defined the TC encourages extensibility, and this can be regarded as a good thing. In order to do this a vendor must invent some numerical assignment, which is not yet used by the standard, and the DESCRIPTION requires that this assignment "MUST ensure no collision with officially assigned method identifier values" but says nothing about how collision can be avoided. It would be useful to split the identifiers numbers space into standard and experimental, and create a second experimental registry where vendors building an extension method and receive a number in the experimental space. This would ensure that collisions are avoided, and experimental methods are identified at a glance.
2. Another MIB Doctor asked 'why the method name has not been used as an index as this would be the natural naming scheme. Having to go through a lookup table (in case the SipMethodIdentifier has only local significance) is painful and the alternative to establish another IANA registry to number the SIP methods seems also kind of costly.'. I am not sure that a change is necessary at this stage, as nothing is broken, but as I would suggest that you provide a rationale for this design choice.
3. The TC misses a DISPLAY-HINT (probably "d"), which results into a smilint warning

Some more editorial things.

4. Since the document was published the Intellectual Property boilerplates were updated. See http://www.ietf.org/ietf/1id-guidelines.txt for the latest version
5. It is recommended that the module name of the SIP-TC module be changed to SIP-TC-MIB
6. typo - DESCRIPTION clause of SipStatusCodeNotifTable - "seperate"
7. typo - DESCRIPTION clause of SipMethodIdentifier - "extention"
8. typo - DESCRIPTION clause of sipServiceNotifEnable - "approriate"
9. type - DESCRIPTION clause of sipServiceWarmStart - "adminstrative"
10. There are 129 instances of too long lines in this documents. Please run idnits for the full list http://ietf.levkowetz.com/tools/idnits/idnits.pyht
11. Warnings of weird spacing in lines
tmp/draft-ietf-sip-mib-09.txt(4495): Line has weird spacing: '...CodeIns  rena...'
tmp/draft-ietf-sip-mib-09.txt(4496): Line has weird spacing: '...odeOuts  renam...'
tmp/draft-ietf-sip-mib-09.txt(4789): Line has weird spacing: '...odTable  in th...'
12. As Section 8 including the Log of Changes will be taken out, but there are other sections after this section it would be better to move it to an annex and renumber, making sure that proper references from the text go to the intended place.

Regards,

Dan