Subject: Re: [MIB-DOCTORS] Dan Romascanu's Discuss on draft-ietf-mpls-fastreroute-mib-19: (with DISCUSS)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 16 Jun 2011 14:06:59 +0200

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Thursday, June 16, 2011 6:37 AM
> To: Romascanu, Dan (Dan); 'The IESG'
> Cc: [email-masked]
> Subject: RE: Dan Romascanu's Discuss on draft-ietf-mpls-fastreroute-
> mib-19: (with DISCUSS)
> 
> I'm sorry, I should have responded to this sooner...
> 
> > 1. The latest change in the MIB module fixed the pre-allocation
> problem but
> > introduced another one. The LAST-UPDATED and REVISION clauses
> remained
> > unchanged at the level of the 2009 version. Now there are two sets of
> MIB
> > modules with the same dates in these clauses but different contents.
> This is not
> > acceptable. Please issue a new version with these clauses updated.
> 
> Dan, you're wrong.
> 
> The last-updated and revision clauses in Internet-Drafts have no
> meaning as the MIB modules in I-Ds are not to be implemented. There was
> no 2009 version and no previous MIB module exists.
> 
> I have lost count of the number of times MIB Doctors and ADs have
> beaten me up over this in MIB modules I have written, but it was often
> enough that I got the message.
> 
> Quite how these fields get set in the published RFC defeats me, but I
> suspect the RFC Editor should set them to match publication.
> 
> Cheers,
> Adrian
> 

[[DR]] Adrian,

Do you happen to have at hand an example of such a beating in the past?

I agree that the final published version is to be set by the RFC Editor IF they perform any changes during the editing process. However, intermediate versions need to be discriminated as well IMO, and the argument that 'MIB modules in I-Ds are not to be implemented' is a good advice which is not always followed. 

MIB Doctors - can you help here with your advice?

Thanks and Regards,

Dan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Jun 2011 14:24:13 +0200

> MIB Doctors - can you help here with your advice?

I am not sure what the debate is really about but RFC 4181 says among
other things:

   Note that after RFC publication, a REVISION clause is present only
   for published versions of a MIB module and not for interim versions
   that existed only as Internet-Drafts.  Thus, a draft version of a MIB
   module MUST contain just one new REVISION clause that covers all
   changes since the last published version (if any).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 16 Jun 2011 14:46:48 +0200

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-
> university.de]
> Sent: Thursday, June 16, 2011 3:24 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MIB-DOCTORS] Dan Romascanu's Discuss on draft-ietf-mpls-
> fastreroute-mib-19: (with DISCUSS)
> 
> > > meaning as the MIB modules in I-Ds are not to be implemented.
There
> was
> > > Quite how these fields get set in the published RFC defeats me,
but
> I
> > I agree that the final published version is to be set by the RFC
> Editor IF they perform any changes during the editing process.
However,
> intermediate versions need to be discriminated as well IMO, and the
> argument that 'MIB modules in I-Ds are not to be implemented' is a
good
> advice which is not always followed.
> >

The debate is about the LAST-UPDATE and REVISION clauses remaining
unchanged in the MIB modules included in revisions 18 and 19 of
https://datatracker.ietf.org/doc/draft-ietf-mpls-fastreroute-mib/
despite the MIB modules having changed. 

Actually now I see that version 20 was issued and it fixed the issue, so
I am clearing my DISCUSS.

Regards,

Dan

---

From: "Joan Cucchiara" <[email-masked]>
Date: Thu, 16 Jun 2011 09:25:52 -0400

Dan, Juergen and Adrian,

As I recall the RFC Editor sometimes asks the authors to add the REVISION 
clause
just prior to publishing as an RFC (as part of a final RFC editing).

 As a MIB Doctor, if it the REVISION clause is there during
the draft revisions, I don't ask that it be removed, but do check to see 
that it is
updated appropriately for each revision along with the LAST-UPDATED clause.
(Hopefully, this is a gentle request and not a beating!)

Perhaps, I am incorrect as a MIB Dr to allow the REVISIONS clause to remain 
in during
the draft revision process, but find that the authors see this as 
conflicting
requirements, (remove it, then adding it back during RFC editing).   Mostly, 
I think  that
the REVISIONS clause has made it into someone's template so it exists more 
and more, often
from the beginning.

At any rate, I do see that this happens, i.e.  both of the clauses 
(LAST-UPDATED and REVISIONS) are not
updated from one draft revision to the next (particularly before the draft 
comes under MIB Dr. review) ,
which I agree is a problem (and not sure how to solve).   However,  most 
developers that decide to
implement a draft add in the title of the draft in a MIB Comment, so they do 
document which
specific version of a draft they are implementing.

Thanks,
  -Joan

----- Original Message ----- 
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, June 16, 2011 8:24 AM
Subject: Re: [MIB-DOCTORS] Dan Romascanu's Discuss on 
draft-ietf-mpls-fastreroute-mib-19: (with DISCUSS)

>> I agree that the final published version is to be set by the RFC Editor 
>> IF they perform any changes during the editing process. However, 
>> argument that 'MIB modules in I-Ds are not to be implemented' is a good 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Jun 2011 15:33:34 +0200

On Thu, Jun 16, 2011 at 09:25:52AM -0400, Joan Cucchiara wrote:
 
> Perhaps, I am incorrect as a MIB Dr to allow the REVISIONS clause to
> remain in during
> requirements, (remove it, then adding it back during RFC editing).
> Mostly, I think  that
> the REVISIONS clause has made it into someone's template so it
> exists more and more, often
> from the beginning.

RFC 4181:

   While a MIB module is under development, the RFC number in which it
   will eventually be published is usually unknown and must be filled in
   by the RFC Editor prior to publication.  An appropriate form for the
   REVISION clause applying to a version under development would be
   something along the following lines:

          REVISION    "200212132358Z"  -- December 13, 2002
          DESCRIPTION "Initial version, published as RFC yyyy."
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note
 
> updated from one draft revision to the next (particularly before the
> draft comes under MIB Dr. review) ,
> which I agree is a problem (and not sure how to solve).   However,
> most developers that decide to
> implement a draft add in the title of the draft in a MIB Comment, so
> they do document which

I-D implementation is fine and welcome, shipping I-D implementations
in production code is not so welcome. Note that MIB modules in I-Ds
usually do not have assigned OIDs so a vendor has to root the module
in his private OID space and hence there is not really a problem
(especially if the vendor ACME at the same time renames FOO-MIB to
ACME-FOO-MIB).

That said, it is good practice to check during MIB review that the
dates are reasonable and consistent.

/js

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 16 Jun 2011 11:11:28 -0700

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, June 16, 2011 5:06 AM
> Subject: Re: [MIB-DOCTORS] Dan Romascanu's Discuss ondraft-ietf-mpls-fastreroute-mib-19: (with DISCUSS)

...
> intermediate versions need to be discriminated as well IMO, and
> the argument that 'MIB modules in I-Ds are not to be implemented'
> is a good advice which is not always followed. 

In my opinion, MIB modules in I-Ds SHOULD be implemented (though
of course not distributed or incorporated in anything to be shipped!)
because that's an important part of the process of learning whether
modules function as they should.

The argument that it doesn't matter because the OID hasn't been
assigned isn't totally correct - consider  I-Ds containing updates
to a module which has previously been published.

The argument that other methods might be sufficient, such as
mentioning the I-D version in a comment, doesn't take into account
that automated tools for building instrumentation or manager code
rely on the machine-parseable information, i.e., the LAST-UPDATED
clause, to discriminate multiple versions and as part of a configuration
management audit trail.

So while I wouldn't get too uptight about updating REVISIONs during
the I-D editing process (as long as the final one before publication is
correct), I do think some care should be taken with respect to the
LAST-UPDATED clause, even between I-D versions, whevener the
MIB module has been modified.  (Even if on occasion I've failed to update
it myself.  :-)

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Jun 2011 11:39:29 -0700

On 06/16/2011 11:11 AM, Randy Presuhn wrote:
> Hi -
>
>> From: "Romascanu, Dan (Dan)"<[email-masked]>
>> To:<[email-masked]>
>> Cc:<[email-masked]>

Companies serious enough to implement a new MIB module deserve
some help.  There are two parts of their effort:
   1) how to interpret the spec and implement it
   2) how to make it useful to customers

It might be necessary to release an I-D implementation to some customers
to determine the operational value of the MIB module.

IMO, with every new I-D, the MIB module should match the I-D date.
It really isn't that hard to change the revision date string.

Andy