Subject: [Entmib] entPhysicalUris object wrap-up

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Dec 2004 08:56:01 -0800

Hi,

I'd like to finish this up so I can submit an I-D update.
I have some issues to clarify, which require WG consensus.
I would rather remove this object than hold up progress
any longer, but if issues get resolved quickly then it
would be better to finish it now.

1) object purpose

There is strong opposition to a generic URI(s) placeholder
object by a couple people.  This is an object that contains
any semantics related to a physical entity, for which the
syntax happens to be encoded as a URI string. (very low
cohesion). 

I propose that this object be changed back to entPhysicalClei.
It should contain the empty string (for none) or a URI
string conforming to the CLEI URN specification (from Kaj).
If we think of other required semantics in the future, 
we can add new objects then.

2) references

As per Bert's comments, the citation to RFC 2396 will be 
removed from the DESCRIPTION clause, since it is redundant.
Should this be changed to point to the CLEI URN specification, 
or just add another document to the REFERENCE clause?
Where else should this spec be cited in the document?
There are normative references, so how long will the 
Entity MIB be held up waiting for the CLEI URN RFC?

3) conformance

Currently the new OBJECT-GROUP (entityPhysical3Group)
is in the MANDATORY-GROUPS clause.  If both objects
allow for null values, then this should not be a problem.

4) examples

I don't really have time (or enough info) to fill in the
examples in section 4, but I know somebody will eventually
ask about this before RFC publication.  I would really
appreciate some help updating the examples.  (I need to
add an example for entPhysicalClass==cpu(12) as well.)
Any volunteers? (4.1 and 4.2 can be done independently)
I would like to get this over with now ;-)

thanks,
Andy

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

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 8 Dec 2004 13:24:15 -0500

>we can add new objects then.

This makes sense to me if we can quickly, easily resolve the reference issues.

Otherwise, I think we should just remove the object and let others 
add it as an "augments" if/when the proposed contents are 
well-defined.

>Entity MIB be held up waiting for the CLEI URN RFC?

If we pursue this choice, I think that the CLEI URN document needs to 
be a normative reference.  Kaj submitted a draft, but I don't know 
what shape it is in and/or whether Bert is willing to either: (1) 
allow this group to take on that document, or (2) move it forward as 
an individual submission.  How close do folks think it is to ready 
for publication?  Has a MIB doctor reviewed it?  Bert, do you have 
any thoughts?

>allow for null values, then this should not be a problem.

Okay.

>I would like to get this over with now ;-)

Yes.  It would be good to get this finished, so volunteer would be appreciated.

Margaret

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Dec 2004 22:27:43 +0100

> for publication?  Has a MIB doctor reviewed it?  Bert, do you have 

If at all, this needs a URI doctor review, not a MIB doctor review.

/js

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

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 8 Dec 2004 13:27:37 -0800 (PST)

HI,

I somehow missed the motivating reasons to go from a 
an object that can provide a alternative identification
to an object that supports only CLEI codes.

> add it as an "augments" if/when the proposed contents are 
Regards,
/david t. perkins

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Dec 2004 16:12:20 -0800

>to an object that supports only CLEI codes.

IMO, standard objects add value by providing common, well-defined 
semantics.  A list of undefined, unconstrained "alternate identifiers"
doesn't meet this criteria.  If the DESCRIPTION clause somehow 
constrained (and guided) implementations with a finite set of
alternatives, that would be fine.  Rationale for each alternative 
would need to be documented as well.  I strongly oppose doing
all this "alternative identifier" work as part of the 2737 update, 
because it isn't well-defined yet.

Andy

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 8 Dec 2004 18:27:25 -0800 (PST)

HI,

Ok, you guys caught me not staying current on all messages.
Now that I've read the I-D and read the messages from approx
Nov 30 time frame, here are my comments:
1) The text of the document and the text in the description
   clause to not seem to be in alignment with reguards to
   an empty value. Some people like to not create an instance
   and others like the use of a zero length string. I prefer
   a zero length string.
2) The data type is OCTET STRING. I think it should be the
   proper TC for a "printable US ASCII" (that is, printable
   7-bit ASCII). URIs cannot contain spaces, and must contain
   only a subset of characters from printable 7-bit ASCII. 
3) In RFC 3413, textual convention SNMP-TARGET-MIB::SnmpTagList
   provides a superset of what is needed for the syntax.
   It provides support for UTF8 encodings, which are not needed
   for URIs. It describes leading, trailing, and multiple
   deliminators (you can't have them!).
4) This issue has been discussed many times. As was pointed out
   by Kaj in an earlier message, the approach choosen was the
   best solution and was acceptable to all on the WG mailing
   list. I don't believe that it is fair to undo what was
   hammered out over a long period of time where:
   a) it was demonstrated that use of an
      "alternative identification" scheme was needed
      and provided value at little cost.
   b) the scheme was neutral
   c) the scheme provided support for multiple competing
      alternative identifications (limited only by the size
      of the object)
   d) the cost to support a "non implementation" was next
      to nothing
5) Yes, all MIB purests hate this and similar objects, since
   they are really for "lazy management app writers". However,
   this object does provide benefit when it is difficult to
   determine values of OIDs that are used for the value of
   object entPhysicalVendorType. Tracking down OID values
   used for identification can be a time consuming and
   frustrating job.
6) I don't remember why it is "read-write" and not read-only,
   since entPhysicalVendorType is read-only. But maybe someone
   can provide the reason. (I think if you want to change it,
   then there should be a path not via SNMP. Because if you
   can write it via SNMP, a management app must be translating
   the value of entPhysicalVendorType.)

So, I suggest that 
1) the DESCRIPTION text be cleaned up and aligned with
   the text in the document to say that the object is
   a) an alternative way to identify the component
      than the value of entPhysicalVendorType
   b) potentially a list of alternative identifications
2) the value of the SYNTAX be changed to DisplayString
   (and the DESCRPTION clause restrict the values further).
3) the descriptor be changed to something like
   "entPhysicalAltIDlist" to better convey it's
   semantics.
4) Possibly change it to read-only. (But ignore this
   if there is a good reason not to.)

Note, I thought that maybe object entPhysicalAssetID could
do double duty and hold the URI value, but it is too small.
So, again, I feel that the WG made the best choices to
create a new neutral object. 

> because it isn't well-defined yet.
I believe that Andy's objection can be resolved by a registry
at IANA for URIs for this object.

Regards,
/david t. perkins

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Dec 2004 19:34:33 -0800

>   d) the cost to support a "non implementation" was next

I missed all this on the mailing list.
I'll let the WG Chair decide, and I'll wait
on any edits.

>   they are really for "lazy management app writers". However,

No -- they are for lazy standards writers.

>at IANA for URIs for this object.

yep -- that works for me ;-)

thanks,
Andy

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 9 Dec 2004 08:23:55 -0500

Hi All,

>I'll let the WG Chair decide, and I'll wait

Kaj's document was never a WG document and, IMO, the Entity MIB WG 
did not make any official decisions about these objects before we 
decided to add them to the Entity MIB.  I know that a few people used 
the Entity MIB mailing list to discuss Kaj's personal submission, and 
I thought that was fine.  But, I didn't track the discussion closely 
enough to have a mental record of it, and no official consensus calls 
were made about it.

Personally, I agree with Andy that it is a bit lame to have an 
undiscriminated, unformatted, loosely specified string in the middle 
of this MIB.   How are applications supposed to know that this 
contains?  Would it be possible to compare these strings?  Use them 
as URLs?  Or do anything with them besides just display them on a 
screen?

I am not actually religious about this, though.  So, if that's what 
the WG thinks is the best way to represent this object, so be it.

Margaret

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 9 Dec 2004 15:13:10 +0100

On Thu, Dec 09, 2004 at 08:23:55AM -0500, Margaret Wasserman wrote:
 
> of this MIB.

This is I think a total mis-understanding of the MIB object. You may
not like this object, but saying it is an undiscriminated, unformatted,
loosely specified string really missed the point.

> How are applications supposed to know that this contains?  

The object contains URIs separated by white space. Meaning is attached
to URIs and applications have to understand the URIs (such as CLEI code
URNs). If they do not understand the URI semantics, the URIs can still
be displayed as a service to the operator who has to write down the
hardware identification into an email message or speak it into a phone.

> Would it be possible to compare these strings?

This boils down to comparisons of URIs. In the case of CLEI code URNs,
I would not see any problem.

> Use them as URLs?  Or do anything with them besides just display 
> them on a screen?

See above. And yes, displaying a hardware identification number 
such as a CLEI code on screen can be useful. Note that most of the
SnmpAdminString objects in the EntPhysicalEntry mainly serve the 
purpose of being displayed to the operator. (Unless I am missing
some magic hidden algorithm burried deeply inside of the MIB.)

Note: I do not claim that we have to add this object. There might 
be reasons not do so and there are of course reasons why we ended 
up with what we have on the table. What I dislike, however, are 
general and unsubstantiated statements.

As far as I understand things, Andy dislikes the fact that the object 
allows arbitrary URIs and thus naming schemes. So we may have to 
reconsider the discussion that lead us to use URIs in the first place, 
namely to side-step the fact that these codes are not "openly" 
available. If that is now not a problem anymore, we can reconsider 
the URI notation we came up with to side-step the issue and have
something that is less fancy. [But in any case, this is all about
syntax and does not really change what a management application can
or cannot do with a CLEI code.]

/js

---

From: Kaj Tesink <[email-masked]>
Date: Wed, 08 Dec 2004 22:03:17 -0500

>>we can add new objects then.

works for me; this is fairly close to the original request
(but see my previous note on how we got to the URI solution)

>This makes sense to me if we can quickly, easily resolve the reference issues.

my sense is that there are several references we can use, including
the T1.213 references which are authoritative on the CLEI format.
the draft i submitted just turns that format into a URI.

>Otherwise, I think we should just remove the object and let others add it 
>as an "augments" if/when the proposed contents are well-defined.
>
>>2) references
>>
>If we pursue this choice, I think that the CLEI URN document needs to be a 
>normative reference.  Kaj submitted a draft, but I don't know what shape 
>it is in and/or whether Bert is willing to either: (1) allow this group to 
>take on that document, or (2) move it forward as an individual 
>submission.  How close do folks think it is to ready for publication?  Has 
>a MIB doctor reviewed it?  Bert, do you have any thoughts?

the URN document is a standard request for the particular name space;
so it follows the path stipulated in RFC3406.
my understanding of that process (sect 4.3) is that after
mailing to <mailto:[email-masked]>[email-masked] and
a two week discussion period
(one week has past already) the spec will be reviewed by the IESG.
i'm unfamiliar with the length of that review but as the spec has been
written using the standard template and closely parallels
several other published URN RFCs the process should be straightforward.

>>allow for null values, then this should not be a problem.

yup

>Yes.  It would be good to get this finished, so volunteer would be 

if you like to add the Uri object to the exaample section
we could leverage the examples in the example
section of the CLEI URN document:

**********************************************************************
3.  Examples

    The following three examples are based on the examples provided in
    [T1.213a], and correspond with three different sets of features by
    three different manufacturers (Nortel Networks, Lear and Lucent
    Technologies) producing "D4CE" (a particular D4 channel bank type)
    equipment. The fourth example refers to a SONET power unit convertor
    of Alcatel.

       URN:CLEI:D4CE18B7AA
       URN:CLEI:D4CE4248AA
       URN:CLEI:D4CE363PAB
       URN:CLEI:SNPWBBC7AA
*********************************************************************

however, if you like to create an example in section 4 using the
acme approach in the other examples i would have to find some bogus
CLEI code for acme. is that what you're looking for?

kaj

>Margaret

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

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

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 09 Dec 2004 07:24:41 -0800

>or cannot do with a CLEI code.]

I dislike MIB objects that are too general to add value
to a standard.  A URI is very generic.  What kind of 
resource is being identified here? Anything at all the
vendor wants to put there.  I think vendor MIBs are more
appropriate for this usage.  I am happy enough with an
IANA registry for the URNs that SHOULD be used.

Andy

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 09 Dec 2004 11:57:54 -0500

At 08:23 AM 12/9/2004, Margaret Wasserman wrote:

>Kaj's document was never a WG document and, IMO, the Entity MIB WG did not 
>make any official decisions about these objects before we decided to add 
>them to the Entity MIB.  I know that a few people used the Entity MIB 
>mailing list to discuss Kaj's personal submission, and I thought that was 
>fine.  But, I didn't track the discussion closely enough to have a mental 
>record of it, and no official consensus calls were made about it.
>
>undiscriminated, unformatted, loosely specified string in the middle of 
>this MIB.   How are applications supposed to know that this 
>contains?  Would it be possible to compare these strings?  Use them as 
>URLs?  Or do anything with them besides just display them on a screen?
>
>I am not actually religious about this, though.  So, if that's what the WG 
>thinks is the best way to represent this object, so be it.

fair enough, so let me recall again how we got here:
1. the original proposal was for some simple (i thought :-)
    object additions to be added to the entmib itself.
2. support for the objects was demonstrated over time,
    but there were 2 issues:
      a) status of the entmib (trying for Draft)
      b) the CLEI object representation
3. (2a) was solved by coming up with a separate
      supplemental MIB, a procedural move.
4. the supplemental MIB had to be a personal
      submission due to the procedural issue of wg charter.
5. later, the need for a supplemental MIB was removed
      since entmib stays at Proposed. thus,
      removing the procedural issues, and
      we are back to the original objects.
6. (2b) went thru an interesting discussion on concerns
      on how best to represent T1.213 format. this
      resulted eventually IMHO in an elegant proposal
      by Juergen and Dave using the URI representation.
      note that the object's nature is Identification; one
      advantage also pointed out by Juergen is that the URI
      approach allows identification not only of CLEIs
      but of other things as well, avoiding the need to
      rework the entmib in the future on this aspect.
7. to support (6) we needed a URN request for CLEI name space.
      this request has been posted using appropriate format
      and 3406 process.
8. irrespective of (6) and (7), the use and application of
      CLEIs themselves are perfectly clear; see T1.213 for
      details, and years of use.

so, based on (1)-(8) i think Dave's observations above
are reasonable.
(i'd not suse in Dave's item (c) the word 'competing';
rather it accommodates identifiers for different applications,
but i assume that that was meant).

the string in the Uri object, at least for the CLEI
application is well formatted and defined. IANA registries
http://www.iana.org/assignments/uri-schemes  and
http://www.iana.org/assignments/urn-namespaces
are there to help sort things out, no?

kaj

Kaj Tesink

---

From: Andy Bierman <[email-masked]>
Date: Thu, 09 Dec 2004 09:32:27 -0800

At 08:57 AM 12/9/2004, Kaj Tesink wrote:
>>Kaj's document was never a WG document and, IMO, the Entity MIB WG did not make any official decisions about these objects before we decided to add them to the Entity MIB.  I know that a few people used the Entity MIB mailing list to discuss Kaj's personal submission, and I thought that was fine.  But, I didn't track the discussion closely enough to have a mental record of it, and no official consensus calls were made about it.
>>
>>Personally, I agree with Andy that it is a bit lame to have an undiscriminated, unformatted, loosely specified string in the middle of this MIB.   How are applications supposed to know that this contains?  Would it be possible to compare these strings?  Use them as URLs?  Or do anything with them besides just display them on a screen?
>>
>>I am not actually religious about this, though.  So, if that's what the WG thinks is the best way to represent this object, so be it.
>
>

The documentation I was provided for this object (especially the 
OBJECT-TYPE macro) did not convey any of this info, rationale, 
or references.  If it did, I wouldn't have objected to the
vagueness of the object.

I still don't understand why we need a list of URIs per entity.
This adds complexity.  It there a compelling need for multiple
URIs per entity?

Andy

---

From: Kaj Tesink <[email-masked]>
Date: Thu, 09 Dec 2004 18:36:38 -0500

At 12:32 PM 12/9/2004, Andy Bierman wrote:

[..snip..]

>This adds complexity.  It there a compelling need for multiple

from a CLEI perspective a single URI per entity would be
sufficient. however, in the discussion i think it was argued
that other or multiple things may be of interest.
it seems easy to parse (and at least display it) so the cost
in terms of complexity seems low.

looking at beefing up the description, one way to work it
is to beef up section 2.12.1 (or you may prefer to port
selected portions to the DESCRIPTION clause), e.g.,

   - entPhysicalUris
      This object provides additional identification information about
      the physical entity.
      The object contains one or more Uniform Resource Identifiers
      (URIs) and therefore the syntax of this object  must conform to
      RFC 2396 [RFC2396] section 2.
      Uniform Resource Names (URNs) are resource identifiers with the
      specific requirements for enabling location independent
      identification of a resource, as well as longevity of reference.
      URNs are part of the larger URI family with the specific goal
      of providing persistent naming of resources.
      URI schemes and URN name spaces are registered by IANA (see
      http://www.iana.org/assignments/uri-schemes and
      http://www.iana.org/assignments/urn-namespaces.

      The entPhysicalUris object may be used to encode for example
      a URI containing a Common Language Equipment Identifier (CLEI) URI
      for the managed physical entity. The URN name space for CLEIs is
      defined in [RFC CLEIURN], and the CLEI format is defined in
      [T1.213][T1.213a].
      For example, an entPhysicalUris instance may have the value  of

         URN:CLEI:D4CE18B7AA

      [RFC2396] and [RFCCLEIURN] identify this as a URI in the CLEI
      URN name space, and the specific CLEI code, D4CE18B7AA is based on
      the example provided in [T1.213a].

      Multiple URIs may be present and are separated by white space
      characters. Leading and trailing white space characters are
      ignored.

      If no additional identification information is known or supported
      about the physical entity the object is not instantiated.

[RFC2396]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource
             Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[RFCCLEIURN] Tesink, K., and Robert H. Fox, "A Uniform Resource Name (URN)
             Namespace for the CLEI Code", Work in progress, November 7, 2004.

[T1.213]    ATIS T1.213-2001, Coded Identification of Equipment Entities
             in the North American Telecommunications System for
             Information Exchange, 2001, www.ansi.org

[T1.213a]   ATIS T1.213a, Supplement to T1.213-2001, Coded
             Identification of Equipment Entities in the North American
             Telecommunications System for Information Exchange, to
             correct the representation of the Basic Code in Figure B.1,
             2001, www.ansi.org

---

From: Kaj Tesink <[email-masked]>
Date: Fri, 10 Dec 2004 14:01:43 -0500

At 11:56 AM 12/8/2004, Andy Bierman wrote:

[..snip..]

>I would like to get this over with now ;-)

andy,

we came up with some acme-compatible URIs for the examples below;
see additions. also included the MfgDate. included examples for both
instantiated and non-instantiated cases.

kaj

--------------------------------------------------------------------

Kaj Tesink