Subject: RE: [Entmib] Re: Entity mib support for tcif

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 1 Apr 2004 08:30:50 -0500

hi

Where are we in this discussion? Have we decided whether the working group
wants to take this on?

This is a requirement I've heard bounced around a few times so I think this
is worth trying to address, but like Dan I have a few concerns with some
aspects of the proposed solution. As he has mentioned, the title is not
sufficiently descriptive. In addition, I think the data types might be too
opaque to be useful. 

Sharon
-----Original Message-----
From: Kaj Tesink [mailto:[email-masked]] 
Sent: Wednesday, February 11, 2004 10:25 AM
To: [email-masked]
Subject: RE: [Entmib] Re: Entity mib support for tcif

Hi Dan,

At 10:03 PM 2/10/2004 +0200, Romascanu, Dan (Dan) wrote:
>Kaj,
>
>I was among the ones who supported doing this work. I did not change my 
>mind.
>
>Two comments:
>1. I would like the title of the document to be more explicit about 
>what
>is really provided by this MIB. 'Supplemental' is really too generic a 
>title - what about something like 'Entity MIB Extensions for manufacturing 
>and physical modules identification'?

I see what you're trying to do. While this would more accurately reflect the
content, there is the issue of future compatibility. The problem with 
adding
new objects to MIBs over time is that
a) either you add to the original spec; but this means there's a problem
    with advancing the spec over time
b) or you define supplemental specs; the problem here is that you dont want
    all sorts of miblets around; you want to minimize the number So, similar
as what we did for ATM, and attempted for DS1s, the tactic was to use this
generic title, so that additional functions could still be added for a
while. I agree its not perfect. I also thought that in previous 
discussions
there were some thoughts about some additional functions(?).

>2. Some of the concerns expressed in the meeting (not by me) were 
>related
>to the availability and the proprietary nature of the CLEI codes. Can you 
>comment on these? Are the documents mentioned in the REFERENCE clause of 
>the cleiCode object freely available?

You're right, some of that did come up before.
My understanding is the following:
- the references point to documents by different standards groups,
   and i think are available for a small fee at www.atis.org
- CLEI codes are defined in those standards;
   Telcordia is the registrar to obtain an actual code
In previous discussion it was pointed out that
while CLEIs are in wide use, there is no obligation to
use them; I've tried to reflect that in the draft
in two ways: (a) use an opaque object instead of a dedicated object as
proposed by Dave, and (b) language for the case that the whole thing (no
CLEI nor any other application of the object) is not supported.

Kaj

>Thanks and Regards,
>
>Dan
>
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf 
> > Of Kaj Tesink
> > Sent: 10 February, 2004 6:48 PM
> > To: [email-masked]
> > Subject: Fwd: [Entmib] Re: Entity mib support for tcif
> >
> >
> > all,
> >
> > the draft i sent to the list last week is now available at 
> > http://www.ietf.org/internet-drafts/draft-tesink-entity-supplm
> > ib-00.txt
> >
> > pl note that the file name was changed (my error).
> > in order to move this forward the WG would need
> > to accept this as a formal work item.
> >
> > so we'd appreciate comments on
> > a) whether there is support/objection to do this work
> > b) any technical comments
> > while the minneapolis meeting already indicated some tentative 
> > support, restating this or any new/additional views would be helpful
> >
> > kaj
> >
> >
> >
> >
> > >X-Sender: [email-masked]
> > >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
> > >Date: Thu, 05 Feb 2004 15:06:54 -0500
> > >To: [email-masked]
> > >From: Kaj Tesink <[email-masked]>
> > >
> > >
> > >all,
> > >
> > >attached is the supplemental entity miblet
> > >discussed a while ago, supporting
> > >- manufacturing date
> > >- additional entity info
> > >the latter uses the method proposed by dave
> > >to convey information such as CLEIs.
> > >i do recall that there were some different
> > >views on whether to use an opaque encoding
> > >method versus using a dedicated object, but
> > >please read it over and provide any comments.
> > >
> > >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

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

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

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 1 Apr 2004 08:30:50 -0500

hi

Sharon
-----Original Message-----
From: Kaj Tesink [mailto:[email-masked]] 
Sent: Wednesday, February 11, 2004 10:25 AM
To: [email-masked]
Subject: RE: [Entmib] Re: Entity mib support for tcif

Hi Dan,

Kaj

Kaj Tesink

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 1 Apr 2004 12:56:45 -0500

hi

Apologies if this shows up twice, but I think it got lost.

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:0S00:EXCH] 
Sent: Thursday, April 01, 2004 8:31 AM
To: [email-masked]'
Subject: RE: [Entmib] Re: Entity mib support for tcif

hi

Sharon
-----Original Message-----
From: Kaj Tesink [mailto:[email-masked]] 
Sent: Wednesday, February 11, 2004 10:25 AM
To: [email-masked]
Subject: RE: [Entmib] Re: Entity mib support for tcif

Hi Dan,

Kaj

Kaj Tesink

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 1 Apr 2004 12:56:45 -0500

hi

Sharon

-----Original Message-----
From: Chisholm, Sharon [CAR:0S00:EXCH] 
Sent: Thursday, April 01, 2004 8:31 AM
To: [email-masked]'
Subject: RE: [Entmib] Re: Entity mib support for tcif

hi

Sharon
-----Original Message-----
From: Kaj Tesink [mailto:[email-masked]] 
Sent: Wednesday, February 11, 2004 10:25 AM
To: [email-masked]
Subject: RE: [Entmib] Re: Entity mib support for tcif

Hi Dan,

Kaj

Kaj Tesink

---

From: Kaj Tesink <[email-masked]>
Date: Fri, 02 Apr 2004 11:37:53 -0500

hi Sharon,

At 12:56 PM 4/1/2004 -0500, Sharon Chisholm wrote:

hi

Where are we in this discussion? Have we decided whether the working
group

wants to take this on?

i think that question is still pending;

we asked for input and expressions of interest well before the

last ietf meeting but there has not been much traffic on this

since that request. so let me repeat the request for input on this
spec:

http://www.ietf.org/internet-drafts/draft-tesink-entity-supplmib-00.txt

This is a requirement I've
heard bounced around a few times so I think this

is worth trying to address, but like Dan I have a few concerns with
some

aspects of the proposed solution. As he has mentioned, the title is
not

sufficiently descriptive. In addition, I think the data types might be
too

opaque to be useful.

as per my comments based on Dan's note, there were

some good reasons for the high level title, but

i'd be open to other suggestions.

as for the opaque object, the history is that

the initial proposal based on an octet string

syntax invoked a discussion about flexibility

and some other aspects, and resulted in a proposal

by Dave for the current opaque construct, although

some other comments expressed reservations (i believe

by Juergen and Dan).

i'm willing to go with whatever the rough consensus

dictates.

kaj

Sharon

-----Original Message-----

From: Kaj Tesink
[mailto:[email-masked]]

To: [email-masked]

Hi Dan,

>and physical modules identification'?

I see what you're trying to do. While this would more accurately reflect
the

adding

a) either you add to the original spec; but this means there's a
problem

b) or you define supplemental specs; the problem here is that you dont
want

all sorts of miblets around; you want to minimize the
number So, similar

as what we did for ATM, and attempted for DS1s, the tactic was to use
this

generic title, so that additional functions could still be added for
a

discussions

and i think are available for a small fee at
www.atis.org

in two ways: (a) use an opaque object instead of a dedicated object
as

proposed by Dave, and (b) language for the case that the whole thing
(no

Kaj

> > From: [email-masked]
[mailto:[email-masked]]On
Behalf

Kaj Tesink

331 Newman Springs Road

Red Bank, NJ 07701

Tel: (732) 758-5254

Fax: (732) 758-4177

Entmib mailing list

[email-masked]

Entmib mailing list

[email-masked]

Kaj Tesink

331 Newman Springs Road

Red Bank, NJ 07701

Tel: (732) 758-5254

Fax: (732) 758-4177

---

From: Kaj Tesink <[email-masked]>
Date: Fri, 02 Apr 2004 11:37:53 -0500

hi Sharon,

hi

wants to take this on?

opaque to be useful.

by Juergen and Dan).

dictates.

kaj

Sharon

-----Original Message-----

From: Kaj Tesink

To: [email-masked]

Hi Dan,

adding

discussions

Kaj

Kaj Tesink

331 Newman Springs Road

Red Bank, NJ 07701

Tel: (732) 758-5254

Fax: (732) 758-4177

Entmib mailing list

[email-masked]

Entmib mailing list

[email-masked]

Kaj Tesink

331 Newman Springs Road

Red Bank, NJ 07701

Tel: (732) 758-5254

Fax: (732) 758-4177

---

From: "Faye Ly" <[email-masked]>
Date: Fri, 9 Apr 2004 15:34:01 -0700

Hi,
 
Yes, we have a need for this MIB.  Any chance of getting this done?
 
-faye

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kaj Tesink
	Sent: Friday, April 02, 2004 8:38 AM
	To: Sharon Chisholm; [email-masked]
	Subject: [Entmib] Re: Entity mib support for tcif

	hi Sharon,

		hi
		
		Where are we in this discussion? Have we decided whether
the working group
		wants to take this on?

	i think that question is still pending;
	we asked for input and expressions of interest well before the
	last ietf meeting but there has not been much traffic on this
	since that request. so let me repeat the request for input on
this spec:

	

		This is a requirement I've heard bounced around a few
times so I think this
		is worth trying to address, but like Dan I have a few
concerns with some
		aspects of the proposed solution. As he has mentioned,
the title is not
		sufficiently descriptive. In addition, I think the data
types might be too
		opaque to be useful. 

	
	kaj

		Sharon
		-----Original Message-----
		From: Kaj Tesink [mailto:[email-masked]] 
		Sent: Wednesday, February 11, 2004 10:25 AM
		To: [email-masked]
		Subject: RE: [Entmib] Re: Entity mib support for tcif

		Hi Dan,
		
		>and physical modules identification'?

		I see what you're trying to do. While this would more
accurately reflect the
		content, there is the issue of future compatibility. The
problem with 
		adding
		new objects to MIBs over time is that
		a) either you add to the original spec; but this means
there's a problem
		    with advancing the spec over time
		b) or you define supplemental specs; the problem here is
that you dont want
		    all sorts of miblets around; you want to minimize
the number So, similar
		as what we did for ATM, and attempted for DS1s, the
tactic was to use this
		generic title, so that additional functions could still
be added for a
		while. I agree its not perfect. I also thought that in
previous 
		discussions
		there were some thoughts about some additional
functions(?).

		You're right, some of that did come up before.
		My understanding is the following:
		- the references point to documents by different
standards groups,
		   and i think are available for a small fee at
www.atis.org <http://www.atis.org/> 
		- CLEI codes are defined in those standards;
		   Telcordia is the registrar to obtain an actual code
		In previous discussion it was pointed out that
		while CLEIs are in wide use, there is no obligation to
		use them; I've tried to reflect that in the draft
		in two ways: (a) use an opaque object instead of a
dedicated object as
		proposed by Dave, and (b) language for the case that the
whole thing (no
		CLEI nor any other application of the object) is not
supported.
		
		Kaj

		
		> > From: [email-masked]
[mailto:[email-masked]]On <mailto:[email-masked]%5DOn>
Behalf 

		Kaj Tesink

		

	Kaj Tesink

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

---

From: Kaj Tesink <[email-masked]>
Date: Wed, 14 Apr 2004 19:01:31 -0400

At 03:34 PM 4/9/2004 -0700, Faye Ly wrote:

Hi,

Yes, we have a need for this
MIB.  Any chance of getting this done?

i think the following issues have been raised:

1. document title is too vague

2. opaque object is cumbersome to implement

3. acceptance as work item

1. document title is too vague:

current proposed title is:

Definitions of Supplemental Entity Managed Objects

the current contents of the MIB module is only two objects

- manufacturing date

- additional info (an opaque object with one currently identified

application)

i proposed this title to be

a) in line with similar documentation techniques in the past

b) to be compatible with possible extensions in the future

given the two current objects, and that one of them is opaque,

it is hard to be very specific. Dan suggested something like:

'Entity MIB Extensions for manufacturing date and physical module
identification'

or perhaps:

Extensions to entPhysicalTable of the Entity MIB

(more precise but still not very illuminating)

I suggest we go with Dan's proposal.

2. opaque object is cumbersome to implement.

the suggested construct was based on neat suggestions by Dave

and was meant to accommodate several concerns and also

allow flexibility. but several comments pointed out that

this may be too cumbersome to implement. i attach the

original proposal which was an object dedicated to CLEI.

note that my original question was posed in the context of

extending the Entity MIB directly instead of creating a separate

document.

any strong feelings against going back to the original? Dave?

3. acceptance as work item

since the original proposal i've seen several supporting comments

but i leave this to the WG chair and AD to gauge

kaj

---snip from initial
posting-------------------------------------------------

=============================================================

new objects:

entPhysicalCLIECode   OBJECT-TYPE

SYNTAX
SnmpAdminString (SIZE (0..10))

MAX-ACCESS  read-write

STATUS
current

DESCRIPTION

"The CLIE Code for the physical entity. If a CLIE Code

is unknown or non-existent, the entPhysicalCLIECode will

be set to a zero-length string instead."

::= { entPhysicalEntry xx }

REFERENCE "TCIF-02-004, Guideline for data
elements

included in the Management Information Base,

Telecommunications Industry Forum (TCIF), 09/11/2002.

ANSI T1.213-2001, Coded identification of equipment entities

of the North American telecommunications system for

information exchange, ANSI.

ANSI T1.213a-2001, Supplement to T1.213-2001,

Coded identification of equipment entities of the North

American telecommunications system for information exchange,

to correct the representation of the Basic Code in

Figure B.1, ANSI."

entPhysicalMfgDate   OBJECT-TYPE

SYNTAX
DateAndTime

MAX-ACCESS  read-only

STATUS
current

DESCRIPTION

"The manufacturing date for the physical entity."

::= { entPhysicalEntry xx }

-faye

-----Original Message-----

From: [email-masked]
[mailto:[email-masked]]
On Behalf Of Kaj Tesink

hi Sharon,

hi

wants to take this on?

This is a requirement I've heard bounced around a few times so I
think this

sufficiently descriptive. In addition, I think the data types might
be too

opaque to be useful.

by Juergen and Dan).

dictates.

kaj

Sharon

-----Original Message-----

From: Kaj Tesink

To: [email-masked]

Hi Dan,

>and physical modules identification'?

I see what you're trying to do. While this would more accurately
reflect the

adding

b) or you define supplemental specs; the problem here is that you
dont want

discussions

Kaj

Kaj Tesink

331 Newman Springs Road

Red Bank, NJ 07701

Tel: (732) 758-5254

Fax: (732) 758-4177

Entmib mailing list

[email-masked]

Entmib mailing list

[email-masked]

Kaj Tesink

331 Newman Springs Road

Red Bank, NJ 07701

Tel: (732) 758-5254

Fax: (732) 758-4177

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

Kaj Tesink

331 Newman Springs Road

Red Bank, NJ 07701

Tel: (732) 758-5254

Fax: (732) 758-4177

---

From: "Faye Ly" <[email-masked]>
Date: Wed, 14 Apr 2004 16:25:49 -0700

Kaj,
 
Regarding 2, (Please see cut and paste text), I agree with the string
approach as it is a well defined standard in ASCII displayble format.
It will simplify the implementation a lot as vendor like us typically
just save it as a string in the chassis/board table and never meddle
with it.
 
Also do you think it is worth a while to also include the CLLI code
support in this MIB?  It is used when SNMP and TL1 both exist either in
the device or proxied by one another.  Thanks.
 
-faye

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kaj Tesink
	Sent: Wednesday, April 14, 2004 4:02 PM
	To: [email-masked]
	Subject: RE: [Entmib] Re: Entity mib support for tcif

		Hi,
		 
		Yes, we have a need for this MIB.  Any chance of getting
this done?

	
	the current contents of the MIB module is only two objects
	- manufacturing date
	- additional info (an opaque object with one currently
identified
	  application)

	given the two current objects, and that one of them is opaque,
	it is hard to be very specific. Dan suggested something like:
	'Entity MIB Extensions for manufacturing date and physical
module identification'
	
	or perhaps:

	3. acceptance as work item
	since the original proposal i've seen several supporting
comments 
	but i leave this to the WG chair and AD to gauge
	
	kaj

	---snip from initial

	entPhysicalCLIECode   OBJECT-TYPE
	     SYNTAX      SnmpAdminString (SIZE (0..10))
	     MAX-ACCESS  read-write
	     STATUS      current
	     DESCRIPTION
	             "The CLIE Code for the physical entity. If a CLIE
Code
	             is unknown or non-existent, the entPhysicalCLIECode
will
	             be set to a zero-length string instead."
	     ::= { entPhysicalEntry xx }
	     REFERENCE "TCIF-02-004, Guideline for data elements
	             included in the Management Information Base,
	             Telecommunications Industry Forum (TCIF),
09/11/2002.
	             ANSI T1.213-2001, Coded identification of equipment
entities
	             of the North American telecommunications system for
	             information exchange, ANSI.
	             ANSI T1.213a-2001, Supplement to T1.213-2001,
	             Coded identification of equipment entities of the
North
	             American telecommunications system for information
exchange,
	             to correct the representation of the Basic Code in
	             Figure B.1, ANSI."
	
	     SYNTAX      DateAndTime
	     STATUS      current

		-faye 

			-----Original Message----- 
			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Kaj Tesink 
			Sent: Friday, April 02, 2004 8:38 AM 
			To: Sharon Chisholm; [email-masked] 
			Subject: [Entmib] Re: Entity mib support for
tcif

			hi Sharon,

			At 12:56 PM 4/1/2004 -0500, Sharon Chisholm
wrote:

				hi

				Where are we in this discussion? Have we
decided whether the working group 
				wants to take this on?

			i think that question is still pending; 
			we asked for input and expressions of interest
well before the 
			last ietf meeting but there has not been much
traffic on this 
			since that request. so let me repeat the request
for input on this spec:

			

				This is a requirement I've heard bounced
around a few times so I think this 
				is worth trying to address, but like Dan
I have a few concerns with some 
				aspects of the proposed solution. As he
has mentioned, the title is not 
				sufficiently descriptive. In addition, I
think the data types might be too 
				opaque to be useful. 

			as per my comments based on Dan's note, there
were 
			some good reasons for the high level title, but 
			i'd be open to other suggestions.

			as for the opaque object, the history is that 
			the initial proposal based on an octet string 
			syntax invoked a discussion about flexibility 
			and some other aspects, and resulted in a
proposal 
			by Dave for the current opaque construct,
although 
			some other comments expressed reservations (i
believe 
			by Juergen and Dan). 
			i'm willing to go with whatever the rough
consensus 
			dictates. 

			kaj

			

				Sharon 
				-----Original Message----- 
				From: Kaj Tesink
[mailto:[email-masked]] 
				Sent: Wednesday, February 11, 2004 10:25
AM 
				To: [email-masked] 
				Subject: RE: [Entmib] Re: Entity mib
support for tcif

				
				Hi Dan,

				At 10:03 PM 2/10/2004 +0200, Romascanu,
				>and physical modules identification'?

				
				I see what you're trying to do. While
this would more accurately reflect the 
				content, there is the issue of future
compatibility. The problem with 
				adding 
				new objects to MIBs over time is that 
				a) either you add to the original spec;
but this means there's a problem 
				    with advancing the spec over time 
				b) or you define supplemental specs; the
problem here is that you dont want 
				    all sorts of miblets around; you
want to minimize the number So, similar 
				as what we did for ATM, and attempted
for DS1s, the tactic was to use this 
				generic title, so that additional
functions could still be added for a 
				while. I agree its not perfect. I also
thought that in previous 
				discussions 
				there were some thoughts about some
additional functions(?).

				>the cleiCode object freely available?

				You're right, some of that did come up
before. 
				My understanding is the following: 
				- the references point to documents by
different standards groups, 
				   and i think are available for a small
fee at www.atis.org <http://www.atis.org/>  
				- CLEI codes are defined in those
standards; 
				   Telcordia is the registrar to obtain
an actual code 
				In previous discussion it was pointed
out that 
				while CLEIs are in wide use, there is no
obligation to 
				use them; I've tried to reflect that in
the draft 
				in two ways: (a) use an opaque object
instead of a dedicated object as 
				proposed by Dave, and (b) language for
the case that the whole thing (no 
				CLEI nor any other application of the
object) is not supported.

				Kaj

				

				> > >Date: Thu, 05 Feb 2004 15:06:54
-0500 
<[email-masked]> 

				Kaj Tesink 

				

	

	

			Kaj Tesink 

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

	Kaj Tesink

---

From: "Faye Ly" <[email-masked]>
Date: Wed, 14 Apr 2004 16:25:49 -0700

Kaj,

 
-faye

	-----Original Message-----

		Hi,

	

	
	or perhaps:

	
	kaj

	---snip from initial

	

		-faye 

			-----Original Message----- 

			hi Sharon,

				hi

	

			

			kaj

			

				Sharon 
				-----Original Message----- 
				From: Kaj Tesink

				
				Hi Dan,

				

				Kaj

				

				

				Kaj Tesink 

				

	

	

			Kaj Tesink 

	Kaj Tesink

---

From: "David T. Perkins" <[email-masked]>
Date: Fri, 16 Apr 2004 00:34:02 -0700

HI,

Juergen and I did some back and forth on what to do, and we both
believe that there should be one generic object that you can put
a list of any type of identification using a URNs, instead of a
specific object that holds only a single CLEI code.

Sorry, I cannot provide and updated definition now, but maybe
on sunday if someone else has not already.

Regards,
/david t. perkins