Subject: RE: [Entmib] entity mib support for tcif

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sun, 7 Sep 2003 20:25:37 +0200

Or..., the DESCRIPTION clause could say that all zeroes for
the DateAndTime would mean 
"manufacture date unknown or nor supported"

Just thinking aloud here.

By the way, I believe that most of us are on entmib or atommib 
lists, so I have trimmed all the people names (except whom I responded to).
I have bcc:-ed you all this time, so you can spoeak up if my
assumtion is incorrect.

But even 2 mailing lists... can we move this to one list for now?

Thanks,
Bert 

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: zondag 7 september 2003 11:06
> To: Kaj Tesink; [email-masked]
> Cc: C. M. Heard; Giamboi, Anthony; Lam, Hing-Kam (Kam); Wijnen, Bert
> (Bert); [email-masked]; Faye Ly
> Subject: RE: [Entmib] entity mib support for tcif
> 
> 
> 
> If this proposal is adopted, it looks like we need a 
> DateAndTimeOrNul TC, for these systems that do not support 
> manufacture date for some reason. 
> 
> Dan
> 
> > 
> > entPhysicalMfgDate   OBJECT-TYPE
> >       SYNTAX      DateAndTime
> >       MAX-ACCESS  read-only
> >       STATUS      current
> >       DESCRIPTION
> >               "The manufacturing date for the physical entity."
> >       ::= { entPhysicalEntry xx }
> 

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

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 7 Sep 2003 13:24:57 -0700 (PDT)

>>>>> On Sun, 7 Sep 2003, Romascanu, Dan (Dan) wrote:
Dan> If this proposal is adopted, it looks like we need a
Dan> DateAndTimeOrNul TC, for these systems that do not support
Dan> manufacture date for some reason.
Dan> 
Dan> Dan
Dan> 
Dan> > 
Dan> > entPhysicalMfgDate   OBJECT-TYPE
Dan> >       SYNTAX      DateAndTime
Dan> >       MAX-ACCESS  read-only
Dan> >       STATUS      current
Dan> >       DESCRIPTION
Dan> >               "The manufacturing date for the physical entity."
Dan> >       ::= { entPhysicalEntry xx }

Using a special value (e.g., a zero-length OCTER STRING) to represent
"no date" is one way.  Another is just not to instantiate the object.
Since a manager would have to deal with that anyway (existing 
implementations don't support this object), maybe that's the
simplest approach.

>>>>> On Sun, 7 Sep 2003, Wijnen, Bert (Bert) replied:
Bert> Or..., the DESCRIPTION clause could say that all zeroes for
Bert> the DateAndTime would mean 
Bert> "manufacture date unknown or nor supported"
Bert> 
Bert> Just thinking aloud here.

It seems to me that this would conflict with the DateAndTime
DESCRIPTION clause in RFC 2579.

Bert> By the way, I believe that most of us are on entmib or atommib
Bert> lists, so I have trimmed all the people names (except whom I
Bert> responded to). I have bcc:-ed you all this time, so you can
Bert> spoeak up if my assumtion is incorrect.
Bert> 
Bert> But even 2 mailing lists... can we move this to one list for now?

Indeed, I think there is a practical reason to avoid long lists of
addresses in the To: and Cc: fields -- the spam filters for the
lists hosted as ietf.org seem to be trapping such messages as
potential spam.  When that happens it results in moderation delays,
which inhibits the discussion;  indeed, several messages from this
thread seem to be sitting in the entmib moderation queue as we
speak, and I suspect this as the cause.  If this message makes it to
the entmib list without delay, thereby confirming my suspicions, I
suggest that we trim down the To: and Cc: lists and send the
messages to [email-masked] only.

Thanks,

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 7 Sep 2003 13:24:57 -0700 (PDT)

Thanks,

Mike

---

From: Andy Bierman <[email-masked]>
Date: Sun, 07 Sep 2003 13:37:51 -0700

>DESCRIPTION clause in RFC 2579.

yes, some fields do not allow the value zero.

>messages to [email-masked] only.

thanks for pointing this out.  I run the entmib list
and I try to check the queue once a day.  Messages are
blocked for too many recipients and also messages posted
by non-members of the list.

>Mike

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Sep 2003 12:05:36 +0300

If this proposal is adopted, it looks like we need a DateAndTimeOrNul TC, for these systems that do not support manufacture date for some reason. 

Dan

---

From: Andy Bierman <[email-masked]>
Date: Sun, 07 Sep 2003 13:37:51 -0700

Andy

---

From: Kaj Tesink <[email-masked]>
Date: Mon, 08 Sep 2003 10:12:32 -0400

>implementations don't support this object), maybe that's the

thats was my thinking too & the reason why i didnt write that
case in the DESCRIPTION

kaj

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. Inc.
331 Newman Springs Road
Red Bank, NJ 07701
Email: [email-masked]
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Sep 2003 17:10:29 +0200

> DESCRIPTION clause in RFC 2579.

While true, it is existing practice in other MIB modules to use
'0000000000000000'H as a NULL value and I personally consider not
allowing this special value an oversight in the SMIv2 revision.

/js

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Sep 2003 17:10:29 +0200

/js

---

From: Kaj Tesink <[email-masked]>
Date: Mon, 08 Sep 2003 10:12:32 -0400

kaj

Kaj Tesink