From ipcdn-admin@ietf.org Fri Aug 10 03:14:29 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00225; Fri, 10 Aug 2001 03:14:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12365; Fri, 10 Aug 2001 03:15:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12343 for ; Fri, 10 Aug 2001 03:15:01 -0400 (EDT) Received: from ns.intelenet.net (mailhost.intelenet.net [207.38.45.138]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00215 for ; Fri, 10 Aug 2001 03:13:53 -0400 (EDT) Received: from kbook (c783252-a.boulder1.co.home.com [24.255.131.229]) by ns.intelenet.net (8.9.3/8.9.3) with SMTP id AAA00409; Fri, 10 Aug 2001 00:14:55 -0700 (PDT) From: "Kaz Ozawa" To: "Nakanishi, Greg \(SD-EX\)" , "DOCSIS OSS Mailing List" , "DOCSIS Security Mailing List" Cc: "IETF Ipcdn" Date: Fri, 10 Aug 2001 01:13:34 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE204AD65AC@ntas0027.gi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Transfer-Encoding: 7bit Subject: [ipcdn] RE: Time Offset for docsBpi2Code*AccessStart in BPI+ MIB Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Greg, I see your point. Probably we can allow any time offset value because there is no ambiguity as long as the time offset is specified. However, as you pointed out, we should specify if the 8-octet format without time offset is either the local time or the GMT. If there is not a text "... value referenced to Greenwich Mean Time (GMT)", there is no doubt that it's local time. But why this text is necessary if the 8-octet format is the local time? Therefore, I believe the 8-octet format should be GMT as long as the above text is in the description. On the other hand, other objects with DateAndTime syntax such as docsDevDateTime, docsBpi*Expires* are local time if they are 8-octet format. It may make sense to remove the portion "referenced to Greenwich Mean Time (GMT)" from the description and show the local time in the 8-octet format. If the CM want to use the GMT, it can use the 11-octet format with the time offset "+0:0". Any comments? BTW, I found my email on the same topic sent to IETF ipcdn mailing list on 5/25. At that time, I did not receive any comments. I am forwarding this email to ipcdn mailing list again to hear the opinion of the people on the list. Thanks, kaz > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > (SD-EX) > Sent: Thursday, August 09, 2001 12:35 PM > To: 'Kaz Ozawa'; DOCSIS OSS Mailing List; DOCSIS Security Mailing List > Subject: RE: Time Offset for docsBpi2Code*AccessStart in BPI+ MIB > > > Kaz, > > I interpret ".... value referenced to Greenwich Mean Time (GMT)." to mean > that GMT can be determined from the date/time value stored in the mib > object. The important thing is that GMT can be determined so that the CM > can properly compare the accessStartTime with the validity start in the CVC. > > To me it is OK for the CM to store the date/time as "local time" in the mib > object, so long as the offset is also stored to be able to determine GMT. > > That said, I think any 11-octet format (i.e. date/time + offset) should be > valid. > > On the other hand, the 8-octet format is ambiguous because without the > offset you don't know what time zone is represented by the date/time. > Hence, no reference to GMT. > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Wednesday, August 08, 2001 9:07 AM > > To: DOCSIS OSS Mailing List; DOCSIS Security Mailing List > > Subject: Time Offset for docsBpi2Code*AccessStart in BPI+ MIB > > > > > > In the BPI+ MIB (draft-ietf-ipcdn-bpiplus-mib-05.txt), there are 4 > > MIB objects which show the AccesStart time value used for the DOCSIS > > BPI+ Secure Software Downloading. > > > > docsBpi2CodeMfgCodeAccessStart > > docsBpi2CodeMfgCvcAccessStart > > docsBpi2CodeCoSignerCodeAccessStart > > docsBpi2CodeCoSignerCvcAccessStart > > > > In the description of these 4 objects, it reads ".... value > > referenced > > to Greenwich Mean Time (GMT)." Therefore, the 8-octets Octet String > > without offset and the 11-octets Octet String with offset "+0:0" (or > > "-0:0"?) are correct but I think all the other cases (ex. 11-octet > > Octet String with offset "-6:0" for MDT) are not correct. Should we > > add clarification to these descriptions? > > > > Thanks, > > kaz > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Fri Aug 10 03:14:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00241; Fri, 10 Aug 2001 03:14:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12318; Fri, 10 Aug 2001 03:14:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA12299 for ; Fri, 10 Aug 2001 03:14:50 -0400 (EDT) Received: from ns.intelenet.net (mailhost.intelenet.net [207.38.45.138]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00212 for ; Fri, 10 Aug 2001 03:13:42 -0400 (EDT) Received: from kbook (c783252-a.boulder1.co.home.com [24.255.131.229]) by ns.intelenet.net (8.9.3/8.9.3) with SMTP id AAA00401; Fri, 10 Aug 2001 00:14:48 -0700 (PDT) From: "Kaz Ozawa" To: "Daniel Hegglin" , "Docsis-Sec" Cc: "IETF Ipcdn" , "DOCSIS OSS Mailing List" Date: Fri, 10 Aug 2001 01:13:27 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Transfer-Encoding: 7bit Subject: [ipcdn] RE: TEK Reset Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Dan, You are right. We have to cover both BPI+ mode and BPI mode. By the way, in BPI mode, I think the BPI spec does not prohibit the CMTS from generating two key at the same time. If this is correct, probably we don't need to specify the number of keys. How about the followings. Setting this object to TRUE causes the CMTS to invalidate all current active TEK(s) and to generate new TEK(s) for the associated SAID. The CMTS MAY also generate an unsolicited TEK Invalid message, to optimize the TEK synchronization between the CMTS and the CM. Reading this object always returns FALSE." This time, I am forwarding this email to docsis-oss and IETF ipcdn mailing list because the BPI+ MIB should be updated by issuing the new Internet Draft in the ipcdn working group. Thanks, kaz > -----Original Message----- > From: owner-docsis-sec@cablelabs.com > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Daniel Hegglin > Sent: Thursday, August 02, 2001 10:37 AM > To: Kaz Ozawa; Docsis-Sec > Subject: RE: TEK Reset > > > I believe this description isn't quite correct either since we manage BPI > modems as well using the BPI+ MIBs on the CMTS. How about this: > > Setting this object to TRUE causes the CMTS to invalidate the current active > TEK(s). For modems running in BPI+ mode, the CMTS MUST generate 2 new TEKs > for the associated SAID. For modems running in BPI mode, the CMTS MUST > generate only 1 new TEK for the associated SAID. The CMTS MAY also generate > an unsolicited TEK Invalid message to optimize the TEK synchronization > between the CMTS and the CM. Reading this object always returns FALSE. > > thanks, > dan > > > Daniel Hegglin > Riverstone Networks > 5200 Great America Parkway > Santa Clara, CA 95054 > (408) 878-6526 - work > (925) 216-8137 - cell > (925) 736-4474 - home office > http://www.riverstonenet.com/ > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Wednesday, August 01, 2001 8:23 PM > > To: Daniel Hegglin; Docsis-Sec > > Subject: RE: TEK Reset > > > > > > Hi Dan, > > > > Sorry for a very late reply. > > Yes, you are right and we should update the description. > > How about the followings? > > > > Setting this object to TRUE causes the CMTS to invalidate the current > > active TEKs and to generate two new TEK for the associated SAID; the > > CMTS MAY also generate an unsolicited TEK Invalid message, to optimize > > the TEK synchronization between the CMTS and the CM. Reading this > > object always returns FALSE." > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Daniel Hegglin > > > Sent: Thursday, June 28, 2001 4:51 PM > > > To: Docsis-Sec > > > Subject: TEK Reset > > > > > > > > > > > > The mib object docsBpi2CmtsTEKReset has the following description: > > > > > > Setting this object to TRUE causes the CMTS to > > > invalidate the current active TEK(s) (plural due to key > > > transition periods), and to generate a new TEK for the > > > associated SAID; the CMTS MAY also generate an unsolicited > > > TEK Invalid message, to optimize the TEK synchronization > > > between the CMTS and the CM. Reading this object always > > > returns FALSE. > > > > > > However, the BPI+ spec sais that we must always hold 2 active > > TEKs, which > > > means after resetting the TEKs, we will need to create 2 new > > TEKs for the > > > SAID. Should the mib be changed to reflect the new > > requirements for BPI+? > > > > > > dan > > > > > > > > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Fri Aug 10 13:08:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08393; Fri, 10 Aug 2001 13:08:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA26004; Fri, 10 Aug 2001 13:06:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25977 for ; Fri, 10 Aug 2001 13:06:48 -0400 (EDT) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08358 for ; Fri, 10 Aug 2001 13:05:38 -0400 (EDT) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01K6YR2TZNW4EZO8U9@GI.COM> for ipcdn@ietf.org; Fri, 10 Aug 2001 10:05:29 PDT Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Aug 2001 10:01:15 -0400 Content-return: allowed Date: Fri, 10 Aug 2001 13:05:04 -0400 From: "Nakanishi, Greg (SD-EX)" To: "'Kaz Ozawa'" , DOCSIS OSS Mailing List , DOCSIS Security Mailing List Cc: IETF Ipcdn Message-id: <97DEDE66B3DCD11199D200805FA71BE204AD65B1@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Subject: [ipcdn] RE: Time Offset for docsBpi2Code*AccessStart in BPI+ MIB Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Kaz, I think it is better to be consistent in the interpretation of the 8-octet format. That is, an 8-octet format is always interpreted as "local time". I believe this is the interpretation per RFC 2579. Having the 8-octet format be either local time or GMT depending on which MIB object it is, only leads to confusion, IMHO. Unless an operator knows the spec, he/she will not know whether the time in the mib object is local or GMT. Since the ToD server gives GMT time to the CM, there shouldn't be any reason that the CM couldn't always use the 11-octet format. greg > -----Original Message----- > From: Kaz Ozawa [mailto:kaz@pobox.com] > Sent: Friday, August 10, 2001 12:14 AM > To: Nakanishi, Greg (SD-EX); DOCSIS OSS Mailing List; DOCSIS Security > Mailing List > Cc: IETF Ipcdn > Subject: RE: Time Offset for docsBpi2Code*AccessStart in BPI+ MIB > > > Greg, > > I see your point. Probably we can allow any time offset value > because there > is no ambiguity as long as the time offset is specified. > However, as you > pointed out, we should specify if the 8-octet format without > time offset is > either the local time or the GMT. If there is not a text "... value > referenced to Greenwich Mean Time (GMT)", there is no doubt > that it's local > time. But why this text is necessary if the 8-octet format is > the local > time? Therefore, I believe the 8-octet format should be GMT > as long as the > above text is in the description. > > On the other hand, other objects with DateAndTime syntax such as > docsDevDateTime, docsBpi*Expires* are local time if they are > 8-octet format. > It may make sense to remove the portion "referenced to > Greenwich Mean Time > (GMT)" from the description and show the local time in the > 8-octet format. > If the CM want to use the GMT, it can use the 11-octet format > with the time > offset "+0:0". > > Any comments? > > BTW, I found my email on the same topic sent to IETF ipcdn > mailing list on > 5/25. At that time, I did not receive any comments. I am > forwarding this > email to ipcdn mailing list again to hear the opinion of the > people on the > list. > > Thanks, > kaz > > > -----Original Message----- > > From: owner-docsis-sec@cablelabs.com > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > (SD-EX) > > Sent: Thursday, August 09, 2001 12:35 PM > > To: 'Kaz Ozawa'; DOCSIS OSS Mailing List; DOCSIS Security > Mailing List > > Subject: RE: Time Offset for docsBpi2Code*AccessStart in BPI+ MIB > > > > > > Kaz, > > > > I interpret ".... value referenced to Greenwich Mean Time > (GMT)." to mean > > that GMT can be determined from the date/time value stored > in the mib > > object. The important thing is that GMT can be determined > so that the CM > > can properly compare the accessStartTime with the validity > start in the CVC. > > > > To me it is OK for the CM to store the date/time as "local > time" in the mib > > object, so long as the offset is also stored to be able to > determine GMT. > > > > That said, I think any 11-octet format (i.e. date/time + > offset) should be > > valid. > > > > On the other hand, the 8-octet format is ambiguous because > without the > > offset you don't know what time zone is represented by the > date/time. > > Hence, no reference to GMT. > > > > greg > > > > > -----Original Message----- > > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > > Sent: Wednesday, August 08, 2001 9:07 AM > > > To: DOCSIS OSS Mailing List; DOCSIS Security Mailing List > > > Subject: Time Offset for docsBpi2Code*AccessStart in BPI+ MIB > > > > > > > > > In the BPI+ MIB (draft-ietf-ipcdn-bpiplus-mib-05.txt), > there are 4 > > > MIB objects which show the AccesStart time value used for > the DOCSIS > > > BPI+ Secure Software Downloading. > > > > > > docsBpi2CodeMfgCodeAccessStart > > > docsBpi2CodeMfgCvcAccessStart > > > docsBpi2CodeCoSignerCodeAccessStart > > > docsBpi2CodeCoSignerCvcAccessStart > > > > > > In the description of these 4 objects, it reads ".... value > > > referenced > > > to Greenwich Mean Time (GMT)." Therefore, the 8-octets > Octet String > > > without offset and the 11-octets Octet String with offset > "+0:0" (or > > > "-0:0"?) are correct but I think all the other cases (ex. > 11-octet > > > Octet String with offset "-6:0" for MDT) are not correct. > Should we > > > add clarification to these descriptions? > > > > > > Thanks, > > > kaz > > > > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Wed Aug 15 20:13:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03411; Wed, 15 Aug 2001 20:13:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21936; Wed, 15 Aug 2001 20:13:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA21913 for ; Wed, 15 Aug 2001 20:13:57 -0400 (EDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03405 for ; Wed, 15 Aug 2001 20:12:44 -0400 (EDT) Received: from kbook ([10.252.0.199]) by ondar.cablelabs.com (8.10.1/8.10.1) with SMTP id f7G0DO122396; Wed, 15 Aug 2001 18:13:25 -0600 (MDT) From: "Kaz Ozawa" To: "Nakanishi, Greg \(SD-EX\)" , "DOCSIS OSS Mailing List" , "DOCSIS Security Mailing List" Cc: "IETF Ipcdn" Subject: RE: [ipcdn] RE: Time Offset for docsBpi2Code*AccessStart in BPI+ MIB Date: Wed, 15 Aug 2001 18:12:04 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE204AD65B1@ntas0027.gi.com> Importance: Normal X-Approved: ondar Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org Content-Transfer-Encoding: 7bit Greg, I agree with your point. In the definition of DateAndTime in RFC 1903, it reads "if only local time is known, then timezone information (field 8-10) is not present". (Note that "field 8-10" are 9-11th octets of the value.) Then I would like to know if everyone can agree to change the descriptions for four of docsBpi2Code*AccessStart objects from "The value of this object is .... value referenced to Greenwich Mean Time (GMT)." to "The value of this object is .... value. If the timezone information (9-11th octets) is not present, the value is the local time." (That is, remove "referenced to ... (GMT)" and add one sentence.) This change should be incorporated in the next Internet Draft. Thanks, kaz > -----Original Message----- > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > Nakanishi, Greg (SD-EX) > Sent: Friday, August 10, 2001 11:05 AM > To: 'Kaz Ozawa'; DOCSIS OSS Mailing List; DOCSIS Security Mailing List > Cc: IETF Ipcdn > Subject: [ipcdn] RE: Time Offset for docsBpi2Code*AccessStart in BPI+ > MIB > > > Kaz, > > I think it is better to be consistent in the interpretation of the 8-octet > format. That is, an 8-octet format is always interpreted as "local time". > I believe this is the interpretation per RFC 2579. > > Having the 8-octet format be either local time or GMT depending on which MIB > object it is, only leads to confusion, IMHO. Unless an operator knows the > spec, he/she will not know whether the time in the mib object is local or > GMT. > > Since the ToD server gives GMT time to the CM, there shouldn't be any reason > that the CM couldn't always use the 11-octet format. > > greg > > > -----Original Message----- > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > Sent: Friday, August 10, 2001 12:14 AM > > To: Nakanishi, Greg (SD-EX); DOCSIS OSS Mailing List; DOCSIS Security > > Mailing List > > Cc: IETF Ipcdn > > Subject: RE: Time Offset for docsBpi2Code*AccessStart in BPI+ MIB > > > > > > Greg, > > > > I see your point. Probably we can allow any time offset value > > because there > > is no ambiguity as long as the time offset is specified. > > However, as you > > pointed out, we should specify if the 8-octet format without > > time offset is > > either the local time or the GMT. If there is not a text "... value > > referenced to Greenwich Mean Time (GMT)", there is no doubt > > that it's local > > time. But why this text is necessary if the 8-octet format is > > the local > > time? Therefore, I believe the 8-octet format should be GMT > > as long as the > > above text is in the description. > > > > On the other hand, other objects with DateAndTime syntax such as > > docsDevDateTime, docsBpi*Expires* are local time if they are > > 8-octet format. > > It may make sense to remove the portion "referenced to > > Greenwich Mean Time > > (GMT)" from the description and show the local time in the > > 8-octet format. > > If the CM want to use the GMT, it can use the 11-octet format > > with the time > > offset "+0:0". > > > > Any comments? > > > > BTW, I found my email on the same topic sent to IETF ipcdn > > mailing list on > > 5/25. At that time, I did not receive any comments. I am > > forwarding this > > email to ipcdn mailing list again to hear the opinion of the > > people on the > > list. > > > > Thanks, > > kaz > > > > > -----Original Message----- > > > From: owner-docsis-sec@cablelabs.com > > > [mailto:owner-docsis-sec@cablelabs.com]On Behalf Of Nakanishi, Greg > > > (SD-EX) > > > Sent: Thursday, August 09, 2001 12:35 PM > > > To: 'Kaz Ozawa'; DOCSIS OSS Mailing List; DOCSIS Security > > Mailing List > > > Subject: RE: Time Offset for docsBpi2Code*AccessStart in BPI+ MIB > > > > > > > > > Kaz, > > > > > > I interpret ".... value referenced to Greenwich Mean Time > > (GMT)." to mean > > > that GMT can be determined from the date/time value stored > > in the mib > > > object. The important thing is that GMT can be determined > > so that the CM > > > can properly compare the accessStartTime with the validity > > start in the CVC. > > > > > > To me it is OK for the CM to store the date/time as "local > > time" in the mib > > > object, so long as the offset is also stored to be able to > > determine GMT. > > > > > > That said, I think any 11-octet format (i.e. date/time + > > offset) should be > > > valid. > > > > > > On the other hand, the 8-octet format is ambiguous because > > without the > > > offset you don't know what time zone is represented by the > > date/time. > > > Hence, no reference to GMT. > > > > > > greg > > > > > > > -----Original Message----- > > > > From: Kaz Ozawa [mailto:kaz@pobox.com] > > > > Sent: Wednesday, August 08, 2001 9:07 AM > > > > To: DOCSIS OSS Mailing List; DOCSIS Security Mailing List > > > > Subject: Time Offset for docsBpi2Code*AccessStart in BPI+ MIB > > > > > > > > > > > > In the BPI+ MIB (draft-ietf-ipcdn-bpiplus-mib-05.txt), > > there are 4 > > > > MIB objects which show the AccesStart time value used for > > the DOCSIS > > > > BPI+ Secure Software Downloading. > > > > > > > > docsBpi2CodeMfgCodeAccessStart > > > > docsBpi2CodeMfgCvcAccessStart > > > > docsBpi2CodeCoSignerCodeAccessStart > > > > docsBpi2CodeCoSignerCvcAccessStart > > > > > > > > In the description of these 4 objects, it reads ".... value > > > > referenced > > > > to Greenwich Mean Time (GMT)." Therefore, the 8-octets > > Octet String > > > > without offset and the 11-octets Octet String with offset > > "+0:0" (or > > > > "-0:0"?) are correct but I think all the other cases (ex. > > 11-octet > > > > Octet String with offset "-6:0" for MDT) are not correct. > > Should we > > > > add clarification to these descriptions? > > > > > > > > Thanks, > > > > kaz > > > > > > > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > http://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-admin@ietf.org Fri Aug 31 17:57:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16879; Fri, 31 Aug 2001 17:57:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25661; Fri, 31 Aug 2001 17:56:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25636 for ; Fri, 31 Aug 2001 17:56:24 -0400 (EDT) Received: from xchange.stargus.com (medusa.stargus.com [65.193.169.162]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16864 for ; Fri, 31 Aug 2001 17:55:02 -0400 (EDT) Received: from jason ([192.160.73.194]) by xchange.stargus.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 31 Aug 2001 17:49:02 -0400 Reply-To: From: "Jason Schnitzer" To: "Docsis-Oss" Cc: "Ipcdn" Date: Fri, 31 Aug 2001 17:48:58 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0010_01C13245.36208E40" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-OriginalArrivalTime: 31 Aug 2001 21:49:03.0019 (UTC) FILETIME=[BFDED7B0:01C13266] Subject: [ipcdn] USB-MIB-00 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IP over Cable Data Network X-BeenThere: ipcdn@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C13245.36208E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, For those having difficulty tracking down USB-MIB-00, a copy is attached. Does anyone know where to find the editor of this draft (Benjamin Dolnik, 3COM)? Though ID version 00 of this MIB is the current DOCSIS requirement, drafts 01, 02, and 03 have circulated in the past. Can anyone provide the history on this? Thanks, Jason ------=_NextPart_000_0010_01C13245.36208E40 Content-Type: application/octet-stream; name="USB-MIB-00" Content-Disposition: attachment; filename="USB-MIB-00" Content-Transfer-Encoding: 7bit -- extracted from draft-dolnik-usb-mib-00.txt -- at Sat May 13 07:07:14 2000 USB-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Integer32, experimental FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, MacAddress, TruthValue FROM SNMPv2-TC InterfaceIndexOrZero FROM IF-MIB; usbMib MODULE-IDENTITY LAST-UPDATED "200003010000Z" -- March 01, 2000 ORGANIZATION "3Com" CONTACT-INFO " Benjamin Dolnik Postal: 3Com Corporation 3800 Golf Road Rolling Meadows, IL 60008 USA Phone: +1 847 262 2098 E-mail: benjamin_dolnik@3com.com" DESCRIPTION "The MIB module to describe the USB interface." ::= { experimental 103 } -- Generic information usbMibObjects OBJECT IDENTIFIER ::= { usbMib 1 } usbNumber OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of ports regardless of their current state in the usb general port table" ::= { usbMibObjects 1 } -- -- usb Generic Port Table -- usbPortTable OBJECT-TYPE SYNTAX SEQUENCE OF UsbPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of port entries. The number of entries is given by the value usbNumber." ::= { usbMibObjects 2 } usbPortEntry OBJECT-TYPE SYNTAX UsbPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for the USB port." INDEX { usbPortIndex } ::= { usbPortTable 1 } UsbPortEntry ::= SEQUENCE { usbPortIndex Integer32, usbPortType INTEGER, usbPortRate INTEGER } usbPortIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The unique identifier of the USB port hardware. By convention and if possible, hardware port numbers map directly to external connectors." ::= { usbPortEntry 1 } usbPortType OBJECT-TYPE SYNTAX INTEGER { host(1), device(2), hub(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of the USB port" ::= { usbPortEntry 2 } usbPortRate OBJECT-TYPE SYNTAX INTEGER { low-speed (1), full-speed(2), high-speed(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The USB port rate that could be low-speed(1) for 1.5 Mbps, full-speed(2) for 12Mbps or high-speed(3) for USB 2.0" ::= { usbPortEntry 3 } -- -- usb Device MIB -- usbDeviceTable OBJECT-TYPE SYNTAX SEQUENCE OF UsbDeviceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of USB device ports. Usually the device has only one USB device port" ::= { usbMibObjects 3 } usbDeviceEntry OBJECT-TYPE SYNTAX UsbDeviceEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for the USB device port." INDEX { usbDeviceIndex } ::= { usbDeviceTable 1 } UsbDeviceEntry ::= SEQUENCE { usbDeviceIndex Integer32, usbDevicePower INTEGER, usbDeviceVendorID OCTET STRING, usbDeviceProductID OCTET STRING, usbDeviceNumberConfigurations Integer32, usbDeviceActiveClass INTEGER, usbDeviceStatus INTEGER, usbDeviceEnumCounter Counter32, usbDeviceRemoteWakeup TruthValue, usbDeviceRemoteWakeupOn TruthValue } usbDeviceIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The index is identical to usbPortIndex for the correspondent USB port" ::= { usbDeviceEntry 1 } usbDevicePower OBJECT-TYPE SYNTAX INTEGER { unknown(1), self-powered(2), bus-powered(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "the way USB device port is powered" ::= { usbDeviceEntry 2 } usbDeviceVendorID OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The USB device port vendor HEX-formatted string as it is provided to the USB host by the USB device" ::= { usbDeviceEntry 3 } usbDeviceProductID OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The product ID HEX-formatted string as it is provided to the USB host by the USB device" ::= { usbDeviceEntry 4 } usbDeviceNumberConfigurations OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of configurations the USB port supports. Device port should support at least one configuration" ::= { usbDeviceEntry 5 } usbDeviceActiveClass OBJECT-TYPE SYNTAX INTEGER { other(1), cdc(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "This object returns USB Device Class type of the active configuration" ::= { usbDeviceEntry 6 } usbDeviceStatus OBJECT-TYPE SYNTAX INTEGER { unattached(1), attached(2), powered(3), default(4), address(5), configured(6), suspended(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "Current status of the USB device state machine" ::= { usbDeviceEntry 7 } usbDeviceEnumCounter OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number reconnections (enumerations) since device is operational" ::= { usbDeviceEntry 8 } usbDeviceRemoteWakeup OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If set to true(1), the device supports Remote Wakeup function. If set to false(2), the device doesn't support it" ::= { usbDeviceEntry 9 } usbDeviceRemoteWakeupOn OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "If set to true(1), the remote wakeup function is activated by the host. If set to false(2), remote wakeup function is not active." ::= { usbDeviceEntry 10 } -- -- Table of the CDC interfaces -- usbCDCTable OBJECT-TYPE SYNTAX SEQUENCE OF UsbCDCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Communication Device Class (CDC) interfaces supported by the USB device. It could be more then one CDC interface for the device that expose more then one interface to the network" ::= { usbMibObjects 4 } usbCDCEntry OBJECT-TYPE SYNTAX UsbCDCEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for CDC device" INDEX { usbCDCIndex, usbCDCIfIndex } ::= { usbCDCTable 1 } UsbCDCEntry ::= SEQUENCE { usbCDCIndex Integer32, usbCDCIfIndex InterfaceIndexOrZero, usbCDCSubclass INTEGER, usbCDCVersion OCTET STRING, usbCDCDataTransferType INTEGER, usbCDCDataEndpoints Integer32, usbCDCStalls Counter32 } usbCDCIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The index is identical to usbPortIndex for the correspondent USB port" ::= { usbCDCEntry 1 } usbCDCIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The variable uniquely identifies the interface index which this CDC device is representing" ::= { usbCDCEntry 2 } usbCDCSubclass OBJECT-TYPE SYNTAX INTEGER { other(0), directLine(1), acm(2), telephony(3), multichannel(4), capi(5), ethernet(6), atm(7) } MAX-ACCESS read-only STATUS current DESCRIPTION "Subclass used in data transfer in Communication Device Class" REFERENCE "USB Class definitions for Communication Devices ver 1.1, p.28 " ::= { usbCDCEntry 3 } usbCDCVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only STATUS current DESCRIPTION "String that describes the version of Communication Device Class in HEX format (Major, Minor) " ::= { usbCDCEntry 4 } usbCDCDataTransferType OBJECT-TYPE SYNTAX INTEGER { synchronous(1), asynchronous(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Type of data transfer for Data Class Interface used by the Communication Device. Isochronious mode is used for synchronous(1) and bulk transfer mode is used for asynchronous(2)" ::= { usbCDCEntry 5 } usbCDCDataEndpoints OBJECT-TYPE SYNTAX Integer32 (0..16) MAX-ACCESS read-only STATUS current DESCRIPTION "Number of the data endpoints (IN and OUT) used by the Communication Device. If the networking device is in default interface setting, there are are no data endpoints and no traffic is exchanged. Under the normal operation there should be 2 Data Endpoints (one IN and one OUT) for the networking device. For the multichannel model this number could be larger then 2" ::= { usbCDCEntry 6 } usbCDCStalls OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of times USB Data interface recovered from stall since re-initialization and while the port state was 'up' or 'test'." ::= { usbCDCEntry 7 } -- -- Table of the CDC Ethernet-type interface or interface that uses -- Remote NDIS over Abstract Control Model -- usbCDCEtherTable OBJECT-TYPE SYNTAX SEQUENCE OF UsbCDCEtherEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of Communication Device Class (CDC) USB devices that support Ethernet Networking Control Model." ::= { usbMibObjects 5 } usbCDCEtherEntry OBJECT-TYPE SYNTAX UsbCDCEtherEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Status and parameter values for CDC devices that support Ethernet Networking Control Model" INDEX { usbCDCEtherIndex, usbCDCEtherIfIndex } ::= { usbCDCEtherTable 1 } UsbCDCEtherEntry ::= SEQUENCE { usbCDCEtherIndex Integer32, usbCDCEtherIfIndex InterfaceIndexOrZero, usbCDCEtherMacAddress MacAddress, usbCDCEtherPacketFilter BITS, usbCDCEtherDataStatisticsCapabilities BITS, usbCDCEtherDataCheckErrs Counter32 } usbCDCEtherIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "The index is identical to usbPortIndex for the correspondent USB port" ::= { usbCDCEtherEntry 1 } usbCDCEtherIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "The variable uniquely identifies the interface index to which this CDC device is connected " ::= { usbCDCEtherEntry 2 } usbCDCEtherMacAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The 48bit MAC address that is provided by USB CDC device to the host. This address will be used as the source address of Ethernet frames sent by the host over the particular CDC interface." ::= { usbCDCEtherEntry 3} usbCDCEtherPacketFilter OBJECT-TYPE SYNTAX BITS { packetPromiscuous(0), packetAllMulticast(1), packetDirected(2), packetBroadcast(3), packetMulticast(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "Bitmap indicates the host requirements to the USB device to perform Ethernet packet filtering of the particular type frames directed to the host" REFERENCE "USB Class definitions for Communication Devices ver 1.1, p.66 Table 62" ::= { usbCDCEtherEntry 4 } usbCDCEtherDataStatisticsCapabilities OBJECT-TYPE SYNTAX BITS { frameXmitOk(0), frameRcvOk(1), frameXmitErr(2), frameRcvErr(3), frameRcvNoBuff(4), bytesXmitDirectOk(5), framesXmitDirectOk(6), bytesXmitMulticastOk(7), framesXmitMulticastOk(8), bytesXmitBroadcastOk(9), framesXmitBroadcastOk(10), bytesRcvDirectOk(11), framesRcvDirectOk(12), bytesRcvMulticastOk(13), framesRcvMulticastOk(14), bytesRcvBroadcastOk(15), framesRcvBroadcastOk(16), framesRcvCrcErr(17), xmitQueueLen(18), rcvErrAlignment(19), xmitOneCollision(20), xmitMoreCollisions(21), xmitDeferred(22), xmitMaxCollision(23), rcvOverrun(24), xmitUnderrun(25), xmitHearbeatFailure(26), xmitTimesCrsLost(27), xmitLateCollisions(28) } MAX-ACCESS read-only STATUS current DESCRIPTION "Bitmap indicates the ability to collect Ethernet statistics of different types as it provided in Ethernet Networking Functional Descriptor. If the Particular bit is set, the device could provide the corresponding statistics counter to the host" REFERENCE "USB Class definitions for Communication Devices ver 1.1, p.46 Table 42" ::= { usbCDCEtherEntry 5 } usbCDCEtherDataCheckErrs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Total number of frames with an invalid frame check sequence, input from the USB Data interface since system re-initialization and while the port state was 'up' or 'test'." ::= { usbCDCEtherEntry 6 } usbCDCEtherXmtAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF UsbCDCEtherXmtAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains an entry for each multicast address for which the system will transmit packets/frames on a particular USB interface." ::= { usbMibObjects 5 } usbCDCEtherXmtAddressEntry OBJECT-TYPE SYNTAX UsbCDCEtherXmtAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of objects identifying an address for which the system will send packets/frames on the particular USB interface identified by the index values usbCDCIndex and ifIndex." INDEX {usbCDCEtherIndex, usbCDCEtherIfIndex, ifCDCEtherXmtAddress } ::= { usbCDCEtherXmtAddressTable 1 } UsbCDCEtherXmtAddressEntry ::= SEQUENCE { ifCDCEtherXmtAddress MacAddress } ifCDCEtherXmtAddress OBJECT-TYPE SYNTAX MacAddress MAX-ACCESS read-only STATUS current DESCRIPTION "An address for which the system will will send packets/frames on the particular USB interface. The address only could be set by the host by using the command for USB interface." ::= { usbCDCEtherXmtAddressEntry 1 } -- -- notification group is for future extension. -- usbMibNotification OBJECT IDENTIFIER ::= { usbMib 2 } usbMibConformance OBJECT IDENTIFIER ::= { usbMib 3 } usbMibCompliances OBJECT IDENTIFIER ::= { usbMibConformance 1 } usbMibGroups OBJECT IDENTIFIER ::= { usbMibConformance 2 } -- compliance statements usbMibBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for devices that implement USB MIB" MODULE -- usbMib -- unconditionally mandatory groups MANDATORY-GROUPS { usbMibBasicGroup } -- unconditionally mandatory group GROUP usbMibBasicGroup DESCRIPTION "Group of objects that are mandatory to support by device implementing this MIB" -- conditionally mandatory group GROUP usbMibCDCGroup DESCRIPTION "This group is implemented only in devices having at least one CDC interface" -- conditionally mandatory group GROUP usbMibCDCEtherGroup DESCRIPTION "This group is implemented only in devices having at least one CDC interface that uses Ethernet Networking Control Model or remote NDIS" -- conditionally mandatory group GROUP usbCDCEtherXmtAddressGroup DESCRIPTION "This group is implemented only for USB CDC interfaces that have transmit multicast filtering capabilities." ::= {usbMibCompliances 1} usbMibBasicGroup OBJECT-GROUP OBJECTS { usbNumber, usbPortIndex, usbPortType, usbPortRate, usbDeviceIndex, usbDevicePower, usbDeviceVendorID, usbDeviceProductID, usbDeviceNumberConfigurations, usbDeviceActiveClass, usbDeviceStatus, usbDeviceEnumCounter, usbDeviceRemoteWakeup, usbDeviceRemoteWakeupOn } STATUS current DESCRIPTION "Group of objects that are mandatory to support by device implementing this MIB" ::= { usbMibGroups 1 } usbMibCDCGroup OBJECT-GROUP OBJECTS { usbCDCIndex, usbCDCIfIndex, usbCDCSubclass, usbCDCVersion, usbCDCDataTransferType, usbCDCDataEndpoints, usbCDCStalls } STATUS current DESCRIPTION "This group is implemented only in devices having at least one CDC interface" ::= { usbMibGroups 2 } usbMibCDCEtherGroup OBJECT-GROUP OBJECTS { usbCDCEtherIndex, usbCDCEtherIfIndex, usbCDCEtherMacAddress, usbCDCEtherPacketFilter, usbCDCEtherDataStatisticsCapabilities, usbCDCEtherDataCheckErrs } STATUS current DESCRIPTION "This group is implemented only in devices having at least one CDC interface that uses Ethernet Networking Control Model or remote NDIS" ::= { usbMibGroups 3 } usbCDCEtherXmtAddressGroup OBJECT-GROUP OBJECTS { ifCDCEtherXmtAddress } STATUS current DESCRIPTION "This group is implemented only for USB CDC interfaces that have transmit multicast filtering capabilities." ::= { usbMibGroups 4 } END ------=_NextPart_000_0010_01C13245.36208E40-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org http://www1.ietf.org/mailman/listinfo/ipcdn