Re: entPhysicalUris object wrap-up

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

>Hi All,
>
>>At 06:27 PM 12/8/2004, David T. Perkins wrote:
>>>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
>>
>>I missed all this on the mailing list.
>>I'll let the WG Chair decide, and I'll wait
>>on any edits.
>
>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.


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









>Margaret
>
>
>_______________________________________________
>Entmib mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/entmib


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

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

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