Subject: RE: OSS-R-99031 technical objection

From: Gervais John <[email-masked]>
Date: Wed, 12 May 1999 12:52:22 -0500

I would like to propose adding the following two objects to the current
version of the Cable Device MIB for DOCSIS 1.0 ( and DOCSIS 1.1 ).  Please
let me know if there are any objections to the timing of this request or the
content of these objects.  If not, I can write an ECR or follow whatever
approved method there is.

docsDevSwOriginatingServer OBJECT-TYPE
         SYNTAX      IpAddress
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "The address of the TFTP server used during the last successful
              software upgrade.  If this device has not yet been
successfully
              upgraded since its manufacture, this object must read 0.0.0.0"
         ::= { docsDevSoftware 6 }
 
docsDevSwExecutingFilename OBJECT-TYPE
         SYNTAX      DisplayString (SIZE (0..64))
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "The file name of the software image currently executing on
              this device.  If this device has not yet been successfully
              upgraded since its manufacture or if otherwise unknown, 
              the string '(unknown)' is returned."
         ::= { docsDevSoftware 7 }

John Gervais, Thomson Consumer Electronics  (317)587-4227
[email-masked]

-----Original Message-----
From: Jason Schnitzer [mailto:[email-masked]]
Sent: Tuesday,May 11,1999 4:29 PM
To: 'Gervais John'
Cc: DOCSIS OSS Majordomo List
Subject: RE: OSS-R-99031 technical objection

Folks,

Great idea on the addition of two new MIB docsDevSoftware objects.

Mike, John, Bob, or Steve -- I'm looking forward to your proposal on the
ipcdn reflector :^)

Cheers,
Jason

> ----------
> From: 	Gervais John[SMTP:[email-masked]]
> Sent: 	Tuesday, May 11, 1999 7:16 AM
> To: 	'Michael W. Patrick'; [email-masked]
> Cc: 	[email-masked]
> Subject: 	RE: OSS-R-99031 technical objection
> 
> I concur completely with Mike ( I was just too lazy to reply ).  Adding a
> new object docsDevSwExecutingFilename would be the best solution.  In the
> interim, sysDesc and docsDevSwCurrVersion may provide the necessary
> information.
> 
> John Gervais, Thomson Consumer Electronics  (317)587-4227
> [email-masked]
> 
> 
> -----Original Message-----
> From: Michael W. Patrick [mailto:[email-masked]]
> Sent: Tuesday,May 11,1999 12:24 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: OSS-R-99031 technical objection
> 
> 
> Jason,
> 
> I'm afraid I still have a major issue with 99031.  
> 
> That is the language that the value of docsDevSwServer
> and docsDevSwFilename must "return" to their last
> good values if a download fails:
> 
>      "If the upgrade is unsuccessful, the value 
>      [of docsDevSwServer] MUST return immediately
>      to the address of the TFTP server used during
>      the last known successful upgrade."
> 
>      "..if the upgrade is unsuccessful, the value [of
>      docsDevSwFilename] MUST return immediately to the 
>      filename (fully qualified directory path name) of 
>      the image used during the last successful upgrade."
> 
> This is just an awkward attempt to store two different
> object values in one object name. The two different
> objects are:
> 
>      1) The -new- server/filename that is being attempted; and
> 
>      2) The -old- last successful server/filename.
> 
> The main technical problem with the ECR as written is
> that we LOSE the attempted server/filename after a failure.
> So an operator will not be able to investigate just what
> ip/filename was being attempted after it fails!
> 
> A lesser technical issue I have (mostly because NVRAM is so
> tight in my particular product) is that BOTH the "new" and
> "old" server&filename must be stored non-volatilely. That's because
> the "new" (i.e. in-progress) server&filename may have been
> SNMP-initiated, and so must be restarted after a reboot. 
> And if the re-started download fails, I have to restore the
> "old" good server&filename.  This should at least be clarified
> in the "Ramifications" section.
> 
> Of the two objects, the current MIB wording (attached) for
> docsDevSwServer and docsDevSwFilename makes it clear that they are
> intended as the "new" server/filename being attempted. 
> The ECR must also change the MIB description before it can be
> accepted, IMO.
> 
> While I understand the desire have MIB objects to represent
> the "currently running" server/filename, I disagree with the 
> overloading of this concept with the "requested" server/filename
> of docsDevSwServer and docsDevSwFilename.
> 
> I think we should keep objects named docsDevSwServer and docsDevSwFilename
> to mean only the "last requested" server/filename. They will represent
> the actual running server/filename only in the case where 
> docsDevSwOperStatus is completeFromProvisioning or
> completeFromManagement.  In the "failed" state
> of docsDevSwOperStatus, they contain the attempted server and
> filename failed.  In the "other" state, they are undefined.
> 
> I think we should add two NEW objects to represent the 
> server and filename of the currently operating image. 
> In the absence of these new objects, I think we can live
> with NOT knowing the currently running server/filename after
> a download failure.  After all, we have that "unknown" condition, too,
> when a modem is first shipped from the factory.
> 
> Hence, I vote NO to ECR 99031 as written.
> 
> Regards,
> mike
> 
> 
> 
> 
> 
> Appendix: MIB wording (RFI 06)
> 
> docsDevSwServer OBJECT-TYPE
>         SYNTAX      IpAddress
>         MAX-ACCESS  read-write
>         STATUS      current
>         DESCRIPTION
>             "The address of the TFTP server used for software upgrades."
>         ::= { docsDevSoftware 1 }
> 
> docsDevSwFilename OBJECT-TYPE
>         SYNTAX      DisplayString (SIZE (0..64))
>         MAX-ACCESS  read-write
>         STATUS      current
>         DESCRIPTION
>             "The file name of the software image to be loaded into this
>              device. Unless set via SNMP, this is the file name
>              specified by the provisioning server that corresponds to
>              the software version that is desired for this device.
>              If unknown, the string '(unknown)' is returned."
>         ::= { docsDevSoftware 2 }
> 
> 
> 
> 
> oss-r-99031
> 
> Comment Period Expires: 05/12/99
> 
> Name:                   Jason Schnitzer
> Company:                CableLabs (Shaw Communications)
> Address:                400 Centennial Parkway	
> City/State/Zip:         Louisville, CO 80027
> Phone:                  303-661-9100
> Fax:                    303-661-9199
> E-mail Address:         [email-masked]
> 
> Affected Documents:     SP-OSSI-RF-I03-990113
> 
> Section:
> 
> 2.2.2 Software upgrades
> 
> Problem Description:
> 
> The CM software upgrade process requires clarification. 
> 
> Proposed Change(s):
> 
> After paragraph 2, add:
> 
> "docsDevSwAdminStatus MUST persist across resets/reboots until 
> over-written from an SNMP manager or via the CM configuration file.  
> 
> The default state of docsDevSwAdminStatus MUST be allowProvisioning
> Upgrade(2) until it is over-written by ignoreProvisioningUpgrade(3) 
> following a successful SNMP initiated software upgrade.
> 
> docsDevSwOperStatus MUST persist across resets to report the outcome 
> of the last software upgrade attempt.
> 
> docsDevSwServer and docsDevSwFilename MUST persist across resets 
> and behave as follows:
> 
> - docsDevSwServer MUST return the address of the TFTP server 
>   the CM used during the last successful software upgrade. If 
>   docsDevSwServer is set via SNMP, it contains the IP address 
>   of the TFTP server the CM MUST use for SNMP initiated software 
>   upgrade. If the upgrade is unsuccessful, the value MUST return
>   immediately to the address to the TFTP server used during the 
>   last known successful upgrade.
> 
> - docsDevSwFilename MUST return the filename (fully qualified 
>   directory path name) of the image used during the last successful 
>   upgrade. If docsDevSwFilename is set via SNMP it returns 
>   the filename (fully qualified directory path name) of the software 
>   image intended for this device during upgrade. If the upgrade is 
>   unsuccessful, the value MUST return immediately to the filename 
>   (fully qualified directory path name) of the image used during 
>   the last successful upgrade.
> 
> - If these conditions do not apply, then docsDevSwServer MUST
>   display IP address 0.0.0.0 and docsDevSwFileName MUST return
>   "(unknown)".
> 
> If a CM suffers loss of power or resets during an SNMP initiated
> upgrade, the CM MUST resume the interrupted upgrade without 
> requiring manual intervention."
> 
> Change:
> 
> "Note that software upgrades should not be accepted blindly by
> the cable modem. The cable modem may refuse upgrade if:
> 
> - The download is incomplete.
> - The file contents are incomplete or damaged.
> - The software is not intended for that hardware device (may include
>   the case of a feature set that has not been purchased for this 
>   device)."
> 
> To:
> 
> "Note that software upgrades MUST not be accepted blindly by
> the cable modem. The processes defined in [MCNS7] for CM response 
> following software upgrade failure MUST be supported."
> 
> 
> Ramifications:
> 
> None
>

---

From: Guenter Roeck <[email-masked]>
Date: Wed, 12 May 1999 11:27:48 -0700

I would suggest to name the new objects
	docsDevSwUpdateServer
	docsDevSwUpdateFilename
[ or whatever is appropriate]

and use those objects to request a SW upgrade. The existing objects
would then be read-only and reflect the name and source of the current image.

Guenter

---

From: Guenter Roeck <[email-masked]>
Date: Wed, 12 May 1999 12:06:07 -0700

It does not overload a single object with both current and loading information.
With the new objects as defined below, you may need to check two objects 
to find out what the currently running image is, at least up to the first 
successful upgrade.

Another possibility would be to extend docsDevSwExecutingFilename 
to contain the currently executing image name even for factory installed 
images (assuming those also have a name, either on flash or built-in).

Anyway, just my thoughts. No need to start an argument about it.

Guenter

At 11:34 AM 5/12/99 -0700, Keller, Steve (SD-EX) wrote:
>	How is that better?
>	Steve Keller -- GI

---

From: Gervais John <[email-masked]>
Date: Wed, 12 May 1999 16:02:42 -0500

I think Guenter's suggestion is to modify the definition of existing
docsDevSwFilename and docsDevServer objects and to change my suggested
objects as shown below.  I agree... that this would make the object names
more self explanatory.

As far as extending the definition of the new (proposed) docsDevSwFilename
to include the name of a factory installed image, technically I like the
idea, but I'm sure we would screw it up and the filename would mismatch was
as actually loaded in the factory( via a proprietary method ).  But I've
reworded the objects to allow it.

docsDevSwServer OBJECT-TYPE
         SYNTAX      IpAddress
         MAX-ACCESS  read-only
         STATUS      current
         DESCRIPTION
             "The address of the TFTP server used during the last
              successful software upgrade.  If otherwise unknown, 
              0.0.0.0 is returned."
         ::= { docsDevSoftware 1 }
 
             this device.  If unknown, the string '(unknown)' is
             returned."

docsDevSwUpdateServer OBJECT-TYPE
         SYNTAX      IpAddress
         MAX-ACCESS  read-write
         STATUS      current
         DESCRIPTION
             "The address of the TFTP server used for the next proposed
              software upgrade."
         ::= { docsDevSoftware 6 }
 
docsDevSwUpdateFilename OBJECT-TYPE
        SYNTAX      DisplayString (SIZE (0..64))
         MAX-ACCESS  read-write
         STATUS      current
         DESCRIPTION
             "The file name of the proposed software image to be loaded
              into this device. Unless set via SNMP, this is the file
              name specified by the provisioning server that corresponds
              to the software version that is desired for this device.
              If unknown, the string '(unknown)' is returned."
         ::= { docsDevSoftware 7 }

-----Original Message-----
From: Guenter Roeck [mailto:[email-masked]]
Sent: Wednesday,May 12,1999 2:06 PM
To: Keller, Steve (SD-EX)
Cc: Gervais John; [email-masked]'; [email-masked]';
DOCSIS OSS Majordomo List
Subject: RE: OSS-R-99031 technical objection

It does not overload a single object with both current and loading
information.
With the new objects as defined below, you may need to check two objects 
to find out what the currently running image is, at least up to the first 
successful upgrade.

Guenter

At 11:34 AM 5/12/99 -0700, Keller, Steve (SD-EX) wrote:
>> >> I concur completely with Mike ( I was just too lazy to reply ).
Adding
>> a