[ipcdn] FW: IESG review of: draft-ietf-ipcdn-subscriber-mib-15.txt

"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Mon, 27 September 2004 21:46 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12428 for <ipcdn-archive@ietf.org>; Mon, 27 Sep 2004 17:46:22 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC3Ru-0001Lk-Sj for ipcdn-archive@ietf.org; Mon, 27 Sep 2004 17:54:23 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC38B-0000rm-RY; Mon, 27 Sep 2004 17:33:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CC2tI-0003tP-Cb for ipcdn@megatron.ietf.org; Mon, 27 Sep 2004 17:18:36 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09756 for <ipcdn@ietf.org>; Mon, 27 Sep 2004 17:18:33 -0400 (EDT)
Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CC30z-0000Tg-8h for ipcdn@ietf.org; Mon, 27 Sep 2004 17:26:33 -0400
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i8RLI2Ws001950 for <ipcdn@ietf.org>; Mon, 27 Sep 2004 16:18:03 -0500 (CDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <RLRKMY5G>; Mon, 27 Sep 2004 23:18:02 +0200
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79D39@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Ipcdn (E-mail)" <ipcdn@ietf.org>
Date: Mon, 27 Sep 2004 23:17:56 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Subject: [ipcdn] FW: IESG review of: draft-ietf-ipcdn-subscriber-mib-15.txt
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Sender: ipcdn-bounces@ietf.org
Errors-To: ipcdn-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb

Sorry, forgot to set proper subject line

-----Original Message-----
From: Wijnen, Bert (Bert) 
Sent: Monday, September 27, 2004 23:14
To: 'wsawyer@ieee.org'; Ipcdn (E-mail)
Subject: IESG review of: 



So below is the complete set of IESG review comments.

I think my reaction is as follows:

1. W.r.t. to referencing draft-ietf-ipcdn-device-mibv2-06.txt
   I wonder what the current status is of that document?
   It experied a while ago... and I am not seeing activity.
   So maybe we should just list RFC2669 and not talk about
   the draft?

2. Based on the above, I also wonder about 
   draft-ietf-ipcdn-docs-rfmibv2-06.txt
   Where are we with that one?

3. The comment from Ted Hardie is the same as some discussion we 
   had from Steve Bellovin, and I believe the answer is that 
   current MODULE COMPLIANCE only requires IPv4 but the 
   MIB module itself is all ready to also support IPv6.
   So no change needed.

4. The comments from Russ and Allison's DISCUSS seem valid to me.

So to address all of the above, I could add the
following RFC-Editor notes:

RFC-Editor, pls fix the following 

- on page 4, pls ignore and remove:

       -- ***********************************************************
       -- * Note to RFC Editor (to be removed)
       -- * If DOCSIS Cable Device MIB [RFC2669] is updated prior to
       -- * this publication, replace "docsDevCpeIp" with
       -- * "docsDevCpeInetAddr"
       -- ***********************************************************

- mmm also comes back on page 10 and page 14

- In section 9, 2nd para, pls change text

  OLD:
    Effective network filtering of TCP traffic requires that implementors
    MUST follow the recommendations in section 3.2.6.
   
  NEW:
    For network filtering of TCP traffic to be effective, implementors
    MUST follow the recommendations in section 3.4.

- on page 23, pls ignore and remove:
       ************************************************************
       * NOTES TO RFC Editor (to be removed prior to publication) *
       *                                                          *
       *     The I-D <draft-ietf-ipcdn-device-mibv2-06.txt> (or a *
       * successor) is expected to eventually replace RFC 2669.   *
       * If that draft (or a successor) is published as an RFC    *
       * prior to or concurrently with this document, then the    *
       * normative reference [RFC2669] should be updated to       *
       * point to the replacement RFC, and the reference tag      *
       * [RFC2669] should be updated to match.                    *
       *                                                          *
       ************************************************************

- ANd possibly a similar statement about
   draft-ietf-ipcdn-docs-rfmibv2-06.txt

Mmm... that is I think more than we want to do in an RFC-Ed note.
Wilson, how quick can you do a revision?

Bert

------------- IESG comments/discusses 

Discusses and Comments 
Harald Alvestrand:
Comment:
[2004-09-27] Reviewed by John Loughney, Gen-ART

His review:

Document seems ready, a couple of small nits:

1) Shouldn't the Security Considerations come before the references?
2) For the references, there is text that says the following:

        ************************************************************
        * NOTES TO RFC Editor (to be removed prior to publication) *
        *                                                          *
        *    The I-D <draft-ietf-ipcdn-device-mibv2-06.txt> (or a *
        * successor) is expected to eventually replace RFC 2669.  *
        * If that draft (or a successor) is published as an RFC    *
        * prior to or concurrently with this document, then the    *
        * normative reference [RFC2669] should be updated to      *
        * point to the replacement RFC, and the reference tag      *
        * [RFC2669] should be updated to match.                    *
        *                                                          *
        ************************************************************

Shouldn't the I-D just be referenced? Some of these references
seem that they should reference the I-D, not the RFC.

Ted Hardie:
Comment:
[2004-09-24] I have to say that I think the v4-only nature of this doc is pretty questionable; I understand
that the document is relative to DOCSIS deployments which don't deploy v6, but this
is starting them down a design road that is going to require more than a little backtracking.
The whole mechanism presumes that use of multiple address is a wrong/restricted
activity; this isn't the right focus for v6.  Rather than working out some management 
framework than can handle both, they could end up with such separate things that
the user experience is affected by the overlapping attempts at control (or the
attempts to control are frustrated trivially).

I'm not DISCUSSing this document, since it is clear on its scope, but I strongly encourage
them to create a joint v4/v6 management scope as a successor to this, rather than
a v6 auxillary to this.

Russ Housley:
Comment:
[2004-09-22] 
  The 2nd paragraph of Section 9 says:
  :
  : Effective network filtering of TCP traffic requires that implementors
  : MUST follow the recommendations in section 3.2.6.
  :
  I suggest replacement text:
  
    For network filtering of TCP traffic to be effective, implementors
    MUST follow the recommendations in section 3.2.6.

Allison Mankin:
Discuss:
[2004-09-26] The document states:
  Effective network filtering of TCP traffic requires that implementors
  MUST follow the recommendations in section 3.2.6.
But there is no section 3.2.6 here.  MUST must be clear.

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn