RE: Updating the MIB Review guidelines - my comments part 2

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Inline

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: woensdag 9 juni 2004 07:10
> To: Mreview (E-mail)
> Subject: Re: Updating the MIB Review guidelines - my comments part 2
> 
> 
> On Tue, 8 Jun 2004, Wijnen, Bert (Bert) wrote:
> > Here are my comments about the remainder of the doc. Just a few :-)
> > - probably better to reference rfc3291bis instead of 3291.
> >   Juergen is fixing a last issue and then it goes to RFC-Ed queue
> >   (i.e. it has been approved by IESG modulo a fix for the last issue)
> > - 3191bis has a few extra TCs that we probably want to list in appex B
> >   (and I should add them to www.ops.ietf.org web pages
> 
> I saw the announcement for the -05 draft of 3291bis earlier today. I
> had figured to cover this with a note to the RFC Editor to update
> the reference to RFC 3291, but since there are new TCs to add to
> Appendix B I will do as you (and Dan) request.
> 
> > - We may want to add the TCs from RFC3705 to app B. and to 
> >   the web page of course.
> 
> OK, I'll do that.
> 
Good

> While I am at it, I recall that I made a deal with Juergen some time
> ago to include PhysicalIndex and PhysicalIndexOrZero from
> <draft-ietf-entmib-v3-04.txt> _provided_ that the latter made it to
> the publication queue.  I see from the I-D tracker that it is still
> in the AD Evaluation state.  How close do you think it is to
> being approved?
> 
I hope I can make that to IETF Last Call before I go on vacation, so
it would then enter the queues faster/earlier than the review guidelines.

> > That's it. Thanks for your work on this Mike!
> 
> And thanks to you for putting up with my stubborness.
> 
It is OK to defend the things you have strong opinions on.
As long as we do not deadlock after having talked/discussed.
And that seems not to be happening, so I am happy

> Now, as regards the last few loose ends:
> 
.. snip ..

> On Tue, 8 Jun 2004, C. M. Heard wrote:
> > On Tue, 8 Jun 2004, Wijnen, Bert (Bert) wrote:
> > > So we should not make ourselves dependent on 2223bis. Or so is
> > > my personal (actaully pretty strong) opinion.
> >
> > I suppose that we could try to cut the tie with 2223bis [ ... ]
> 
> I have already agreed to remove most of the citations of 2223bis, but
> the ones in Section 3, Section 3.5, and Appendix A are difficult to
> remove without a fair amount of rewriting.  What I would like to do is
> issue an updated draft with all the other agreed-upon changes and
> then revisit this issue if necessary after we have some "running
> code" experience with the new set of changes.
> 

COuld we phrase it so that 2223bis becomes informational ref, 
i.e. something aka

OLD:
  In general, IETF standards-track specifications containing MIB
   modules MUST conform to the requirements for IETF standards-track
   RFCs documented in [RFC2223bis].  Because the version under review
   will be an Internet-Draft, the notices on the front page will comply
   with the requirements of http://www.ietf.org/ietf/1id-guidelines.txt
   and not with those of [RFC2223bis].  The rest of the requirements in
   [RFC2223bis], however, do apply (see http://www.ietf.org/ID-
   Checklist.html for additional details).

   Section 4 of [RFC2223bis] lists the sections that may exist in an
   RFC.  The "body of memo" part of an RFC in general contains multiple
   sections, and in a MIB document MUST contain at least the following:

NEW:
   In general, IETF standards-track specifications containing MIB
   modules MUST conform to the requirements for IETF standards-track
   RFCs documented in [RFC2223] or its follow on, currently work is
   being done as per [RFC2223bis].  Because the version under review
   will be an Internet-Draft, the notices on the front page will comply
   with the requirements of http://www.ietf.org/ietf/1id-guidelines.txt
   and not with those of [RFC2223].  The rest of the requirements in
   [RFC2223] or its follow on, however, do apply 
   (see http://www.ietf.org/ID-Checklist.html for additional details).

   Section 4 of [RFC2223] lists the sections that may exist in an
   RFC.  The "body of memo" part of an RFC in general contains multiple
   sections, and in a MIB document MUST contain at least the following:

That way, RFC2223 becomes the normative ref and we already point (informatively)
to the follow on work and we would not get dependent on the 2223bis version.
I would think/hope that the changes you need to maek for that are not
too big. Just thinking aloud here.

Bert
> Mike
> 
>