Subject: [ipcdn] FW: Sanity check on StorageType

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Mon, 15 Sep 2003 14:58:53 +0200

FYI

Thanks,
Bert 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: maandag 15 september 2003 13:20
To: Wijnen, Bert (Bert)
Cc: Mreview (E-mail)
Subject: Re: Sanity check on StorageType

On Sat, Sep 13, 2003 at 10:34:58PM +0200, Wijnen, Bert (Bert) wrote:

> in document draft-ietf-ipcdn-subscriber-mib-12.txt you will
> find (in the MODULE-COMPLIANCE):
> 
>    OBJECT diffServDataPathStorage
>        SYNTAX StorageType { nonVolatile(3) }
>        DESCRIPTION
>            "An implementation is only required to support nonvolatile
>             storage."
> 
> Do we believe this makes sense and is wise?
> I have my doubts. There is nothing illegal here, but it feels
> strange to me, no?

Perhaps the boxes in question only have non-volatile memory and 
no good old volatile ram anymore...  It kind of looks strange since 
one would expect volatile(2) but you really have to ask the WG what 
they indended to achieve.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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

---

From: "Eduardo Cardona" <[email-masked]>
Date: Mon, 15 Sep 2003 08:56:26 -0600

Bert, Wilson, et all, 

It may sound strange requiring only non-volatile RAM, It does not mean
that the box has no volatile RAM.
The intention is that all entries created in this table will persist if
CMTS reboots. For an operator POV non-persistent entries in the
subcriber Management tables are unlikely. 

It may lead to a simplified management policy to maintain an even CMTS
configuration across the system under the premise of long time btw
reboots in CMTSes which handles a local configuration, rather than a
centralized boot process. 

That's not far from the RFC 3289 requirement itself in all objects.
e.g
    OBJECT       diffServDataPathStorage
    MIN-ACCESS   read-only
    DESCRIPTION
       "Write access is not required."

The above COMPLIANCE combined with DEFVAL 'nonVolatile', I believe means
a CLI propietary configuration management and the MIB as only a
reporting tool.

In the other side to move to a more active SNMP configuration, I believe
the Author (Wilson) is extending the origina subscriber management
intention to the DIFF-SERV related tables. 

What is not clear to me is combining both MIB compliances, 
Does DOCS-IETF-SUBMGT-MIB  COMPLIANCE statements clearly overrides the
RFC3289 ? Instead of compliemnt then ?

A Compliance from subscriber Management 

( the above should be the requirement ) 

A Wrong combined COMPLIANCE interpretation for Subscriber Management

 OBJECT diffServDataPathStorage
       SYNTAX StorageType { nonVolatile(3) }
       MIN-ACCESS read-only 
       DESCRIPTION
           "An implementation is only required to support nonvolatile
            storage.Write access is not required."

Proposed edits:
Remove the comments : "-- same as RFC3289"
Could be confusing...

Compare 

RFC 3289
   OBJECT       diffServAlgDropStatus
    SYNTAX       RowStatus { active(1) }
    MIN-ACCESS   read-only
    DESCRIPTION
       "Write access is not required, and active is the only status that
       needs to be supported."

SUBMGT-MIB
   OBJECT diffServAlgDropStatus  -- same as RFC3289
       SYNTAX RowStatus { active(1) }
       WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
       DESCRIPTION
           "Support for createAndWait and notInService is not required."

   docsSubMgtBasicCompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for CMTS devices that implement
       CMTS centric subscriber management. This COMPLIANCES are
       required rather than RFC3289 "

Eduardo

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Monday, September 15, 2003 6:59 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] FW: Sanity check on StorageType

FYI

Thanks,
Bert 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]]
Sent: maandag 15 september 2003 13:20
To: Wijnen, Bert (Bert)
Cc: Mreview (E-mail)
Subject: Re: Sanity check on StorageType

On Sat, Sep 13, 2003 at 10:34:58PM +0200, Wijnen, Bert (Bert) wrote:

> in document draft-ietf-ipcdn-subscriber-mib-12.txt you will find (in 
> the MODULE-COMPLIANCE):
> 
> I have my doubts. There is nothing illegal here, but it feels strange 
> to me, no?

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
Germany

---

From: [email-masked]
Date: Mon, 15 Sep 2003 17:02:00 +0000

Eduardo - my understanding is that the compliance statements are independent: 
an implementation may claim submgt compliance, RFC3289 compliance, or both.

I suspect that RFC3289 compliance may be a gimme if the device meets submgt 
compliance, but I don't think we really care. I would be surprised, for 
example, if CableLabs would want to test for diffServMIBCompliances.

The submgt mib includes compliance statements referencing 3289 objects because 
the diffServMIBCompliances are not strong enough to support the required 
submgt management functions.

I included the "--same as RFC3289" comments because the two compliance 
statements are not assumed to be combined: submgt has to stand on its own. For 
the particular "same as" objects, I thought it helpful to indicate that submgt 
wasn't carving out special exemptions for these objects, just propagating them 
from 3289 where they made sense.

Regards,
Wilson

---

From: "Eduardo Cardona" <[email-masked]>
Date: Mon, 15 Sep 2003 11:40:20 -0600

Wilson, 

Thanks for the clarification, Sorry I overlooked the two sections in
diff-serv MIB diffServMIBReadOnlyCompliance vs
diffServMIBFullCompliance,

Thanks

Eduardo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, September 15, 2003 11:02 AM
To: Eduardo Cardona
Cc: Wijnen, Bert (Bert); Ipcdn (E-mail)
Subject: RE: [ipcdn] FW: Sanity check on StorageType

Eduardo - my understanding is that the compliance statements are
independent: 
an implementation may claim submgt compliance, RFC3289 compliance, or
both.

I suspect that RFC3289 compliance may be a gimme if the device meets
submgt 
compliance, but I don't think we really care. I would be surprised, for 
example, if CableLabs would want to test for diffServMIBCompliances.

The submgt mib includes compliance statements referencing 3289 objects
because 
the diffServMIBCompliances are not strong enough to support the required

I included the "--same as RFC3289" comments because the two compliance 
statements are not assumed to be combined: submgt has to stand on its
own. For 
the particular "same as" objects, I thought it helpful to indicate that
submgt 
wasn't carving out special exemptions for these objects, just
propagating them 
from 3289 where they made sense.

Regards,
Wilson

> that the box has no volatile RAM. The intention is that all entries 
> created in this table will persist if CMTS reboots. For an operator 
> POV non-persistent entries in the subcriber Management tables are 
> unlikely.
> 

> The above COMPLIANCE combined with DEFVAL 'nonVolatile', I believe 
> means a CLI propietary configuration management and the MIB as only a 
> reporting tool.
> 
> In the other side to move to a more active SNMP configuration, I 
> believe the Author (Wilson) is extending the origina subscriber 
> management intention to the DIFF-SERV related tables.
> 
> 
> > strange