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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 29 Dec 2002 14:09:26 +0100

Inline

Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:[email-masked]]
> Sent: zaterdag 28 december 2002 20:42
> To: Wijnen, Bert (Bert)
> Cc: Kam Lam (E-mail); [email-masked]; [email-masked];
> Thomas Narten (E-mail); Erik Nordmark (E-mail); Atommib (E-mail)
> Subject: Re: FW: submitting draft-ietf-atommib-opticalmib-07.txt to IESG
> 
> 
> On Sat, 28 Dec 2002, Wijnen, Bert (Bert) wrote:
> 
> > 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.
> 
> Yes, indeed, I went over the document very thoroughly.
> 
.. snip ..

> > - MIB security statement to be added to DESCRIPTION of MODULE-IDNETITY
> >   ( but RFC-Editor has instruction how to do it) 
> 
> You mean the copyright notice, I think:

yes I did. You can see I was working on two topics... (seems I am not
good at it).

> 
>     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
> 
That would be good to add indeed

> 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.
> 
Yep

> > - 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 ??
> 
> 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.

Well, for all I can tell, the above TC just represents a boolean value 
(true/false), no? So in that sense it is exactly the same as TruthValue.

What I further see, is that every time it is used, it repeats the
DESCRIPTION clause, see:
  optIfOTSnTIMActEnabled OBJECT-TYPE
    SYNTAX  OptIfTIMActEnabled
    MAX-ACCESS  read-write
    STATUS  current
    DESCRIPTION
    "Indicates whether the Trace Identifier Mismatch (TIM)
     Consequent Action function is enabled. This object 
     ...

  optIfOTUkTIMActEnabled OBJECT-TYPE
    SYNTAX  OptIfTIMActEnabled
    MAX-ACCESS  read-write
    STATUS  current
    DESCRIPTION
    "Indicates whether the Trace Identifier Mismatch (TIM)
     Consequent Action function is enabled.
     ...

and so on. Sometimes there is additional text, sometimes there is not.
So, as far as I can tell, if you repeat that DESCRIPTION text from the TC
in every occurance anyway, then why would it be wrong to use TruthValue?

Maybe I just don't see it yet.

>                                            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.

So I meant that you would use the TruthValue TC directly in the 
OBJECT-TYPE definitions. Is that not what you were thinking of?

> Kam and co-authors, what do you say about this?
> 
I do not want to make too big an issue of this. 
It just seemed to me that we could be re-using an existing TC (that
is already at full STD level).

> > - while we are trying to agree on the new Security Guidelines for
> >   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.
> 
Yep. Even though the debate is not over, I will probably accept the
current thinking of the new security guidelines, where as I can no
longer accept the old one with the old references.

> 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.
> 
What I am discussing with IANA and with a few other IESG members (who
worry about this), is to see if all we ask IANA to do is to assign
just one new branch in an existing OID tree, that doing something like

    ::={ transmission xxx } -- to be assigned by IANA
    -- RFC Ed.: replace xxx with IANA-assigned number & remove this notice

would be sufficient and that we do not need an IANA COnsiderations Section.
(In fact the RFC Ed comment line may not even be needed, but is nice).

I believe IANA is OK with that... but I want to get consensus between them
and IESG before we go ahead and declare this the valid way to do things.
Up till now, IANA has mostly been happy with the above approach.
So for now, I am happy with what is in the rev 7 draft in terms of IANA
stuff.

> > I know that Kam can do a quick respin if needed. 
> > 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.
> 
Great, thanks.

I beleive Kam will be back Jan 2nd, could be Jan 6th though.

Bert
> Regards,
> Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 29 Dec 2002 11:35:25 -0800 (PST)

> (true/false), no? So in that sense it is exactly the same as TruthValue.

Sorry for not making myself clear.  What appeared in the version of the
MIB module that I got for MIB Doctor review was

          SYNTAX  TruthValue

Unfortunately this won't compile, because the SMI does not allow a new
TC to be defined in terms of a previous one.  And there were several
TCs with this problem.  My recommendation was to copy the SYNTAX clause
from the base types to get around this SMI limitation.

> in every occurance anyway, then why would it be wrong to use TruthValue?

OK, I see your point ... the TC does not add any real value because the
object DESCRIPTION clauses already spell everything out, and this would
still be true even if the TC itself could have had SYNTAX TruthValue.

> OBJECT-TYPE definitions. Is that not what you were thinking of?

Looking back in the proceedings for IETF-51 I see that it was done
in precisely that way in draft-ietf-atommib-opticalmib-01.txt.  The
OptIfTIMActEnabled TC was added later.

> is already at full STD level).

OK, I'm convinced.

Mike