From imss-bounces@ietf.org Mon Mar 06 13:34:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FGKWv-0005bA-2b; Mon, 06 Mar 2006 13:34:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKWt-0005b5-Lc
	for imss@ietf.org; Mon, 06 Mar 2006 13:33:59 -0500
Received: from ihemail2.lucent.com ([192.11.222.163])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGKWt-0004xV-AK
	for imss@ietf.org; Mon, 06 Mar 2006 13:33:59 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k26IXrfG003672; 
	Mon, 6 Mar 2006 12:33:53 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <DVB459LM>; Mon, 6 Mar 2006 19:33:52 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097B8DCE@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Black_David@emc.com, cds@cisco.com, vgaonkar@cisco.com, kzm@cisco.com,
	sgai@cisco.com
Date: Mon, 6 Mar 2006 19:33:51 +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: 093efd19b5f651b2707595638f6c4003
Cc: "Imss \(E-mail\)" <imss@ietf.org>,
	"Dan Romascanu \(E-mail\)" <dromasca@avaya.com>
Subject: [imss] AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

Summary:

looks good. I would be OK with doing IETF Last Call and consider these
comments as initial IETF Last Call comments. At the other hand, IETF
LC right before/during an IETF will not get many people to pay
attention to this. Maybe you rather do a new rev first?

more serious questions/issues:

SMICng tells me:
  E: f(t11fcfspf.mi2), (915,54) Index item "t11FspfLinkIndex" must be
     defined with syntax that includes a range
  W: f(t11fcfspf.mi2), (1007,19) Variable "ifIndex" in notification
     "t11FspfNbrStateChangNotify" is an index for a table

The warning is OK/acceptable as far as I am concerned.
The Error would probably be best fixed.

SMILINT tells me:

C:\smi\mibs\work>smilint -m -s -l 6 ./T11-FC-FSPF-MIB
./T11-FC-FSPF-MIB:212: [5] {identifier-case-match} warning: identifier `t11FspfA
RegionNum' differs from `T11FspfARegionNum' only in case
./T11-FC-FSPF-MIB:61: [6] {previous-definition} info: previous definition of `T1
1FspfARegionNum'
./T11-FC-FSPF-MIB:824: [5] {identifier-case-match} warning: identifier `t11FspfL
srType' differs from `T11FspfLsrType' only in case
./T11-FC-FSPF-MIB:71: [6] {previous-definition} info: previous definition of `T1
1FspfLsrType'
./T11-FC-FSPF-MIB:964: [5] {identifier-case-match} warning: identifier `t11FspfL
inkType' differs from `T11FspfLinkType' only in case
./T11-FC-FSPF-MIB:89: [6] {previous-definition} info: previous definition of `T1
1FspfLinkType'
./T11-FC-FSPF-MIB:61: [5] {type-without-format} warning: type `T11FspfARegionNum
' has no format specification
./T11-FC-FSPF-MIB:71: [5] {type-without-format} warning: type `T11FspfLsrType' h
as no format specification
./T11-FC-FSPF-MIB:89: [5] {type-without-format} warning: type `T11FspfLinkType'
has no format specification
./T11-FC-FSPF-MIB:129: [5] {type-without-format} warning: type `T11FspfLastCreat
ionTime' has no format specification

The identifier-case-match are acceptable. They may confuse people though.

The type-without-format warnings are for your TCs.
You may want to add a SIPLAY-HINT


- sect 5 states:
   protocol.  (Note that there are no definitions in this MIB module of
   "managed actions" which can be invoked via SNMP.)
  So what does that mean for t11FspfSetToDefault, which to me seems to
  be an action that can be invoked via SNMP??
  Same for t11FspfIfSetToDefault

- redundant objects??
  I do not see what the difference is between the follow two
  (well, except SYNTAX). Is there any? If so, can that be made
  clear in the DESCRIPTION clauses? If not, can one be removed?

  t11FspfLsrs OBJECT-TYPE
    SYNTAX      Gauge32
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
           "The current number of entries for this Fabric in the
           t11FspfLsrTable."
    ::= { t11FspfEntry 19 }

  t11FspfLsrNumber  OBJECT-TYPE
    SYNTAX      Unsigned32 (0..2147483647)
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
           "The current number of rows for this fabric in the
           t11FspfLsrTable."
    ::= { t11FspfEntry 23 }

- t11FspfStorageType
  Which writeable objects must be writable for a 'permanent' row?

- Mmm. I find the way you delete a row in t11FspfIfRowStatus
  a bit strange/weird. But I guess I can live with it.
  Can you explain why you do it this way?

- t11FspfLinkIndex probably better specifies a range that excludes zero ??
  see also smicng error above.

admin/nits and just questions for clarity/explanation

- I see:
    t11FspfIfNbrPortIndex OBJECT-TYPE
        SYNTAX      Unsigned32 (1..4294967295)

    t11FspfLinkPortIndex OBJECT-TYPE
        SYNTAX      Unsigned32 (0..16777215)

    t11FspfLinkNbrPortIndex OBJECT-TYPE
        SYNTAX      Unsigned32 (0..16777215)

  Is it just me who wonders about the different ranges??
  Maybe I am missing something or misunderstanding.
    
- I wonder what a value of zero means for T11FspfLinkType
  If it can never exist, would it be better to make the range
  (1..255) ??

- I wonder if T11FspfLsrType and T11FspfLinkType would be better
  defined with a base type of INTEGER? In other words Enumerations?

- I wonder how new non-Vendor-Specific values for T11FspfLsrType 
  and T11FspfLinkType will be assigned/allocated?
  Probably by T11? Would not hurt to say something about that.

- I suspect that the RFCyyyy in t11FspfAdminStatus REFERENCE clause
  is (or should be) a different yyyy than the one in the
  MODULE-IDENTITY macro?

- In a number of places I would prefer to see "MIB module" instead
  of just "MIB". But I cam live with if if this is the doc does not
  need changing for anything else.

- Section 7 is redundant and contains same material as the back matter.

Bert

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



From imss-bounces@ietf.org Mon Mar 06 13:34:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FGKXR-0005zv-7R; Mon, 06 Mar 2006 13:34:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FGKXP-0005zW-Lx
	for imss@ietf.org; Mon, 06 Mar 2006 13:34:31 -0500
Received: from ihemail2.lucent.com ([192.11.222.163])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGKXP-0004y5-Cr
	for imss@ietf.org; Mon, 06 Mar 2006 13:34:31 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com
	[135.85.76.62])
	by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k26IXsW7003700; 
	Mon, 6 Mar 2006 12:33:55 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <DVB459LN>; Mon, 6 Mar 2006 19:33:54 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097B8DCF@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Black_David@emc.com, cds@cisco.com, skode@cisco.com,
	"Keith McCloghrie (E-mail)" <kzm@cisco.com>, sgai@cisco.com
Date: Mon, 6 Mar 2006 19:33:52 +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: 4d87d2aa806f79fed918a62e834505ca
Cc: "Imss \(E-mail\)" <imss@ietf.org>,
	"Dan Romascanu \(E-mail\)" <dromasca@avaya.com>
Subject: [imss] AD review of: draft-ietf-imss-fc-rtm-mib-02.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

This document is ready for IETF Last Call.

One topic that I would prefer to see addressed:

- When I see:
    t11FcRouteDestAddrId OBJECT-TYPE
       SYNTAX      FcAddressIdOrZero
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The destination Fibre Channel Address Identifier of
           this route.  A zero-length string for this field is
           not allowed."
       ::= { t11FcRouteEntry 1 }

  I then wonder why the syntax is not:

      SYNTAX      FcAddressIdOrZero (SIZE(3))

  So that the restriction that zero-length is not allowed is
  also machine readable.

  COuld be addressesd after IETF Last Call, even with an RFC-Editor note.

Mainly have some NITs below.
You may consider them as initial IETF Last Call comments.
Let me know if you rather do a new rev first or if you
prefer to do IETF LC now. I will probably let IETF LC extend
beyond the IETF week, because people are probably busy reviewing
documents for the IETF week itself.

- t11FcRouteRowStatus has a pretty meager DESCRIPTION clause
  For example, from the DESCRIPTION clause of t11FcRouteIfDown
  it seems that maybe a 'destroy' to the RowStatus object
  may not take immediate effect? You might want to describe that.
  It is also unclear if any writeable objects can be written
  when a row is active?


- The 4 OBJECT clauses that you did as comments in the
  MODULE-COMPLIANCE are normally put as comments inside the
  DESCRIPTION clause of the MODULE-COMPLIANCE clause itself.
  That way the text is better kept when MIB module gets
  extracted from RFC. Not a blocking comment though.

- Section 7 seems redundant with the back matter, and might as
  well be removed.

- In the references section, are the details for [FC-SW-4] now
  known? If so, might want to fill them out.

Bert

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



From imss-bounces@ietf.org Tue Mar 07 10:43:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FGeLH-00015C-9B; Tue, 07 Mar 2006 10:43:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FGeLF-00011R-TI
	for imss@ietf.org; Tue, 07 Mar 2006 10:43:17 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGeLF-00078y-Kb
	for imss@ietf.org; Tue, 07 Mar 2006 10:43:17 -0500
Received: from sj-core-4.cisco.com ([171.68.223.138])
	by sj-iport-4.cisco.com with ESMTP; 07 Mar 2006 07:43:17 -0800
X-IronPort-AV: i="4.02,172,1139212800"; 
	d="scan'208"; a="1782629364:sNHT35006012"
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k27FhGYg017750;
	Tue, 7 Mar 2006 07:43:16 -0800 (PST)
Received: (from kzm@localhost)
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA21489;
	Tue, 7 Mar 2006 07:43:15 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200603071543.HAA21489@cisco.com>
To: kzm@cisco.com (Keith McCloghrie)
Date: Tue, 7 Mar 2006 07:43:15 -0800 (PST)
In-Reply-To: <no.id> from "Keith McCloghrie" at Mar 07, 2006 07:23:40 AM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Cc: silvano@ip6.com, cds@cisco.com, imss@ietf.org, kzm@cisco.com,
	dromasca@avaya.com, bwijnen@lucent.com, Black_David@emc.com,
	vgaonkar@cisco.com
Subject: [imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

> > looks good. I would be OK with doing IETF Last Call and consider these
> > comments as initial IETF Last Call comments. At the other hand, IETF
> > LC right before/during an IETF will not get many people to pay
> > attention to this. Maybe you rather do a new rev first?
>  
> I'll do a new rev first, but it won't now get posted until after the IETF.

In starting to do the edits, I have found one other thing which it
might be appropriate to change at this time.

The present MIB, draft-ietf-imss-fc-fspf-mib-01.txt, defines the
object:

  t11FspfARegionNum OBJECT-TYPE
      SYNTAX      T11FspfARegionNum
      MAX-ACCESS  read-write
      STATUS      current
      DESCRIPTION
             "The AR number of this switch in this Fabric."
      REFERENCE  "Fibre Channel - Switch Fabric - 4 (FC-SW-4), Rev 7.5,
                 May 2005, section D.3.1."
      DEFVAL     {0}
      ::= { t11FspfEntry 2 }

I was starting to update the REFERENCE clauses to refer to the latest
rev of FC-SW-4, but in doing so I find that Annex/section D.3.1 is
missing.  In fact, the whole of what was Annex D has been removed from
the latest revision (rev 7.7 of December 2005).  I knew that T11 was
deprecating the concept of an "FSPF-Backbone" which was defined as:

    The FSPF-Backbone Fabric consists of multiple Autonomous Regions
    (AR) that are interconnected by a backbone network.

What I didn't realise was that it would disappear from the FC-SW-4
specification so soon.

Without that Annex, the definition of t11FspfARegionNum no longer
makes any sense.

So, the question is:

- should the T11-FC-FSPF-MIB retain the definition of t11FspfARegionNum,
  and do so by referring to an out-of-date T11 specification, or,

- should the definition of t11FspfARegionNum be removed from the
  T11-FC-FSPF-MIB at this time ??

(Note that the edits that would be needed to remove it are obvious and
straight-forward, e.g., the T11FspfARegionNum TC which is only used by
t11FspfARegionNum would be deleted; t11FspfARegionNum would deleted
from both the MODULE-COMPLIANCE clause and from the t11FspfGeneralGroup
group.)

Keith.

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



From imss-bounces@ietf.org Tue Mar 07 11:56:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FGfTd-0008BI-6S; Tue, 07 Mar 2006 11:56:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FGfTc-0008B7-Ce
	for imss@ietf.org; Tue, 07 Mar 2006 11:56:00 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGeH0-0006sc-8J
	for imss@ietf.org; Tue, 07 Mar 2006 10:38:54 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FGe2H-0006xa-PP
	for imss@ietf.org; Tue, 07 Mar 2006 10:23:44 -0500
Received: from sj-core-2.cisco.com ([171.71.177.254])
	by sj-iport-1.cisco.com with ESMTP; 07 Mar 2006 07:23:41 -0800
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k27FNeGv011931;
	Tue, 7 Mar 2006 07:23:40 -0800 (PST)
Received: (from kzm@localhost)
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA16108;
	Tue, 7 Mar 2006 07:23:40 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200603071523.HAA16108@cisco.com>
To: bwijnen@lucent.com
Date: Tue, 7 Mar 2006 07:23:40 -0800 (PST)
In-Reply-To: <no.id> from "Wijnen, Bert (Bert)" at Mar 06, 2006 07:33:51 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-Scan-Signature: e367d58950869b6582535ddf5a673488
Cc: silvano@ip6.com, cds@cisco.com, imss@ietf.org, kzm@cisco.com,
	dromasca@avaya.com, Black_David@emc.com, vgaonkar@cisco.com
Subject: [imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

Hi Bert,
 
> Summary:
> 
> looks good. I would be OK with doing IETF Last Call and consider these
> comments as initial IETF Last Call comments. At the other hand, IETF
> LC right before/during an IETF will not get many people to pay
> attention to this. Maybe you rather do a new rev first?
 
I'll do a new rev first, but it won't now get posted until after the IETF.

> more serious questions/issues:
> 
> SMICng tells me:
>   E: f(t11fcfspf.mi2), (915,54) Index item "t11FspfLinkIndex" must be
>      defined with syntax that includes a range
>   W: f(t11fcfspf.mi2), (1007,19) Variable "ifIndex" in notification
>      "t11FspfNbrStateChangNotify" is an index for a table
> 
> The warning is OK/acceptable as far as I am concerned.
> The Error would probably be best fixed.
 
SMICng is confused:

- t11FspfLinkIndex is defined as Unsigned32, which is defined with a
  range of (0..4294967295).  So, it does have a range (but see below).

- ifIndex is read-only.  RFC 2578 says (in section 7.3):

    The value "not-accessible" indicates an auxiliary object (see Section
    7.7).  The value "accessible-for-notify" indicates an object which is
    accessible only via a notification (e.g., snmpTrapOID [5]).

    These values are ordered, from least to greatest:  "not-accessible",
    "accessible-for-notify", "read-only", "read-write", "read-create".

  Since "read-only" is greater than "accessible-for-notify", it is
  both readable and accessible via a notification.  Indeed, consider
  the situation described in bullet (2) of section 7.7 of RFC 2578 --
  the only way to have a notification include any information from a row
  of a table for which all of the row's objects are also specified in
  its INDEX clause, is for it to include an object from the INDEX clause.

> SMILINT tells me:
> 
> C:\smi\mibs\work>smilint -m -s -l 6 ./T11-FC-FSPF-MIB
> ./T11-FC-FSPF-MIB:212: [5] {identifier-case-match} warning: identifier `t11FspfA
> RegionNum' differs from `T11FspfARegionNum' only in case
> ./T11-FC-FSPF-MIB:61: [6] {previous-definition} info: previous definition of `T1
> 1FspfARegionNum'
> ./T11-FC-FSPF-MIB:824: [5] {identifier-case-match} warning: identifier `t11FspfL
> srType' differs from `T11FspfLsrType' only in case
> ./T11-FC-FSPF-MIB:71: [6] {previous-definition} info: previous definition of `T1
> 1FspfLsrType'
> ./T11-FC-FSPF-MIB:964: [5] {identifier-case-match} warning: identifier `t11FspfL
> inkType' differs from `T11FspfLinkType' only in case
> ./T11-FC-FSPF-MIB:89: [6] {previous-definition} info: previous definition of `T1
> 1FspfLinkType'
> ./T11-FC-FSPF-MIB:61: [5] {type-without-format} warning: type `T11FspfARegionNum
> ' has no format specification
> ./T11-FC-FSPF-MIB:71: [5] {type-without-format} warning: type `T11FspfLsrType' h
> as no format specification
> ./T11-FC-FSPF-MIB:89: [5] {type-without-format} warning: type `T11FspfLinkType'
> has no format specification
> ./T11-FC-FSPF-MIB:129: [5] {type-without-format} warning: type `T11FspfLastCreat
> ionTime' has no format specification
> 
> The identifier-case-match are acceptable. They may confuse people though.
> 
> The type-without-format warnings are for your TCs.
> You may want to add a SIPLAY-HINT
 
Both section 3.1 of RFC 2579 and section 4.6.3 of RFC 4181 say that
the DISPLAY-HINT clause is optional/need not be present.
 
> - sect 5 states:
>    protocol.  (Note that there are no definitions in this MIB module of
>    "managed actions" which can be invoked via SNMP.)
>   So what does that mean for t11FspfSetToDefault, which to me seems to
>   be an action that can be invoked via SNMP??
>   Same for t11FspfIfSetToDefault
 
It depends on how one defines "action", and you're right that the term
"managed action" is not well-defined.  That sentence was added based on
a question that arose in T11.  The term "managed action" was intended
to mean a setRequest which caused a switch to send out a command in one
of the T11-defined protocols; for comparison, see some of the objects
defined in draft-ietf-imss-fc-fam-mib-03.txt (e.g., t11FamRestart).
Since that sentence is adding confusion, I will delete it.

> - redundant objects??
>   I do not see what the difference is between the follow two
>   (well, except SYNTAX). Is there any? If so, can that be made
>   clear in the DESCRIPTION clauses? If not, can one be removed?
> 
>   t11FspfLsrs OBJECT-TYPE
>     SYNTAX      Gauge32
>     MAX-ACCESS  read-only
>     STATUS      current
>     DESCRIPTION
>            "The current number of entries for this Fabric in the
>            t11FspfLsrTable."
>     ::= { t11FspfEntry 19 }
> 
>   t11FspfLsrNumber  OBJECT-TYPE
>     SYNTAX      Unsigned32 (0..2147483647)
>     MAX-ACCESS  read-only
>     STATUS      current
>     DESCRIPTION
>            "The current number of rows for this fabric in the
>            t11FspfLsrTable."
>     ::= { t11FspfEntry 23 }
 
Thanks for spotting that.  I will remove one of them.

> - t11FspfStorageType
>   Which writeable objects must be writable for a 'permanent' row?
 
Since I already succumbed in adding the sentence that you're looking
for to t11FspfIfStorageType, I will (so as to be consistent) add it to
t11FspfStorageType also.

However, the requirement at the top of page 23 in RFC 4181 is bogus
because: a) a requirement which says that an "object must be writeable"
under some particular circumstance is for the minimum requried access,
i.e., MIN-ACCESS, and belongs in MODULE-COMPLIANCE, not in OBJECT-TYPE,
b) in this case, all of the accessible objects in this table have a
MIN-ACCESS of read-only.  So, the answer to your question is already
present in the document.

> - Mmm. I find the way you delete a row in t11FspfIfRowStatus
>   a bit strange/weird. But I guess I can live with it.
>   Can you explain why you do it this way?

Because:

1. having unnecessary rows in this table clutters it up, and makes
   those rows that are useful harder for a NMS to find.
2. having the current value always be in same object, irrespective of
   whether it is a default or a non-default value is desirable. 
3. when non-default values are specified for a port's parameters,
   they need to be retained in the MIB even when the port is 'isolated'.
4. when an E_Port becomes isolated, we want its row to get deleted
   if and only if all of its parameter values are the default values.

> - t11FspfLinkIndex probably better specifies a range that excludes zero ??
>   see also smicng error above.
 
The smicng error is confused, but I agree it would be better to exclude
zero, and I'll change it to do so.

> admin/nits and just questions for clarity/explanation
> 
> - I see:
>     t11FspfIfNbrPortIndex OBJECT-TYPE
>         SYNTAX      Unsigned32 (1..4294967295)
> 
>     t11FspfLinkPortIndex OBJECT-TYPE
>         SYNTAX      Unsigned32 (0..16777215)
> 
>     t11FspfLinkNbrPortIndex OBJECT-TYPE
>         SYNTAX      Unsigned32 (0..16777215)
> 
>   Is it just me who wonders about the different ranges??
>   Maybe I am missing something or misunderstanding.
     
The format of the FSPF protocol packets as shown in FC-SW-4 indicates
that the port number field is 3 bytes long.  Hence, (0..16777215) is
correct, and (1..4294967295) is incorrect -- I will change
t11FspfIfNbrPortIndex.

> - I wonder what a value of zero means for T11FspfLinkType
>   If it can never exist, would it be better to make the range
>   (1..255) ??
 
The only difference between the definition in the MIB and the definition
pointed to by the REFERENCE clause is that FC-SW-4 says "all others"
rather than just "others", i.e., zero is a reserved value.  I can add
"all" into the DESCRIPTION.

> - I wonder if T11FspfLsrType and T11FspfLinkType would be better
>   defined with a base type of INTEGER? In other words Enumerations?
 
This is a trade-off between having the MIB definition being more
explicit or more open-ended.  As these objects are currently defined,
they implicitly get any new values as and when T11 defines new values
for that field.  Having them as enumerations would be more explicit,
but would require a MIB change to incorporate newly defined values.  I
think this trade-off should be made individually for each object on its
own merits.

> - I wonder how new non-Vendor-Specific values for T11FspfLsrType 
>   and T11FspfLinkType will be assigned/allocated?
>   Probably by T11? Would not hurt to say something about that.

Both of those TC's have a REFERENCE clause pointing to a T11 spec.
That particular spec doesn't define the term "Vendor Specific" (and 
I'm not sure which, if any, T11 spec does define it), but if I
understand correctly, in T11 the term means that it is the vendors who
define such values and that different vendors can (and do) have
different meanings for the same value, i.e., they are reserved but
*not* allocated by an IANA-equivalent organization.  A network manager
managing a Fibre Channel has to know this, not because of SNMP or the
MIB, but because of Fibre Channel.

> - I suspect that the RFCyyyy in t11FspfAdminStatus REFERENCE clause
>   is (or should be) a different yyyy than the one in the
>   MODULE-IDENTITY macro?

Right. I'll change t11FspfAdminStatus to use zzzz.

> - In a number of places I would prefer to see "MIB module" instead
>   of just "MIB". But I cam live with if if this is the doc does not
>   need changing for anything else.

I'll look for them.

> - Section 7 is redundant and contains same material as the back matter.
 
Right.

Thanks,
Keith.

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



From imss-bounces@ietf.org Wed Mar 08 10:21:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FH0TH-0001lT-ME; Wed, 08 Mar 2006 10:21:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FH0TH-0001lO-63
	for imss@ietf.org; Wed, 08 Mar 2006 10:21:03 -0500
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FH0TG-0005C3-SM
	for imss@ietf.org; Wed, 08 Mar 2006 10:21:03 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-1.cisco.com with ESMTP; 08 Mar 2006 07:21:02 -0800
Received: from cisco.com (cypher.cisco.com [171.69.11.142])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k28FL17T023754;
	Wed, 8 Mar 2006 07:21:01 -0800 (PST)
Received: (from kzm@localhost)
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) id HAA21168;
	Wed, 8 Mar 2006 07:21:01 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200603081521.HAA21168@cisco.com>
To: bwijnen@lucent.com ("Wijnen, Bert (Bert)")
Date: Wed, 8 Mar 2006 07:21:01 -0800 (PST)
In-Reply-To: <no.id> from "Wijnen, Bert (Bert)" at Mar 06, 2006 07:33:52 PM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.8 (+)
X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2
Cc: sgai@cisco.com, cds@cisco.com, "\"Imss E-mail" <imss@ietf.org>,
	"\"Keith McCloghrie E-mail" <kzm@cisco.com>,
	"\"Dan Romascanu E-mail" <dromasca@avaya.com>, skode@cisco.com,
	Black_David@emc.com
Subject: [imss] Re: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

Bert,

Thanks for the review.

> This document is ready for IETF Last Call.
> 
> One topic that I would prefer to see addressed:
> 
> - When I see:
>     t11FcRouteDestAddrId OBJECT-TYPE
>        SYNTAX      FcAddressIdOrZero
>        MAX-ACCESS  not-accessible
>        STATUS      current
>        DESCRIPTION
>            "The destination Fibre Channel Address Identifier of
>            this route.  A zero-length string for this field is
>            not allowed."
>        ::= { t11FcRouteEntry 1 }
> 
>   I then wonder why the syntax is not:
> 
>       SYNTAX      FcAddressIdOrZero (SIZE(3))
> 
>   So that the restriction that zero-length is not allowed is
>   also machine readable.
 
While I agree in principle, I think it also has one other effect: 
it changes t11FcRouteDestAddrId from being a variable-length string
into a fixed-length string, which only matters because 
t11FcRouteDestAddrId is present in the INDEX clause, and thus,
I fear that some implementations might get the INDEX-ing wrong (re:
difference between bullets 2 and 3 at top of RFC 2578's page 28).
Thus, if you really want to see the restriction reflected in the
SYNTAX clause, I would prefer to do so as:

       SYNTAX      OCTET STRING (SIZE (3))

so that it uses a regular construct, and implementors will immediately
know what to do.  Do you agree ?

>   Could be addressesd after IETF Last Call, even with an RFC-Editor note.
> 
> Mainly have some NITs below.
> You may consider them as initial IETF Last Call comments.
> Let me know if you rather do a new rev first or if you
> prefer to do IETF LC now. I will probably let IETF LC extend
> beyond the IETF week, because people are probably busy reviewing
> documents for the IETF week itself.
 
I'd prefer to fix them now, but I'll wait for your response to this
message before doing so.

> - t11FcRouteRowStatus has a pretty meager DESCRIPTION clause
>   For example, from the DESCRIPTION clause of t11FcRouteIfDown
>   it seems that maybe a 'destroy' to the RowStatus object
>   may not take immediate effect? You might want to describe that.
>   It is also unclear if any writeable objects can be written
>   when a row is active?
 
The last sentence of RowStatus's DESCRIPTION in RFC 2579 says that
a 'destroy' requires the row to be removed immediately.  There was
discussion in T11.5 of the relationship between this table and the
routing mechanisms that a FC switch uses, and we agreed that such a
relationship is proprietary, and that the MIB needs to stay at
arms-length from being too specific about this relationship.  Thus, I
would prefer not to add text talking about it.

There is one thing I can add, which is implicit in t11FcRouteTable's
DESCRIPTION, but it would probably be useful to add a more explicit
statement in t11FcRouteRowStatus's DESCRIPTION:

         The only rows which can be deleted by setting this object to
         'destroy' are those for which t11FcRouteProto has the value
         'netmgmt'.

Then, it won't be so meagre :-).
 
> - The 4 OBJECT clauses that you did as comments in the
>   MODULE-COMPLIANCE are normally put as comments inside the
>   DESCRIPTION clause of the MODULE-COMPLIANCE clause itself.
>   That way the text is better kept when MIB module gets
>   extracted from RFC. Not a blocking comment though.
 
OK, I'll move them.  (The downside is that the double-quotes have to
change, e.g., to single-quotes).

> - Section 7 seems redundant with the back matter, and might as
>   well be removed.
 
I'll let the RFC Editor do that.

> - In the references section, are the details for [FC-SW-4] now
>   known? If so, might want to fill them out.

Yes, we filled them in recently on one of the other FC MIBs.
Thanks for reminding me of that.

Keith.

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



From imss-bounces@ietf.org Wed Mar 08 15:16:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FH55N-0000PK-4Z; Wed, 08 Mar 2006 15:16:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FH55L-0000PA-Rm
	for imss@ietf.org; Wed, 08 Mar 2006 15:16:39 -0500
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH55L-00074v-HS
	for imss@ietf.org; Wed, 08 Mar 2006 15:16:39 -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 k28KGWjC023323; 
	Wed, 8 Mar 2006 14:16:32 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <G3YWVF13>; Wed, 8 Mar 2006 21:16:31 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097B9796@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Keith McCloghrie <kzm@cisco.com>
Date: Wed, 8 Mar 2006 21:16:31 +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: sgai@cisco.com, cds@cisco.com, imss@ietf.org, dromasca@avaya.com,
	skode@cisco.com, Black_David@emc.com
Subject: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

Inline

> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Wednesday, March 08, 2006 16:21
> To: bwijnen@lucent.com
> Cc: Black_David@emc.com; cds@cisco.com; skode@cisco.com; 
> kzm@cisco.com;
> sgai@cisco.com; imss@ietf.org; dromasca@avaya.com
> Subject: Re: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt
> 
> 
> Bert,
> 
> Thanks for the review.
> 
Welcome

> > This document is ready for IETF Last Call.
> > 
> > One topic that I would prefer to see addressed:
> > 
> > - When I see:
> >     t11FcRouteDestAddrId OBJECT-TYPE
> >        SYNTAX      FcAddressIdOrZero
> >        MAX-ACCESS  not-accessible
> >        STATUS      current
> >        DESCRIPTION
> >            "The destination Fibre Channel Address Identifier of
> >            this route.  A zero-length string for this field is
> >            not allowed."
> >        ::= { t11FcRouteEntry 1 }
> > 
> >   I then wonder why the syntax is not:
> > 
> >       SYNTAX      FcAddressIdOrZero (SIZE(3))
> > 
> >   So that the restriction that zero-length is not allowed is
> >   also machine readable.
>  
> While I agree in principle, I think it also has one other effect: 
> it changes t11FcRouteDestAddrId from being a variable-length string
> into a fixed-length string, which only matters because 
> t11FcRouteDestAddrId is present in the INDEX clause, and thus,
> I fear that some implementations might get the INDEX-ing wrong (re:
> difference between bullets 2 and 3 at top of RFC 2578's page 28).
> Thus, if you really want to see the restriction reflected in the
> SYNTAX clause, I would prefer to do so as:
> 
>        SYNTAX      OCTET STRING (SIZE (3))
> 
> so that it uses a regular construct, and implementors will immediately
> know what to do.  Do you agree ?
> 

Thanks Keith, I had overlooked that aspect of variable length for indexing.
Using OCTET STRING as you suggest does fix my initial comment, but then
takes away that this is a FCAddressId.
So I am not sure which choice I prefer. Does WG have any comments?
Are there any implementers on the list who want to comment?

So I have no firm opinion on which choice I like best anymore.


> From imss-bounces@ietf.org Wed Mar 08 15:16:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FH55N-0000PK-4Z; Wed, 08 Mar 2006 15:16:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FH55L-0000PA-Rm
	for imss@ietf.org; Wed, 08 Mar 2006 15:16:39 -0500
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH55L-00074v-HS
	for imss@ietf.org; Wed, 08 Mar 2006 15:16:39 -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 k28KGWjC023323; 
	Wed, 8 Mar 2006 14:16:32 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <G3YWVF13>; Wed, 8 Mar 2006 21:16:31 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097B9796@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Keith McCloghrie <kzm@cisco.com>
Date: Wed, 8 Mar 2006 21:16:31 +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: sgai@cisco.com, cds@cisco.com, imss@ietf.org, dromasca@avaya.com,
	skode@cisco.com, Black_David@emc.com
Subject: [imss] RE: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

Inline

> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Wednesday, March 08, 2006 16:21
> To: bwijnen@lucent.com
> Cc: Black_David@emc.com; cds@cisco.com; skode@cisco.com; 
> kzm@cisco.com;
> sgai@cisco.com; imss@ietf.org; dromasca@avaya.com
> Subject: Re: AD review of: draft-ietf-imss-fc-rtm-mib-02.txt
> 
> 
> Bert,
> 
> Thanks for the review.
> 
Welcome

> > This document is ready for IETF Last Call.
> > 
> > One topic that I would prefer to see addressed:
> > 
> > - When I see:
> >     t11FcRouteDestAddrId OBJECT-TYPE
> >        SYNTAX      FcAddressIdOrZero
> >        MAX-ACCESS  not-accessible
> >        STATUS      current
> >        DESCRIPTION
> >            "The destination Fibre Channel Address Identifier of
> >            this route.  A zero-length string for this field is
> >            not allowed."
> >        ::= { t11FcRouteEntry 1 }
> > 
> >   I then wonder why the syntax is not:
> > 
> >       SYNTAX      FcAddressIdOrZero (SIZE(3))
> > 
> >   So that the restriction that zero-length is not allowed is
> >   also machine readable.
>  
> While I agree in principle, I think it also has one other effect: 
> it changes t11FcRouteDestAddrId from being a variable-length string
> into a fixed-length string, which only matters because 
> t11FcRouteDestAddrId is present in the INDEX clause, and thus,
> I fear that some implementations might get the INDEX-ing wrong (re:
> difference between bullets 2 and 3 at top of RFC 2578's page 28).
> Thus, if you really want to see the restriction reflected in the
> SYNTAX clause, I would prefer to do so as:
> 
>        SYNTAX      OCTET STRING (SIZE (3))
> 
> so that it uses a regular construct, and implementors will immediately
> know what to do.  Do you agree ?
> 

Thanks Keith, I had overlooked that aspect of variable length for indexing.
Using OCTET STRING as you suggest does fix my initial comment, but then
takes away that this is a FCAddressId.
So I am not sure which choice I prefer. Does WG have any comments?
Are there any implementers on the list who want to comment?

So I have no firm opinion on which choice I like best anymore.


> >   Could be addressesd after IETF Last Call, even with an 
> RFC-Editor note.
> > 
> > Mainly have some NITs below.
> > You may consider them as initial IETF Last Call comments.
> > Let me know if you rather do a new rev first or if you
> > prefer to do IETF LC now. I will probably let IETF LC extend
> > beyond the IETF week, because people are probably busy reviewing
> > documents for the IETF week itself.
>  
> I'd prefer to fix them now, but I'll wait for your response to this
> message before doing so.
> 
> > - t11FcRouteRowStatus has a pretty meager DESCRIPTION clause
> >   For example, from the DESCRIPTION clause of t11FcRouteIfDown
> >   it seems that maybe a 'destroy' to the RowStatus object
> >   may not take immediate effect? You might want to describe that.
> >   It is also unclear if any writeable objects can be written
> >   when a row is active?
>  
> The last sentence of RowStatus's DESCRIPTION in RFC 2579 says that
> a 'destroy' requires the row to be removed immediately.  There was
> discussion in T11.5 of the relationship between this table and the
> routing mechanisms that a FC switch uses, and we agreed that such a
> relationship is proprietary, and that the MIB needs to stay at
> arms-length from being too specific about this relationship.  Thus, I
> would prefer not to add text talking about it.
> 
> There is one thing I can add, which is implicit in t11FcRouteTable's
> DESCRIPTION, but it would probably be useful to add a more explicit
> statement in t11FcRouteRowStatus's DESCRIPTION:
> 
>          The only rows which can be deleted by setting this object to
>          'destroy' are those for which t11FcRouteProto has the value
>          'netmgmt'.
> 
> Then, it won't be so meagre :-).
>  

Good.

> > - The 4 OBJECT clauses that you did as comments in the
> >   MODULE-COMPLIANCE are normally put as comments inside the
> >   DESCRIPTION clause of the MODULE-COMPLIANCE clause itself.
> >   That way the text is better kept when MIB module gets
> >   extracted from RFC. Not a blocking comment though.
>  
> OK, I'll move them.  (The downside is that the double-quotes have to
> change, e.g., to single-quotes).
> 
yep, but thanks for moving them. I think it makes IETF MIB docs more
consistent. And I just happen to like consistency in this space.


> > - Section 7 seems redundant with the back matter, and might as
> >   well be removed.
>  
> I'll let the RFC Editor do that.
> 

Mmm... why is that?
If you do a new rev anyway, why not just make it right BEFORE it
goes to RFC-Editor?

> > - In the references section, are the details for [FC-SW-4] now
> >   known? If so, might want to fill them out.
> 
> Yes, we filled them in recently on one of the other FC MIBs.
> Thanks for reminding me of that.
> 

Thanks,
Bert
> Keith.
> 

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

From imss-bounces@ietf.org Wed Mar 08 15:16:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FH55O-0000Pq-6x; Wed, 08 Mar 2006 15:16:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FH55M-0000PF-QO
	for imss@ietf.org; Wed, 08 Mar 2006 15:16:40 -0500
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH55M-00074z-9G
	for imss@ietf.org; Wed, 08 Mar 2006 15:16:40 -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 k28KGZ0a023366; 
	Wed, 8 Mar 2006 14:16:35 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <G3YWVF1Q>; Wed, 8 Mar 2006 21:16:34 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097B9797@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Keith McCloghrie <kzm@cisco.com>
Subject: RE: [imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
Date: Wed, 8 Mar 2006 21:16:31 +0100 
MIME-Version: 1>   Could be addressesd after IETF Last Call, even with an 
> RFC-Editor note.
> > 
> > Mainly have some NITs below.
> > You may consider them as initial IETF Last Call comments.
> > Let me know if you rather do a new rev first or if you
> > prefer to do IETF LC now. I will probably let IETF LC extend
> > beyond the IETF week, because people are probably busy reviewing
> > documents for the IETF week itself.
>  
> I'd prefer to fix them now, but I'll wait for your response to this
> message before doing so.
> 
> > - t11FcRouteRowStatus has a pretty meager DESCRIPTION clause
> >   For example, from the DESCRIPTION clause of t11FcRouteIfDown
> >   it seems that maybe a 'destroy' to the RowStatus object
> >   may not take immediate effect? You might want to describe that.
> >   It is also unclear if any writeable objects can be written
> >   when a row is active?
>  
> The last sentence of RowStatus's DESCRIPTION in RFC 2579 says that
> a 'destroy' requires the row to be removed immediately.  There was
> discussion in T11.5 of the relationship between this table and the
> routing mechanisms that a FC switch uses, and we agreed that such a
> relationship is proprietary, and that the MIB needs to stay at
> arms-length from being too specific about this relationship.  Thus, I
> would prefer not to add text talking about it.
> 
> There is one thing I can add, which is implicit in t11FcRouteTable's
> DESCRIPTION, but it would probably be useful to add a more explicit
> statement in t11FcRouteRowStatus's DESCRIPTION:
> 
>          The only rows which can be deleted by setting this object to
>          'destroy' are those for which t11FcRouteProto has the value
>          'netmgmt'.
> 
> Then, it won't be so meagre :-).
>  

Good.

> > - The 4 OBJECT clauses that you did as comments in the
> >   MODULE-COMPLIANCE are normally put as comments inside the
> >   DESCRIPTION clause of the MODULE-COMPLIANCE clause itself.
> >   That way the text is better kept when MIB module gets
> >   extracted from RFC. Not a blocking comment though.
>  
> OK, I'll move them.  (The downside is that the double-quotes have to
> change, e.g., to single-quotes).
> 
yep, but thanks for moving them. I think it makes IETF MIB docs more
consistent. And I just happen to like consistency in this space.


> > - Section 7 seems redundant with the back matter, and might as
> >   well be removed.
>  
> I'll let the RFC Editor do that.
> 

Mmm... why is that?
If you do a new rev anyway, why not just make it right BEFORE it
goes to RFC-Editor?

> > - In the references section, are the details for [FC-SW-4] now
> >   known? If so, might want to fill them out.
> 
> Yes, we filled them in recently on one of the other FC MIBs.
> Thanks for reminding me of that.
> 

Thanks,
Bert
> Keith.
> 

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

From imss-bounces@ietf.org Wed Mar 08 15:16:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FH55O-0000Pq-6x; Wed, 08 Mar 2006 15:16:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FH55M-0000PF-QO
	for imss@ietf.org; Wed, 08 Mar 2006 15:16:40 -0500
Received: from ihemail1.lucent.com ([192.11.222.161])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH55M-00074z-9G
	for imss@ietf.org; Wed, 08 Mar 2006 15:16:40 -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 k28KGZ0a023366; 
	Wed, 8 Mar 2006 14:16:35 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <G3YWVF1Q>; Wed, 8 Mar 2006 21:16:34 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097B9797@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Keith McCloghrie <kzm@cisco.com>
Subject: RE: [imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
Date: Wed, 8 Mar 2006 21:16:31 +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: 2c12be3f3a8d57895fb9c003e1517c01
Cc: silvano@ip6.com, cds@cisco.com, imss@ietf.org, dromasca@avaya.com,
	Black_David@emc.com, vgaonkar@cisco.com
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

Inline

> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Tuesday, March 07, 2006 16:24
> To: bwijnen@lucent.com
> Cc: silvano@ip6.com; cds@cisco.com; imss@ietf.org; kzm@cisco.com;
> dromasca@avaya.com; Black_David@emc.com; vgaonkar@cisco.com
> Subject: [imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
> 
> 
> Hi Bert,
>  
> > Summary:
> > 
> > looks good. I would be OK with doing IETF Last Call and consider these
> > comments as initial IETF Last Call comments. At the other hand, IETF
> > LC right before/during an IETF will not get many people to pay
> > attention to this. Maybe you rather do a new rev first?
>  
> I'll do a new rev first, but it won't now get posted until 
> after the IETF.
> 

I think the repository opens on Monday of IETF week already.

> > more serious questions/issues:
> > 
> > SMICng tells me:
> >   E: f(t11fcfspf.mi2), (915,54) Index item "t11FspfLinkIndex" must be
> >      defined with syntax that includes a range
> >   W: f(t11fcfspf.mi2), (1007,19) Variable "ifIndex" in notification
> >      "t11FspfNbrStateChangNotify" is an index for a table
> > 
> > The warning is OK/acceptable as far as I am concerned.
> > The Error would probably be best fixed.
>  
> SMICng is confused:
> 
> - t11FspfLinkIndex is defined as Unsigned32, which is defined with a
>   range of (0..4294967295).  So, it does have a range (but see below).
> 
seem my comment below

> - ifIndex is read-only.  RFC 2578 says (in section 7.3):
> 
>     The value "not-accessible" indicates an auxiliary object (see Section
>     7.7).  The value "accessible-for-notify" indicates an object which is
>     accessible only via a notification (e.g., snmpTrapOID [5]).
> 
>     These values are ordered, from least to greatest:  "not-accessible",
>     "accessible-for-notify", "read-only", "read-write", "read-create".
> 
>   Since "read-only" is greater than "accessible-for-notify", it is
>   both readable and accessible via a notification.  Indeed, consider
>   the situation described in bullet (2) of section 7.7 of RFC 2578 --
>   the only way to have a notification include any information from a row
>   of a table for which all of the row's objects are also specified in
>   its INDEX clause, is for it to include an object from the INDEX clause.
> 

Understood, but we do have the desire to not include INDEX items.
For ifIndex, one could have used ifDescr.
I would further think that t11FspfIfNbrDomainId also already includes 
the ifIndex in its INDEX part of the OID.
But I agree with you that this is not a big issue, as I said above:

   The warning is OK/acceptable as far as I am concerned.


> > SMILINT tells me:
> > 
> > C:\smi\mibs\work>smilint -m -s -l 6 ./T11-FC-FSPF-MIB
> > ./T11-FC-FSPF-MIB:212: [5] {identifier-case-match} warning: 
> identifier `t11FspfA
> > RegionNum' differs from `T11FspfARegionNum' only in case
> > ./T11-FC-FSPF-MIB:61: [6] {previous-definition} info: 
> previous definition of `T1
> > 1FspfARegionNum'
> > ./T11-FC-FSPF-MIB:824: [5] {identifier-case-match} warning: 
> identifier `t11FspfL
> > srType' differs from `T11FspfLsrType' only in case
> > ./T11-FC-FSPF-MIB:71: [6] {previous-definition} info: 
> previous definition of `T1
> > 1FspfLsrType'
> > ./T11-FC-FSPF-MIB:964: [5] {identifier-case-match} warning: 
> identifie.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01
Cc: silvano@ip6.com, cds@cisco.com, imss@ietf.org, dromasca@avaya.com,
	Black_David@emc.com, vgaonkar@cisco.com
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

Inline

> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm@cisco.com]
> Sent: Tuesday, March 07, 2006 16:24
> To: bwijnen@lucent.com
> Cc: silvano@ip6.com; cds@cisco.com; imss@ietf.org; kzm@cisco.com;
> dromasca@avaya.com; Black_David@emc.com; vgaonkar@cisco.com
> Subject: [imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
> 
> 
> Hi Bert,
>  
> > Summary:
> > 
> > looks good. I would be OK with doing IETF Last Call and consider these
> > comments as initial IETF Last Call comments. At the other hand, IETF
> > LC right before/during an IETF will not get many people to pay
> > attention to this. Maybe you rather do a new rev first?
>  
> I'll do a new rev first, but it won't now get posted until 
> after the IETF.
> 

I think the repository opens on Monday of IETF week already.

> > more serious questions/issues:
> > 
> > SMICng tells me:
> >   E: f(t11fcfspf.mi2), (915,54) Index item "t11FspfLinkIndex" must be
> >      defined with syntax that includes a range
> >   W: f(t11fcfspf.mi2), (1007,19) Variable "ifIndex" in notification
> >      "t11FspfNbrStateChangNotify" is an index for a table
> > 
> > The warning is OK/acceptable as far as I am concerned.
> > The Error would probably be best fixed.
>  
> SMICng is confused:
> 
> - t11FspfLinkIndex is defined as Unsigned32, which is defined with a
>   range of (0..4294967295).  So, it does have a range (but see below).
> 
seem my comment below

> - ifIndex is read-only.  RFC 2578 says (in section 7.3):
> 
>     The value "not-accessible" indicates an auxiliary object (see Section
>     7.7).  The value "accessible-for-notify" indicates an object which is
>     accessible only via a notification (e.g., snmpTrapOID [5]).
> 
>     These values are ordered, from least to greatest:  "not-accessible",
>     "accessible-for-notify", "read-only", "read-write", "read-create".
> 
>   Since "read-only" is greater than "accessible-for-notify", it is
>   both readable and accessible via a notification.  Indeed, consider
>   the situation described in bullet (2) of section 7.7 of RFC 2578 --
>   the only way to have a notification include any information from a row
>   of a table for which all of the row's objects are also specified in
>   its INDEX clause, is for it to include an object from the INDEX clause.
> 

Understood, but we do have the desire to not include INDEX items.
For ifIndex, one could have used ifDescr.
I would further think that t11FspfIfNbrDomainId also already includes 
the ifIndex in its INDEX part of the OID.
But I agree with you that this is not a big issue, as I said above:

   The warning is OK/acceptable as far as I am concerned.


> > SMILINT tells me:
> > 
> > C:\smi\mibs\work>smilint -m -s -l 6 ./T11-FC-FSPF-MIB
> > ./T11-FC-FSPF-MIB:212: [5] {identifier-case-match} warning: 
> identifier `t11FspfA
> > RegionNum' differs from `T11FspfARegionNum' only in case
> > ./T11-FC-FSPF-MIB:61: [6] {previous-definition} info: 
> previous definition of `T1
> > 1FspfARegionNum'
> > ./T11-FC-FSPF-MIB:824: [5] {identifier-case-match} warning: 
> identifier `t11FspfL
> > srType' differs from `T11FspfLsrType' only in case
> > ./T11-FC-FSPF-MIB:71: [6] {previous-definition} info: 
> previous definition of `T1
> > 1FspfLsrType'
> > ./T11-FC-FSPF-MIB:964: [5] {identifier-case-match} warning: 
> identifier `t11FspfL
> > inkType' differs from `T11FspfLinkType' only in case
> > ./T11-FC-FSPF-MIB:89: [6] {previous-definition} info: 
> previous definition of `T1
> > 1FspfLinkType'
> > ./T11-FC-FSPF-MIB:61: [5] {type-without-format} warning: 
> type `T11FspfARegionNum
> > ' has no format specification
> > ./T11-FC-FSPF-MIB:71: [5] {type-without-format} warning: 
> type `T11FspfLsrType' h
> > as no format specification
> > ./T11-FC-FSPF-MIB:89: [5] {type-without-format} warning: 
> type `T11FspfLinkType'
> > has no format specification
> > ./T11-FC-FSPF-MIB:129: [5] {type-without-format} warning: 
> type `T11FspfLastCreat
> > ionTime' has no format specification
> > 
> > The identifier-case-match are acceptable. They may confuse 
> people though.
> > 
> > The type-without-format warnings are for your TCs.
> > You may want to add a SIPLAY-HINT
>  
> Both section 3.1 of RFC 2579 and section 4.6.3 of RFC 4181 say that
> the DISPLAY-HINT clause is optional/need not be present.
>  

As I said: you MAY want to add a DISPLAY-HINT (well I see I misspelled it)
so I will appreciate if you do, but I won't get sleepless nights if you don't.

> > - sect 5 states:
> >    protocol.  (Note that there are no definitions in this MIB module of
> >    "managed actions" which can be invoked via SNMP.)
> >   So what does that mean for t11FspfSetToDefault, which to me seems to
> >   be an action that can be invoked via SNMP??
> >   Same for t11FspfIfSetToDefault
>  
> It depends on how one defines "action", and you're right that the term
> "managed action" is not well-defined.  That sentence was added based on
> a question that arose in T11.  The term "managed action" was intended
> to mean a setRequest which caused a switch to send out a command in one
> of the T11-defined protocols; for comparison, see some of the objects
> defined in draft-ietf-imss-fc-fam-mib-03.txt (e.g., t11FamRestart).
> Since that sentence is adding confusion, I will delete it.
> 
Thanks

> > - redundant objects??
> >   I do not see what the difference is between the follow two
> >   (well, except SYNTAX). Is there any? If so, can that be made
> >   clear in the DESCRIPTION clauses? If not, can one be removed?
> > 
> >   t11FspfLsrs OBJECT-TYPE
> >     SYNTAX      Gauge32
> >     MAX-ACCESS  read-only
> >     STATUS      current
> >     DESCRIPTION
> >            "The current number of entries for this Fabric in the
> >            t11FspfLsrTable."
> >     ::= { t11FspfEntry 19 }
> > 
> >   t11FspfLsrNumber  OBJECT-TYPE
> >     SYNTAX      Unsigned32 (0..2147483647)
> >     MAX-ACCESS  read-only
> >     STATUS      current
> >     DESCRIPTION
> >            "The current number of rows for this fabric in the
> >            t11FspfLsrTable."
> >     ::= { t11FspfEntry 23 }
>  
> Thanks for spotting that.  I will remove one of them.
> 
Good

> > - t11FspfStorageType
> >   Which writeable objects must be writable for a 'permanent' row?
>  
> Since I already succumbed in adding the sentence that you're looking
> for to t11FspfIfStorageType, I will (so as to be consistent) add it to
> t11FspfStorageType also.
> 
Mmm.. my comment was/is mainly based on text from RFC2579 (on of yours):
StorageType ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "Describes the memory realization of a conceptual row.  A
            row which is volatile(2) is lost upon reboot.  A row which
            is either nonVolatile(3), permanent(4) or readOnly(5), is
            backed up by stable storage.  A row which is permanent(4)
            can be changed but not deleted.  A row which is readOnly(5)
            cannot be changed nor deleted.

            If the value of an object with this syntax is either
            permanent(4) or readOnly(5), it cannot be written.
            Conversely, if the value is either other(1), volatile(2) or
            nonVolatile(3), it cannot be modified to be permanent(4) or
            readOnly(5).  (All illegal modifications result in a
            'wrongValue' error.)

            Every usage of this textual convention is required to
    r `t11FspfL
> > inkType' differs from `T11FspfLinkType' only in case
> > ./T11-FC-FSPF-MIB:89: [6] {previous-definition} info: 
> previous definition of `T1
> > 1FspfLinkType'
> > ./T11-FC-FSPF-MIB:61: [5] {type-without-format} warning: 
> type `T11FspfARegionNum
> > ' has no format specification
> > ./T11-FC-FSPF-MIB:71: [5] {type-without-format} warning: 
> type `T11FspfLsrType' h
> > as no format specification
> > ./T11-FC-FSPF-MIB:89: [5] {type-without-format} warning: 
> type `T11FspfLinkType'
> > has no format specification
> > ./T11-FC-FSPF-MIB:129: [5] {type-without-format} warning: 
> type `T11FspfLastCreat
> > ionTime' has no format specification
> > 
> > The identifier-case-match are acceptable. They may confuse 
> people though.
> > 
> > The type-without-format warnings are for your TCs.
> > You may want to add a SIPLAY-HINT
>  
> Both section 3.1 of RFC 2579 and section 4.6.3 of RFC 4181 say that
> the DISPLAY-HINT clause is optional/need not be present.
>  

As I said: you MAY want to add a DISPLAY-HINT (well I see I misspelled it)
so I will appreciate if you do, but I won't get sleepless nights if you don't.

> > - sect 5 states:
> >    protocol.  (Note that there are no definitions in this MIB module of
> >    "managed actions" which can be invoked via SNMP.)
> >   So what does that mean for t11FspfSetToDefault, which to me seems to
> >   be an action that can be invoked via SNMP??
> >   Same for t11FspfIfSetToDefault
>  
> It depends on how one defines "action", and you're right that the term
> "managed action" is not well-defined.  That sentence was added based on
> a question that arose in T11.  The term "managed action" was intended
> to mean a setRequest which caused a switch to send out a command in one
> of the T11-defined protocols; for comparison, see some of the objects
> defined in draft-ietf-imss-fc-fam-mib-03.txt (e.g., t11FamRestart).
> Since that sentence is adding confusion, I will delete it.
> 
Thanks

> > - redundant objects??
> >   I do not see what the difference is between the follow two
> >   (well, except SYNTAX). Is there any? If so, can that be made
> >   clear in the DESCRIPTION clauses? If not, can one be removed?
> > 
> >   t11FspfLsrs OBJECT-TYPE
> >     SYNTAX      Gauge32
> >     MAX-ACCESS  read-only
> >     STATUS      current
> >     DESCRIPTION
> >            "The current number of entries for this Fabric in the
> >            t11FspfLsrTable."
> >     ::= { t11FspfEntry 19 }
> > 
> >   t11FspfLsrNumber  OBJECT-TYPE
> >     SYNTAX      Unsigned32 (0..2147483647)
> >     MAX-ACCESS  read-only
> >     STATUS      current
> >     DESCRIPTION
> >            "The current number of rows for this fabric in the
> >            t11FspfLsrTable."
> >     ::= { t11FspfEntry 23 }
>  
> Thanks for spotting that.  I will remove one of them.
> 
Good

> > - t11FspfStorageType
> >   Which writeable objects must be writable for a 'permanent' row?
>  
> Since I already succumbed in adding the sentence that you're looking
> for to t11FspfIfStorageType, I will (so as to be consistent) add it to
> t11FspfStorageType also.
> 
Mmm.. my comment was/is mainly based on text from RFC2579 (on of yours):
StorageType ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "Describes the memory realization of a conceptual row.  A
            row which is volatile(2) is lost upon reboot.  A row which
            is either nonVolatile(3), permanent(4) or readOnly(5), is
            backed up by stable storage.  A row which is permanent(4)
            can be changed but not deleted.  A row which is readOnly(5)
            cannot be changed nor deleted.

            If the value of an object with this syntax is either
            permanent(4) or readOnly(5), it cannot be written.
            Conversely, if the value is either other(1), volatile(2) or
            nonVolatile(3), it cannot be modified to be permanent(4) or
            readOnly(5).  (All illegal modifications result in a
            'wrongValue' error.)

            Every usage of this textual convention is required to
            specify the columnar objects which a permanent(4) row must
            at a minimum allow to be writable."

So that last sentence to me seems to require it.


> However, the requirement at the top of page 23 in RFC 4181 is bogus
> because: a) a requirement which says that an "object must be 
> writeable"
> under some particular circumstance is for the minimum requried access,
> i.e., MIN-ACCESS, and belongs in MODULE-COMPLIANCE, not in 
> OBJECT-TYPE,
> b) in this case, all of the accessible objects in this table have a
> MIN-ACCESS of read-only.  So, the answer to your question is already
> present in the document.
> 

Mmm... I thought the MIN-ACCESS in the module compliance is to indicate
that this MIB module can be implemented read-only. 
It seems to me that if the object is supported in READ-WRITE or READ-CREATE
mode, that in that case the normal StorageType requirments (as in RFC2579)
apply. So I am not sure I agree with your argumentation here.
Anyway, if you add the sentence, then the point is moot (at least for this
document).

> > - Mmm. I find the way you delete a row in t11FspfIfRowStatus
> >   a bit strange/weird. But I guess I can live with it.
> >   Can you explain why you do it this way?
> 
> Because:
> 
> 1. having unnecessary rows in this table clutters it up, and makes
>    those rows that are useful harder for a NMS to find.
> 2. having the current value always be in same object, irrespective of
>    whether it is a default or a non-default value is desirable. 
> 3. when non-default values are specified for a port's parameters,
>    they need to be retained in the MIB even when the port is 'isolated'.
> 4. when an E_Port becomes isolated, we want its row to get deleted
>    if and only if all of its parameter values are the default values.
> 

Thanks. Might be good if you add some of that explnanation. But I won't
loose sleep if you (and the WG) decide that your current text is good enough.

> > - t11FspfLinkIndex probably better specifies a range that excludes zero ??
> >   see also smicng error above.
>  
> The smicng error is confused, but I agree it would be better 
> to exclude zero, and I'll change it to do so.
> 

So I use the SMICng warning/error messages to check what the situation is.
And doing so made me wonder about the zero value for the INDEX.

> > admin/nits and just questions for clarity/explanation
> > 
> > - I see:
> >     t11FspfIfNbrPortIndex OBJECT-TYPE
> >         SYNTAX      Unsigned32 (1..4294967295)
> > 
> >     t11FspfLinkPortIndex OBJECT-TYPE
> >         SYNTAX      Unsigned32 (0..16777215)
> > 
> >     t11FspfLinkNbrPortIndex OBJECT-TYPE
> >         SYNTAX      Unsigned32 (0..16777215)
> > 
> >   Is it just me who wonders about the different ranges??
> >   Maybe I am missing something or misunderstanding.
>      
> The format of the FSPF protocol packets as shown in FC-SW-4 indicates
> that the port number field is 3 bytes long.  Hence, (0..16777215) is
> correct, and (1..4294967295) is incorrect -- I will change
> t11FspfIfNbrPortIndex.
> 

Thanks

> > - I wonder what a value of zero means for T11FspfLinkType
> >   If it can never exist, would it be better to make the range
> >   (1..255) ??
>  
> The only difference between the definition in the MIB and the definition
> pointed to by the REFERENCE clause is that FC-SW-4 says "all others"
> rather than just "others", i.e., zero is a reserved value.  I can add
> "all" into the DESCRIPTION.
> 

Would be good I think

> > - I wonder if T11FspfLsrType and T11FspfLinkType would be better
> >   defined with a base type of INTEGER? In other words Enumerations?
>  
> This is a trade-off between having the MIB definition being more
> explicit or more open-ended.  As these objects are currently defined,
> they implicitly get any new values as and when T11 defines new values
> for that field.  Having them as enumerations would be more explicit,
> but would require a MIB change to incorporate newly defined values.  I
> think this trade-off should be made individually for each 
> object on its own merits.
> 

So it seems thought        specify the columnar objects which a permanent(4) row must
            at a minimum allow to be writable."

So that last sentence to me seems to require it.


> However, the requirement at the top of page 23 in RFC 4181 is bogus
> because: a) a requirement which says that an "object must be 
> writeable"
> under some particular circumstance is for the minimum requried access,
> i.e., MIN-ACCESS, and belongs in MODULE-COMPLIANCE, not in 
> OBJECT-TYPE,
> b) in this case, all of the accessible objects in this table have a
> MIN-ACCESS of read-only.  So, the answer to your question is already
> present in the document.
> 

Mmm... I thought the MIN-ACCESS in the module compliance is to indicate
that this MIB module can be implemented read-only. 
It seems to me that if the object is supported in READ-WRITE or READ-CREATE
mode, that in that case the normal StorageType requirments (as in RFC2579)
apply. So I am not sure I agree with your argumentation here.
Anyway, if you add the sentence, then the point is moot (at least for this
document).

> > - Mmm. I find the way you delete a row in t11FspfIfRowStatus
> >   a bit strange/weird. But I guess I can live with it.
> >   Can you explain why you do it this way?
> 
> Because:
> 
> 1. having unnecessary rows in this table clutters it up, and makes
>    those rows that are useful harder for a NMS to find.
> 2. having the current value always be in same object, irrespective of
>    whether it is a default or a non-default value is desirable. 
> 3. when non-default values are specified for a port's parameters,
>    they need to be retained in the MIB even when the port is 'isolated'.
> 4. when an E_Port becomes isolated, we want its row to get deleted
>    if and only if all of its parameter values are the default values.
> 

Thanks. Might be good if you add some of that explnanation. But I won't
loose sleep if you (and the WG) decide that your current text is good enough.

> > - t11FspfLinkIndex probably better specifies a range that excludes zero ??
> >   see also smicng error above.
>  
> The smicng error is confused, but I agree it would be better 
> to exclude zero, and I'll change it to do so.
> 

So I use the SMICng warning/error messages to check what the situation is.
And doing so made me wonder about the zero value for the INDEX.

> > admin/nits and just questions for clarity/explanation
> > 
> > - I see:
> >     t11FspfIfNbrPortIndex OBJECT-TYPE
> >         SYNTAX      Unsigned32 (1..4294967295)
> > 
> >     t11FspfLinkPortIndex OBJECT-TYPE
> >         SYNTAX      Unsigned32 (0..16777215)
> > 
> >     t11FspfLinkNbrPortIndex OBJECT-TYPE
> >         SYNTAX      Unsigned32 (0..16777215)
> > 
> >   Is it just me who wonders about the different ranges??
> >   Maybe I am missing something or misunderstanding.
>      
> The format of the FSPF protocol packets as shown in FC-SW-4 indicates
> that the port number field is 3 bytes long.  Hence, (0..16777215) is
> correct, and (1..4294967295) is incorrect -- I will change
> t11FspfIfNbrPortIndex.
> 

Thanks

> > - I wonder what a value of zero means for T11FspfLinkType
> >   If it can never exist, would it be better to make the range
> >   (1..255) ??
>  
> The only difference between the definition in the MIB and the definition
> pointed to by the REFERENCE clause is that FC-SW-4 says "all others"
> rather than just "others", i.e., zero is a reserved value.  I can add
> "all" into the DESCRIPTION.
> 

Would be good I think

> > - I wonder if T11FspfLsrType and T11FspfLinkType would be better
> >   defined with a base type of INTEGER? In other words Enumerations?
>  
> This is a trade-off between having the MIB definition being more
> explicit or more open-ended.  As these objects are currently defined,
> they implicitly get any new values as and when T11 defines new values
> for that field.  Having them as enumerations would be more explicit,
> but would require a MIB change to incorporate newly defined values.  I
> think this trade-off should be made individually for each 
> object on its own merits.
> 

So it seems thought has gone into this.
If this is what the WG wants, then fine.

> > - I wonder how new non-Vendor-Specific values for T11FspfLsrType 
> >   and T11FspfLinkType will be assigned/allocated?
> >   Probably by T11? Would not hurt to say something about that.
> 
> Both of those TC's have a REFERENCE clause pointing to a T11 spec.
> That particular spec doesn't define the term "Vendor Specific" (and 
> I'm not sure which, if any, T11 spec does define it), but if I
> understand correctly, in T11 the term means that it is the vendors who
> define such values and that different vendors can (and do) have
> different meanings for the same value, i.e., they are reserved but
> *not* allocated by an IANA-equivalent organization.  A network manager
> managing a Fibre Channel has to know this, not because of SNMP or the
> MIB, but because of Fibre Channel.
> 

Might want to add some explanatory text then.

> > - I suspect that the RFCyyyy in t11FspfAdminStatus REFERENCE clause
> >   is (or should be) a different yyyy than the one in the
> >   MODULE-IDENTITY macro?
> 
> Right. I'll change t11FspfAdminStatus to use zzzz.
>
AS you see, I can still be very nitpicky ;-)
 
> > - In a number of places I would prefer to see "MIB module" instead
> >   of just "MIB". But I cam live with if if this is the doc does not
> >   need changing for anything else.
> 
> I'll look for them.
>
Thanks
 
> > - Section 7 is redundant and contains same material as the 
> back matter.
>  
> Right.
> 

Bert
> Thanks,
> Keith.
> 
> _______________________________________________
> imss mailing list
> imss@ietf.org
> https://www1.ietf.org/mailman/listinfo/imss
> 

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





 has gone into this.
If this is what the WG wants, then fine.

> > - I wonder how new non-Vendor-Specific values for T11FspfLsrType 
> >   and T11FspfLinkType will be assigned/allocated?
> >   Probably by T11? Would not hurt to say something about that.
> 
> Both of those TC's have a REFERENCE clause pointing to a T11 spec.
> That particular spec doesn't define the term "Vendor Specific" (and 
> I'm not sure which, if any, T11 spec does define it), but if I
> understand correctly, in T11 the term means that it is the vendors who
> define such values and that different vendors can (and do) have
> different meanings for the same value, i.e., they are reserved but
> *not* allocated by an IANA-equivalent organization.  A network manager
> managing a Fibre Channel has to know this, not because of SNMP or the
> MIB, but because of Fibre Channel.
> 

Might want to add some explanatory text then.

> > - I suspect that the RFCyyyy in t11FspfAdminStatus REFERENCE clause
> >   is (or should be) a different yyyy than the one in the
> >   MODULE-IDENTITY macro?
> 
> Right. I'll change t11FspfAdminStatus to use zzzz.
>
AS you see, I can still be very nitpicky ;-)
 
> > - In a number of places I would prefer to see "MIB module" instead
> >   of just "MIB". But I cam live with if if this is the doc does not
> >   need changing for anything else.
> 
> I'll look for them.
>
Thanks
 
> > - Section 7 is redundant and contains same material as the 
> back matter.
>  
> Right.
> 

Bert
> Thanks,
> Keith.
> 
> _______________________________________________
> imss mailing list
> imss@ietf.org
> https://www1.ietf.org/mailman/listinfo/imss
> 

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





From imss-bounces@ietf.org Wed Mar 08 20:44:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FHACQ-0000RD-K7; Wed, 08 Mar 2006 20:44:18 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FHABd-0008He-To
	for imss@ietf.org; Wed, 08 Mar 2006 20:43:29 -0500
Received: from ihemail2.lucent.com ([192.11.222.163])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHA5O-0005a9-Tq
	for imss@ietf.org; Wed, 08 Mar 2006 20:37:04 -0500
Received: from ihemail1.lucent.com (h192-11-222-161.lucent.com
	[192.11.222.161])
	by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k291ava7007733; 
	Wed, 8 Mar 2006 19:36:58 -0600 (CST)
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 k291atg9022148; 
	Wed, 8 Mar 2006 19:36:55 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service
	(5.5.2657.72) id <G3YWVH7K>; Thu, 9 Mar 2006 02:36:54 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155097B97CA@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: Black_David@emc.com, scott.kipp@mcdata.com,
	"Keith McCloghrie (E-mail)" <kzm@cisco.com>, g.ramkumar@mcdata.com
Date: Thu, 9 Mar 2006 02:36:53 +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: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: "Imss \(E-mail\)" <imss@ietf.org>,
	"Dan Romascanu \(E-mail\)" <dromasca@avaya.com>
Subject: [imss] AD review for: draft-ietf-imss-fc-vf-mib-01.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org


- SMICng states
  C:\bwijnen\smicng\work>smicng t11fcvf.inc
  E: f(t11fcvf.mi2), (77,4) Row "t11vfCoreSwitchEntry" may not have columns with M
  AX-ACCESS of read-write if any column is read-create 
  E: f(t11fcvf.mi2), (219,4) Row "t11vfPortEntry" may not have columns with MAX-AC
  CESS of read-write if any column is read-create

  *** 2 errors and 0 warnings in parsing
 
  Probably has to do with the read-create comment I make below as well.

- When I see:
   t11vfCoreSwitchSwitchName OBJECT-TYPE
       SYNTAX      FcNameIdOrZero
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The Core Switch_Name (WWN) of this Core Switch. A
            zero-length string for this field is not allowed. "
       ::= { t11vfCoreSwitchEntry 1 }

  I wonder if it would not be better to use a 

       SYNTAX      FcNameIdOrZero (SIZE(8 | 16))

  Because that at the same time makes the restriction (zero-length
  not allowed) machine-readable!!

-   t11vfCoreSwitchMaxSupported OBJECT-TYPE
      SYNTAX      Unsigned32

  Reading the description clause, it seems to me that a value of zero
  is not allowed. So I would add a range to exclude zero.

- Mmm a read-create SYNTAX in a row that does not have a RowStatus
  SYNTAX:
    t11vfCoreSwitchStorageType OBJECT-TYPE
      SYNTAX      StorageType
      MAX-ACCESS  read-create
  Peobably just read-write?

- t11vfVirtualSwitchCoreSwitchName
  is a zero-length string allowed? ANd if so what does that mean?


- t11vfLocallyEnabledRowStatus
  Meager DESCRIPTION clause.
  Missing if any objects can be changed if in active state

- In MODULE-COMPLIANCE I See
           OBJECT t11vfVirtualSwitchRowStatus
           MIN-ACCESS read-only
           DESCRIPTION
               "Write access is not required."

   Would you want to add the SYNTAX is many just active in that case?

- In MODULE-IDENTITY macro:
            Copyright (C) The Internet Society (2006).  This version of
            this MIB module is part of RFC yyyy; see the RFC itself for
            full legal notices."
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note
       REVISION        "200601230000Z"
       DESCRIPTION
               "Initial version of this MIB module, published as RFCxxxx."
   -- RFC-Editor, replace yyyy with actual RFC number & remove this note

  Probaly xxxx and yyyy are the same !!??

NITS:


- the formatting of the MIB in this document is not a preal of beauty.
  If you do a new rev, you may want to pay some attention to that.
  Actually formatting is somewhat weird at several places.

- The acknowledgement section seems to indicate that it is an INCITS work
  item and has nothing to do with IETF.
  The acknowledgement section of the other imss MIBs I reviewed earlier
  this week were better at that.
  Might at least want to thank IETF IMSS WG members?

- IANA COnsiderations section at a weird (at least different than normal)
  place.

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



From imss-bounces@ietf.org Mon Mar 13 11:25:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FIprf-0004iT-0c; Mon, 13 Mar 2006 11:25:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FIprd-0004iO-Eb
	for imss@ietf.org; Mon, 13 Mar 2006 11:25:45 -0500
Received: from sj-iport-3-in.cisco.com ([171.71.176.72]
	helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FIprb-0003ot-4T
	for imss@ietf.org; Mon, 13 Mar 2006 11:25:45 -0500
Received: from sj-core-5.cisco.com ([171.71.177.238])
	by sj-iport-3.cisco.com with ESMTP; 13 Mar 2006 08:25:42 -0800
X-IronPort-AV: i="4.02,187,1139212800"; 
	d="scan'208"; a="414993587:sNHT33500044"
Received: from cisco.com (pita.cisco.com [171.71.177.199])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2DGPg7T028653;
	Mon, 13 Mar 2006 08:25:42 -0800 (PST)
Received: (from kzm@localhost)
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA17862;
	Mon, 13 Mar 2006 08:25:39 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200603131625.IAA17862@cisco.com>
To: imss@ietf.org
Date: Mon, 13 Mar 2006 08:25:39 -0800 (PST)
In-Reply-To: <no.id> from "Keith McCloghrie" at Mar 07, 2006 07:43:15 AM
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: silvano@ip6.com, Claudio Desanti <cds@cisco.com>, dromasca@avaya.com,
	bwijnen@lucent.com, Black_David@emc.com, vgaonkar@cisco.com
Subject: [imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

Hi,

I didn't see any response to my message below.  So, I propose to
pick one of the solutions below and ask for objections.  Specifically,
I will remove the definition of t11FspfARegionNum from the 
T11-FC-FSPF-MIB unless I hear objections.  I plan to submit the
updated I-D at the beginning of next week when (I think) I-D submission
re-opens.

Thanks,
Keith.
--------------
Forwarded message:
> From: Keith McCloghrie <kzm>
> Message-Id: <200603071543.HAA21489@cisco.com>
> Subject: Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
> To: kzm@cisco.com (Keith McCloghrie)
> Date: Tue, 7 Mar 2006 07:43:15 -0800 (PST)
> Cc: bwijnen@lucent.com, Black_David@emc.com, cds@cisco.com, vgaonkar@cisco.com,
>         kzm@cisco.com, silvano@ip6.com, dromasca@avaya.com, imss@ietf.org
> 
> > > looks good. I would be OK with doing IETF Last Call and consider these
> > > comments as initial IETF Last Call comments. At the other hand, IETF
> > > LC right before/during an IETF will not get many people to pay
> > > attention to this. Maybe you rather do a new rev first?
> >  
> > I'll do a new rev first, but it won't now get posted until after the IETF.
> 
> In starting to do the edits, I have found one other thing which it
> might be appropriate to change at this time.
> 
> The present MIB, draft-ietf-imss-fc-fspf-mib-01.txt, defines the
> object:
> 
>   t11FspfARegionNum OBJECT-TYPE
>       SYNTAX      T11FspfARegionNum
>       MAX-ACCESS  read-write
>       STATUS      current
>       DESCRIPTION
>              "The AR number of this switch in this Fabric."
>       REFERENCE  "Fibre Channel - Switch Fabric - 4 (FC-SW-4), Rev 7.5,
>                  May 2005, section D.3.1."
>       DEFVAL     {0}
>       ::= { t11FspfEntry 2 }
> 
> I was starting to update the REFERENCE clauses to refer to the latest
> rev of FC-SW-4, but in doing so I find that Annex/section D.3.1 is
> missing.  In fact, the whole of what was Annex D has been removed from
> the latest revision (rev 7.7 of December 2005).  I knew that T11 was
> deprecating the concept of an "FSPF-Backbone" which was defined as:
> 
>     The FSPF-Backbone Fabric consists of multiple Autonomous Regions
>     (AR) that are interconnected by a backbone network.
> 
> What I didn't realise was that it would disappear from the FC-SW-4
> specification so soon.
> 
> Without that Annex, the definition of t11FspfARegionNum no longer
> makes any sense.
> 
> So, the question is:
> 
> - should the T11-FC-FSPF-MIB retain the definition of t11FspfARegionNum,
>   and do so by referring to an out-of-date T11 specification, or,
> 
> - should the definition of t11FspfARegionNum be removed from the
>   T11-FC-FSPF-MIB at this time ??
> 
> (Note that the edits that would be needed to remove it are obvious and
> straight-forward, e.g., the T11FspfARegionNum TC which is only used by
> t11FspfARegionNum would be deleted; t11FspfARegionNum would deleted
> from both the MODULE-COMPLIANCE clause and from the t11FspfGeneralGroup
> group.)
> 
> Keith.
> 

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



From imss-bounces@ietf.org Mon Mar 13 14:26:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FIsgb-0000oB-JK; Mon, 13 Mar 2006 14:26:33 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsga-0000o6-D6
	for imss@ietf.org; Mon, 13 Mar 2006 14:26:32 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIsga-0001j3-3V
	for imss@ietf.org; Mon, 13 Mar 2006 14:26:32 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 13 Mar 2006 11:26:32 -0800
X-IronPort-AV: i="4.02,187,1139212800"; 
	d="scan'208"; a="1784495615:sNHT33195472"
Received: from [171.71.49.195] (dhcp-171-71-49-195.cisco.com [171.71.49.195])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2DJQV1j027778;
	Mon, 13 Mar 2006 11:26:31 -0800 (PST)
Message-ID: <4415C762.1080502@cisco.com>
Date: Mon, 13 Mar 2006 11:26:26 -0800
From: Claudio DeSanti <cds@cisco.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Keith McCloghrie <kzm@cisco.com>
References: <200603131625.IAA17862@cisco.com>
In-Reply-To: <200603131625.IAA17862@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: silvano@ip6.com, imss@ietf.org, dromasca@avaya.com, bwijnen@lucent.com,
	Black_David@emc.com, vgaonkar@cisco.com
Subject: [imss] Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

Keith,

your proposal makes sense to me.
Thanks,

                       Claudio.


Keith McCloghrie wrote:
> Hi,
>
> I didn't see any response to my message below.  So, I propose to
> pick one of the solutions below and ask for objections.  Specifically,
> I will remove the definition of t11FspfARegionNum from the 
> T11-FC-FSPF-MIB unless I hear objections.  I plan to submit the
> updated I-D at the beginning of next week when (I think) I-D submission
> re-opens.
>
> Thanks,
> Keith.
> --------------
> Forwarded message:
>   
>> From: Keith McCloghrie <kzm>
>> Message-Id: <200603071543.HAA21489@cisco.com>
>> Subject: Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
>> To: kzm@cisco.com (Keith McCloghrie)
>> Date: Tue, 7 Mar 2006 07:43:15 -0800 (PST)
>> Cc: bwijnen@lucent.com, Black_David@emc.com, cds@cisco.com, vgaonkar@cisco.com,
>>         kzm@cisco.com, silvano@ip6.com, dromasca@avaya.com, imss@ietf.org
>>
>>     
>>>> looks good. I would be OK with doing IETF Last Call and consider these
>>>> comments as initial IETF Last Call comments. At the other hand, IETF
>>>> LC right before/during an IETF will not get many people to pay
>>>> attention to this. Maybe you rather do a new rev first?
>>>>         
>>>  
>>> I'll do a new rev first, but it won't now get posted until after the IETF.
>>>       
>> In starting to do the edits, I have found one other thing which it
>> might be appropriate to change at this time.
>>
>> The present MIB, draft-ietf-imss-fc-fspf-mib-01.txt, defines the
>> object:
>>
>>   t11FspfARegionNum OBJECT-TYPE
>>       SYNTAX      T11FspfARegionNum
>>       MAX-ACCESS  read-write
>>       STATUS      current
>>       DESCRIPTION
>>              "The AR number of this switch in this Fabric."
>>       REFERENCE  "Fibre Channel - Switch Fabric - 4 (FC-SW-4), Rev 7.5,
>>                  May 2005, section D.3.1."
>>       DEFVAL     {0}
>>       ::= { t11FspfEntry 2 }
>>
>> I was starting to update the REFERENCE clauses to refer to the latest
>> rev of FC-SW-4, but in doing so I find that Annex/section D.3.1 is
>> missing.  In fact, the whole of what was Annex D has been removed from
>> the latest revision (rev 7.7 of December 2005).  I knew that T11 was
>> deprecating the concept of an "FSPF-Backbone" which was defined as:
>>
>>     The FSPF-Backbone Fabric consists of multiple Autonomous Regions
>>     (AR) that are interconnected by a backbone network.
>>
>> What I didn't realise was that it would disappear from the FC-SW-4
>> specification so soon.
>>
>> Without that Annex, the definition of t11FspfARegionNum no longer
>> makes any sense.
>>
>> So, the question is:
>>
>> - should the T11-FC-FSPF-MIB retain the definition of t11FspfARegionNum,
>>   and do so by referring to an out-of-date T11 specification, or,
>>
>> - should the definition of t11FspfARegionNum be removed from the
>>   T11-FC-FSPF-MIB at this time ??
>>
>> (Note that the edits that would be needed to remove it are obvious and
>> straight-forward, e.g., the T11FspfARegionNum TC which is only used by
>> t11FspfARegionNum would be deleted; t11FspfARegionNum would deleted
>> from both the MODULE-COMPLIANCE clause and from the t11FspfGeneralGroup
>> group.)
>>
>> Keith.
>>
>>     
>
>   

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



From imss-bounces@ietf.org Wed Mar 15 08:57:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FJWVR-0006Up-98; Wed, 15 Mar 2006 08:57:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FJWVQ-0006Uk-5M
	for imss@ietf.org; Wed, 15 Mar 2006 08:57:40 -0500
Received: from gold.veritas.com ([143.127.12.110])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJWVP-0001kR-Hd
	for imss@ietf.org; Wed, 15 Mar 2006 08:57:40 -0500
Received: from sxchcon1-int.veritas.com (HELO
	SVLXCHCON1.enterprise.veritas.com) ([10.137.18.171])
	by gold.veritas.com with ESMTP; 15 Mar 2006 05:57:35 -0800
X-IronPort-AV: i="4.02,194,1139212800"; 
	d="scan'208,217"; a="57211657:sNHT65867836"
Received: from hroxchcon2.enterprise.veritas.com ([10.67.33.18]) by
	SVLXCHCON1.enterprise.veritas.com with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 05:57:34 -0800
Received: from hroxchcln1.enterprise.veritas.com ([10.67.33.21]) by
	hroxchcon2.enterprise.veritas.com with Microsoft
	SMTPSVC(6.0.3790.211); Wed, 15 Mar 2006 08:57:33 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 15 Mar 2006 08:57:32 -0500
Message-ID: <EC41F8507437734C9D3679FEBC902E660263DF2D@hroxchcln1.enterprise.veritas.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New FLIP I-D Available
Thread-Index: AcZIN4hVgyOw79T/RC6u+1uvvO1nqw==
From: "Roger Cummings" <roger_cummings@symantec.com>
To: "Imss \(E-mail\)" <imss@ietf.org>
X-OriginalArrivalTime: 15 Mar 2006 13:57:33.0166 (UTC)
	FILETIME=[684998E0:01C64838]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a
Cc: roweber@ieee.org, Black_David@emc.com, william.chow@qlogic.com
Subject: [imss] New FLIP I-D Available
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0015993947=="
Errors-To: imss-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0015993947==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C64838.68032E60"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C64838.68032E60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI, I case this got lost in the flood of I-D announcements last week.
Also, the I-D digest message containing this announcement was actually
corrupted when I went to look at it.
=20
Regards,
=20
=20
=20
=20
Roger Cummings
SYMANTEC
=20
roger_cummings@symantec.com
=20
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++
To: i-d-announce at ietf.org
Subject: I-D ACTION:draft-cummings-imss-flip-02.txt=20
From: Internet-Drafts at ietf.org
Date: Fri, 10 Mar 2006 10:50:01 -0500
Cc:=20
List-help: <mailto:i-d-announce-request@ietf.org?subject=3Dhelp>
List-id: i-d-announce.ietf.org
List-post: <mailto:i-d-announce@ietf.org>
List-subscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
<mailto:i-d-announce-request@ietf.org?subject=3Dsubscribe>
List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/i-d-announce>,
<mailto:i-d-announce-request@ietf.org?subject=3Dunsubscribe>
Reply-to: internet-drafts at ietf.org
=20
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
=20

Title: FAIS Line Interface Protocol Architecture & Requirements
Author(s): R. Cummings
Filename: draft-cummings-imss-flip-02.txt
Pages: 14
Date: 2006-3-10
=20
FAIS Line Interface Protocol (FLIP) describes mechanisms that allow a
set of functions that have been defined for an internal API related to
storage virtualization to be extended to operate over a TCP/IP
infrastructure. Significant deployment and configuration flexibility is
gained by taking such an approach.
=20
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cummings-imss-flip-02.txt
=20
To remove yourself from the I-D Announcement list, send a message to=20
i-d-announce-request at ietf.org with the word unsubscribe in the body
of the message. =20
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20
to change your subscription settings.
=20

Internet-Drafts are also available by anonymous FTP. Login with the
username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-cummings-imss-flip-02.txt".
=20
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html=20
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
=20

Internet-Drafts can also be obtained by e-mail.
=20
Send a message to:
mailserv at ietf.org.
In the body type:
"FILE /internet-drafts/draft-cummings-imss-flip-02.txt".
=20
NOTE:The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
=20

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-cummings-imss-flip-02.txt>
=20
_______________________________________________
I-D-Announce mailing list
I-D-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

------_=_NextPart_001_01C64838.68032E60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2802" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D654124913-15032006>FYI, I =
case this got=20
lost in the flood of I-D announcements last week. Also, the I-D=20
digest&nbsp;message containing this announcement was =
actually&nbsp;corrupted=20
when I went to look at it.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D654124913-15032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D654124913-15032006>Regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D654124913-15032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D654124913-15032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D654124913-15032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D654124913-15032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D654124913-15032006>Roger=20
Cummings</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D654124913-15032006>SYMANTEC</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D654124913-15032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D654124913-15032006><A=20
href=3D"mailto:roger_cummings@symantec.com">roger_cummings@symantec.com</=
A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D654124913-15032006></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D654124913-15032006>++++++++++++++++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To: i-d-announce at =
ietf.org<BR>Subject: I-D=20
ACTION:draft-cummings-imss-flip-02.txt <BR>From: Internet-Drafts at=20
ietf.org<BR>Date: Fri, 10 Mar 2006 10:50:01 -0500<BR>Cc: <BR>List-help: =
&lt;<A=20
href=3D"mailto:i-d-announce-request@ietf.org?subject=3Dhelp">mailto:i-d-a=
nnounce-request@ietf.org?subject=3Dhelp</A>&gt;<BR>List-id:=20
i-d-announce.ietf.org<BR>List-post: &lt;<A=20
href=3D"mailto:i-d-announce@ietf.org">mailto:i-d-announce@ietf.org</A>&gt=
;<BR>List-subscribe:=20
&lt;<A=20
href=3D"https://www1.ietf.org/mailman/listinfo/i-d-announce">https://www1=
.ietf.org/mailman/listinfo/i-d-announce</A>&gt;,=20
&lt;<A=20
href=3D"mailto:i-d-announce-request@ietf.org?subject=3Dsubscribe">mailto:=
i-d-announce-request@ietf.org?subject=3Dsubscribe</A>&gt;<BR>List-unsubsc=
ribe:=20
&lt;<A=20
href=3D"https://www1.ietf.org/mailman/listinfo/i-d-announce">https://www1=
.ietf.org/mailman/listinfo/i-d-announce</A>&gt;,=20
&lt;<A=20
href=3D"mailto:i-d-announce-request@ietf.org?subject=3Dunsubscribe">mailt=
o:i-d-announce-request@ietf.org?subject=3Dunsubscribe</A>&gt;<BR>Reply-to=
:=20
internet-drafts at ietf.org</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>A New Internet-Draft is available from =
the on-line=20
Internet-Drafts directories.</FONT></DIV>
<DIV>&nbsp;</DIV><FONT face=3DArial size=3D2>
<DIV><BR>Title: FAIS Line Interface Protocol Architecture &amp;=20
Requirements<BR>Author(s): R. Cummings<BR>Filename:=20
draft-cummings-imss-flip-02.txt<BR>Pages: 14<BR>Date: 2006-3-10</DIV>
<DIV>&nbsp;</DIV>
<DIV>FAIS Line Interface Protocol (FLIP) describes mechanisms that allow =

a<BR>set of functions that have been defined for an internal API related =

to<BR>storage virtualization to be extended to operate over a=20
TCP/IP<BR>infrastructure. Significant deployment and configuration =
flexibility=20
is<BR>gained by taking such an approach.</DIV>
<DIV>&nbsp;</DIV>
<DIV>A URL for this Internet-Draft is:<BR><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-cummings-imss-flip-02.t=
xt">http://www.ietf.org/internet-drafts/draft-cummings-imss-flip-02.txt</=
A></DIV>
<DIV>&nbsp;</DIV>
<DIV>To remove yourself from the I-D Announcement list, send a message =
to=20
<BR>i-d-announce-request at ietf.org with the word unsubscribe in the =
body of=20
the message.&nbsp; <BR>You can also visit <A=20
href=3D"https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1=
.ietf.org/mailman/listinfo/I-D-announce</A>=20
<BR>to change your subscription settings.</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>Internet-Drafts are also available by anonymous FTP. Login with =
the=20
username<BR>"anonymous" and a password of your e-mail address. After =
logging=20
in,<BR>type "cd internet-drafts" and then<BR>"get=20
draft-cummings-imss-flip-02.txt".</DIV>
<DIV>&nbsp;</DIV>
<DIV>A list of Internet-Drafts directories can be found in<BR><A=20
href=3D"http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html<=
/A>=20
<BR>or <A=20
href=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/iet=
f/1shadow-sites.txt</A></DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>Internet-Drafts can also be obtained by e-mail.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Send a message to:<BR>mailserv at ietf.org.<BR>In the body =
type:<BR>"FILE=20
/internet-drafts/draft-cummings-imss-flip-02.txt".</DIV>
<DIV>&nbsp;</DIV>
<DIV>NOTE:The mail server at ietf.org can return the document =
in<BR>MIME-encoded=20
form by using the "mpack" utility.&nbsp; To use this<BR>feature, insert =
the=20
command "ENCODING mime" before the "FILE"<BR>command.&nbsp; To decode =
the=20
response(s), you will need "munpack" or<BR>a MIME-compliant mail =
reader.&nbsp;=20
Different MIME-compliant mail readers<BR>exhibit different behavior, =
especially=20
when dealing with<BR>"multipart" MIME messages (i.e. documents which =
have been=20
split<BR>up into multiple messages), so check your local documentation =
on<BR>how=20
to manipulate these messages.</DIV>
<DIV>&nbsp;</DIV>
<DIV><BR>Below is the data which will enable a MIME compliant mail=20
reader<BR>implementation to automatically retrieve the ASCII version of=20
the<BR>Internet-Draft.<BR>&lt;<A=20
href=3D"ftp://ftp.ietf.org/internet-drafts/draft-cummings-imss-flip-02.tx=
t">ftp://ftp.ietf.org/internet-drafts/draft-cummings-imss-flip-02.txt</A>=
&gt;</DIV>
<DIV>&nbsp;</DIV>
<DIV>_______________________________________________<BR>I-D-Announce =
mailing=20
list<BR>I-D-Announce at ietf.org<BR><A=20
href=3D"https://www1.ietf.org/mailman/listinfo/i-d-announce">https://www1=
.ietf.org/mailman/listinfo/i-d-announce</A></FONT></DIV></BODY></HTML>

------_=_NextPart_001_01C64838.68032E60--


--===============0015993947==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0015993947==--




From imss-bounces@ietf.org Mon Mar 20 00:50:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLDHA-0001OO-9F; Mon, 20 Mar 2006 00:49:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FLDH9-0001OJ-2i
	for imss@ietf.org; Mon, 20 Mar 2006 00:49:55 -0500
Received: from mexforward.lss.emc.com ([168.159.213.200])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLDH8-0002zt-OC
	for imss@ietf.org; Mon, 20 Mar 2006 00:49:55 -0500
Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12])
	by mexforward.lss.emc.com (Switch-3.1.0/Switch-3.1.7) with ESMTP id
	k2K5noqN026576; Mon, 20 Mar 2006 00:49:50 -0500 (EST)
Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32])
	by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.7) with ESMTP id
	k2K5nSrn004295; Mon, 20 Mar 2006 00:49:35 -0500 (EST)
Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19)
	id <D4XND2P6>; Mon, 20 Mar 2006 00:49:28 -0500
Message-ID: <F222151D3323874393F83102D614E05503128C1F@CORPUSMX20A.corp.emc.com>
From: Black_David@emc.com
To: cds@cisco.com, kzm@cisco.com
Date: Mon, 20 Mar 2006 00:49:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.3.0.1,
	Antispam-Data: 2006.03.19.211108
X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -2,
	NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0,
	__HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0,
	__MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0,
	__STOCK_CRUFT 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: b22590c27682ace61775ee7b453b40d3
Cc: silvano@ip6.com, imss@ietf.org, dromasca@avaya.com, bwijnen@lucent.com,
	Black_David@emc.com, vgaonkar@cisco.com
Subject: [imss] RE: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

It also looks like the right course of action to me.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: Claudio DeSanti [mailto:cds@cisco.com] 
> Sent: Monday, March 13, 2006 2:26 PM
> To: Keith McCloghrie
> Cc: imss@ietf.org; bwijnen@lucent.com; Black, David; 
> vgaonkar@cisco.com; silvano@ip6.com; dromasca@avaya.com
> Subject: Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
> 
> Keith,
> 
> your proposal makes sense to me.
> Thanks,
> 
>                        Claudio.
> 
> 
> Keith McCloghrie wrote:
> > Hi,
> >
> > I didn't see any response to my message below.  So, I propose to
> > pick one of the solutions below and ask for objections.  
> Specifically,
> > I will remove the definition of t11FspfARegionNum from the 
> > T11-FC-FSPF-MIB unless I hear objections.  I plan to submit the
> > updated I-D at the beginning of next week when (I think) 
> I-D submission
> > re-opens.
> >
> > Thanks,
> > Keith.
> > --------------
> > Forwarded message:
> >   
> >> From: Keith McCloghrie <kzm>
> >> Message-Id: <200603071543.HAA21489@cisco.com>
> >> Subject: Re: AD review of: draft-ietf-imss-fc-fspf-mib-01.txt
> >> To: kzm@cisco.com (Keith McCloghrie)
> >> Date: Tue, 7 Mar 2006 07:43:15 -0800 (PST)
> >> Cc: bwijnen@lucent.com, Black_David@emc.com, 
> cds@cisco.com, vgaonkar@cisco.com,
> >>         kzm@cisco.com, silvano@ip6.com, 
> dromasca@avaya.com, imss@ietf.org
> >>
> >>     
> >>>> looks good. I would be OK with doing IETF Last Call and 
> consider these
> >>>> comments as initial IETF Last Call comments. At the 
> other hand, IETF
> >>>> LC right before/during an IETF will not get many people to pay
> >>>> attention to this. Maybe you rather do a new rev first?
> >>>>         
> >>>  
> >>> I'll do a new rev first, but it won't now get posted 
> until after the IETF.
> >>>       
> >> In starting to do the edits, I have found one other thing which it
> >> might be appropriate to change at this time.
> >>
> >> The present MIB, draft-ietf-imss-fc-fspf-mib-01.txt, defines the
> >> object:
> >>
> >>   t11FspfARegionNum OBJECT-TYPE
> >>       SYNTAX      T11FspfARegionNum
> >>       MAX-ACCESS  read-write
> >>       STATUS      current
> >>       DESCRIPTION
> >>              "The AR number of this switch in this Fabric."
> >>       REFERENCE  "Fibre Channel - Switch Fabric - 4 
> (FC-SW-4), Rev 7.5,
> >>                  May 2005, section D.3.1."
> >>       DEFVAL     {0}
> >>       ::= { t11FspfEntry 2 }
> >>
> >> I was starting to update the REFERENCE clauses to refer to 
> the latest
> >> rev of FC-SW-4, but in doing so I find that Annex/section D.3.1 is
> >> missing.  In fact, the whole of what was Annex D has been 
> removed from
> >> the latest revision (rev 7.7 of December 2005).  I knew 
> that T11 was
> >> deprecating the concept of an "FSPF-Backbone" which was defined as:
> >>
> >>     The FSPF-Backbone Fabric consists of multiple 
> Autonomous Regions
> >>     (AR) that are interconnected by a backbone network.
> >>
> >> What I didn't realise was that it would disappear from the FC-SW-4
> >> specification so soon.
> >>
> >> Without that Annex, the definition of t11FspfARegionNum no longer
> >> makes any sense.
> >>
> >> So, the question is:
> >>
> >> - should the T11-FC-FSPF-MIB retain the definition of 
> t11FspfARegionNum,
> >>   and do so by referring to an out-of-date T11 specification, or,
> >>
> >> - should the definition of t11FspfARegionNum be removed from the
> >>   T11-FC-FSPF-MIB at this time ??
> >>
> >> (Note that the edits that would be needed to remove it are 
> obvious and
> >> straight-forward, e.g., the T11FspfARegionNum TC which is 
> only used by
> >> t11FspfARegionNum would be deleted; t11FspfARegionNum would deleted
> >> from both the MODULE-COMPLIANCE clause and from the 
> t11FspfGeneralGroup
> >> group.)
> >>
> >> Keith.
> >>
> >>     
> >
> >   
> 

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



From imss-bounces@ietf.org Mon Mar 20 01:01:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FLDRs-00084C-Oo; Mon, 20 Mar 2006 01:01:00 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FKLl2-0005FA-Jl; Fri, 17 Mar 2006 15:41:12 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FKLl1-0004ja-BP; Fri, 17 Mar 2006 15:41:12 -0500
Received: from sj-core-3.cisco.com ([171.68.223.137])
	by sj-iport-4.cisco.com with ESMTP; 17 Mar 2006 12:41:11 -0800
X-IronPort-AV: i="4.03,105,1141632000"; 
	d="scan'208"; a="1785969006:sNHT29837596"
Received: from cisco.com (pita.cisco.com [171.71.177.199])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2HKfA1j027343;
	Fri, 17 Mar 2006 12:41:10 -0800 (PST)
Received: (from kzm@localhost)
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA04645;
	Fri, 17 Mar 2006 12:41:05 -0800 (PST)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200603172041.MAA04645@cisco.com>
To: internet-drafts@ietf.org (Internet Drafts Submissions)
Date: Fri, 17 Mar 2006 12:41:05 -0800 (PST)
X-Mailer: ELM [version 2.5 PL5]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de
X-Mailman-Approved-At: Mon, 20 Mar 2006 01:00:59 -0500
Cc: silvano@ip6.com, Claudio Desanti <cds@cisco.com>, imss@ietf.org,
	Keith McCloghrie <kzm@cisco.com>, dromasca@avaya.com,
	bwijnen@lucent.com, srinikode@yahoo.com, black_david@emc.com,
	Vinay Gaonkar <vgaonkar@cisco.com>
Subject: [imss] Submission of two updated Internet-Drafts
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

Please accept the following two files as updated Internet-Drafts:

  ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fspf-mib-02.txt

and

  ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-rtm-mib-03.txt

Thanks,
Keith.

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



From imss-bounces@ietf.org Wed Mar 22 18:50:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMD5c-0005kj-CV; Wed, 22 Mar 2006 18:50:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMD5W-0005dm-TX; Wed, 22 Mar 2006 18:50:02 -0500
Received: from oak.neustar.com ([209.173.53.70])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMD5W-0000a7-Hw; Wed, 22 Mar 2006 18:50:02 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k2MNo2BX024209
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Wed, 22 Mar 2006 23:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FMD5W-0002Fc-Bo; Wed, 22 Mar 2006 18:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1FMD5W-0002Fc-Bo@stiedprstage1.ietf.org>
Date: Wed, 22 Mar 2006 18:50:02 -0500
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: imss@ietf.org
Subject: [imss] I-D ACTION:draft-ietf-imss-fc-rtm-mib-03.txt 
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF.

	Title		: Fibre-Channel Routing Information MIB
	Author(s)	: C. DeSanti, et al.
	Filename	: draft-ietf-imss-fc-rtm-mib-03.txt
	Pages		: 22
	Date		: 2006-3-22
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for information related
   to routing within a Fibre Channel fabric which is independent of the
   usage of a particular routing protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-rtm-mib-03.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imss-fc-rtm-mib-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imss-fc-rtm-mib-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-3-22154206.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imss-fc-rtm-mib-03.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-imss-fc-rtm-mib-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-3-22154206.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From imss-bounces@ietf.org Wed Mar 22 18:50:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMD5i-0005rM-PT; Wed, 22 Mar 2006 18:50:14 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FMD5X-0005eD-7s; Wed, 22 Mar 2006 18:50:03 -0500
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FMD5W-0000aA-Ou; Wed, 22 Mar 2006 18:50:03 -0500
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
	[10.31.47.10])
	by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k2MNo2vP026491
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
	Wed, 22 Mar 2006 23:50:02 GMT
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
	id 1FMD5W-0002FS-Aa; Wed, 22 Mar 2006 18:50:02 -0500
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
From: Internet-Drafts@ietf.org
Message-Id: <E1FMD5W-0002FS-Aa@stiedprstage1.ietf.org>
Date: Wed, 22 Mar 2006 18:50:02 -0500
X-Spam-Score: -2.5 (--)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: imss@ietf.org
Subject: [imss] I-D ACTION:draft-ietf-imss-fc-fspf-mib-02.txt 
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet and Management Support for Storage Working Group of the IETF.

	Title		: MIB for Fibre-Channel's Fabric Shortest Path First Protocol
	Author(s)	: C. DeSanti, et al.
	Filename	: draft-ietf-imss-fc-fspf-mib-02.txt
	Pages		: 39
	Date		: 2006-3-22
	
This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes managed objects for information related
   to the Fibre Channel network's Fabric Shortest Path First (FSPF)
   routing protocol.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imss-fc-fspf-mib-02.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request@ietf.org with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imss-fc-fspf-mib-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-imss-fc-fspf-mib-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID: <2006-3-22153925.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-imss-fc-fspf-mib-02.txt

--OtherAccess
Content-Type: Message/External-body; name="draft-ietf-imss-fc-fspf-mib-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2006-3-22153925.I-D@ietf.org>


--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--




From imss-bounces@ietf.org Fri Mar 31 19:21:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPTro-0002jy-L8; Fri, 31 Mar 2006 19:21:24 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FPTrk-0002jd-Uu; Fri, 31 Mar 2006 19:21:20 -0500
Received: from nit.isi.edu ([128.9.160.116])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FPTrj-00076F-J9; Fri, 31 Mar 2006 19:21:20 -0500
Received: from nit.isi.edu (loopback [127.0.0.1])
	by nit.isi.edu (8.12.11.20060308/8.12.11) with ESMTP id k310LJ0Y030592; 
	Fri, 31 Mar 2006 16:21:19 -0800
Received: (from apache@localhost)
	by nit.isi.edu (8.12.11.20060308/8.12.11/Submit) id k310LIf9030591;
	Fri, 31 Mar 2006 16:21:18 -0800
Date: Fri, 31 Mar 2006 16:21:18 -0800
Message-Id: <200604010021.k310LIf9030591@nit.isi.edu>
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
X-Spam-Score: -14.8 (--------------)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Cc: imss@ietf.org, rfc-editor@rfc-editor.org
Subject: [imss] RFC 4439 on Fibre Channel Fabric Address Manager MIB
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
	<imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>,
	<mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4439

        Title:      Fibre Channel Fabric Address Manager 
                    MIB 
        Author:     C. DeSanti,  V. Gaonkar, 
                    K. McCloghrie,  S. Gai
        Status:     Standards Track
        Date:       March 2006
        Mailbox:    cds@cisco.com, 
                    vgaonkar@cisco.com, 
                    kzm@cisco.com,  none
        Pages:      40
        Characters: 77153
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-imss-fc-fam-mib-03.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4439.txt

This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it describes managed objects for information related
to a Fibre Channel network's Fabric Address Manager.  [STANDARDS TRACK]

This document is a product of the Internet and Management Support for 
Storage Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...



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