Cable Device Management Information Base for Data-Over-Cable Service Interface Specification (DOCSIS) Compliant Cable Modems and Cable Modem Termination Systems
draft-ietf-ipcdn-device-mibv2-11

[Ballot comment]
Cablelabs really uses the 1983 Time Server protocol (Historic)?: 
"The Internet address of the RFC 868 Time server as provided by DHCP option 4"

[Ballot comment]
The Abstract says:
  >
  > This memo is a revision of the standards track RFC 2669.  Please see
  > "Revision Descriptions" below for a description of changes.  This
  > document obsoletes RFC 2669.
  >
  Thanks for including the fact that this is a revision of RFC 2669 in
  the Abstract.  However, I think the pointer to a specific section
  should apper in the Introduction, not the Abstract.

  Please delete the last paragraph of the Abstract prior to publication.

[Ballot comment]
The Abstract says:
  >
  > This memo is a revision of the standards track RFC 2669.  Please see
  > "Revision Descriptions" below for a description of changes.  This
  > document obsoletes RFC 2669.
  >
  Thanks for including the fact that this is a revision of RFC 2669 on
  the Abstracts.  However, I think the pointer to a specific section
  should apper in the Introduction, not the Abstract.

  Please delete the last paragraph of the Abstract prior to publication.

Pinging WG chairs to see where we are with responding to IETF Last Call Comments. Supposedly such would have been done by mid Jan or so.

IANA Comments:
We understand this document to use a value that has been previously assigned: docsDevMIB { mib-2 69 }.  We understand there are no IANA Actions for this document.

For the record:

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Wednesday, December 28, 2005 16:02
To: Jean-Francois Mule; Richard Woundy @ Comcast
Subject: RE: [ipcdn] Last Call: 'Cable Device Management Information
Base forData-Over-Cable Service Interface Specification
CompliantCableModem s and Cable Modem Termination Systems' to
ProposedStandard


I guess it is best if I wait till at least the end of the 1st week
in January to see what the reaction is.

Bert

> -----Original Message-----
> From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]
> Sent: Wednesday, December 21, 2005 21:50
> To: Richard Woundy @ Comcast; Brian Hedstrom
> Cc: Ipcdn (E-mail); Wijnen, Bert (Bert)
> Subject: RE: [ipcdn] Last Call: 'Cable Device Management Information
> Base forData-Over-Cable Service Interface Specification
> CompliantCableModem s and Cable Modem Termination Systems' to
> ProposedStandard
>
>
> Rich, Brian and all,
>
>    Given where we are in the process and given the existing
> restrictions
> in RFC2669, my first reaction would be to do a real check
> with operators
> and implementers by asking:
> a) CM operators about their actual use of the syslog server DHCP
> option in field deployments (multi-value or single?).
> b) CM vendors about how their implementations deal with
> multi-values in the mentioned DHCP options.
>
>    Given that syslog is UDP-based, what would it mean to have multiple
> server values? It can't reliably be used for fail-over scenarios so
> should mean broadcast syslog. I personally think that this
> would best be
> done by using a management station that could act like a trap exploder
> and broadcast or multicast the syslog msg to multiple servers.
>
> Comments and feedback from the list is appreciated.
> Jean-Francois
>

Proto-writeup (for the record):

-----Original Message-----
From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]
Sent: Friday, December 09, 2005 17:41
To: Wijnen, Bert (Bert); iesg-secretary@ietf.org
Cc: Richard Woundy @ Comcast; kevin.marez@motorola.com; ipcdn@ietf.org
Subject: [ipcdn] Request for publication and proto write-up for draft-ietf-ipcdn-device-mibv2-10.txt on the standards track


Bert and all,

  This note is the request for publication and proto write-up for
draft-ietf-ipcdn-device-mibv2-10.txt.

Let us know if you have any questions or concerns with the above by
sending txt to the ipcdn list. Thank you Rich and Kevin for your
continued efforts and big thanks to Randy, Bert et al. for the detailed
and constructive MIB doctor and expert reviews.

Jean-François
jfm@cablelabs.com
IPCDN co-chair.

The PROTO process (cf. draft-ietf-proto-wgchair-doc-shepherding-05.txt)
is being used for the IPCDN Cable Device MIB v2 Internet-Draft.

Here is the proposed PROTO writeup for:
Cable Device Management Information Base for Data-Over-Cable Service
Interface Specification Compliant Cable Modems and Cable Modem
                          Termination Systems
                    draft-ietf-ipcdn-device-mibv2-10

ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-10.txt


Requested Publication Status: Proposed Standard
Obsoletes: RFC 2669
PROTO shepherd: Jean-Francois Mule (IPCDN WG co-chair)
------------------------------------------------------------------------

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.
One of the 2 IPCDN co-chairs is a co-author and the other is the PROTO
shepherd writing this note. Both have reviewed this version of the ID.
Based on the WG comments, MIB doctors & AD review comments, the ID is
believed to be ready for publication.


  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes, reviews from both subject-matter experts that are WG members and
MIB doctors who provided valuable comments to improve the quality of
the MIB module.


        Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

No, given the time this ID has been in existence and the number of
revisions due to comments.


  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No. The IETF 63 meeting was dedicated to addressing all the remaining
WG comments and the draft update does close those open issues. No other
concerns from the PROTO shepherd.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

This document represents the WG consensus as a whole: the WG as a whole
understands and agrees with it.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No. An explicit request for intent to appeal was made on the list on
November 25, 2005.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The ID nits checker (v1.82) was ran on Nov 25 2005 and found no issues.
idnits 1.82 output:
-----------
tmp/draft-ietf-ipcdn-device-mibv2-10.txt:


  Checking nits according to http://www.ietf.org/ID-Checklist.html:

    Checking conformance with RFC 3978/3979 boilerplate...

    the boilerplate looks good.
    No nits found.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
    Nothing found here (but these checks do not cover all of
    1id-guidelines.txt yet).

  Miscellaneous warnings:
    None.

    No nits found.
---------------


  1.h) Is the document split into normative and informative references?

Yes.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

No.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality
Ok.

  1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

--- Technical Summary

  This document is a revision of the standards track RFC 2669.
  This memo defines a portion of the Management Information Base (MIB)
  for use with network management protocols in the Internet community.
  In particular, it defines a basic set of managed objects for SNMP-
  based management of DOCSIS-compliant Cable Modems and Cable Modem
  Termination Systems.


--- Working Group Summary

  The Working Group has consensus to publish this document as a
  Proposed Standard.


--- Protocol Quality

  The MIB module has been reviewed by Randy Presuhn. The overall quality
  with respect to DOCSIS functionality has been reviewed by Greg White
  and Eduardo Cardona. This document has been reviewed for the IESG by
  Bert Wijnen.

Ballot writeup received; IETF Last Call requested.

Added (in ballot writeup)  Note to RFC Editor

  - Pls fix the DESCRIPTION clause of the MODULE-IDENTITY (page 17):

  OLD:
                Copyright (C) The Internet Society (2005). The initial
                version of this MIB module was published in RFC XXXX;
                for full legal notices see the RFC itself.
                Supplementary information may be available at:
                http://www.ietf.org/copyrights/ianamib.html."
  NEW:
                Copyright (C) The Internet Society (2005). The initial
                version of this MIB module was published in RFC XXXX;
                for full legal notices see the RFC itself."

Revisions 10 does address my earlier comments on a pre-release
of that revision (as per below). So I am happy.

Only thing left is:
In the DESCRIPTION clause of the MODULE-IDENTITY you state:
                Copyright (C) The Internet Society (2005). The initial
                version of this MIB module was published in RFC XXXX;
                for full legal notices see the RFC itself.
                Supplementary information may be available at:
                http://www.ietf.org/copyrights/ianamib.html."
  Those last two lines can go away. This is not an IANA maintained
  MIB module, so their copyrights have nothing to do with this.

You can consider that as an early IETF Last Call comment, and we
can fix it with a note to RFC-Editor if this is all that gets
reported.



-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Tuesday, August 16, 2005 22:34
To: Woundy, Richard; Jean-Francois Mule
Cc: Ipcdn (E-mail)
Subject: AD review: draft-ietf-ipcdn-device-mibv2-09.txt


In fact I did a review of a somewhat updated document:
    draft-ietf-ipcdn-device-mibv2-10-discussion.txt.
as per below email exchange between AD and WG chairs.

Note that I did not re-review the decisions we took
(and that are being verified by Jean Francois on the list)
in Paris. The changes resulting from that should also go in.

So here we go:

- ID-Checklist - OK
  no nits found

- References - NOK
  I find:
      !! Missing citation for Normative reference:
      P088 L036:    [OSSI1.1]  CableLabs, "Data-Over-Cable Service Interface

      !! Missing citation for Normative reference:
      P088 L041:    [OSSI2.0]  CableLabs, "Data-Over-Cable Service Interface

  Also:
    !! Missing citation for Normative reference:
    P090 L008:    [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
  You have it in the IMPORTS clause.
  Possible solution
  OLD:
          SnmpAdminString
                  FROM SNMP-FRAMEWORK-MIB  -- RFC 3411
  NEW:
          SnmpAdminString
                  FROM SNMP-FRAMEWORK-MIB  -- [RFC3411]
  Also:
    !! Missing citation for Normative reference:
    P089 L036:    [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
  Possible solution
  OLD:
          InterfaceIndexOrZero
                  FROM IF-MIB              -- RFC 2863
  NEW:
          InterfaceIndexOrZero
                  FROM IF-MIB              -- [RFC2863]
  Also:
    !! Missing citation for Normative reference:
    P089 L008:    [RFC2021]  Waldbusser, S., "Remote Network Monitoring Management
  Similar solution possible
  Also:
    !! Missing citation for Normative reference:
    P090 L035:    [RFC3617]  Lear, E., "Uniform Resource Identifier (URI) Scheme and
  It is listed in he REFERENCE clause of docsDevServerConfigTftpAddress.
  A possible solution:
  OLD:
          REFERENCE
              "RFC 3617, Section 5"
  NEW:
          REFERENCE
              "RFC 3617, Section 5"  -- [RFC3617]

  Another way to solve it is to put some text just before the MIB Module
  that states something aka:

      This MIB Module IMPORTS (normatively) from [RFC2580], [RFCxxxx], etc
      It also has REFERENCE Clauses that refer to [RFCxxxx]. etc

  That way you will also be covered.

  Further, you may want to update refrence to RFC3291 with reference to RFC4001.
  Pls make sure to also correct the citations.

- MIB Module contents - SYNTAX check:

  docsDevEvReporting OBJECT-TYPE
          SYNTAX BITS {
              local(0),
              traps(1),
              syslog(2),
              localVolatile(8),
              stdInterface(9)
          }

  causes SMICng to bark:

      E: f(ipcdndevice.mi2), (1196,16) Named bits for BITS must be in
          contiguous positions
 
  I guess you do this to not cause backward compatibility problems?
  Would it be good to do something aka:

    docsDevEvReporting OBJECT-TYPE
          SYNTAX BITS {
              local(0),
              traps(1),
              syslog(2),
              -- the following are extensions to the original set of
              -- labels. The extensions start at octet boundary. So
              -- for bits 3-7, one MUST set them to zero on send and
              -- one MUST ignore them on receipt.
              localVolatile(8),
              stdInterface(9)
          }

- More module syntax checking:

      W: f(ipcdndevice.mi2), (427,24) Item "docsDevNmAccessCommunity"
              should have SIZE specified
  I guess theoretically we could specify a size of (0..255) because
  that must have been the intention all along (a community name
  is limited to that size).
  But since object is deprecated I won't mind to leave as is

      W: f(ipcdndevice.mi2), (2428,4) Row "docsDevCpeInetEntry" has
        indexing that may create variables with more than 128 sub-ids

  I see that the InetAddress object DESCRIPTION clause instructs
  implementors. So no problem.

      E: f(ipcdndevice.mi2), (2801,11) Item "diffServDataPathStatus"
        should be IMPORTed
      E: f(ipcdndevice.mi2), (2808,11) Item "diffServClfrStatus" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2815,11) Item "diffServClfrElementStatus"
        should be IMPORTed
      E: f(ipcdndevice.mi2), (2822,11) Item "diffServMultiFieldClfrAddrType"
        should be IMPORTed
      E: f(ipcdndevice.mi2), (2829,11) Item "diffServMultiFieldClfrSrcAddr"
        should beIMPORTed
      E: f(ipcdndevice.mi2), (2835,11) Item "diffServMultiFieldClfrDstAddr"
        should beIMPORTed
      E: f(ipcdndevice.mi2), (2841,11) Item "diffServAlgDropStatus" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2848,11) Item "diffServDataPathStorage" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2854,11) Item "diffServClfrStorage" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2860,11) Item "diffServClfrElementStorage"
        should be IMPORTed
      E: f(ipcdndevice.mi2), (2866,11) Item "diffServMultiFieldClfrStorage"
        should beIMPORTed
      E: f(ipcdndevice.mi2), (2872,11) Item "diffServActionStorage" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2879,11) Item "diffServCountActStorage" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2885,11) Item "diffServAlgDropStorage" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2891,11) Item "diffServAlgDropType" should
        be IMPORTed

  Most of those were also imported in the subscriber MIB, so it seems to me
  we have dealth with this before in that other MIB module.

      W: f(ipcdndevice.mi2), (3140,4) OBJECT-GROUP "docsDevNmAccessExtGroup"
        is not used in a MODULE-COMPLIANCE in current module

  I am kind of surprised to see this Group at all.
  It is deprecated, and it contains one object docsDevNmAccessTrapVersion
  which is also deprecated. The object nor the Group existed in RFC 2669
  (which this doc obsoletes). So why are we having this deprecated
  object and object group at all?
  OK, OK, I see in DESCRIPTION clause why it was added.
  Mmm... Not exactly right... maybe I can live with it.
  But possibly this would be added to some (new) deprecated MODULE-COMPLIANCE.
  I guess it could even be added as optional group to the
  deprecated docsDevBasicCompliance, since it does not make old claims
  for that MODULE-COMPLIANCE invalid.... (borderline I think)
  So maybe accept the warning that the group is not used.

Nits:
-  "IPSec" (I  know it was incorrect in the mib security template too, I just fixed it)
    should be spelled "IPsec"

Bert

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Tuesday, August 16, 2005 22:34
To: Woundy, Richard; Jean-Francois Mule
Cc: Ipcdn (E-mail)
Subject: AD review: draft-ietf-ipcdn-device-mibv2-09.txt


In fact I did a review of a somewhat updated document:
    draft-ietf-ipcdn-device-mibv2-10-discussion.txt.
as per below email exchange between AD and WG chairs.

Note that I did not re-review the decisions we took
(and that are being verified by Jean Francois on the list)
in Paris. The changes resulting from that should also go in.

So here we go:

- ID-Checklist - OK
  no nits found

- References - NOK
  I find:
      !! Missing citation for Normative reference:
      P088 L036:    [OSSI1.1]  CableLabs, "Data-Over-Cable Service Interface

      !! Missing citation for Normative reference:
      P088 L041:    [OSSI2.0]  CableLabs, "Data-Over-Cable Service Interface

  Also:
    !! Missing citation for Normative reference:
    P090 L008:    [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
  You have it in the IMPORTS clause.
  Possible solution
  OLD:
          SnmpAdminString
                  FROM SNMP-FRAMEWORK-MIB  -- RFC 3411
  NEW:
          SnmpAdminString
                  FROM SNMP-FRAMEWORK-MIB  -- [RFC3411]
  Also:
    !! Missing citation for Normative reference:
    P089 L036:    [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
  Possible solution
  OLD:
          InterfaceIndexOrZero
                  FROM IF-MIB              -- RFC 2863
  NEW:
          InterfaceIndexOrZero
                  FROM IF-MIB              -- [RFC2863]
  Also:
    !! Missing citation for Normative reference:
    P089 L008:    [RFC2021]  Waldbusser, S., "Remote Network Monitoring Management
  Similar solution possible
  Also:
    !! Missing citation for Normative reference:
    P090 L035:    [RFC3617]  Lear, E., "Uniform Resource Identifier (URI) Scheme and
  It is listed in he REFERENCE clause of docsDevServerConfigTftpAddress.
  A possible solution:
  OLD:
          REFERENCE
              "RFC 3617, Section 5"
  NEW:
          REFERENCE
              "RFC 3617, Section 5"  -- [RFC3617]

  Another way to solve it is to put some text just before the MIB Module
  that states something aka:

      This MIB Module IMPORTS (normatively) from [RFC2580], [RFCxxxx], etc
      It also has REFERENCE Clauses that refer to [RFCxxxx]. etc

  That way you will also be covered.

  Further, you may want to update refrence to RFC3291 with reference to RFC4001.
  Pls make sure to also correct the citations.

- MIB Module contents - SYNTAX check:

  docsDevEvReporting OBJECT-TYPE
          SYNTAX BITS {
              local(0),
              traps(1),
              syslog(2),
              localVolatile(8),
              stdInterface(9)
          }

  causes SMICng to bark:

      E: f(ipcdndevice.mi2), (1196,16) Named bits for BITS must be in
          contiguous positions
 
  I guess you do this to not cause backward compatibility problems?
  Would it be good to do something aka:

    docsDevEvReporting OBJECT-TYPE
          SYNTAX BITS {
              local(0),
              traps(1),
              syslog(2),
              -- the following are extensions to the original set of
              -- labels. The extensions start at octet boundary. So
              -- for bits 3-7, one MUST set them to zero on send and
              -- one MUST ignore them on receipt.
              localVolatile(8),
              stdInterface(9)
          }

- More module syntax checking:

      W: f(ipcdndevice.mi2), (427,24) Item "docsDevNmAccessCommunity"
              should have SIZE specified
  I guess theoretically we could specify a size of (0..255) because
  that must have been the intention all along (a community name
  is limited to that size).
  But since object is deprecated I won't mind to leave as is

      W: f(ipcdndevice.mi2), (2428,4) Row "docsDevCpeInetEntry" has
        indexing that may create variables with more than 128 sub-ids

  I see that the InetAddress object DESCRIPTION clause instructs
  implementors. So no problem.

      E: f(ipcdndevice.mi2), (2801,11) Item "diffServDataPathStatus"
        should be IMPORTed
      E: f(ipcdndevice.mi2), (2808,11) Item "diffServClfrStatus" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2815,11) Item "diffServClfrElementStatus"
        should be IMPORTed
      E: f(ipcdndevice.mi2), (2822,11) Item "diffServMultiFieldClfrAddrType"
        should be IMPORTed
      E: f(ipcdndevice.mi2), (2829,11) Item "diffServMultiFieldClfrSrcAddr"
        should beIMPORTed
      E: f(ipcdndevice.mi2), (2835,11) Item "diffServMultiFieldClfrDstAddr"
        should beIMPORTed
      E: f(ipcdndevice.mi2), (2841,11) Item "diffServAlgDropStatus" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2848,11) Item "diffServDataPathStorage" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2854,11) Item "diffServClfrStorage" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2860,11) Item "diffServClfrElementStorage"
        should be IMPORTed
      E: f(ipcdndevice.mi2), (2866,11) Item "diffServMultiFieldClfrStorage"
        should beIMPORTed
      E: f(ipcdndevice.mi2), (2872,11) Item "diffServActionStorage" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2879,11) Item "diffServCountActStorage" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2885,11) Item "diffServAlgDropStorage" should
        be IMPORTed
      E: f(ipcdndevice.mi2), (2891,11) Item "diffServAlgDropType" should
        be IMPORTed

  Most of those were also imported in the subscriber MIB, so it seems to me
  we have dealth with this before in that other MIB module.

      W: f(ipcdndevice.mi2), (3140,4) OBJECT-GROUP "docsDevNmAccessExtGroup"
        is not used in a MODULE-COMPLIANCE in current module

  I am kind of surprised to see this Group at all.
  It is deprecated, and it contains one object docsDevNmAccessTrapVersion
  which is also deprecated. The object nor the Group existed in RFC 2669
  (which this doc obsoletes). So why are we having this deprecated
  object and object group at all?
  OK, OK, I see in DESCRIPTION clause why it was added.
  Mmm... Not exactly right... maybe I can live with it.
  But possibly this would be added to some (new) deprecated MODULE-COMPLIANCE.
  I guess it could even be added as optional group to the
  deprecated docsDevBasicCompliance, since it does not make old claims
  for that MODULE-COMPLIANCE invalid.... (borderline I think)
  So maybe accept the warning that the group is not used.

Nits:
-  "IPSec" (I  know it was incorrect in the mib security template too, I just fixed it)
    should be spelled "IPsec"

Bert

-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Wednesday, August 10, 2005 16:29
To: Wijnen, Bert (Bert); Jean-Francois Mule
Cc: Woundy, Richard
Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews


OK, that would be terrific, thanks!

-- Rich
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: Wednesday, August 10, 2005 10:07 AM
To: Woundy, Richard; Wijnen, Bert (Bert); Jean-Francois Mule
Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews


So hwo about me reviewing
  http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion.txt.
and assuming you will fix the 4 issues we discussed at the WG session
last week. If I indeed do keep my promise (I have a bda track record)
then by the 15th you can incorporate all comments in to the next
official revision.

Bert
-----Original Message-----
From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
Sent: Wednesday, August 10, 2005 15:24
To: Wijnen, Bert (Bert); Jean-Francois Mule
Cc: Woundy, Richard
Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews


Bert, Jean-Francois,

About this one review:

3.1/ DOCSIS Cable Device MIB version 2
    draft-ietf-ipcdn-device-mibv2-09.txt
    Editors: Kevin Marez & Rich Woundy
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt

# AD review by Bert due by August 15
As you know from last week's working group meeting, this draft is undergoing editing to address Randy's comments.

There are three versions that could undergo AD review:
The officially posted draft-ietf-ipcdn-device-mibv2-09 version. Randy sent a number of emails to the IPCDN mailing list with numerous MIB doctor comments against this version.
I generated an interim version, http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion.txt. This is the draft version that was the basis of the review in the working group (e.g. the "four issues").
I would like to submit a real draft-ietf-ipcdn-device-mibv2-10 based on the working group meeting discussions, but I cannot finish this before August 15 at the earliest. This would be incompatible with your review being due on August 15.
Bert, if you choose to review the posted -09 version, or the interim -10 "discussion", then I will wait for your review comments before I post the real -10 version.

If you want to review a posted -10 version, then I need to know soon, so that I hurry up on incorporating the working group comments (and Randy's email comments as well). Then we probably need to push back your review date a week or two.

For me, the ideal choice would be for you to review the interim version http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion.txt, and then I would incorporate your AD review comments into a posted -10 version.

-- Rich