RE: FW: IESG review of: draft-ietf-ipcdn-subscriber-mib-15.txt
"Jean-Francois Mule" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
[sending the same text I sent to Wilson, Rich and Bert to IPCDN]
I have some questions/concerns before deciding on the reference part.
> > 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?
> >
I made some comments to Wilson in draft 15 about some tables that were being deprecated or superseded by others in the cable device mib v2. For e.g., section 3.2.1 in draft 15 now says:
----------------------------------
3.2.1. Interaction with DOCSIS provisioning for CPE address control
Rows in docsSubMgtCpeControlTable are created by the CMTS for each
modem as a result of the DOCSIS registration process. The DOCSIS
registration attributes may include items semantically equivalent to
those in the docsDevCpe section of the DOCSIS Cable Device MIB
[RFC2669]:
o docsDevCpeEnroll
o docsDevCpeIpMax
o docsDevCpeIp
-- ***********************************************************
-- * Note to RFC Editor (to be removed)
-- * If DOCSIS Cable Device MIB [RFC2669] is updated prior to
-- * this publication, replace "docsDevCpeIp" with
-- * "docsDevCpeInetAddr"
-- ***********************************************************
----------------------------------
=> While I have no objection referencing RFC 2669 instead of the cable device v2 MIB, I am concerned that some of the core tables used in the subs mgmt mib are going away in RFC2669bis: for e.g. docsDevCpeTable.
So the content of my comment to Wilson can be summarized as follows:
+ if the subs mgmt MIB module is supposed to co-exist with both RFC2669 and its successor, may be we want to be explicit here and provide guidance on what tables to use in each case.
+ if the subs mgmt MIB module is supposed to co-exist only with RFC2669, I'm ok with removing the above text but I have some concerns that within ipcdn, we are not consistent.
+ if the subs mgmt MIB module is supposed to co-exist with RFC2669bis - the successor of RFC2669, may be we want to be explicit here and provide guidance on what tables to use in case the old RFC is implemented as well.
Finally, I do not understand why the subs mgmt MIB could not move to RFC editor status now and await the 2 dependent IDs to be updated and advance. It seems that the proposed alternatives do not take into consideration some of the updates in RFC2669bis and I have a pb with that.
Comments?
Jean-François
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]]
> Sent: Monday, September 27, 2004 3:18 PM
> To: Ipcdn (E-mail)
> Subject: [ipcdn] FW: IESG review of:
> draft-ietf-ipcdn-subscriber-mib-15.txt
>
>
> Sorry, forgot to set proper subject line
>
> -----Original Message-----
> From: Wijnen, Bert (Bert)
> Sent: Monday, September 27, 2004 23:14
> To: '[email protected]'; 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
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipcdn
>
>