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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 3 Sep 2003 18:01:53 +0200

Inline for those pieces that warrant another comment/answer from me

Thanks,
Bert 

> -----Original Message-----
> From: Wilson Sawyer [mailto:[email-masked]]
> Sent: woensdag 3 september 2003 3:31
> To: Wijnen, Bert (Bert)
> Cc: 'Woundy, Richard'; IPCDN WG (E-mail); [email-masked]
> Subject: Re: [ipcdn] AD Review: draft-ietf-ipcdn-subscriber-mib-12.txt
> 
> 
> 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 ?)

So realize that what you have currently defined is:
   - implementations MUST support nonVolatile
   - implementations are free to NOT support any of the other
     storageTypes.
   - when an operator uses the system, he can only rely on nonVolatile
     being supported, and all the otehr storageTypes may or may not
     be present. So basically the compliance statement tells them
     they can ONLy assume nonVolatile.
So... in principle you could vene remove the StorageType object/column
and put in the xxxEntry DESCRIPTION clasue:
   "all entries in this table MUST be saved in stable storage so that
    they will survive a restart/reboot."
Where as if you did not refine this, then you basically say:
   - implementation must support ALL storage types, including
     nonVolatile
   - when an operator uses the system, then he/she can decide if
     they want to use just nonVolatile or a mix of nonVolatile,
     volatile and any of the other StorageTypes.

Hope this explains why I found the single value "nonVolatile"
kind of strange.

> Rich & Jean-Francois: need help with RFC2669/2670 status
> 
I understood a while back that these updates to 2669 and 2670
were planned to go all together with this and a few other documents?
Maybe that is just "hope" and not reality, I do not know.

More below

> Thanks
> Wilson
> 
> "Wijnen, Bert (Bert)" wrote:
> 
> > 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.
> >
> 
> In a previous run, SMICng complained when they *were* 
> included. I'd rather leave them out
> unless the guidelines are going the other way.
> 
You must have been using an OLD version of SMICng (I suspect).
I am using:
    SMICng version 2.2.11-beta(PRO)(MS-DOS32), July 4, 2001.
with these (strict) options:
    smicopts=/CC /CB /CH /CS /C0D /C0F /C0M /C12 /C1S /C1O /C16 /C1G

In any event, I believe Mike Heard mentioned he prefers to see them
imported. So do I, otherwise I would not have brought it up.
But... it is not mandatory, so you as WG decide.

> >
> > - 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.
> 
> I was planning to use Mike's wording from August 3.
> 
That is OK.

> >
> >   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.
> 
> 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?
> 
Yep, WG pls chime in!

> 
> >
> > - 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?
> 
> 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?
> 
See above

> >
> >   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?
> 
> 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.
> 
See above

> >
> > - Can you add Mike Heard to the Acknowledgement section? I think
> >   he has contributed quitea bit in some of these discussions.
> 
> good point. yes.
> 
Thank you.

> >
> > - I think you need to add RFC3290 as a NORMATIVE reference.
> >   You are IMPORTing from that document
> >
> 
> I assume you mean 3291. If so, yes.
> 
Yep, typo.

Bert

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

---

From: Wilson Sawyer <[email-masked]>
Date: Mon, 08 Sep 2003 20:06:00 -0400

>      they can ONLy assume nonVolatile.

Yes, that is the intent.

>     they will survive a restart/reboot."

Not exactly. The entries must be capable of being saved in stable
storage. The implementor is welcome to exceed this floor. This is the
minimal useful functionality expected of this product class.

> Hope this explains why I found the single value "nonVolatile"

Your argument seems a bit abstract, since I haven't heard such needs
from operators. And I'm really not sure how you'd test compliance with
'permanent' and 'other'. 

On carefully considering your comments, it also occurred to me that this
is something that should be consistent across at least the DOCSIS MIBs
for this class of device. On reviewing the other DOCSIS MIBs, I find:

- bpiplus and RFI omit StorageType altogether (perhaps incorrectly)
- Event Mib doesn't appear to need StorageType
- QoS MIB and Device MIB have the same StorageType compliance language
as subscriber management.

Of course, if the other documents change, subscriber management should
also change to stay consistent.

(remainder snipped)

Regards,
Wilson