Subject: [Hubmib] AD review of draft-ietf-hubmib-mau-mib-v3-02.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 17 Nov 2002 05:23:12 +0100

Sorry that it took so long

- Sect 3.1 claims/states that rfc2668 will go to historic.
  Well, you can recommend that in this document, but the WG cannot
  just declare it. Maybe it is best to wriet a small doc that
  recommends this action, similar to the way it was done for
    draft-ietf-hubmib-1643-to-historic-01.txt
  And maybe at the same time you can ask to make 2239 Historic
  (instead of claiming so in sect 3.2) And are you also trying
  to get 1515 to historic per sect 3.3?
- MODULE-IDENTITY latest (time wise) revision clause says
  that updates were done for 10G support. I think that that
  is indeed correect, but it would be probably good to add
  that you also therefor added 64 bit counters, 
  And how about the new enumerations as listed under (6) in sect 
  A.1.?

- When I see things like:
          dot3MauType10Base5 OBJECT-IDENTITY
           STATUS      current
           DESCRIPTION "thick coax MAU (per 802.3 section 8)"
           ::= { dot3MauType 2 }
  then I thing that (per 802.3 section) is probably better captured
  in some sort of REFERENCE clause, no?
  You have a few more of those
- in DESCRIPTION for  rpMauJabberingStateEnters I read
      Discontinuities in the value of this counter can
      occur at re-initialization of the management
      system, and at other times as indicated by the
      value of rptrMonitorPortLastChange."
  So I wonder if I should not see that under teh MODULE-COMPLIANCE

- in DESCRIPTION clause of ifMauMediaAvailableStateExits I read:
                     Discontinuities in the value of this counter can
                     occur at re-initialization of the management
                     system, and at other times as indicated by the
                     value of ifCounterDiscontinuityTime."
  So I wonder if I should not see that under teh MODULE-COMPLIANCE

- I wonder if it would not be wise to change
      ifMauType OBJECT-TYPE
          SYNTAX      OBJECT IDENTIFIER
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "This object identifies the MAU type.  An
                      initial set of MAU types are defined above.  The
                      assignment of OBJECT IDENTIFIERs to new types of
  into
      ifMauType OBJECT-TYPE
          SYNTAX      AutonomousType
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "This object identifies the MAU type.  An
                      initial set of MAU types are defined above.  The
                      assignment of OBJECT-IDENTITIES to new types of
  I think it is cleaner and I think it is a change that is allowed,
  the underlying datatype is still OBJECT IDENTIFIER

- Smae question for ifMauDefaultType

Nits and administrative comments

- The RFC-Editor does no longer accept more than 5 authors/editors
  on front page, see: http://www.rfc-editor.org/policy.html
  I know I suggested the current format a year or so ago.
  But RFC-Editor is changing the rules. Probably it is best to
  keep John as Editor on front page and move the other names
  in the acknowledgement section or in a contributors section
  (this ection is talked about in the rfc-editor policy)
- In the abstract, it is sufficient to list just the RFC that is
  being obsoleted, no need to have the title too.
- you skip from sect 3.3. to sect 3.5 
  is 3.4 missing, or did the counter just bump?
- I see read-only access for various INDEX objects. I think we inherited
  this from old SMIv1 MIB modules. WOuld it be good to add a comment line
  that says something aka
    MAX-ACCESS read-only   -- read-only since originally an SMIv1 index
  that makes it clear to everyone, and then mib reviewers do not have to
  re-check all the time
- would it not be better to move the comments just before ifMauAutoNegTable
  into the DESCRIPTION clause of the table itself?
- You have a number of objects and compliances that are deprecated.
  It would be good to add a sentence (or two) to explain why.
  Oops, I see that is stated at the end of the DESCRIPTION clause.
  Mmm.. maybe would have been better at the beginning.
- You may want to add in DESCRIPTION clause of broadMauBasicTable why the
  table was deprecated

OK, I am still waiting for output from a smidiff run to check if indeed
all changes are legal. So based on that output I may have some more.

Thanks,
Bert 
_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 17 Nov 2002 20:07:28 +0200

>   just declare it. Maybe it is best to write a small doc that

Cannot we avoid the need to issue two Internet-Drafts each time when we release a document that obsoletes a previous RFC to the point of making it Historical? Something like a clause like 'Impact on other Standard Tracks Documents' in the Internet-Draft?  The IESG could debate both actions by the time they approve the new RFC.

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 17 Nov 2002 20:07:28 +0200

Dan

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 17 Nov 2002 19:24:56 +0100

This is what we (IESG) normally require for moving a doc to
Historic. I will bring this up in IESG and get back to you.

Thanks,
Bert 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: zondag 17 november 2002 19:07
> To: Wijnen, Bert (Bert); John Flick (E-mail)
> Cc: Hubmib Mailing List (E-mail)
> Subject: RE: [Hubmib] AD review of draft-ietf-hubmib-mau-mib-v3-02.txt
> 
> 
> > 
> Cannot we avoid the need to issue two Internet-Drafts each 
> time when we release a document that obsoletes a previous RFC 
> to the point of making it Historical? Something like a clause 
> like 'Impact on other Standard Tracks Documents' in the 
> Internet-Draft?  The IESG could debate both actions by the 
> time they approve the new RFC.
> 
> Dan
> 
> > 
>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 17 Nov 2002 19:24:56 +0100

Thanks,
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 17 Nov 2002 21:30:58 +0100

OK, what I got back when talking to IESG (Specifically 
Scott, since he is our process guru) is that in fact
Obsoleted and Historic are equivalent.

When a document obsoletes and earlier one, then that is 
effectively the same as making old one historic. The doc
normally just keeps the tag obsoleted.

When an old doc needs to be obsoleted, but we have no new 
document that actually replaces (obsoletes) such a doc, 
then we typically write a informational RFC in which we 
document and recommend why to make the old document historic.

So it seems that we do not need to make 2668 and such Historic.
What would be our motivation to do so?

Thanks,
Bert