Subject: [ipcdn] AD Review: draft-ietf-ipcdn-subscriber-mib-12.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 2 Sep 2003 14:39:17 +0200

Too late for Last Call I suspect, but this is what I still find
with SMICng, strict checking:
  E: f(ipcdnsub.mi2), (415,15) Item "diffServMIBDataPathGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (416,15) Item "diffServMIBClfrGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (417,15) Item "diffServMIBClfrElementGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (418,15) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (419,15) Item "diffServMIBActionGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (420,15) Item "diffServMIBAlgDropGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (421,15) Item "diffServMIBCounterGroup" should be IMPORTed
  E: f(ipcdnsub.mi2), (424,11) Item "diffServDataPathStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (430,11) Item "diffServClfrStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (437,11) Item "diffServClfrElementStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (443,11) Item "diffServMultiFieldClfrAddrType" should be IMPORTed
  E: f(ipcdnsub.mi2), (449,11) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed
  E: f(ipcdnsub.mi2), (455,11) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed
  E: f(ipcdnsub.mi2), (461,11) Item "diffServAlgDropStatus" should be IMPORTed
  E: f(ipcdnsub.mi2), (467,11) Item "diffServDataPathStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (473,11) Item "diffServClfrStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (479,11) Item "diffServClfrElementStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (485,11) Item "diffServMultiFieldClfrStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (492,11) Item "diffServActionStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (498,11) Item "diffServCountActStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (504,11) Item "diffServAlgDropStorage" should be IMPORTed
  E: f(ipcdnsub.mi2), (510,11) Item "diffServAlgDropType" should be IMPORTed

The draft-ietf-ops-mib-review-guidelines-02.txt document says about this,
sect 4.4. pages 10 and 11):
   ... snip ...
   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 acceptable the way you have done it, but if you do add them it does
make the above errors go away. I thought we had discussed this before...
but maybe it was some other MIB where I did discuss it.

Additional comments/questions:
- I see that references are made to RFC2669 and 2670.
  But at the same time this WG is working on replacements for those
  RFCs, so they will soon be obsoleted. Is it not better to reference
  the replacement documents?
- For objects that are not in a table, like docsSubMgtCpeMaxIpDefault,
  can you add a few words to the DESCRIPTION clause  to describe what
  the expected persistency behaviour is?
- I see:
   docsSubMgtCpeIpAddr OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The IP address either set from provisioning or learned via
       address gleaning or other forwarding means. See
       docsSubMgtCpeIpIndex for the mechanism."
  According to RFc3291, you MUST specify which InetAddressType opbject
  is used to specify the type. So something aka:
       DESCRIPTION
           "The Internet address either set from provisioning or learned
       via address gleaning or other forwarding means. See
       docsSubMgtCpeIpIndex for the mechanism.

       The type of this address is determined by the value of the
       docsSubMgtCpeIpAddressType object."
- In DESCRIPTION clause of: docsSubMgtCmFilterUpstream
  Change:        zero use default classification)
  Into:          zero (use default classification)
- In DESCRIPTION of: docsSubMgtFilterGroupTable
   s/OIDs/object definitions/ 
   and is it a collection? There is only an index object
- IN DESCRIPTION of: docsSubMgtFilterGroupIndex
    "Provides an OID to which.. 
  It defines an object, and the diffServClfrElementSpecific
  can point to an instance in this table (it does use the OID
  that identifies the instance). 
  Also w.r.t. to the range of this object...
  Is the entry with index zero the (use default classification)?
  or is it not intended to exist? From teh way I read things now,
  there is no need for value 0 in this index object, so better
  not include it in the range I would say.
- docsSubMgtBasicCompliance
  I am not sure were exactly we were with our discussion to the
  wording that only IPv4 needs to be supported. If the
  current DOCSIS only supports IPv4, then just doing IPv4 in
  MODULE-COMPLIANCE is probably OK. Maybe rename it to 
  docsSubMgtBasicIPv4Compliance?  It certainly would be good to
  add something about that, either in the DESCRIPTION clause of
  the module compliance itself, or in the InetAddressType and
  InetAddress DESCRIPTION clauses in the compliance statement.
  Let me also add Juergen Schoenwaelders comment (not sure he posted
  it to this WG list):
     Note that scoped link-local addresses are not captured in 
     the compliance statement on devices that potentially can
     connect multiple links if you restrict the SYNTAX to
     { ipv4(1) } or { ipv4(1), ipv6(2) }. 
     So people should think twice whether it is not good to
     include ipv4z(3) and ipv6z(4) as well so that proper
     support for link-local addresses is required on devices
     which connect multiple links where conflicts can appear.
- I am a little surprised by the definitions that DiffServTables
  only need nonVolatile support. Seems more difficult than volatile,
  so would you not at least add that?
  I do not believe we have such sort of refinements for StorageType
  in any MIB module yet. Can you explain what your thinking is/was?
- Can you add Mike Heard to the Acknowledgement section? I think
  he has contributed quitea bit in some of these discussions.
- I think you need to add RFC3290 as a NORMATIVE reference.
  You are IMPORTing from that document

Thanks,
Bert 

> -----Original Message-----
> From: Woundy, Richard [mailto:[email-masked]]
> Sent: maandag 4 augustus 2003 20:58
> To: IPCDN WG (E-mail)
> Cc: [email-masked]'; Bert Wijnen (E-mail)
> Subject: WGLC of the DOCSIS Subscriber Management MIB
> 
> 
> Folks,
> 
> I would like to start the working group last call for the 
> DOCSIS Subscriber
> Management MIB,
> <http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscrib
> er-mib-12.txt>
> . The last call is scheduled to end on August 18th.
> 
> Please send comments (both positive and negative) to the 
> [email-masked]
> mailing list reflector.
> 
> -- Richard Woundy and Jean-Francois Mule, IPCDN Co-Chairs
> 
> -----Original Message-----
> From: Woundy, Richard 
> Sent: Monday, August 04, 2003 9:53 AM
> To: [email-masked]'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [ipcdn] draft -12 of subscriber management MIB
> 
> 
> I posted the draft on the IPCDN website,
> <http://www.ipcdn.org/drafts/draft-ietf-ipcdn-subscriber-mib-12.txt>.
> 
> As soon as it is also posted on the IETF website, we will 
> start a two-week
> WG last call...
> 
> -- Rich
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, August 04, 2003 9:41 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [ipcdn] draft -12 of subscriber management MIB
> 
> 
> 
> 
> 
> 
> On Friday, at Jean-Francois' request,  I went ahead and 
> submitted the -12
> draft of the Docsis Subscriber Management MIB. It should be 
> appearing soon
> through the usual IETF publication process, as well as on the 
> ipcdn web
> site.
> 
> It is still lacking final text on the IPv4/IPv6 question, 
> although recent
> emails suggest that we are converging on wording. I'll 
> republish with that
> wording as soon as we've reached consensus.
> 
> The new draft also attempts to address a question from Kirk Friedman
> regarding 'interface' usage.
> 
> Please review and get comments to me and to the WG mailing list.
> 
> - Wilson Sawyer
> 
> 
> 
> _______________________________________________
> IPCDN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 
> _______________________________________________
> IPCDN mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipcdn
> 

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

---

From: Wilson Sawyer <[email-masked]>
Date: Tue, 02 Sep 2003 21:30:33 -0400

Bert - thank you for the review. Responses interspersed.
WG members: I need help with:
     (1) ipv4z addresses (see discussion about scoped link-local addresses)
     (2) StorageType (nonVolatile as minimum requirement, or ?)
Rich & Jean-Francois: need help with RFC2669/2670 status

Thanks
Wilson

> but maybe it was some other MIB where I did discuss it.

In a previous run, SMICng complained when they *were* included. I'd rather leave them out
unless the guidelines are going the other way.

>   the replacement documents?

Rich? Jean-Francois?

>   the expected persistency behaviour is?

ok.

>        docsSubMgtCpeIpAddressType object."

agreed.

>   Into:          zero (use default classification)

agreed.

>   that identifies the instance).

I think I understand your point, but I'll have to think about how to reword this so that
the sense of linkage of ClfrElementSpecific to Docsis signaling isn't lost.

>   not include it in the range I would say.

you're right. zero should be excluded.

>   InetAddress DESCRIPTION clauses in the compliance statement.

I was planning to use Mike's wording from August 3.

>      which connect multiple links where conflicts can appear.

Juergen makes a good point - I had neglected zoned non-global addresses. What is the
working group opinion on this? Should we require support for ipv4z addresses?

>   so would you not at least add that?

This class of device has had a longstanding market requirement for nonVolatile support.
There isn't a corresponding market requirement for volatile support. Is there a benefit to
adding such a requirement for specification purposes?

>   in any MIB module yet. Can you explain what your thinking is/was?

This corresponds to market requirements for this class of device (as I understand them).
Please keep in mind that, unlike most devices and MIBs, we have a rigorous certification
process (by CableLabs) that renders noncompliant products nearly unsellable. So vendors
must take the requirements in this document very seriously. So I'd prefer not to require
supersets of what the customer base has asked for. The danger is that CableLabs would be
forced to substitute its own (non-IETF) compliance document, rendering this compliance
statement moot.

>   he has contributed quitea bit in some of these discussions.

good point. yes.

>   You are IMPORTing from that document

I assume you mean 3291. If so, yes.