Subject: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 14 Jul 2004 16:14:22 +0200

Wilson (and WG). Sorry that it took long (again) to do another
good check of this MIB document.

I think this doc is basically OK now. I did find some small things
as per below, and it would be good to fix those at some point.
I propose that I issue an IETF Last Call, and that the below comments
are considered as the initial comments on such an IETF Last Call
and that you address them (or answer them) as part of any other comments
that may come up from IETF Last Call.

Wilson/WG-chair(s), pls let me know if that sounds like a plan or if
you ratehr address/answer the below first.

What I did find is:

>From SMICng (strict checking). I thought I had reported this before ( see I 
did, but you probably opted to not do it since it is not mandatory).
Oh well, I am including it anayway (again), because I really belive it
is betetr to include them.

  E: f(ipcdnsub.mi2), (478,15) Item "diffServMIBDataPathGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (479,15) Item "diffServMIBClfrGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (480,15) Item "diffServMIBClfrElementGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (481,15) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (482,15) Item "diffServMIBActionGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (483,15) Item "diffServMIBAlgDropGroup" should be IMPORTed 
  E: f(ipcdnsub.mi2), (484,15) Item "diffServMIBCounterGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (487,11) Item "diffServDataPathStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (493,11) Item "diffServClfrStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (499,11) Item "diffServClfrElementStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (506,11) Item "diffServMultiFieldClfrAddrType" should be IMPORTed
  E: f(ipcdnsub.mi2), (512,11) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed
  E: f(ipcdnsub.mi2), (518,11) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed
  E: f(ipcdnsub.mi2), (524,11) Item "diffServAlgDropStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (530,11) Item "diffServDataPathStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (536,11) Item "diffServClfrStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (542,11) Item "diffServClfrElementStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (548,11) Item "diffServMultiFieldClfrStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (554,11) Item "diffServActionStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (560,11) Item "diffServCountActStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (566,11) Item "diffServAlgDropStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (572,11) Item "diffServAlgDropType" should be IMPORTed

According to our MIB review guidelines (draft-ietf-ops-mib-review-guidelines-03.txt)
section 4.4, 3rd para:
   Note that exemptions to this general requirement are granted by RFC
   2580 Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in
   the OBJECT clause of a MODULE-COMPLIANCE statement or in the
   VARIATION clause of an AGENT-CAPABILITIES statement.  Some MIB
   compilers also grant exemptions to descriptors of notifications
   appearing in a VARIATION clause and to descriptors of object groups
   and notification groups referenced by a MANDATORY-GROUPS clause, a
   GROUP clause, or an INCLUDES clause, although RFC 2580 (through
   apparent oversight) does not mention those cases.  The exemptions are
   sometimes seen as unhelpful because they make IMPORTS rules more
   complicated and inter-module dependencies less obvious than they
   otherwise would be.  External symbols referenced by compliance
   statements and capabilities statements MAY therefore be listed in the
   IMPORTS statement;  if this is done, it SHOULD be done consistently.

So it is not mandatory to do the IMPORTs, but in my view it will help in
many places with less warning/errors. So may I suggest to add the IMPORT
statement for the above.

Also, all documents from whihc you IMPORT (implied or explicit) you must
put in normative reference section (which you have done). But all such
references MUST have a citation in the text (see MIB review guidelines,
(draft-ietf-ops-mib-review-guidelines-03.txt, sect 3.5):
   3.5.  References Sections

   Section 4.7f of [RFC2223bis] specifies the requirements for the
   references sections.  In particular, there MUST be separate lists of
   normative and informative references, each in a separate section.
   The style SHOULD follow that of recently published RFCs.

   The standard MIB boilerplate available at
   http://www.ops.ietf.org/mib-boilerplate.html includes lists of
   normative and informative references that MUST appear in all IETF
   specifications that contain MIB modules.  If items from other MIB
   modules appear in an IMPORTS statement in the Definitions section,
   then the specifications containing those MIB modules MUST be included
   in the list of normative references.  When items are imported from an
   IANA-maintained MIB module the corresponding normative reference
   SHALL point to the on-line version of that MIB module.  It is the
   policy of the RFC Editor that all references must be cited in the
   text;  such citations MUST appear in the overview section where
   documents containing imported definitions (other those already
   mentioned in the MIB boilerplate) are required to be mentioned (cf.
   Section 3.2).

You have such a reference for RFC3291 (as required), but no citation
to [RFC3291] anywhere in the document. Can you pls add it at
some point in the text.

I have some other nits/questions:

1. Desription clause of docsSubMgtCpeIpIndex states, towards the end:

       the table and the packet is forwarded.  If the number of entries
       equals the docsSubMgtCpeControlMaxCpeIp, AND
       docsSubMgtCpeControlActive is true, then the packet is dropped.
       Otherwise the packet is forwarded. "

   In the case that the packet is forwarded, will then also an entry be
   created? That is not clear to me. May I suggest to add some text to
   make that 100% clear?

2. In description clause of docsSubMgtCmFilterTable it states:

       Zero is a distinguished value, indicating that the default
       filtering action is to be taken, rather than that associated

   Mmm... a value for the table? I guess you mean that such a zero
   value "in any of the columns of the table has a special maening.
   Right? Might want to make that clearer.

3. I see:
     1.3.6.1.2.1.xx.1.6      docsSubMgtCmFilterTable 
     1.3.6.1.2.1.xx.1.6.1    docsSubMgtCmFilterEntry 
     1.3.6.1.2.1.xx.1.6.1.1  docsSubMgtSubFilterDownstream
     1.3.6.1.2.1.xx.1.6.1.2  docsSubMgtSubFilterUpstream
     1.3.6.1.2.1.xx.1.6.1.3  docsSubMgtCmFilterDownstream
     1.3.6.1.2.1.xx.1.6.1.4  docsSubMgtCmFilterUpstream 
   I think that for naming consistency, it might be better to rename
     1.3.6.1.2.1.xx.1.6.1.1  docsSubMgtSubFilterDownstream
     1.3.6.1.2.1.xx.1.6.1.2  docsSubMgtSubFilterUpstream
   into something like:
     1.3.6.1.2.1.xx.1.6.1.1  docsSubMgtCmSubFilterDownstream
     1.3.6.1.2.1.xx.1.6.1.2  docsSubMgtCMmubFilterUpstream
   so as to make it clearer (from the name/descriptor) that these 2
   objects exists in the docsSubMgtCmFilterTable.

4. I am a bit worried about the hard limit (range) of 1-255 for FilterGroupIndex.
   Is this enough forever in the future? Or would it be wiser to use a larger
   range (and limit via MODULE-COMPLIANCE, as you already do)?
   I see it was larger before, and that you changed it to this smaller range.
   So I guess you are doing this consciously.

5. In description clause of docsSubMgtFilterGroupIndex I see:

       the four. Because this is the only field in this table, it is
       read-only, contrary to the usual SNMP custom of making indices
       not-accessible.

   Probably better to change SNMP into SMI.

6. In the Security Considerations, I think I would change the 2nd para
   to make a positive statement, namely that you MUST follow recommendations
   in sect 2.2.6 in order to deploy an effective filtering.

Thanks,
Bert 

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: [email-masked]
Date: Wed, 14 Jul 2004 14:49:09 +0000

I won't be able to respond to these immediately, so my preference would be to go ahead with the Last Call as Bert proposes.
- Wilson

-------------- Original message -------------- 

> According to our MIB review guidelines 
> (draft-ietf-ops-mib-review-guidelines-03.txt) 
> section 4.4, 3rd para:

---

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 14 Jul 2004 08:56:25 -0600

Bert, 
For the benefot of other authors/editors in the same path of AD evaluation, 
I see your comment 3 a little deviation of OPS guidelines Appendix C:
- The descriptor associated with a conceptual table should be of the
     form xxxZzzTable;  the descriptor associated with the corresponding
     conceptual row should be of the form xxxZzzEntry;  the name of the
     associated SEQUENCE type should be of the form XxxZzzEntry;  and
     the descriptors associated with the subordinate columnar objects
     should be of the form xxxZzzSomeotherName.
 
I presume it is a typo and you would like see extrict compliance to those recommendations
Any comments?

Thanks 
 
Eduardo

	-----Original Message----- 
	From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
	Sent: Wed 7/14/2004 8:14 AM 
	To: [email-masked]; [email-masked]; Ipcdn (E-mail) 
	Cc: Harrie Hazewinkel 
	Subject: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt

	

	

	

	

	

	

	3. I see:

	

	
	Thanks,
	Bert

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 14 Jul 2004 09:22:42 -0600

Wilson wrote:
> I won't be able to respond to these immediately, so my 
> preference would be to go ahead with the Last Call as Bert proposes.
> - Wilson

Your proposal Bert sounds like a plan and that we should do a Last Call
asap (based on the nature of your comments Bert, and the upcoming
cut-off ID date).

Jean-Francois.

---

From: "Woundy, Richard" <[email-masked]>
Date: Wed, 14 Jul 2004 14:02:38 -0400

>Wilson/WG-chair(s), pls let me know if that sounds like a plan or
>if you ratehr address/answer the below first.

Going to IETF Last Call sounds like a good plan to me.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Wijnen, Bert (Bert)
Sent: Wednesday, July 14, 2004 10:14 AM
To: [email-masked]; [email-masked]; Ipcdn (E-mail)
Cc: Harrie Hazewinkel
Subject: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt

  E: f(ipcdnsub.mi2), (478,15) Item "diffServMIBDataPathGroup" should be
IMPORTed
  E: f(ipcdnsub.mi2), (479,15) Item "diffServMIBClfrGroup" should be
IMPORTed
  E: f(ipcdnsub.mi2), (480,15) Item "diffServMIBClfrElementGroup" should be
IMPORTed
  E: f(ipcdnsub.mi2), (481,15) Item "diffServMIBMultiFieldClfrGroup" should
be IMPORTed
  E: f(ipcdnsub.mi2), (482,15) Item "diffServMIBActionGroup" should be
IMPORTed
  E: f(ipcdnsub.mi2), (483,15) Item "diffServMIBAlgDropGroup" should be
IMPORTed 
  E: f(ipcdnsub.mi2), (484,15) Item "diffServMIBCounterGroup" should be
IMPORTed
  E: f(ipcdnsub.mi2), (487,11) Item "diffServDataPathStatus" should be
IMPORTed
  E: f(ipcdnsub.mi2), (493,11) Item "diffServClfrStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (499,11) Item "diffServClfrElementStatus" should be
IMPORTed
  E: f(ipcdnsub.mi2), (506,11) Item "diffServMultiFieldClfrAddrType" should
be IMPORTed
  E: f(ipcdnsub.mi2), (512,11) Item "diffServMultiFieldClfrSrcAddr" should
be IMPORTed
  E: f(ipcdnsub.mi2), (518,11) Item "diffServMultiFieldClfrDstAddr" should
be IMPORTed
  E: f(ipcdnsub.mi2), (524,11) Item "diffServAlgDropStatus" should be
IMPORTed
  E: f(ipcdnsub.mi2), (530,11) Item "diffServDataPathStorage" should be
IMPORTed
  E: f(ipcdnsub.mi2), (536,11) Item "diffServClfrStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (542,11) Item "diffServClfrElementStorage" should be
IMPORTed
  E: f(ipcdnsub.mi2), (548,11) Item "diffServMultiFieldClfrStorage" should
be IMPORTed
  E: f(ipcdnsub.mi2), (554,11) Item "diffServActionStorage" should be
IMPORTed
  E: f(ipcdnsub.mi2), (560,11) Item "diffServCountActStorage" should be
IMPORTed
  E: f(ipcdnsub.mi2), (566,11) Item "diffServAlgDropStorage" should be
IMPORTed
  E: f(ipcdnsub.mi2), (572,11) Item "diffServAlgDropType" should be IMPORTed

3. I see:

4. I am a bit worried about the hard limit (range) of 1-255 for
FilterGroupIndex.
   Is this enough forever in the future? Or would it be wiser to use a
larger
   range (and limit via MODULE-COMPLIANCE, as you already do)?
   I see it was larger before, and that you changed it to this smaller
range.
   So I guess you are doing this consciously.

Thanks,
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 14 Jul 2004 21:18:39 +0200

> compliance to those recommendations
Not sure I understand. The idea of the Guidelines is to show that (ideally)
all columns wthin one table have a common prefix (that sets them apart
from other objects in the same (or even otehr) MIB module(s) ).

So by inserting the "Cm" for the two objects I listed, that seems to do
the trick. What did you think that the Guidelines are suggesting?

> Eduardo

.. snip 

>    objects exists in the docsSubMgtCmFilterTable.

.. snip 

Bert

---

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 14 Jul 2004 13:55:46 -0600

Just looking for a clarification of how to interpret the OPS guidelines.
 
"Should be... " is being obscure for me compared with "RECOMMENDED" also  that is at some point "quasy-mandatory" by MIB doctors reviews, That's why I ask the question in a generic way for multiple editors/authors - good to have your perspective.
 
My only recollection of theoretical prefix complains is in smilib for the common model  tool that uses heuristics for dependencies discovery (?) 
 
I got confused if the 'CM' should be added ( recommended) to the SomeOtherName part of xxxZzzSomeotherName  
 
Thanks
 
Eduardo

	-----Original Message----- 
	From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
	Sent: Wed 7/14/2004 1:18 PM 
	To: Eduardo Cardona; [email-masked]; [email-masked]; Ipcdn (E-mail) 
	Cc: Harrie Hazewinkel 
	Subject: RE: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt

	

	.. snip

	.. snip
	
	Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 15 Jul 2004 11:35:27 +0200

OK, so Eduardo and I discussed this a bit more off-line, because I was
not sure I was understanding his comments.

I think I now got it. Eduardo I think wanted to express that the 
MIB review Guidelines do suggest that the best solution would be to
rename all of these:
      1.3.6.1.2.1.xx.1.6      docsSubMgtCmFilterTable
      1.3.6.1.2.1.xx.1.6.1    docsSubMgtCmFilterEntry
      1.3.6.1.2.1.xx.1.6.1.1  docsSubMgtSubFilterDownstream
      1.3.6.1.2.1.xx.1.6.1.2  docsSubMgtSubFilterUpstream
      1.3.6.1.2.1.xx.1.6.1.3  docsSubMgtCmFilterDownstream
      1.3.6.1.2.1.xx.1.6.1.4  docsSubMgtCmFilterUpstream
into:
      1.3.6.1.2.1.xx.1.6      docsSubMgtCmFilterTable
      1.3.6.1.2.1.xx.1.6.1    docsSubMgtCmFilterEntry
      1.3.6.1.2.1.xx.1.6.1.1  docsSubMgtCmFilterSubDownstream
      1.3.6.1.2.1.xx.1.6.1.2  docsSubMgtCmFilterSubUpstream
      1.3.6.1.2.1.xx.1.6.1.3  docsSubMgtCmFilterCmDownstream
      1.3.6.1.2.1.xx.1.6.1.4  docsSubMgtCmFilterCmUpstream
which is completely inline with the MIB review Guidelines.
My original suggestion for change was not as drastic. 

YES... the above change of names would even be BETTER and more
consistent qith the MIB Review Guidelines. It is not a MUST CHANGE
though. But I would think everyone would agree that following a good
naming convention will be better for all of us (MIB developers) to
avoid name conflicts now and in the future.

Thanks,
Bert 
-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]]
Sent: woensdag 14 juli 2004 21:56
To: Wijnen, Bert (Bert); [email-masked]; [email-masked]; Ipcdn (E-mail)
Cc: Harrie Hazewinkel
Subject: RE: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt

Thanks

Eduardo
-----Original Message----- 
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Wed 7/14/2004 1:18 PM 
To: Eduardo Cardona; [email-masked]; [email-masked]; Ipcdn (E-mail) 
Cc: Harrie Hazewinkel 
Subject: RE: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt

.. snip

.. snip

Bert