Subject: RE: Atommib WG Last Call on rfc2495bis and rfc2496bis

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 24 Mar 2004 15:35:36 +0100

Mike, you wrote (quite a while back):

> -----Original Message-----
> From: C. M. Heard [mailto:[email-masked]]
> Sent: donderdag 30 oktober 2003 9:15
> To: AToM MIB Working Group
> Subject: Re: Atommib WG Last Call on rfc2495bis and rfc2496bis
> 
> 
> On Sun, 26 Oct 2003, Lam, Hing-Kam (Kam) wrote:
> > This is to annouce the commencement of working group Last Call
> > on the following two I-Ds:
> > 
> > (1) DS1/E1/DS2/E2 MIB
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-atommib-rfc2495bis-05.txt
> > 

This now revision 6.

> > (2) DS3/E3 MIB
> > 
> http://www.ietf.org/internet-drafts/draft-ietf-atommib-rfc2496bis-05.txt
> > 
> > As people may be busy with the upcoming IETF58 meeting, we give
> > a longer than usual LC period of 4 weeks. The close of this WG
> > LC will [be] on November 24th, 2003.
> > 
> > The author notes that compared to draft v04 there are mainly
> > cosmetic changes and no technical changes in this version.
> 
> These new drafts address the last outstanding MIB doctor issues that
> I raised regarding the -04 drafts, so I think they are ready to go
> to the IESG.  One minor issue that has cropped up with both drafts
> is that the dates on the LAST-UPDATED clauses and the most recent
> REVISION clauses don't match (the latter were not updated from -04),
> but I think this can be handled with an RFC Editor note (or careful
> inspection during the AUTH48 period) since those dates will be
> changed by the RFC Editor anyway as part of the final editing.
> 
I see that there are these warnings from SMICng:

- RFC2495bis

   W: f(rfc2495bis.mi2), (1147,35) Row "dsx1ChanMappingEntry" does not
      have a consistent indexing scheme - index item dsx1Ds1ChannelNumber
      from base row dsx1ConfigEntry is not defined as an index item
  This seems OK, and in fact was already present in original RFC2495

   W: f(rfc2495bis.mi2), (2404,11) OBJECT-GROUP "ds1DeprecatedGroup" is
      not used in a MODULE-COMPLIANCE in current module
  Since this is a deprecated group, this seems OK to me

- RFC2496bis

   W: f(rfc2496bis.mi2), (42,24) The first revision should match the
      last update for MODULE-IDENTITY ds3
  This is what Mike mentions above

   W: f(rfc2496bis.mi2), (1722,11) OBJECT-GROUP "ds3DeprecatedGroup"
      is not used in a MODULE-COMPLIANCE in current module
  Since this is a deprecated group, this seems OK to me

   W: f(rfc2496bis.mi2), (1743,11) NOTIFICATION-GROUP
      "ds3NearEndOptionalTrapGroup" is not used in a MODULE-COMPLIANCE
      in current module
  Would it make sense to the ds3Compliance compliance statement?
  As we did for RFC2495.

I must also say that the formatting of the MIB module is FAR FROM ideal
or elegant. I know that it also exists in the RFC2495/6 already. But
here we had a change to improve. Specifical 2496bis page 53:

                      -- conformance information

                      ds3Conformance OBJECT IDENTIFIER ::= { ds3 14 }

                      ds3Groups      OBJECT IDENTIFIER ::= {
                      ds3Conformance 1 } ds3Compliances OBJECT
                      IDENTIFIER ::= { ds3Conformance 2 }

                      -- compliance statements

                      ds3Compliance MODULE-COMPLIANCE
                          STATUS  current
                          DESCRIPTION
                                  "The compliance statement for DS3/E3
                                  interfaces."
              MODULE  -- this module
                  MANDATORY-GROUPS { ds3NearEndConfigGroup,
                                     ds3NearEndStatisticsGroup }

                  GROUP       ds3FarEndGroup
                  DESCRIPTION
                      "Implementation of this group is optional for all
                      systems that attach to a DS3 Interface.  However,

I also get these NITs (RFC-Editor  can fix I guess):

bwijnen@NL000617195276 /home/ietf
$ /bin/checkpage.awk < drafts/draft-ietf-atommib-rfc2496bis-05.txt
Long page at 59
Long line at 872 with 76 chars
Long line at 880 with 73 chars
Long line at 902 with 78 chars
Long line at 920 with 78 chars
Long line at 1364 with 74 chars
Long line at 1379 with 77 chars
-: 6 lines longer than 72 characters, max 78
-: 1 pages longer than 58 lines, max 3939 lines

bwijnen@NL000617195276 /home/ietf
$ /bin/checkpage.awk < drafts/draft-ietf-atommib-rfc2495bis-06.txt
Long page at 59
Long line at 104 with 74 chars
Long line at 601 with 73 chars
Long line at 625 with 75 chars
Long line at 626 with 73 chars
Long line at 628 with 76 chars
Long line at 629 with 77 chars
Long line at 1266 with 76 chars
Long line at 1296 with 78 chars
Long line at 1314 with 78 chars
Long line at 1317 with 76 chars
Long line at 1320 with 76 chars
Long line at 1321 with 78 chars
Long line at 1323 with 78 chars
Long line at 1324 with 75 chars
Long line at 1326 with 75 chars
Long line at 1327 with 82 chars
Long line at 1343 with 79 chars
Long line at 1344 with 75 chars
Long line at 1347 with 78 chars
Long line at 1348 with 79 chars
Long line at 1355 with 78 chars
Long line at 1356 with 75 chars
Long line at 1370 with 76 chars
Long line at 1371 with 77 chars
Long line at 1372 with 77 chars
Long line at 1374 with 77 chars
Long line at 1375 with 73 chars
Long line at 1376 with 77 chars
Long line at 1378 with 76 chars
Long line at 1455 with 73 chars
Long line at 1456 with 73 chars
Long line at 1624 with 74 chars
Long line at 1626 with 75 chars
Long line at 1637 with 74 chars
Long line at 1888 with 78 chars
Long line at 1889 with 75 chars
Long line at 1892 with 76 chars
Long line at 1899 with 76 chars
Long line at 1900 with 74 chars
Long line at 1902 with 76 chars
Long line at 4560 with 77 chars
-: 41 lines longer than 72 characters, max 82
-: 1 pages longer than 58 lines, max 5647 lines

bwijnen@NL000617195276 /home/ietf
$
It all has to do with indenting everything with 10 spaces of course.
Oh well.

Further, I see this for RFC2496bis from SMIDIFF:

  ../work/DS3-MIB:13 warning: organization of `DS3-MIB' changed
  ../work/DS3-MIB:13 warning: contact of `DS3-MIB' changed
  ../work/DS3-MIB:13 warning: description of module identity
         definition `DS3-MIB' changed 
  ../work/DS3-MIB:45 warning: revision `2003-10-19 00:00' added
  ../work/DS3-MIB:42 warning: revision `2003-08-17 00:00' added
  ../work/DS3-MIB:52 warning: revision `1993-01-25 20:28' added
  ./DS3-MIB:14 info: previous definition of `DS3-MIB'

sofar so good

  ../work/DS3-MIB:175 warning: named number `dsx3M13' added to type
     used in `dsx3LineType'
  ../work/DS3-MIB:175 warning: description of object definition 
     `dsx3LineType' changed
  ../work/DS3-MIB:175 warning: reference added to `dsx3LineType'
  ./DS3-MIB:149 info: previous definition of `dsx3LineType'

seems to warrant a similar change as to what we/you did for RFC2495bis 
for dsx1LineType

  ../work/DS3-MIB:290 warning: reference added to `dsx3CircuitIdentifier'
  ../work/DS3-MIB:500 warning: description of object definition
    `dsx3Ds1ForRemoteLoop' changed
  ./DS3-MIB:453 info: previous definition of `dsx3Ds1ForRemoteLoop'
  ../work/DS3-MIB:1150 warning: description of object definition 
    `dsx3FarEndValidIntervals' changed
  ./DS3-MIB:1098 info: previous definition of `dsx3FarEndValidIntervals'

sofar so good

  ../work/DS3-MIB:1513 range of type used in `dsx3FracIfIndex'
    changed from `(1..2147483647)' to `(0..2147483647)'

This also sounds similar to what we saw in rfc2495bis, and so it probably 
should be replaced by a SYNTAX of InterfaceIndexOrZero, but you did not do 
that for 2495bis either.. so..

Anyway, I will go ahead and issue IETF Last Call for RFC2496bis.
When that finishes, we can see if we want to make some changes.

For RFC2495bis revision 6 I am OK now and have issued IETF Last Call

Bert
> Regards,
> Mike Heard

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 24 Mar 2004 15:37:45 -0800 (PST)

>>>>> On Wed, 24 Mar 2004, Wijnen, Bert (Bert) wrote:
Bert> Mike, you wrote (quite a while back):
[ ... ]
Bert> > > (2) DS3/E3 MIB
Bert> > > 
Bert> > http://www.ietf.org/internet-drafts/draft-ietf-atommib-rfc2496bis-05.txt
Bert> > > 
Bert> > > As people may be busy with the upcoming IETF58 meeting, we give
Bert> > > a longer than usual LC period of 4 weeks. The close of this WG
Bert> > > LC will [be] on November 24th, 2003.
Bert> > > 
Bert> > > The author notes that compared to draft v04 there are mainly
Bert> > > cosmetic changes and no technical changes in this version.
Bert> > 
Bert> > These new drafts address the last outstanding MIB doctor issues that
Bert> > I raised regarding the -04 drafts, so I think they are ready to go
Bert> > to the IESG.  One minor issue that has cropped up with both drafts
Bert> > is that the dates on the LAST-UPDATED clauses and the most recent
Bert> > REVISION clauses don't match (the latter were not updated from -04),
Bert> > but I think this can be handled with an RFC Editor note (or careful
Bert> > inspection during the AUTH48 period) since those dates will be
Bert> > changed by the RFC Editor anyway as part of the final editing.
Bert> > 
Bert> I see that there are these warnings from SMICng:
[ ... ]
Bert> - RFC2496bis
Bert> 
Bert>    W: f(rfc2496bis.mi2), (42,24) The first revision should match the
Bert>       last update for MODULE-IDENTITY ds3
Bert>   This is what Mike mentions above
Bert> 
Bert>    W: f(rfc2496bis.mi2), (1722,11) OBJECT-GROUP "ds3DeprecatedGroup"
Bert>       is not used in a MODULE-COMPLIANCE in current module
Bert>   Since this is a deprecated group, this seems OK to me
Bert> 
Bert>    W: f(rfc2496bis.mi2), (1743,11) NOTIFICATION-GROUP
Bert>       "ds3NearEndOptionalTrapGroup" is not used in a MODULE-COMPLIANCE
Bert>       in current module
Bert>   Would it make sense to the ds3Compliance compliance statement?
Bert>   As we did for RFC2495.

What I said on 18 May 2003 in my original MIB doctor review of the -02
version was this:

Mike> The unreferenced group warning for deprecated group `ds3DeprecatedGroup'
Mike> is likewise not a problem, since it is reasonable for a deprecated
Mike> group of deprecated objects to be unreferenced by any compliance
Mike> statement.  The unreferenced group warning for current group
Mike> `ds3NearEndOptionalTrapGroup' simply indicates that the group (as
Mike> its name indicates) is optional.  In this reviewer's opinion the
Mike> intent is sufficiently clear that there is no need to enforce the
Mike> recommendation in <draft-ietf-ops-mib-review-guidelines-01.txt>
Mike> Section 4.8 to mention this group in a GROUP clause.  (Note,
Mike> however, that when it comes time to advance the specification it
Mike> will be necessary either to provide evidence that this group is
Mike> present in two implementations or else it must be deprecated.)

One issue here that did not arise in 2495bis is that 2496bis does not
have a new conformance statement.  However, what you are requesting is
the addition of a GROUP clause to ds3Compliance along these lines:

OLD:
                  GROUP       ds3NearEndOptionalConfigGroup
                  DESCRIPTION
                      "Implementation of this group is optional for all
                      systems that attach to a DS3 interface."

NEW:
                  GROUP       ds3NearEndOptionalConfigGroup
                  DESCRIPTION
                      "Implementation of this group is optional for all
                      systems that attach to a DS3 interface."

                  GROUP       ds3NearEndOptionalTrapGroup
                  DESCRIPTION
                      "Implementation of this group is optional for all
                      systems that attach to a DS3 Interface.  If it is
                      implemented then ds3NearEndOptionalConfigGroup
                      should also be implemented."

Since this does not change the semantics of the compliance
statement, I don't mind if it is added.

[ ... ]
Bert> Further, I see this for RFC2496bis from SMIDIFF:
Bert> 
Bert>   ../work/DS3-MIB:13 warning: organization of `DS3-MIB' changed
Bert>   ../work/DS3-MIB:13 warning: contact of `DS3-MIB' changed
Bert>   ../work/DS3-MIB:13 warning: description of module identity
Bert>          definition `DS3-MIB' changed 
Bert>   ../work/DS3-MIB:45 warning: revision `2003-10-19 00:00' added
Bert>   ../work/DS3-MIB:42 warning: revision `2003-08-17 00:00' added
Bert>   ../work/DS3-MIB:52 warning: revision `1993-01-25 20:28' added
Bert>   ./DS3-MIB:14 info: previous definition of `DS3-MIB'
Bert> 
Bert> sofar so good
Bert> 
Bert>   ../work/DS3-MIB:175 warning: named number `dsx3M13' added to type
Bert>      used in `dsx3LineType'
Bert>   ../work/DS3-MIB:175 warning: description of object definition 
Bert>      `dsx3LineType' changed
Bert>   ../work/DS3-MIB:175 warning: reference added to `dsx3LineType'
Bert>   ./DS3-MIB:149 info: previous definition of `dsx3LineType'
Bert> 
Bert> seems to warrant a similar change as to what we/you did for RFC2495bis 
Bert> for dsx1LineType

I don't think it is necessary (since the MIN-ACCESS is read-only)
but it does not hurt, so no objection here.

Bert>   ../work/DS3-MIB:290 warning: reference added to `dsx3CircuitIdentifier'
Bert>   ../work/DS3-MIB:500 warning: description of object definition
Bert>     `dsx3Ds1ForRemoteLoop' changed
Bert>   ./DS3-MIB:453 info: previous definition of `dsx3Ds1ForRemoteLoop'
Bert>   ../work/DS3-MIB:1150 warning: description of object definition 
Bert>     `dsx3FarEndValidIntervals' changed
Bert>   ./DS3-MIB:1098 info: previous definition of `dsx3FarEndValidIntervals'
Bert> 
Bert> sofar so good
Bert> 
Bert>   ../work/DS3-MIB:1513 range of type used in `dsx3FracIfIndex'
Bert>     changed from `(1..2147483647)' to `(0..2147483647)'
Bert> 
Bert> This also sounds similar to what we saw in rfc2495bis, and so it probably 
Bert> should be replaced by a SYNTAX of InterfaceIndexOrZero, but you did not
Bert> do that for 2495bis either.. so..
Bert> 
Bert> Anyway, I will go ahead and issue IETF Last Call for RFC2496bis.
Bert> When that finishes, we can see if we want to make some changes.

I guess Orly has already agreed to make the requested changes (plus
others that were made to 2495bis, such as including the list of
changes in the MODULE-IDENTITY REVISION DESCRIPTION), and that
sounds just fine to me.

Thanks,

Mike