Subject: RE: [Entmib] To meet or not to meet?

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 20 Jul 2004 12:42:33 +0300

Juergen,

A few questions:

1. Should the language about using the CLEI codes be more decisive? SHOULD instead of MAY? For example: 'If CLEI codes are supported in the operational environment where this agent is implemented, this object SHOULD include a URI containing a Common Language Equipment Identifier (CLEI) URI [XXX] for the managed physical entity.'
2.' If no additional identification information is known or supported about the physical entity the object is not instantiated' - This object has a MAX-ACCESS read-write. How would the creation or deletion of the first URI in the list work? Would not it be simpler to use a zero-length string for the case when no identification information is known?
3. 'Note that [XXX] would refer to a most likely informational RFC which registers a URN namespace for CLEI codes.' - Does [XXX] really need to be an Informational RFC? I am afraid that this would hang this MIB until that RFC goes through our wonderful IETF process. Maybe the Telcordia folks already have a document to be referenced as an Informative Reference, or can create one on a shorter path.  

Regards,

Dan

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Juergen Schoenwaelder
> Sent: 20 July, 2004 11:05 AM
> To: Kaj Tesink
> Cc: [email-masked]
> Subject: Re: [Entmib] To meet or not to meet?
> 
> 
> On Mon, Jul 19, 2004 at 04:36:47PM -0400, Kaj Tesink wrote:
> > 
> > i cannot be present, but can check whether another 
> telcordia person can 
> > attend.
> > as far as the draft is concerned, we're talking actually 
> only about two 
> > objects,
> > of which only one is under debate. dave p. had volunteered 
> a fix, so that 
> > could
> > be something to discuss (URN approach). i'm personally 
> rather flexible wrt 
> > the
> > solution so if either the meeting or an adhoc group can 
> coble up something
> > we can put it in the draft and be done.
> 
> I think the changes on the MIB side are rather straight forward. Below
> is a first cut an proposed new text:
> 
> 3.2.  entSupplPhysicalUris
> 
>    This object provides additional identification information 
> about the 
>    physical entity. This object may be used to encode for example a 
>    URI containing a Common Language Equipment Identifier (CLEI) URI
>    [XXX] for the managed physical entity. If no additional 
> identification 
>    information is known or supported about the physical 
> entity the object 
>    is not instantiated.
> 
> And in the MIB definition itself:
> 
>    entSupplPhysicalUris 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."
>        ::= { entSupplPhysicalEntry 2 }
> 
> The definition of the cleiCode OBJECT-IDENTITY will be removed and
> someone from Telcordia needs to write up a document registering a
> URN namespace for CLEI codes. 
> 
> Note that [XXX] would refer to a most likely informational RFC which
> registers a URN namespace for CLEI codes.
> 
> /js
> 
> P.S. I will not attend the meeting in San Diego. 
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> _______________________________________________
> 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: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 20 Jul 2004 12:06:40 +0200

On Tue, Jul 20, 2004 at 12:42:33PM +0300, Romascanu, Dan (Dan) wrote:
 
> 1. Should the language about using the CLEI codes be more decisive? 
> SHOULD instead of MAY? For example: 'If CLEI codes are supported in 
> the operational environment where this agent is implemented, this 
> object SHOULD include a URI containing a Common Language Equipment 
> Identifier (CLEI) URI [XXX] for the managed physical entity.'

I guess we should leave that to the decision of the implementator
(or whoever configures this object). If we add more decisive text,
we might again have a debate whether the IETF features proprietary
identification mechanisms.

> 2.' If no additional identification information is known or supported 
> about the physical entity the object is not instantiated' - This object 
> has a MAX-ACCESS read-write. How would the creation or deletion of the 
> first URI in the list work? Would not it be simpler to use a zero-length 
> string for the case when no identification information is known?

I just kept this sentence from the original text. I don't mind allowing a
zero-length string instead.

> 3. 'Note that [XXX] would refer to a most likely informational RFC which 
> registers a URN namespace for CLEI codes.' - Does [XXX] really need to 
> be an Informational RFC? I am afraid that this would hang this MIB until 
> that RFC goes through our wonderful IETF process. Maybe the Telcordia 
> folks already have a document to be referenced as an Informative 
> Reference, or can create one on a shorter path.  

This MIB has already been hanging around for quite some time. While
it is popular to point to the slow IETF process, I believe that in 
many cases the speed in which a reasonable document is written does
contribute quite a bit to the overall speed. I do have a strong 
preference to have a URN namespace formally registered and all this
documented by an RFC. I do not think it is a complicated thing to
do - especially if someone from Telcoridia who knows how these CLEI
codes work writes this up. There are enough template RFCs out there.
There is no reason why such a document should not be ready to go to
the RFC editor as an individual submission directly after the next
WG meeting.

/js

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