Subject: FW: submitting draft-ietf-atommib-opticalmib-07.txt to IESG

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 28 Dec 2002 15:24:01 +0100

Mike, I believe you did the MIB doctor review quite a while ago 
and as a result we got this (final) version from Kam Lam and the 
WG, right? So for now I only did a very quick scan of the document.

I did the SMICng strict compile check, and all seems fine from the pov.
Also smilint is happy with it (only warnings about descriptors longer
than 32 chars, but that is OK).

Of course... since we live in such a dynamic world, we have:

- MIB boilerplate is now out of date because of new SNMPv3 RFCs
  (I thinkw e could do it with an RFC-Editor note if needed)
- some other SNMP references may need updating
  (would beed to check detail)
- MIB security statement to be added to DESCRIPTION of MODULE-IDNETITY
  ( but RFC-Editor has instruction how to do it) 
- I wonder why we see in this MIB module:
   OptIfTIMActEnabled ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION
      "Indicates whether the Trace Identifier Mismatch (TIM)
       Consequent Action function is enabled."
    SYNTAX  INTEGER {
      true(1),
      false(2)
      }
   Why can that not just be a TruthValue from RFC2579 ??

- while we are trying to agree on the new Security Guidelines for
  MIB documents, we may want to update this one too.

I know that Kam can do a quick respin if needed. 
Maybe that is the best and fastest way to go.

Thanks,
Bert 
-----Original Message-----
From: Faye Ly [mailto:[email-masked]]
Sent: vrijdag 27 december 2002 19:45
To: [email-masked]; [email-masked]; [email-masked]
Cc: Atommib (E-mail)
Subject: submitting draft-ietf-atommib-opticalmib-07.txt to IESG

Hi,
 
The working group chair of the AToMMIB working group would like to submit the following document:
 
Draft-ietf-atommib-opticalmib-07.txt
 
To iesg for considering to be a RFC.  The draft-ietf-atommib-opticalmib-07.txt has passed the working group last call.
 
Thank you.
 
-faye

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 28 Dec 2002 11:42:13 -0800 (PST)

> WG, right? So for now I only did a very quick scan of the document.

Yes, indeed, I went over the document very thoroughly.

> than 32 chars, but that is OK).

Right, that's what I got too.

>   (I thinkw e could do it with an RFC-Editor note if needed)

It's probably safer just to submit a new version.

>   (would beed to check detail)

Yes, RFC 3410 (aka 2570bis) needs to replace RFC 2570 as an informative
reference, RFC 3418 needs to replace RFC 1907 as a normative reference,
and RFCs 2570-2575, 1901, 1905, 1906, 1155, 1157, 1212, 1215 can be
removed outright.  (Not related to boilerplate, but while we are talking
about references, [SENSOR-MIB] should be updated to point to RFC 3433
and the note should be removed, as this MIB module has now been published.)

>   ( but RFC-Editor has instruction how to do it) 

You mean the copyright notice, I think:

    DESCRIPTION
       "The MIB module to describe pre-OTN and OTN interfaces.

        Copyright (C) The Internet Society (2002).  This version
        of this MIB module is part of RFC yyyy;  see the RFC
        itself for full legal notices."
-- RFC Ed.: replace yyyy with actual RFC number & remove this notice

The date might have to be 2003, of course, depending on when it's
submitted;  the RFC Editor will fix it as needed upon publication.

>    Why can that not just be a TruthValue from RFC2579 ??

This a more specialized version of TruthValue, intended for the specific
purpose noted in its DESCRIPTION clause.  What Kam really wanted to do
was to have SYNTAX TruthValue;  if he had been able ot do so then this
definition would probably not be questioned.  Unfortunately the SMI does
not allow a TC to refine a TC.  So he did the next best thing.  My
opinion is that this should stay.  I don't think a MIB designer should
be penalized for what most of us now agree is a shortcoming in the SMI.
Kam and co-authors, what do you say about this?

>   MIB documents, we may want to update this one too.

Agreed.  I don't think this debate is over, but I can give Kam a copy
of the latest wisdom that has appeared on the [email-masked] list
if he has not subscribed.

One other thing that you have not mentioned is whether this document
will need to have an IANA considerations section on account of the
need to assign it an OID under the transmission subtree.  Currently
http://www.ietf.org/ID-nits.html says that this is required, but you
have under advisement a message from me regarding the implementation
of this policy objecting to stuff like "IANA is requested to assign ..."
appearing in RFCs _after_ the assignment has been made.  If this issue
is going to take some time to get resolved, would it be possible to
"grandfather" this draft and exempt it from this requirement?  The
requirement is new, after all, and was not applied until recently ...
see, e.g., draft-ietf-entmib-sensor-mib-02.txt which appeared in
mid-October and was published this month as RFC 3433.

> Maybe that is the best and fastest way to go.

As much as I hate to make Kam jump through yet another hoop, I agree
that it's probably the fastest way to get the document published.
Naturally, I'll be happy to scrutinize the changes.

Regards,

Mike