Subject: [Entmib] CONSENSUS CHECK: Undo entAliasMapping deprecation

From: Margaret Wasserman <[email-masked]>
Date: Fri, 6 Aug 2004 23:41:02 -0400

During the Entity MIB meeting at IETF 60 in San Diego, there was 
consensus in the room  for the following course of action:

(1) Pull the Entity State MIB document out of IESG processing 
(currently submitted for publication as a Draft Standard)

(2) Update the document to undo the deprecation of the 
entAliasMapping identifier, and

(3) Re-submit the Entity MIB to the IESG for publication as a 
Proposed Standard.

We now need to confirm this consensus on the mailing list.  Are there 
any objections to taking this course of action?  Other comments?

Thanks,
Margaret

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Aug 2004 10:20:53 +0200

> any objections to taking this course of action?  Other comments?

Sounds like a good plan to me. But if we recycle at Proposed, why do 
we then not simply put the entSupplPhysicalManufacturingDate and the
entSupplPhysicalManufacturerInfo objects into the entPhysicalEntry
where they actually belong? A new compliance statement would deal
with these additions so existing implementations that comply to
entity2Compliance would not be affected.

/js

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

---

From: Kaj Tesink <[email-masked]>
Date: Mon, 16 Aug 2004 10:01:41 -0400

>entity2Compliance would not be affected.

juergen, thanks for pointing this out.
makes a lot of sense & would work for me.

kaj

>/js

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
REACH INFO HAS CHANGED; NEW INFO PER 7/19/04:
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. Inc.
1 Telcordia Drive
Piscataway, NJ 08854-3923
Email: [email-masked]
Tel: (732) 699-6068
Fax: (732) 336-2336

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

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 16 Aug 2004 09:53:38 -0700

HI,

The below sounds like a good suggestion to me.

>entity2Compliance would not be affected.
Regards,
/david t. perkins

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 17 Aug 2004 11:06:10 -0700 (PDT)

> entity2Compliance would not be affected.

Let me add my voice to those supporting this idea.

Mike Heard

---

From: Kaj Tesink <[email-masked]>
Date: Tue, 17 Aug 2004 17:31:24 -0400

i've attached an update of the entity supplemental miblet.
the updates concern:
- change of the title
- inclusion of Juergen's suggested URN text & object
- reference to a to be published rfc for CLEI URN namespace

further actions:
- as per the emerging consensus, it is better to
    insert the two objects in the entPhysicalEntry
    of the entity mib itself; in that case all that is needed
    is to cut&paste from the attached
- we'll post the draft for the for CLEI URN namespace request soon
- any other comments?

kaj

Kaj Tesink

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Aug 2004 10:32:24 +0200

> - we'll post the draft for the for CLEI URN namespace request soon

Cutting and pasting text from your proposal, I came up with this
proposal for integration into the ENTITY-MIB itself:

entPhysicalMfgDate OBJECT-TYPE
    SYNTAX	DateAndTime
    MAX-ACCESS	read-only
    STATUS	current
    DESCRIPTION
	"The manufacturing date for the physical entity. The value
	 '0000000000000000'H should be returned if the manufacturing
	 date for a physical entity is unknown."
    ::= { entPhysicalEntry 17 }

entPhysicalMfgID OBJECT-TYPE
    SYNTAX	DisplayString
    MAX-ACCESS  read-write
    STATUS	current
    DESCRIPTION
	"This object contains additional identification information
         about the physical entity. The object contains URIs and 
	 therefore the syntax of this object must conform to RFC 
	 2396 section 2. Multiple URIs may be separated by white 
	 space characters.

	 This object contains a zero-length string if no additional
         identification information is known or supported about the
         physical entity."
    ::= { entPhysicalEntry 18 }

I think we should say something about when it is appropriate to write 
entPhysicalMfgId and to what extend it is required to provide write 
support for this object. In addition, we have to say something about 
the persistence of any modifications.

Note that I called the objects *MfgDate and *MfgId since we already
have entPhysicalMfgName and I propose to use null values in case a
value is unknown since that avoids holes in tables and seems to be
more consistent with the other objects in the entPhysicalTable.

/js

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 23 Aug 2004 12:29:21 -0400

Sounds reasonable to me.
dbh 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Juergen Schoenwaelder
Sent: Monday, August 16, 2004 4:21 AM
To: Margaret Wasserman
Cc: [email-masked]
Subject: Re: [Entmib] CONSENSUS CHECK: Undo entAliasMapping
deprecation

> (2) Update the document to undo the deprecation of the
entAliasMapping 
> identifier, and
Proposed 
> Standard.

Sounds like a good plan to me. But if we recycle at Proposed, why do
we then not simply put the entSupplPhysicalManufacturingDate and the
entSupplPhysicalManufacturerInfo objects into the entPhysicalEntry
where they actually belong? A new compliance statement would deal with
these additions so existing implementations that comply to
entity2Compliance would not be affected.

/js

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