RE: [Entmib] FW: DISCUSS: draft-ietf-entmib-v3-07.txt

"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Wed, 02 February 2005 16:25 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23878 for <entmib-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:25:54 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwN9U-0000OI-JG; Wed, 02 Feb 2005 11:14:48 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwN5Z-00071p-Ax for entmib@megatron.ietf.org; Wed, 02 Feb 2005 11:10:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22174 for <entmib@ietf.org>; Wed, 2 Feb 2005 11:10:40 -0500 (EST)
Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwNNw-0003qb-NJ for entmib@ietf.org; Wed, 02 Feb 2005 11:29:46 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j12GABTw024309 for <entmib@ietf.org>; Wed, 2 Feb 2005 10:10:11 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <ZXPVBGPW>; Wed, 2 Feb 2005 17:10:09 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C7A060@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: 'Andy Bierman' <abierman@cisco.com>
Subject: RE: [Entmib] FW: DISCUSS: draft-ietf-entmib-v3-07.txt
Date: Wed, 02 Feb 2005 17:10:09 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Cc: "Entmib-wg (E-mail)" <entmib@ietf.org>
X-BeenThere: entmib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Entity MIB WG <entmib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:entmib@ietf.org>
List-Help: <mailto:entmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/entmib>, <mailto:entmib-request@ietf.org?subject=subscribe>
Sender: entmib-bounces@ietf.org
Errors-To: entmib-bounces@ietf.org

Sorry Andy... I think you misinterpreted (probably
my fault for not being clear) my statements.

I wanted to make sure that you as author are OK with it
(which I assumed, but an ack is always nice) and
I want the WG to know we are doing this so anyone 
knows what we're doing.

Bert
> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Wednesday, February 02, 2005 17:06
> To: Wijnen, Bert (Bert)
> Cc: Entmib-wg (E-mail)
> Subject: RE: [Entmib] FW: DISCUSS: draft-ietf-entmib-v3-07.txt
> 
> 
> At 07:54 AM 2/2/2005, Wijnen, Bert (Bert) wrote:
> >Andy writes:
> >> 
> >> At 07:05 AM 2/2/2005, Wijnen, Bert (Bert) wrote:
> >> >Can the author/editor and/or the WG react please.
> >> >I need (if possible) an answer by tomorrow (Thursday) 11am US
> >> >eastern at the latest (that is, if we want to try and get this 
> >> >approved this week).
> >> 
> >> what are the edits? CLEI URI to CLEI URN. reference
> >> RFC 2396 -> RFC 3986.  Any other nits?  Can't you just carry 
> >> forward an edit list without an update?
> >> 
> >
> >I can do that if the WG agrees that that is indeed what we 
> want to do.
> >I cannot just make such changes without checking back with at least
> >the authors/editors or the WG.
> >
> >> It's not like these updates require anybody to comment.
> >> Who's going to object to fixing a nit?
> >> 
> >I can do those fixes with an RFC-Editor note if we agree that
> >is what we want to do.
> 
> I am 100% in favor of fixing typos and out-of-date references.
> I don't think you need to wait for the WG to comment on 
> non-controversial edits.  Any WG members out there in favor of 
> keeping typos and out-of-date references, please speak up now!
> 
> 
> >Bert
> >> 
> >> >Bert
> >> 
> >> Andy
> 
> Andy
> 
> 
> >> 
> >> 
> >> 
> >> >> -----Original Message-----
> >> >> From: entmib-bounces@ietf.org 
> >> >> [mailto:entmib-bounces@ietf.org]On Behalf
> >> >> Of Wijnen, Bert (Bert)
> >> >> Sent: Tuesday, February 01, 2005 01:05
> >> >> To: Entmib-wg (E-mail)
> >> >> Subject: [Entmib] FW: DISCUSS: draft-ietf-entmib-v3-07.txt
> >> >> 
> >> >> 
> >> >> Feedback from IESG
> >> >> 
> >> >> -----Original Message-----
> >> >> From: iesg-bounces@ietf.org 
> >> [mailto:iesg-bounces@ietf.org]On Behalf Of
> >> >> Ted Hardie
> >> >> Sent: Monday, January 31, 2005 23:28
> >> >> To: iesg@ietf.org
> >> >> Subject: DISCUSS: draft-ietf-entmib-v3-07.txt
> >> >> 
> >> >> 
> >> >> Minor, but should be fixed.  The document currently says:
> >> >> 
> >> >> entPhysicalUris OBJECT-TYPE
> >> >>      SYNTAX      OCTET STRING
> >> >>      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 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.  A zero length octet string 
> may also be
> >> >>              returned in this case."
> >> >>      REFERENCE
> >> >>              "RFC 2396, Uniform Resource Identifiers 
> (URI): Generic
> >> >>              Syntax, section 2, August 1998."
> >> >> 
> >> >> This should be updated to the new URI RFC and a pointer to the
> >> >> appropriate syntax restrictions.  This text also does not limit
> >> >> the types of URIs which may be present.  If they are limited,
> >> >> an enumerated list should be included.
> >> >> 
> >> >> The document also uses "CLEI URI" to refer to a URN in the CLEI
> >> >> namespace.  That's technically correct, but it would be easier
> >> >> to understand if CLEI URN was used.  Here's an example:
> >> >> 
> >> >>      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]. 
> >> >> 
> >> >> Simply swapping out (CLEI) URI for (CLEI) URN would be fine.
> >> >> 
> >> >> _______________________________________________
> >> >> Entmib mailing list
> >> >> Entmib@ietf.org
> >> >> https://www1.ietf.org/mailman/listinfo/entmib
> >> >> 
> >> 
> 

_______________________________________________
Entmib mailing list
Entmib@ietf.org
https://www1.ietf.org/mailman/listinfo/entmib