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

"Joan Cucchiara" <jcucchiara@mindspring.com> Thu, 16 June 2011 13:25 UTC

Return-Path: <jcucchiara@mindspring.com>
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37ED11E80DE for <mib-doctors@ietfa.amsl.com>; Thu, 16 Jun 2011 06:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueOt08N70fRD for <mib-doctors@ietfa.amsl.com>; Thu, 16 Jun 2011 06:25:57 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 91CC511E8071 for <mib-doctors@ietf.org>; Thu, 16 Jun 2011 06:25:57 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=MFUOyHeXSwZdwr8IN8Pbcj6PoNerS335yYhwZwgUKZtS/ISVdKkKryg9LGeDRsdD; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [24.41.31.146] (helo=JoanPC) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jcucchiara@mindspring.com>) id 1QXCa2-0007Ey-MV; Thu, 16 Jun 2011 09:25:54 -0400
Message-ID: <003701cc2c28$eabcd6a0$6501a8c0@JoanPC>
From: Joan Cucchiara <jcucchiara@mindspring.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "Romascanu, Dan (Dan)" <dromasca@avaya.com>
References: <20110613154515.9789.80386.idtracker@ietfa.amsl.com><142d01cc2bd6$abfa3900$03eeab00$@olddog.co.uk><EDC652A26FB23C4EB6384A4584434A04033FD7C8@307622ANEX5.global.avaya.com> <20110616122413.GB40130@elstar.local>
Date: Thu, 16 Jun 2011 09:25:52 -0400
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26541597f0f385695824e13a2bdbc7fcb3ce396bf6a0aafa7dc0350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.41.31.146
Cc: adrian@olddog.co.uk, mib-doctors@ietf.org
Subject: Re: [MIB-DOCTORS] Dan Romascanu's Discuss on draft-ietf-mpls-fastreroute-mib-19: (with DISCUSS)
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mib-doctors>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jun 2011 13:25:58 -0000

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" <j.schoenwaelder@jacobs-university.de>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Cc: <adrian@olddog.co.uk>; <mib-doctors@ietf.org>
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)


> On Thu, Jun 16, 2011 at 02:06:59PM +0200, Romascanu, Dan (Dan) wrote:
>>
>>
>>
>> > -----Original Message-----
>> > From: Adrian Farrel [mailto:adrian@olddog.co.uk]
>> > Sent: Thursday, June 16, 2011 6:37 AM
>> > To: Romascanu, Dan (Dan); 'The IESG'
>> > Cc: mpls-chairs@tools.ietf.org
>> > 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?
>
> 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/>
> _______________________________________________
> MIB-DOCTORS mailing list
> MIB-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/mib-doctors