Subject: Re: [imss] imss WG Last Call: Fibre Channel RSCN, Fabric Config S

From: Keith McCloghrie <[email-masked]>
Date: Mon, 4 Sep 2006 03:12:41 -0700 (PDT)

Hi Bert,

I've fixed the missing comma in my source file (but I'll defer submitting
an updated I-D until after all the Last Call comments are in).  The
INDEX issues are both situations where smilint doesn't find anything
wrong -- in both cases, the semantics of the INDEX clause are as
intended, and (I expect) the SMICng warning would go away if a new
auxiliary object were defined with identical semantics, rather than
re-using an object which is an auxiliary object in another table.  So,
they would (I think) be easy to fix if that's what you prefer.

Thanks,
Keith.
 
> Here are the SMICng results:
> 
>   C:\bwijnen\smicng\work>smicng T11-FC-FABRIC-CONFIG-SERVER-MIB.inc
>   W: f(T11-FC-FABRIC-CONFIG-SERVER-MIB.mi2), (716,15) Row 
>   "t11FcsPortListEntry" does not have a consistent indexing scheme
>   - index items from current table must come after index items from
>   other tables
> 
>   *** 0 errors and 1 warning in parsing
> 
>   C:\bwijnen\smicng\work>smicng T11-FC-FABRIC-LOCK-MIB.inc
>   Successful parsing
> 
>   C:\bwijnen\smicng\work>smicng T11-FC-RSCN-MIB.inc
>   E: f(T11-FC-RSCN-MIB.mi2), (198,5) Missing comma between sequence items
> 
>   *** 1 error and 0 warnings in parsing
> 
>   C:\bwijnen\smicng\work>smicng T11-FC-ZONE-SERVER-MIB.inc
>   W: f(T11-FC-ZONE-SERVER-MIB.mi2), (959,15) Row "t11ZsSetZoneEntry"
>   does not have a consistent indexing scheme - cannot specify an index
>   item from additional "base row" t11ZsSetEntry, since can have only one
>   "base row" which is t11ZsZoneEntry
> 
>   *** 0 errors and 1 warning in parsing
> 
> The two warnings for inconistent indexing are possibly OK if what we did
> is indeed intended.
> 
> The missing comma should be fixed. It is in this table:
> T11FcRscnStatsEntry ::= SEQUENCE {
>     t11FcRscnInScrs                    Counter32,
>     t11FcRscnInRscns                   Counter32,
>     t11FcRscnOutRscns                  Counter32,
>     t11FcRscnInSwRscns                 Counter32,
>     t11FcRscnOutSwRscns                Counter32,
>     t11FcRscnScrRejects                Counter32,
>     t11FcRscnRscnRejects               Counter32,
>     t11FcRscnSwRscnRejects             Counter32
>     t11FcRscnInUnspecifiedRscns        Counter32,
>     t11FcRscnOutUnspecifiedRscns       Counter32,
>     t11FcRscnInChangedAttribRscns      Counter32,
>     t11FcRscnOutChangedAttribRscns     Counter32,
>     t11FcRscnInChangedServiceRscns     Counter32,
>     t11FcRscnOutChangedServiceRscns    Counter32,
>     t11FcRscnInChangedSwitchRscns      Counter32,
>     t11FcRscnOutChangedSwitchRscns     Counter32,
>     t11FcRscnInRemovedRscns            Counter32,
>     t11FcRscnOutRemovedRscns           Counter32
> }
> 
> Bert
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Saturday, August 26, 2006 02:26
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: [imss] imss WG Last Call: Fibre Channel RSCN, Fabric Config
> > Svr, and Zone Svr MIBs
> > 
> > 
> > This is to announce an imss WG Last Call on the following
> > three MIB drafts:
> > 
> >      Fibre Channel Registered State Change Notification (RSCN) MIB
> >                    draft-ietf-imss-fc-rscn-mib-00.txt
> > 
> >              Fibre-Channel Fabric Configuration Server MIB
> >                    draft-ietf-imss-fc-fcs-mib-00.txt
> > 
> >                      Fibre-Channel Zone Server MIB
> >                     draft-ietf-imss-fc-zs-mib-00.txt
> >  
> > This WG Last Call will run through 12 midnight Eastern Time on
> > Sunday, September 17, 2006 (your WG chair hopes to deal with
> > Last Call results during the week of September 18th).
> > 
> > Technical comments *must* be sent to the imss mailing list.
> > Editorial comments may be sent directly to the draft editor
> > (but please cc: me) - all three drafts have the same editor:
> > 
> > 		Keith McCloghrie [[email-masked]]
> > 
> > Thanks,
> > --David (imss WG chair)
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> > 
> > _______________________________________________
> > imss mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/imss
> > 
> 
> _______________________________________________
> imss mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/imss
> 

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

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 4 Sep 2006 03:52:33 -0700 (PDT)

See my earlier response for most of the issues.

The one new issue is the use of ifIndex in a notification's OBJECTS
clause.  This is another case where SMIC is providing an individual's
personal interpretation of the SMI, rather than being based on what
the SMI actually says, which is (from section 8.1 of RFC 2578):
								An
   object type specified in this clause must not have an MAX-ACCESS
   clause of "not-accessible".

whereas ifIndex has always had a MAX-ACCESS clause of "read-only".  

Note also the linkUp and linkDown notiifcations also have ifIndex in
their OBJECTS clause.  My experience is that customers prefer the use
of auxiliary objects in notifications, and so, in places where the SMI
allows it, I define them so intentionally.

Keith.

> SMIC strict checking reveals the following:
> 
>   C:\bwijnen\smicng\work>smicstrict
> 
>   does not have a consistent indexing scheme - cannot specify an
>   index item from additional "base row" t11ZsSetEntry, since can
>   have only one "base row" which is t11ZsZoneEntry
> 
> Keith, what is your comments on this one?
>
>   W: f(T11-FC-ZONE-SERVER-MIB.mi2), (2254,20) Variable "ifIndex"
>   in notification "t11ZsMergeFailureNotify" is an index for a table
>   W: f(T11-FC-ZONE-SERVER-MIB.mi2), (2269,20) Variable "ifIndex" in
>   notification "t11ZsMergeSuccessNotify" is an index for a table
> 
> I do not see the above two as fatal flaws. We could pass ifAlias,
> or some other columnar-object of the ifTable I guess. That would make
> the warning go away, and we would be sending extra information in
> the notification.
> 
> Just add the comma (as stated earlier).
> 
> is OK
> Keith, can you comment?

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 4 Sep 2006 03:57:25 -0700 (PDT)

RFC 2579 says:

   The DISPLAY-HINT clause, which need not be present, gives a hint ...

but I can add them if that is your wish.
 
Keith.

> SMIlint tells me the following:
> 
>   C:\smi\mibs\work>smilint -m -s -l 6 ./T11-FC-ZONE-SERVER-MIB
>   ./T11-FC-ZONE-SERVER-MIB:117: [5] {type-without-format} warning:
>    type `T11ZsZoneMemberType' has no format specification
> 
> It is just a warning. Yet we may want to add a DISPLAY-HINT.
> 
>   C:\smi\mibs\work>smilint -m -s -l 6 ./T11-FC-RSCN-MIB
> 
>   C:\smi\mibs\work>smilint -m -s -l 6 ./T11-FC-FABRIC-LOCK-MIB
> 
>   C:\smi\mibs\work>smilint -m -s -l 6 ./T11-FC-FABRIC-CONFIG-SERVER-MIB
>   ./T11-FC-FABRIC-CONFIG-SERVER-MIB:706: [5] {index-element-not-accessible}
>   warning: exactly one index element of row `t11FcsPortListEntry' 
>   must be accessible
> 
> I think this is fine. It is telling us that an INDEX object is accesible
> (normally it should not be accessible), but it explains us why this is OK.
> 
>   ./T11-FC-FABRIC-CONFIG-SERVER-MIB:75: [5] {type-without-format} warning:
>   type `T11ListIndex' has no format specification
>   ./T11-FC-FABRIC-CONFIG-SERVER-MIB:85: [5] {type-without-format} warning:
>   type `T11ListIndexPointer' has no format specification
> 
> It is just two warnings. Yet we may want to add a DISPLAY-HINT.
> 
> Bert
>

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 4 Sep 2006 04:54:04 -0700 (PDT)

> None of the below are fatal issues in my view (except for the
> missing comma, but that is easy to fix).
> 
> Some comments/questions:
> 
> - I see various objects like this one:
> 
>   t11FcRscnIlsRejectNotifyEnable OBJECT-TYPE
>     SYNTAX       TruthValue
>     MAX-ACCESS   read-write
>     STATUS       current
>     DESCRIPTION
>            "This object specifies if a t11FcRscnIlsRejectReqNotify
>            notification should be generated when this switch
>            rejects an SW_RSCN on this fabric.
> 
>            Values written to this object should be retained
>            over agent reboots."
>     DEFVAL { false }
>     ::= { t11FcRscnNotifyControlEntry 1 }
> 
>   Do we all think that "should be retained over agent reboots" is
>   good (and deterministic) enough? It is a lowercase should, and so 
>   any implementation that does not keep this over a reboot seems
>   still compliant. In other words, I have no deterministic way
>   at an NMS to figure out if this is persistent or not.
 
Some systems store this type of information in an ASCII-formatted
"configuration file" which they keep in non-volatile memory, but also
have the capability for the file to be reloaded at boot time.  One of
the reasons why such configuration files have typically (until recently)
been formatted in ASCII is so that they can be edited by an administrator
to change the parameters prior to the device dowloading it (but
presumably, the same can now be done with XML-formatted files and
XML-based editors.)  In such a situation, you are correct that there is
no deterministic way for the agent to tell an NMS whether the parameter
was persistent.

> - I also see a number of times a REFERENCE aka:
> 
>     REFERENCE
>            "ANSI INCITS xxx-200n, Fibre Channel - Link Services
>            (FC-LS), Rev 1.2, June 2005, tables 38 & 43.
> 
>   which I supposed is referenced by:
> 
>    [FC-LS]
>      "Fibre Channel - Link Services (FC-LS)", ANSI INCITS xxx-200n, Rev
>      1.2, http://www.t11.org/t11/stat.nsf/upnum/1620-d, June 2005.
> 
>   do we habve any idea when the   xxx-200n can be filled out?
>   it seems to me that this is a normative reference, no? 
>   so we need a stable doc to look at I think.
 
I'll let Claudio and David speak to this.

> - W.r.t. the notifications, I wonder if we (ever) run a risk that
>   an agent would send so many a to cuase congestion.
>   We do not seem to have a mechanism to control the amount of
>   notifications that can be sent/generated per second/minute/xx
>   Do we need one? If not, should we add some text to the DESCRIPTION
>   clauses of the NOTIFICATIOn-TYPE definitions to explain why an
>   agent would never generate more than x per second/minute/xxx?
 
It is hard to quantify them as "x per second/minute/xxx" but at most,
they would have a similar frequency to linkUp/linkDown.  Nevertheless,
one mechanism was added to reduce the number of notifications in a
specific situation; in particular, the t11ZsFabricIndex object was
defined with the additional value of 4096, such that it could be
included in this t11ZsMergeFailureNotify as described in the
notification's DESCRIPTION:

           If multiple Virtual Fabrics are configured on an
           interface, and all have a Zone merge failure
           at the same time, then just one notification is
           generated and t11ZsFabricIndex has the value 4096."

> - A real nit:
>   In the security considerations section:
>     Even if the network itself is secure (for example by using IPSec),
>   s/IPSec/IPsec/.
>   A while ago, this text was also in error in the security template
>   on the ops.ietf.org website. That has been fixed now as well.
 
Now fixed in the source of all three drafts.

> - Can the content of t11FcRscnRejectedRequestString have any specific 
>   sensitive of secret content? If so, then maybe we should elaborate
>   on that a bit in the security considerations. If not, then fine.
 
It's a list of port numbers of affected ports and/or an error code, and
in some cases the name and state of such ports.  So, no, I don't think
it has any specific secret content.

> - For completenes, here is a SMICng error that I reported ealier
> 
>    E: f(T11-FC-RSCN-MIB.mi2), (198,5) Missing comma between 
>    sequence items> 
  
Right.  I've fixed this in my source.

Thanks,
Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 4 Sep 2006 05:00:50 -0700 (PDT)

Each one has to be re-spun, because they all have to have "IPSec"
changed to "IPsec" in the standard boilerplate :-).

Keith.
 
> As I said "it is just a warning".
> I think it would not hurt to add a DISPLAY-HINT.
> But if that is the only reason to respin the draft, 
> then I can also live with not adding it.
> 
> Bert
> 
> > From: Keith McCloghrie [mailto:[email-masked]]
> > Sent: Monday, September 04, 2006 12:57
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: Re: [imss] imss WG Last Call: Fibre Channel RSCN, 
> > Fabric Config
> > S
> > 
> > 
> > RFC 2579 says:
> >

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 5 Sep 2006 15:03:51 -0700 (PDT)

Bert,

Thanks for the comments.  My responses are below.

Keith.
-----------------

> - In the MODULE-IDENTITY, I see:
> 
>     REVISION  "200608140000Z"
>     DESCRIPTION
>             "Initial version of this MIB module."
>     ::= { mib-2 nnn }                     -- to be determined later
>   
>   I think I would make that:
> 
>     REVISION  "200608140000Z"
>     DESCRIPTION
>             "Initial version of this MIB module, published as RFC yyyy."
>     -- RFC-Editor, replace yyyy with actual RFC number & remove this note
>     ::= { mib-2 nnn }  -- to be assigned by IANA.
>     -- RFC Editor: replace nnn with IANA-assigned number & remove this note
> 
> - To avoid later comments, I would also add this to the DESCRIPTION
>   clause of the MODULE-IDENTITY itself:
> 
>            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 Editor: replace yyyy with actual RFC number & remove this note
 
Oops.  All of this WG's other recent drafts have the required boilerplate;
I'm not sure how this one slipped through without it.

> - I wonder if we would not better rename these TCs (for naming consistency):
> 
>      FcIeType, FcPortState, FcPortTxType
>  
>   and name them instead as follows:
> 
>      T11FcIeType, T11FcPortState, T11FcPortTxType
> 
>   Or are these 3 TCs extending the set of FcXxxx TCs in RFC4044?
>   If so, the I'd suggest to add at least a small SMI comment to state that,
>   so that it is clear why the names are as chosen.
 
I named them to be consistent with FcPortType, and, *if* we were updating
RFC4044, then I'd put them in there, but we're not.   So, rather than
add a "small SMI comment", I'd prefer to change their names.

> - For consistency, but also for betetr info in the DESCRIPTION clause,
>   I would consider to change:
> 
>   FcPortTxType ::= TEXTUAL-CONVENTION
>     STATUS  current
>     DESCRIPTION
>             "The technology of the port transceiver:
> 
>                 unknown        - unknown (includes the 'null' type)
>                 other          - some other technology
>                 shortwave850nm - Short wave laser - SN (850 nm)
>                 longwave1550nm - Long wave laser - LL (1550 nm)
>                 longwave1310nm - Long wave laser cost
>                                  reduced - LC (1310 nm)
>                 electrical     - Electrical - EL."
> 
>   into:
> 
>   FcPortTxType ::= TEXTUAL-CONVENTION
>     STATUS  current
>     DESCRIPTION
>             "The technology of the port transceiver:
> 
>                 unknown(1)        - unknown (includes the 'null' type)
>                 other(2)          - some other technology
>                 shortwave850nm(3) - Short wave laser - SN (850 nm)
>                 longwave1550nm(4) - Long wave laser - LL (1550 nm)
>                 longwave1310nm(5) - Long wave laser cost
>                                     reduced - LC (1310 nm)
>                 electrical(6)     - Electrical - EL."
 
OK.

> - I am a bit surprised by:
> 
>   T11ListIndexPointer ::= TEXTUAL-CONVENTION
>     STATUS  current
>     DESCRIPTION
>             "Objects with this syntax point to a list of elements
>             contained in a table, by holding the same value as the
>             object with syntax T11ListIndex defined in the table's
>             INDEX clause, or, zero to indicate an empty list.
>             The definition of an object with this syntax must
>             identify the table(s) into which it points."
>     SYNTAX  Unsigned32 -- the default range of (0..4294967295)
> 
>   First, I would make it:  SYNTAX Unsigned32 (0..4294967295)
>   instead of putting that in a SMI comment field.
 
The reason I added the ASN.1 comment was to dispel all ambiguity,
i.e., to make it clear that the definition intentionally uses the
default range.  Thus, there is no reason to include the default range
explicitly in the syntax.  Why do we have a default range if we're not
allowed to use it ??

>   Second, I think we normally would use a name of 
> 
>     T11ListIndexOrZero ::= TEXTUAL-CONVENTION
> 
>   To complement the T11ListIndex TC, which does not include the zaero.
> 
>   Third, we also normally do not prescribe what a value of zero means,
>   but we normally say something aka (this is from InetrfaceIndexOrZero):
> 
>             "This textual convention is an extension of the
>             InterfaceIndex convention.  The latter defines a greater
>             than zero value used to identify an interface or interface
>             sub-layer in the managed system.  This extension permits the
>             additional value of zero.  the value zero is object-specific
>             and must therefore be defined as part of the description of
>             any object which uses this syntax.  Examples of the usage of
>             zero might include situations where interface was unknown,
>             or when none or all interfaces need to be referenced."
> 
>   We in fact have quite a few of these XxxSomeIndex and XxxSomeIndexOrZero
>   TCs, which all (i believe) follow/use that same concept. I would strongly
>   suggest that we do so here as well.
> 
>   Mmmm... I see that for some other TCs in the FC/IMSS/IPS space you do
>   not follow the InterfaceIndex/InetrfaceInexOrZero so closely either.
>   Oh well... Up to you and the WG. I personally like the InterfaceIndeOrZero
>   approach better. 
 
OK, I'll rename the TC to T11ListIndexPointerOrZero.

> - I see REFERENCE clauses aka:
> 
>     REFERENCE
>             "ANSI INCITS xxx-200x, Fibre Channel - Generic Services 5,
>             FC-GS-5 T11/Project 1677-D/Rev 8, Table 124."
> 
>   which relates to this reference (I guess):
> 
>    [FC-GS-5]
>      "Fibre Channel - Generic Services - 5 (FC-GS-5)", ANSI INCITS
>      xxx-200x, T11/Project 1677-D/Rev 8.00
>      http://www.t11.org/t11/stat.nsf/upnum/1677-d, September 2004.
> 
>   Do we know when we will get a stable reference?
>   It is normative, so we may have to say something about that.
> 
>   I guess Keith already stated that David or Claudio should answer this 
>   question.
 
Claudio said this morning that revision 8.5 is the final one.
So, I need to go ahead and update the MIB based on Rev 8.5,
including adding any new enumerations which have been defined
since Rev 8.0.

> - For t11FcsFabricDiscoveryRangeLow and t11FcsFabricDiscoveryRangeHigh,
>   is the value in these objects included in teh range? My read would
>   say they are. But we may want to make that clear by stating it?
 
OK, I'll change:

            "The discovery by a particular switch operates
            within all existing Fabrics that have a fabric
            index within a specific range.  ...
to:
            "The discovery by a particular switch operates
            within all existing Fabrics that have a fabric
            index within a specific inclusive range.  ...

> - For t11FcsFabricDiscoveryStart, how long does discovery take?
>   The reason I ask, is that if it may take a while, that we might
>   want to consider a value like "discoveryInProgress(3) ??
>   Just thinking aloud, I can also live with what we have in there now.
 
I think this is already available since 'inProgress' is one of the
defined values for t11FcsDiscoveryStatus.

> - t11FcsFabricDiscoveryTable
>   I guess that this table gets created/instantiated by the agent everytime
>   it starts. There are no default values for the two objects 
>   t11FcsFabricDiscoveryRangeLow and t11FcsFabricDiscoveryRangeHigh.
>   So how is the behavioud if I issue a DiscoveryStart when these objects
>   have not been SET yet? Should we define DEFVALs?

Just adding DEFVALs would be a temptation to write sloppy applications,
because an NMS can not be sure whether a particular entry has been used
or not since the last reboot.  Thus, invoking DiscoveryStart without
checking the values of RangeLow and RangeHigh, would be very sloppy.
Given that an application needs to check, then it also has to change
the values if they're wrong.  Thus, the simplest way to write such an
application is to always specify the range explicitly (i.e., write
RangeLow and RangeHigh) at the same time as invoking DiscoveryStart.

So, I propose to add a recommendation to the DESCRIPTION like this:

  t11FcsFabricDiscoveryStart  OBJECT-TYPE
      SYNTAX       INTEGER {
                       start(1),
                       noOp(2)
                   }
      MAX-ACCESS   read-write
      STATUS       current
      DESCRIPTION
              "This object provides the capability to trigger the start
              of a discovery by a Fabric Configuration Server.  If this
              object is set to 'start', then the discovery is started on
              those fabrics which have their fabric index value in the
              range specified by t11FcsFabricDiscoveryRangeLow and
              t11FcsFabricDiscoveryRangeHigh.  It is recommended that
              whenever an instance of this object is set to 'start',
              that the desired range be concurrently specified by
              setting the corresponding instances of
              t11FcsFabricDiscoveryRangeLow and
              t11FcsFabricDiscoveryRangeHigh.

> - Given the DESCRIPTION clause of t11FcsFabricDiscoveryStart, I 
>   suggest to add  DEFVAL { noOp }

Since the value when read is always 'noOp', to specify a DEFVAL would
either be redundant, or worse, it would weaken the definition because a
DEFVAL is only advisory, whereas the statement:  "the value when read
is always 'noOp'" is mandatory.

> - I suppose that SETTING t11FcsDiscoveryStatus to one of
>                      inProgress(1),
>                      completed(2),
>   would have no effect? I.e. it would be ignored?
>   Whatever the intended behaviour is to be, we probably do best to
>   be specific as to what we want an agent to do.
> 
>   I personally kind of like to add something to the MODULE-COMPLIANCE<
>   which states that the WRITE-SYNTAX is  localOnly(3) and that
>   the SYNTAX is all 3 values. I think that expresses that only the
>   one value that makes sense can be SET/written.
> 
>   I personally might do a similar thing for t11FcsFabricDiscoveryStart,
>   but that one at least explains what to do if I set the value to
>   something that does not trigger an action.
 
I prefer to add a sentence to the DESCRIPTION of t11FcsDiscoveryStatus,
like this:

            It is an error for a manager to set the value of this
            object to anything other than 'localOnly'."

> - t11FcsDiscoveryStatus has no persistency (or so is my reading of
>   the DESCRIPTION clause) and will be set to localOnly upon a restart?
>   If so, it might be usefull to add a sentence about that, just to be
>   explicit and clear.
 
It already has this sentence:

            Initially when the switch comes up, all instances of this
            object have the value: 'localOnly'

Do you want me to change "switch comes up" to "agent restarts" ??

> - For objects t11FcsIeName and t11FcsIeDomainId, I wonder if a zero
>   (i.e. zero length OCTET STRING) are really valid. If not, then we
>   should add a SIZE and RANGE restriction.
 
FC-GS-5 says:

  6.2.3.2.1 Interconnect Element Name

  The format of the Interconnect Element Name attribute, as used by the
  Fabric Configuration Server, shall be identical to the Name_Identifier
  format defined in FC-FS. If the Interconnect Element is a Switch (see
  FC-SW), the Interconnect Element Name attribute shall be the
  Switch_Name of the Switch.

  This standard does not define how this attribute is registered with the
  Fabric Configuration Server.  The null value for the Interconnect
  Element Name attribute is 00 00 00 00 00 00 00 00h.

and

  6.2.3.2.3 Interconnect Element Domain Identifier

  The format of the Interconnect Element Domain Identifier attribute, as
  used by the Fabric Configuration Server, shall be identical to the
  Domain Identifier format defined in FC-SW-3.

  This standard does not define how this attribute is registered with the
  Fabric Configuration Server.  The null value for the Interconnect
  Element Domain Identifier attribute is 00h.

Since t11FcsIeDomainId can have a value of zero, FcDomainIdOrZero
(which is defined as "SYNTAX  Integer32 (0..239)")  should not be
restricted.

For t11FcsIeName, the "null" value is specified as all zeros, rather
than the zero-length value.  So, yes, I'll add a restricted range:

  t11FcsIeName  OBJECT-TYPE
      SYNTAX       FcNameIdOrZero (SIZE(8 | 16))

> - This definition seems strange:
> 
>   t11FcsIeFabricName  OBJECT-TYPE
>     SYNTAX       FcNameIdOrZero
>     MAX-ACCESS   read-only
>     STATUS       current
>     DESCRIPTION
>             "The Fabric_Name (WWN) of this Interconnect Element.
>             When the Fabric_Name is unknown, this object contains
>             the all-zeros value: x'00 00 00 00 00 00 00 00'."
>     REFERENCE
>             "ANSI INCITS xxx-200x, Fibre Channel - Generic Services 5,
>             FC-GS-5 T11/Project 1677-D/Rev 8, section 6.2.3.2.5."
>     DEFVAL { '0000000000000000'h }
>     ::= { t11FcsIeEntry 5 }

I'll add a restricted range here too.

  t11FcsIeFabricName  OBJECT-TYPE
      SYNTAX       FcNameIdOrZero (SIZE(8 | 16))

> - I see this:
> 
>   t11FcsIeMgmtAddrListIndex  OBJECT-TYPE
>     SYNTAX       T11ListIndexPointer
>     MAX-ACCESS   read-only
>     STATUS       current
>     DESCRIPTION
>             "The management address list for this Interconnect Element.
>             This object points to an entry in the
>             t11FcsMgmtAddrListTable."
> 
>   Reading the DESCRIPTIOn clause, I wonder why one would not use a 
>   RowPointer. The fact is that the pointer does not point to "an entry"
>   in the t11FcsMgmtAddrListTable, but to a SET of such entries.
>   So I guess the DESCRIPTION clause could be clarified.

It is sufficient (and simpler) for this TC to be an Unsigned32, whereas
RowPointer is an OID.
 
As a clarification, I've added this sentence to T11ListIndexPointerOrZero's
DESCRIPTION:

              Note that such a table could have one row per list, or
              it could have one row per element of a list.
 
> - I see:
>  
>   t11FcsIeInfoList  OBJECT-TYPE
>     SYNTAX       OCTET STRING (SIZE (0..252))
>     MAX-ACCESS   read-only
>     STATUS       current
>     DESCRIPTION
>             "The information list for this Interconnect Element.
>             This object contains the following substrings in order:
>             vendor name, model name/number and release code/level,
>             followed by zero or more substrings of vendor-specific
>             information. Each substring is terminated with a byte
>             containing a null value (x'00')."
> 
>   And that reads as if it is ASCII information to be (potentially) 
>   consumed by human beings.  So in that case, the IETF wants it to
>   be an internationalized string.  Comment?
 
FC-GS-5 requires the individual values to be ASCII strings (terminated
by nulls).  I'll edit the DESCRIPTION to be:

            The value of this object is formatted as specified in
            FC-GS-5, i.e., it contains the following substrings in
            order:  vendor name, model name/number and release
            code/level, followed by zero or more substrings of
            vendor-specific information. Each substring is terminated
            with a byte containing a null value (x'00')."

> - I see:
> 
>   t11FcsMgmtAddr  OBJECT-TYPE
>     SYNTAX       SnmpAdminString
>     MAX-ACCESS   read-only
>     STATUS       current
>     DESCRIPTION
>             "The management address of this entry.
>             The format of this object may be based on the
>             format of the Uniform Resource Locator (URL).
>             For example, for SNMP, see RFC 4088."
> 
>   So it syas "the format MAY be based on..." (my emphasis on MAY).
>   So, does that mean it may also be based on something else?
>   How do I determine what the actual format is?
 
On re-reading FC-GS-5, I see that it's required to be a URL, and
it's the use of 4088 which is not required.  So, I'll change it to:

            The format of this object is a Uniform Resource Locator
            (URL), e.g., for SNMP, see RFC 4088."

> - SMICng gave a warning about the indexing of
> 
>   t11FcsPortListEntry  OBJECT-TYPE
>     SYNTAX       T11FcsPortListEntry
>     MAX-ACCESS   not-accessible
>     STATUS       current
>     DESCRIPTION
>             "An entry which identifies that the port which has the
>             port name, t11FcsPortName, is in a particular list of
>             ports, which is known to a switch (identified by
>             fcmInstanceIndex and fcmSwitchIndex)."
>     INDEX   { fcmInstanceIndex,  fcmSwitchIndex,
>               t11FcsPortListIndex, t11FcsPortName }
>     ::= { t11FcsPortListTable 1 }
> 
>   I read Keiths explanation, which seemed fine. But now that I am
>   reviewing the MIB module in details and try to understand things,
>   now I am no so sure this is goodness.
> 
>   So, that t11FcsPortname is a value (embedded in the index) that
>   should help me find more detailed info, right?
>   So how do I find that info? I think I need to go to the
>   t11FcsPortTable, which is indexed by:
> 
>     INDEX   { fcmInstanceIndex, fcmSwitchIndex,
>               t11FcsFabricIndex, t11FcsPortName }
> 
>   So assuming that the index values for fcmInstanceIndex, fcmSwitchIndex,
>   are the same in both tables, I can see that I can pick up 3 index
>   values from the list of t11FcsPortsList in the t11FcsPortsListTable.
>   But I am missing the 3rd index of the t11FcsPortnameTable, namely
>   t11FcsFabricIndex. So how am I going to wuickly pick that up?
>   Or how exactly are the tables connected/linked?
> 
>   Maybe I need to study it deeper... but I'd prefer an explanation of
>   the people who created these tables with the current indexing schemes.
 
To generate an answer to your question, I needed to re-review the
structure of the tables, and in doing so, I now think that the current
structure is more open-ended/flexible than it needs to be -- having a
less open-ended structure would make the MIB simpler.  Specifically,
the MIB currently has a table whose only purpose is to identify a list
of (not necessarily related) ports.  However,

- each IE is either a virtual IE attached to one virtual Fabric, or
  (if virtual Fabrics are not in use) it's a physical IE.
- each port is either a virtual port attached to one virtual Fabric, or
  (if virtual Fabrics are not in use) it's a physical port.
- GS-5 mentions that an IE has a "port list" and has a dotted line from the
  "Interconnect Element Object" to the "Port Object" in its "Figure 7 --
  Interconnect Element and Port attributes".
- However, all ports in an IE's port list will be attached to the same 
  Fabric as that IE is attached to.  In other words, the relationship
  between IEs and ports is hierarchical.
- Thus, it would be simpler to:

  - delete the t11FcsPortListTable,
  - delete the t11FcsIePortListIndex object, and
  - insert t11FcsIeName into the INDEX of the t11FcsPortTable, i.e.,
    change the INDEX-ing of the t11FcsPortTable to be:

      INDEX   { fcmInstanceIndex, fcmSwitchIndex, t11FcsFabricIndex,
                t11FcsIeName, t11FcsPortName }

Increasing the INDEX clause from four to five objects makes it a little
more cumbersome, but the length is still far short of the maximum length.

With these changes, while there will no longer be any explicit mention
of a "port list" in the MIB, the list of ports on an IE will be all
the rows in t11FcsPortTable which have the same values for the first
four index objects, i.e., the value of t11FcsPortName will be the only
index value for which they differ.  So, a "port list" is (implicitly)
a set of adjacent rows in the t11FcsPortTable.

David, since this is a MIB design change, may I suggest you ask the WG
for approval of this as a separate/individual question.

> - for
>  
>   t11FcsPortName  OBJECT-TYPE
>     SYNTAX       FcNameIdOrZero
>     MAX-ACCESS   not-accessible
>     STATUS       current
>     DESCRIPTION
>             "The Port_Name (WWN) of the port for which this row
>             contains information."
> 
>   I wonder if a zero value (zero length OCTET STRING) is really valid?
>   If not, then we may need to limit it with a SIZE paramter aka
>     SYNTAX       FcNameIdOrZero SIZE (8 | 16)
> 
>   But,  I do see that in sect "6.2.3.3.1 Port Name" of document
>   http://www.t11.org/ftp/t11/pub/fc/gs-5/06-192v2.pdf, it says:
> 
>       The null value for the Port Name attribute is
>       00 00 00 00 00 00 00 00h.
> 
>   So... is the SYNTAX of FcNameIdOrZero appropriate here? 
>   In any event, the name SIZE seems to be fixed at 8 octets for the
>   PortName, so at least one would then define the syntax as:
> 
>     SYNTAX       FcNameIdOrZero (SIZE (8))
 
A length of 16 is still a possibility -- section 6.2.3.3.1 refers to
FC-FS, in which section 15 (table 66) includes one format which has a
length of 128 (bits).

So, I'll chaneg it to:
 
      SYNTAX       FcNameIdOrZero (SIZE(8 | 16))

> - For:
> 
>   t11FcsPortModuleType  OBJECT-TYPE
>     SYNTAX       Unsigned32 (0..255)
>     MAX-ACCESS   read-only
>     STATUS       current
>     DESCRIPTION
>             "The port module type of this port."
>     REFERENCE
>             "ANSI INCITS xxx-200x, Fibre Channel - Generic Services 5,
>             FC-GS-5 T11/Project 1677-D/Rev 8, section 6.2.3.3.4."
> 
>   It seems better to create a TC that ENUMerates the valid values?

The choice between using either an enumerated value, or, a numeric
value to be looked up in another specification, is a trade-off of
convenience versus maintenance.  For something which changes
frequently, it's better that the MIB *not* contain a list which is
frequently out-of-date; for something which changes infrequently, it's
better to have the convenience of enumeration.
 
Specifically, for those objects defined in this MIB as enumerations,
when a new value is defined in T11, the new value cannot be used in the
MIB until the MIB is updated.  When the MIB syntax is Unsigned32,
new values can be used in the MIB as soon as they are defined by T11.

So, we intentionally chose to specify some objects in this MIB as
enumerations, and others as binary values, based on the frequency at
which new values can be expected to be defined and used -- not just in
the now completed GS-5, but also in GS-6 and its successors.

> - For:
> 
>   t11FcsPortSpeedCapab  OBJECT-TYPE
>     SYNTAX       OCTET STRING (SIZE (2))
> 
>   It seems that the references document and section say that it is a BITS
>   construct ??
> 
> - Same for t11FcsPortOperSpeed
 
While the Capability could be a BITS, OperSpeed would only ever have one
bit set, i.e., not a BITS.  However, both of these are further examples of
the enumerated versus numeric trade-off mentioned above.  That is, port
speed is another area where new enumerations can be expected and will
need to be used.

> - For:
> 
>   t11FcsPlatformName  OBJECT-TYPE
>     SYNTAX       OCTET STRING (SIZE (0..255))
> 
>   It seems to me that the SYNTAX better be:
> 
>     SYNTAX       OCTET STRING (SIZE (0 | 3..256))
> 
>   because http://www.t11.org/ftp/t11/pub/fc/gs-5/06-192v2.pdf
>   section 6.2.3.4.2 tells me:
> 
>     The Platform Name attribute may be registered using the
>     protocol described in 6.2.2.3. The null value for the
>     Platform Name attribute is a zero-length Platform Name.
> 
>   So maybe that is how we can get a length of zero. But I am
>   not even sure about that. It is also possible that the
>   first byte would be valued at zero. Is the format octet 
>   included in this case? Not clear from the PDF file for me.
> 
>   If I understand the PDF file correctly, then (it speaks about
>   reserved to be of length 254-m) then there are 2 octets (1 for
>   length, one for format) plus 254 for the actual name. So that
>   would be a max size of 256 in my view.
 
Many of the format specifications in the GS-5 spec. are like this:

              Logical Name length (m)     1
              Logical Name                m
              Reserved                  255-m

where the aggregate length (of the three sub-fields) is 256 bytes.

So, the way that I interpret the Platform Name field:

              Platform Name length (m)     1
              Platform Name                m
              Platform Name Format         1
              Reserved                   254-m

is similarly, to have an aggregate length is 256 bytes.  Therefore, the
correct MIB syntax is:

     SYNTAX       OCTET STRING (SIZE (0..254))

where the range is the value of m.

> - Several objects in the t11FcsPlatformTable
>   (like t11FcsPlatformVendorId, t11FcsPlatformProductId , etc)
>   suggest (based on the SYNTAX of SnmpAdminString) that the value
>   can be an internationalized human readable string.
>   But the table 121 in the PDF file, section 6.2.3.4.5 seems to
>   tell me that they are all ASCII. So what is it?

It's the format as specified in section 6.2.3.4.5, which is a
subset of SnmpAdminString, which I believe means that using
SnmpAdminString as the syntax is fine.

>   I know that IETF is not happy with using DisplayString, but if
>   that is what the underlying technology (outside IETF) uses, then
>   we should at least not suggest that it is different.
>   I could accept that we say "we want to be prepared for UTF-8 
>   strings, but for now it is ASCII as per DC-GS-5)". But it 
>   might be good to then explicitly state so in the DESCRIPTION
>   clauses of these objects.
> 
>   At the other hand, the objects are all read-only, and so even
>   if they only present ASCII data (in UTF-8 that is exactly the
>   same), then it would still be fine.

How about I leave it as SnmpAdminString, and point to GS-5 for
the definition of which characters are valid:

            "The identifier of the vendor of this platform, in
            the format specified by FC-GS-5."

>   I also wonder if the length for t11FcsPlatformVendorId,
>   t11FcsPlatformProductId can actually be zero, because table
>   121 says that these are REQUIRED fields.

The table gives their minimum length when they are present, *but*
a "Platform Attribute Block" doesn't necessarily contain them all.
 
> - For:
> 
>   t11FcsPlatformFC4Types  OBJECT-TYPE
>     SYNTAX       OCTET STRING (SIZE (0 | 32))
> 
>   should be 
>     SYNTAX       OCTET STRING (SIZE (0 | 20))
> 
>   that is what I read in table 121 of
>   http://www.t11.org/ftp/t11/pub/fc/gs-5/06-192v2.pdf

The text which follows the table says:

   Supported FC-4 Types: This is an 8 word (256 bit) bit mask that
   indicates what FC-4 types are supported on this platform (see 5.2.3.8).
   FCP-2 (FC-4 type 08h) is represented by bit 8 of word 0. The Fabric
   Configuration Server shall not attempt validation of the FC-4 Types
   attribute, and any value shall be accepted for this attribute.

I think the table has a typo.

> - Object t11FcsNodeName. Is it supposed to represent this:
> 
>   6.2.3.4.6 Platform Node Name
>      The format of the Platform Node Name attribute, as used by
>      the Fabric Configuration Server, shall be identical to the
>      Name_Identifier format defined in FC-FS. Zero or more
>      Platform Node Name attributes may be associated with a 
>      Platform object. Node Names are registered to associate
>      a Platform with the Nodes.
>      This attribute may be registered using the protocol described
>      in 6.2.2.3. The null value for the platform Node Name
>      attribute is 00 00 00 00 00 00 00 00h
> 
>   That last description of 8 hex zeroes for a null value seems
>   to conflict with the underlying 
> 
>     SYNTAX       FcNameIdOrZero
> 
>   that you are using in the MIB.
 
Ok, I'll change it to:
 
      SYNTAX       FcNameIdOrZero (SIZE(8 | 16))

> - W.r.t.
>  
>   t11FcsNotifyControlTable OBJECT-TYPE
>     SYNTAX       SEQUENCE OF T11FcsNotifyControlEntry
>     MAX-ACCESS   not-accessible
>     STATUS       current
>     DESCRIPTION
>             "A table of control information for notifications
>             generated due to Fabric Configuration Server events.
> 
>             Values written to objects in this table should be
>             persistent/retained over agent reboots."
> 
>   I have the same questions/concerns about the "should be persistent"
>   as I had for the RSCN MIB module. 
>   So we can probably resolve this one in the same way (or leave it
>   if everyone thinks that I worry too much).
 
OK.

> - It might be good to rename the notifications (for example)
> 
>     t11FcsReqRejectNotify NOTIFICATION-TYPE
> 
>   from xxxxNotify to xxxxNotification.

I chose to use t11FcsReqRejectNotify because t11FcsReqRejectNotification
is 33 characters long, and I think using t11FcsReqRejectNotify is a
clearer abbreviation than t11FcsReqRejNotification.
I guess I could go for:

     t11FcsRqRejectNotification NOTIFICATION-TYPE

if you prefer.

>   But I agree that this is really nitpicking. 
>   For consistency with (most) other MOB modules and notifications
>   I think my argument makes sense though.
> 
> - For the notifications (and the control there-of), it again seems
>   that the Transport Area may want us to say somehting about the
>   max number of nitifications to be expected per second/minute/xxx
>   or to provide a control varianle that a NMS can SET.
 
Their motivation is good, and is applicable to data-plane events, but
asking for a max number per unit time for every type of notification
is too simplistic.  E.g., it's unreasonable to ask how many
t11FcsDiscoveryCompleteNotify notifications can be generated in a
second/minute/xxx -- how big is the network, how many virtual fabrics
need to be discovered, how quickly can the operator ask for another
discovery after the last one completes ??

If a max rate is specified by an NMS, such that notifications can be
suppressed due to their volume, then there needs to be some mechanism
for the NMS to know that suppression(s) have happened/are happening,
which means more notification-types and objects need to be defined.
That is, it increases the complexity, which is not warranted unless
there can really be a "flood" of notifications.

For notifications, like all the ones in this MIB, which are generated
due to control plane events (and providing that none of them are able
to start a chain-reaction), the extra complexity is not warranted.

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 8 Sep 2006 08:41:45 -0700 (PDT)

> T11-FC-FABRIC-LOCK-MIB review
> 
> --------- questions/comments
> 
> - DESSCIPTION clause of t11FLockApplicationID says:
>            The value assigned to identify the 'application' for a
>            lock established via Acquire Change Authorization (ACA)
>            request is: 'D0'h (208 decimal).  This value will be
>            documented in a future revision of the FC-SW-nn
>            specification."
> 
>    Do we have any idea as to "when such future FC-SW-nn will show
>    up ?? If not, is this acceptable?
 
My understanding is that FC-SW-4 is closed, and it lists 'D0'h as one
of the reserved values.  The long-time editor of FC-SW-nn sent an email
message dated 8Aug06 to the T11.5 mailing-list with the assignment of
a range of values including 'D0'h for this purpose.  The assignment
will be documented in FC-SW-5 which is approved as a new project, but
there is no initial draft of it yet.

Would you like a formal liaison message from T11 to the IETF stating
what number has been assigned ??

> - For t11FLockInitiator, in the case the SNMP, would it not be 
>   wise/usefull to add the snmpSecuityName?
 
I suggest it should be possible to be a compliant implementation of this
MIB even for an SNMPv1/SNMPv2 implementation which doesn't support SNMPv3.
So, if we define an object to hold the value of snmpSecurityName, we
need to define what value that object will have in an agent which does
not implement the SNMP-COMMUNITY-MIB (in which snmpCommunitySecurityName
is defined).  What value would you propose ??

> - Reading:
> 
>    t11FLockRowStatus OBJECT-TYPE
>       SYNTAX        RowStatus
>       MAX-ACCESS    read-create
>       STATUS        current
>       DESCRIPTION
>            "The status of this conceptual row.
> 
>            A row for which the value of t11FLockInitiatorType is
>            not 'snmp' cannot be deleted via this object."
> 
>   I wonder:
>   - can a row be set to notReady or notInservice for rows that
>     were not created by 'snmp'? I guess not, but one could get
>     the impression that such is possible based on this one 
>     sentence

How about we change "be deleted" to "have its status changed" ??

>   - What is the persistence behaviour of a row created via snmp?
>     Probably nonVolatile? But would be good to say something
>     about it.
 
No, I think it should be volatile, because an agent restart is the
equivalent of the "various error situations" mentioned in the last
paragraph of t11FLockEntry's DESCRIPTION.  Yes, I'll add some text.

> - SO I see:
> 
>     t11FLockStatus OBJECT-TYPE
>         SYNTAX        INTEGER {
>                       active(1),
>                       settingUp(2),
>                       rejectFailure(3),
>                       otherFailure(4)
>                   }
> 
>   and wonder what will happen if the lock gets released?
>   not sure I understand how such happens, but I would assume a lock does
>   not stay forever once it has become active, does it?

No.  It gets released explicitly or implicitly (as mentioned above). 

>   Does the entry disappear in that case? 
 
Yes, because the table is defined as the list of all *current* locks.
 
> --------- NITS
> 
> - in t11FLockEntry DESCRIPTION clause I read 4th para:
> 
>           Recently, a distinct value of Application_ID has also been
>           assigned/reserved as a means of distinguishing locks
>           established via Acquire Change Authorization (ACA)
>           requests.  With this recent assignment, an Application_ID
> 
>   I think I would remove "Recently" and "recent".
>   This document is intended for a reasonably long lifespan in the
>   future, no?
 
OK, how about I can change it to:

          Not long before this MIB was defined, a distinct value of
          Application_ID was also assigned/reserved as the means to
          distinguish locks established via Acquire Change
	  Authorization (ACA) requests.  This additional assignment
	  allows an Application_ID to be used to uniquely identify a
	  lock amongst all active locks established either by an EACA
	  or by an ACA.

> - REFERENCE clauses of course need to be updated.
 
Right.

> - for t11FLockActiveGroup, the description clause does not say that
>   (if write/create-mode is supported) that a lock can also be
>   established.
 
I don't understand.  One of the objects in the t11FLockActiveGroup is
t11FLockRowStatus, which is defined with a MAX-ACCESS of read-create
and a MIN-ACCESS of read-only.  So, what do you want clarified ??

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 8 Sep 2006 08:48:04 -0700 (PDT)

Sure, I'll make the changes you suggest.

Keith.

> I also see another few NITs now that I am reviewing the 2nd 
> MIB module in the same document.
> 
> - t11FLockRejectReasonCode OBJECT-TYPE
>     SYNTAX        T11NsGs4RejectReasonCode
>     MAX-ACCESS    read-only
>     STATUS        current
>     DESCRIPTION
>            "When the value of the corresponding instance of
>            t11FLockStatus is 'rejected', this object contains
>            the rejection's reason code."
> 
>   Based on the ENUMerated values for t11FlockStatus, I 
>   think we should change 'rejected' into 'rejectFailure'.
> 
> - same for t11FLockRejectReasonCodeExp
>   and t11FLockRejectReasonVendorCode
> 
> - Now that I see t11ZsServerReasonCode, I wonder if the 2nd
>   para in the DESCRIPTION clause would also make sense for
>   the t11FLockRejectReasonCode object
> 
> - do the SIZE for t11ZsServerReasonCodeExp
>   and t11ZsServerReasonVendorCode possibly also make sense for 
>   t11FLockRejectReasonCodeExp, t11FLockRejectReasonVendorCode
>   that is allowing for a SIZE of zero?
> 
> 
> Bert
> 
> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> > Sent: Thursday, September 07, 2006 17:51
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: [imss] WG last call review: T11-FC-FABRIC-LOCK-MIB in
> > draft-ietf-imss-f c-zs-mib-00.txt
> > 
> > 
> > - for t11FLockActiveGroup, the deascription clause does not say that

---

From: Claudio DeSanti <[email-masked]>
Date: Fri, 08 Sep 2006 10:00:47 -0700

Keith,

in a different conversation (unfortunately not happened on this list) 
with the FC-SW-x editor, we agreed that the proper value should be FFh, 
255 decimal. The first revision of FC-SW-5 is expected to contain this 
assignment.
Thanks,

                          Claudio.

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 11 Sep 2006 13:33:46 -0700 (PDT)

Thanks for the comments.  Responses below.

Keith.
---------------------------

> T11-FC-ZONE-SERVER-MIB
> - Would it be better to rename T11ZoningName to T11ZsZoningName?
>   This for naming consistency and avoiding possible future name
>   clashes.
 
First, I would agree if its name was ZoningName, but prepended with
"T11", the odds of it having any affect on "future name clashes" is
negligible.

Second, I regret that I named T11NsGs4RejectReasonCode with an
"Ns" in the middle -- it would have been better to have named it
T11Gs4RejectReasonCode, or better still T11GsRejectReasonCode, 
because it has been used in several FC MIBs for protocols defined in
FC-GS-nn, i.e., it is not specific to the Name Server and not specific
to FC-GS-4.

Third, if used in another MIB, the place where it is defined is
specified in the IMPORTS clause, and thus, doesn't have to be explicit
from the name.

Nevertheless, if you insist that I repeat my past mistakes:-), OK.

> - For t11ZsServerDistribute
>           Setting this object will fail if the corresponding
>           instance of t11ZsServerOperationMode has the value
>           'enhanced', or if the corresponding instance of
>           t11ZsZoneSetResult has the value 'inProgress'."
>   
>   will fail with what? I assume/think 'inconsistentValue'.
>   Might be good to state so, to ensure proper implementation.

I disagree.  I think it's bad practice to put error codes in
DESCRIPTIONs.  I just cricitized the IPSP WG MIBs for putting
'inconsistentValue' in their DESCRIPTIONs because that error code
is NOT used if and when any of the nine higher-precedence error
conditions prevails.

How about I change it to:

         When the corresponding instance of t11ZsServerOperationMode
         has the value 'enhanced', or when the corresponding instance
         of t11ZsZoneSetResult has the value 'inProgress', it
         is inconsistent to try to set the value of this object.

OK.

OK.

> - I wonder why this
> 
>     t11ZsServerDefaultZoneSetting OBJECT-TYPE
>         SYNTAX       INTEGER {
>                         permit(1),
>                         deny(2)
>                      }
> 
>   Is not done with a TruthValue possibly using a different
>   descriptor.
>   Not a fatal flaw though, but a missed opportunity for
>   re-use in my view. Unless if one expects more values in
>   the future.
> 
>   For t11ZsServerMergeControlSetting it is less obvious, but the
>   same question could be asked I guess.
 
Each object in question refers to the setting of a single bit, which
(obviously:-) takes the values 0 or 1, and so, yes, it would be possible
to define each object as a TruthValue which has two values 'true' and
'false'.  However, the FC-GS-5 spec does not define either bit as:
true/false.  Instead, it defines the behaviour when the bit is 0, and
the behaviour when the bit is 1.  I think it's better in these cases to
emphasize the commonality with FC-GS-5 by using the same definition,
rather than intepreting the definitions as true/false.

> - I see:
>     t11ZsSetName OBJECT-TYPE
>         SYNTAX       T11ZoningName
>         MAX-ACCESS   read-create
>         STATUS       current
>         DESCRIPTION
>            "The name of this Zone Set. The t11ZsSetName should
>            be unique within a fabric.
> 
>            The Zone Set can be renamed by setting this object
>            to a new value."
> 
>   and wonder if the rename can also be done while the row is in
>   'active' state !!??
 
It can.  I'll add a few words.

> - I am not sure I understand this:
> 
>     t11ZsSetEntry  OBJECT-TYPE
>         SYNTAX       T11ZsSetEntry
>            "Each entry contains information about a Zone Set
>            in the Zone Set database of a particular fabric
>            (identified by the value of t11ZsServerFabricIndex)
>            on a particular switch (identified by values of
>            fcmInstanceIndex and fcmSwitchIndex).
> 
>            A Zone Set is created containing zero or more
>            existing Zones.  As and when new Zones are created
>            (as rows in the t11ZsZoneTable), they can be added
>            to a Zone Set by creating an entry for each in the
>            t11ZsSetZoneTable.
> 
>            The StorageType of a row in this table is specified by
>            the instance of t11ZsServerDatabaseStorageType which is
>            INDEX-ed by the same values of fcmInstanceIndex,
>            fcmSwitchIndex and t11ZsServerFabricIndex."
>                   t11ZsServerFabricIndex, t11ZsSetIndex }
>         ::= { t11ZsSetTable 1 }
> 
>   So it seems to me I can do SNMP SET to create an entry in this
>   table. But is is not clear if, when I do so, and entry in the 
>   t11ZsServerTable must already exist or not. Probably so,
>   because it uses the actual (index) objects from that table.
>   But in practice, can an SNMP utility not just create entries
>   with index values that do not really exists in the base
>   table? I'd like to know how the agent is supposed to react.
 
Well, yes, the row in the t11ZsServerTable must exist, but to say
"already exist" would mislead the reader because there's no RowStatus
in that table.  Instead, there's an entry in the t11ZsServerTable
for the Zone Server for a particular fabric on a particular switch.
I think that's already implicit in:

           "Each entry contains information about a Zone Set
           in the Zone Set database of a particular fabric
           (identified by the value of t11ZsServerFabricIndex)
           on a particular switch (identified by values of
           fcmInstanceIndex and fcmSwitchIndex).

In other words, this MIB about creating/editing information in the
Zone Set Database of existing Zone Servers, not for creating new
Zone Servers on switches and/or new Fabrics.

Would it help to insert "existing" in the above paragraph to try to
make it more explicit ??

>   So if the base table entrues must exist first,
>   then it would be good to say so, i.e. spell it out.
>   And to say what happens if it does not yet exist.
>   If not, then I wonder how/when the entry in that t11ZsServerTable
>   does get created, because otherwise it is unclear how/if/when
>   the persistency works.
>   
>   And what when I delete the row? Does it have any effect on the
>   associated rows in t11ZsServerTable. Possibly not. But I am
>   not sure how I can determine that based on the current
>   DESCRIPTION clauses.
 
Deleting a row from the t11ZsSetTable deletes the Zone Set from the
Zone Set Database maintained by the Zone Server, but does not
otherwise affect the Zone Server.

> - I have the same/similar question for t11ZsZoneEntry
 
So, shall I also insert "existing" into t11ZsZoneEntry's DESCRIPTION
to try to make it similarly more explicit ??

> - Can t11ZsZoneAttribBlock be changed while row is active?
> 
>   such questions can be asked for more read-write/read-create
>   objects in this MIB module. I won't keep repeating.
 
See the picture in section 5.6 -- all read-write objects in the
Zone Set Database can be modified at any time.  The reason that other
MIBs don't allow writes while a row is active is because they overload
the RowStatus for in-use/not-in-use as well as for create/delete.
In this MIB, only the Active Zone Set is in-use and it is read-only
except to be Activated/De-Activated.

I too don't want to keep repeating it.  So, suggest I add a paragraph
to the MODULE-IDENTITY's DESCRIPTION explaining that the MIB is a
combination of the Zone Set Database and the Active Zone Set, where all
objects representing the former are modifiable at any time whereas all
objects representing the latter are always read-only, other than by
completely overwritting the Active Zone Set by a subset of Zone
Set Database, or by completely deleting it.

> - For t11ZsSetZoneEntry, it seems that the 3 other tables MUST
>   have an existing associated entry(entries) before creating 
>   an entry in this row makes sense. But maybe it is OK to 
>   prepare this table before the other tables have been 
>   completed/created?
 
> - for t11ZsSetZoneRowStatus I wonder what happens if this
>   one has a value of active, byt the rowstatus in some of
>   the other (base) tables have a value of notInservice or
>   notReady ??
> 
>   Are we all supposed to try and figure this out, or would it
>   be better to put something about this in the various
>   DESCRIPTION clauses?
>
> - In fact the whole fate-sharing between all the tables may
>   need to be described. I see some of it in section 5.5. and
>   5.6 of the document, but also from that I do not yet see
>   what the implications are if the rowstatus in one table is
>   notInservice, while others are actve or  maybe notReady,
>   or maybe do not (yet) exist.
>   I must also admit that I have not studied the T11 documents 
>   much (in fact very little) yet. But I'd hope that these
>   basic question would be answered in the IETF MIB document
>   itself.
 
OK.

> - I see no persistency behaviour (or a link to the StorageType
>   objects in the base table in t11ZsActivateTable.
>   I think it is clear that the writable objects are all
>   volatile (they seem to be control objects that cause an
>   action when SET).
 
Persistency is fully specified in those objects which include
this statement: 

           When read, the value of this object is always xxx.

This statement:

           "A textual message indicating the reason for the
           most recent failure of a Zone Set activation or
           de-activation, or the zero-length string if no
           information is available.

allows an agent to retain the info for as long as it can.

I'll modify:

           The value 'none' indicates activation/de-activation
           has not been attempted.

by appending "since the last restart of the management system."

> - For namingconsistency in:
>     T11ZsActiveZoneEntry ::= SEQUENCE {
>        t11ZsActiveZoneIndex      Unsigned32,
>        t11ZsActiveZoneName       T11ZoningName,
>        t11ZsActiveBroadcast      TruthValue,
>        t11ZsActiveHardZoning     TruthValue
>     }
>   I would insert a "Zone" before "Broadcast" and before "Hardzoning"
 
I didn't do that because whereas t11ZsActiveZoneIndex is the Zone's
Index and t11ZsActiveZoneName is the Zone's Name, t11ZsActiveBroadcast
is not the Zone's Broadcast.  Further, t11ZsActiveBroadcast is about
"Broadcast Zoning", not "Zone Broadcast" -- t11ZsActiveZoneBroadcast
gives the wrong impression.  So, I guess it has to be
t11ZsActiveZoneBroadcastZoning.

>   By the way, t11ZsActiveZoneSetName in the T11ZsActiveEntry might be
>   (at first sight) perceived to be in the T11ZsActiveZoneEntry.
>   I understand why it has that name, but it may consfuse some
>   people.
> 
> - t11ZsActiveBroadcast and t11ZsActiveHardZoning both have in
>   their DESCRIPTION clauses:
>              This object is only instantiated in Enhanced mode."
> 
>   would we not want to specify that in a MODULE-COMPLIANCE for 
>   basic mode and one for enhanced mode?
 
They are both in the t11ZsEnhancedModeGroup, and it is specified as:

    GROUP        t11ZsEnhancedModeGroup
    DESCRIPTION
           "This group is mandatory only for those systems
           with Zone Servers which support Enhanced Mode."

which I believe is sufficient.
 
> --------- NITS/TYPOs
> 
> - In one but last para of DESCRIPTION clause of MODULE-IDENTITY
> 
>      When this MIB is used for Basic Zoning Management, the same
>      set of MIBs objects as used for Enhanced mode are used to
> 
>   s/MIBs objects/MIB objects/
> 
> - In t11ZsServerFabricIndex, the last 2 paragraphs of the
>   DESCRIPTION clause seem redundant with the DESCRIPTION clause
>   of the TC itself. I would remove them. The idea of a TC is
>   to have one place (namely in the DESCRIPTION clause of the TC)
>   to describe the (basic) semantics of the objects that use 
>   the TC as a SYNTAX.
 
If I recall correctly, I added them there due to some earlier
comment on an exactly-equivalent definition (I don't remember which
MIB it was in).

> - t11ZsServerCapabilityObject
>   I think I would rename zonesetDb(1) to zoneSetDb(1)
>   but this is pretty subjective taste of course.
> 
> - last para of description clasue of t11ZsServerDatabaseStorageType
> 
>            This value of this object is a...
> 
>   s/This/The/ ??
>   
> - For t11ZsAttribType maybe add "other values reserved" in the 
>   DESCRIPTION clause. I went looking it up, because in an 
>   earlier object we had E0-EF as Vendor specific. So I thought
>   that might also be the case here. But the text in the 
>   REFERENCEd docment/section told me they are reserved.
 
Values which are reserved today could easily be allocated tomorrow.
Values which are allocated today will likely stay allocated to the
same thing for a long time into the future.  Thus, listing the allocated
values and omitting the reserved values has the best chance of
continuing to be correct in the future.

> - for
>    t11ZsActivateRequest OBJECT-TYPE
>      SYNTAX       Unsigned32 (0..4294967295)
>      MAX-ACCESS   read-write
>      STATUS       current
>      DESCRIPTION
>            "Setting this object to a value is a request for a
>            Zone Set to be activated on the fabric which is
>            represented by this row.  The Zone Set to be
>            activated is the one for which t11ZsSetIndex has
>            the same value.
> 
>            If a Zone Set is already active on a fabric when a
>            request is made to activate a different one on that
>            fabric, then the existing Zone Set is automatically
>            deactivated and the specified Zone Set is activated
>            in its place.
> 
>            The value of this object when read is always 0."
> 
>    It seems that setting the value to zero has no effect. Right?
>    But zero seems to also have special meaning. Oh well. I might
>    indicate it by using 
>      SYNTAX       Unsigned32 (0 | 1..4294967295)
>    but that is subjective taste I guess.
>
> - similarly, for
> 
>     t11ZsFabricIndex OBJECT-TYPE
>         SYNTAX       Unsigned32 (0..4096)
> 
>   I think I would use  
> 
>         SYNTAX       Unsigned32 (0..4095 | 4096)
> 
>   to indicate that 4096 has special meaning.
 
The example which is most well-known (at least to me) of a "special
meaning" is InterfaceIndexOrZero which is not indicated like this.
Further, I don't know where, if anywhere, your convention is
documented, and I think you would have difficulty defining the
term "special meaning" if you did try to document it.

>   Maybe I would even create a 
> 
>       T11FabricIndexOrAll ::= TEXTUAL-CONVENTION
> 
>   So it could if an "ALL" option is needed in the future that it is
>   (or at least can be) done in a consistent maner.
 
If I thought that it would be re-used, then yes, I'd do this.
But, after so many (that I've lost count) Fibre Channel MIBs, and
now that I'm working on the last set (at least, the last scheduled
ones), I don't think it's worth it.

> - I personally prefer to name notifications xxxNotification instead
>   of naming them xxxNotify. But I admit that that is subjective.
> 
> Bert
>

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 14 Sep 2006 09:02:33 -0700 (PDT)

> Section 3 is not a "Short" Overview of Fibre Channel ;-).  It could

OK, I'll just delete the "Short".

> usefully be broken into 3 subsections:
> - Overview

After deleting "Short", this would be better as "Introduction" or as
"General Overview".

> - Zoning
> - Zoning Configuration and Management

OK, I assume you're not suggesting a re-ordering, but just the insertion
of sub-section titles, e.g., insert "3.3  Zoning Configuration and
Management" immediately before::

   Zones are configured via a Fabric Zone Server, using ...
 
> The first paragraph describing zoning says:
> 
>    Zones within a fabric provide a mechanism to control frame delivery
>    between Nx_Ports ("Hard Zoning") or to expose selected views of Name
>    Server information ("Soft Zoning").  This technique is similar to
>    virtual private networks in that the fabric has the ability to group
>    devices into Zones.
> 
> It needs an additional few sentences to explain what a zone does and
> where it's enforced, specifically to make the following points:
> - Communication is only possible when the communicating endpoints
> 	are members of a common zone.
> - Hard zoning and soft zoning are two different means of realizing
> 	this.  Hard zoning is enforced in the fabric (i.e., switches)
> 	whereas soft zoning is enforced at the endpoints (e.g., HBAs)
> 	by relying on the endpoints to not send traffic to an N_Port_ID
> 	not obtained from the nameserver with a few exceptions for well
> 	known N_Port_IDs used to bootstrap the fabric (e.g., talk to the
> 	nameserver).
 
OK.

> Section 5.4 ought to explain how an SNMP management client can determine
> whether a fabric is operating in basic vs. enhanced mode.
 
OK.  I'll add a paragraph which mentions t11ZsServerOperationMode, and
probably t11ZsServerCapabilityObject as well.

Keith.

---

From: [email-masked]
Date: Thu, 14 Sep 2006 14:52:58 -0400

>    Zones are configured via a Fabric Zone Server, using ...

Yes.

Thanks,
--David

> Sent: Thursday, September 14, 2006 12:03 PM
> To: Black, David
> Cc: [email-masked]
> Subject: Re: [imss] Last Call comments on

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 18 Sep 2006 12:09:46 -0700 (PDT)

Thanks for the comments.  My responses below.

Keith.
---------------------------------

> 1. smilint complains about: 
> 
> mibs/T11-FC-RSCN-MIB:217: [1] {internal-other} parse error, unexpected
> LOWERCASE_IDENTIFIER, expecting '}' or ','
> mibs/T11-FC-RSCN-MIB:227: [5] {internal-flushing} warning: flushing
> recent incorrect declaration, see previous error(s)
> mibs/T11-FC-RSCN-MIB:170: [2] {type-unknown} unknown type
> `T11FcRscnStatsEntry'
> 
> All seem due to a missing comma in 
> 

Yes, we had already caught this.

>  2. 
>    Note that an interface's ifIndex value must be unique within an SNMP
>    context, irrespective of how many Fibre Channel management instances
>    (see below) and how many Fibre Channel switches are instrumented
>    within that SNMP context.
> 
> What do we exactly mean by 'SNMP context' ? I believe that the meaning
> is of a management domain modeled by SMIv2 MIBs or fiber channel
> management instance, not necessarily SNMP-related.

No, we mean exactly what is specified in RFC 3411, section 3.3.1.

> draft-ietf-imss-fc-fcs-mib-00.txt got it better, 'SNMP context' is only
> an example there. 
 
RSCN is missing a couple of common edits which were done for FCS & ZS,
i.e., both FCS & ZS have just the one reference to an SNMP context:

   "... for example within the same SNMP context ([RFC3411] section 3.3.1)."

In contrast, RSCN has two references to an SNMP context:

1. The same one as FCS & RSCN, except that it is missing the edit which
   inserted "for example".
2. The one in the paragraph you quote above.  This paragraph was written
   for a previous Fibre Channel MIB which IMPORT-ed ifIndex for use in
   INDEX clauses alongside index-ing objects for Fibre Channel
   management instances and Fibre Channel switches.  The intent of the
   paragraph is to clarify that an ifIndex value must be unique within
   an SNMP context even if that means it must be unique across multiple
   Fibre Channel management instances and across multiple Fibre Channel
   switches.  However, the paragraph is not needed in any of the FCS,
   RSCN or ZS MIBs because none of them have ifIndex in any INDEX
   clause.  This paragraph has already been deleted from the FCS & RSCN
   MIB documents.

So, there are two missing edits in the RSCN MIB document:
- insert "for example"
- deleted extraneous paragraph.

> 3. The Security Considerations section does not really provide an
> explanation about the hazards in intentionally or unintentionally
> misconfiguring the read-write objects (probably suppressing information,
> or flooding the network with undesired notifications) 
 
These notifications can't occur so often, and so I won't say "flooding".
But it's easy to add a sentence to say: 

   The object to enable/disable the notifications would, if
   misconfigured, either generate unwanted notifications or suppress
   wanted notifications.

While I think it's redundant, it doesn't do any harm.  So, I will add it.

> 1. smilints returns 3 warnings: 
> 
> T11-FC-FABRIC-CONFIG-SERVER-MIB:773: [5] {index-element-not-accessible}
> warning: exactly one index element of row `t11FcsPortListEntry' must be
> accessible

This is a bug in smilint.  t11FcsPortListTable has only one columnar
object: t11FcsPortListIndex, and it is read-only.

> mibs/T11-FC-FABRIC-CONFIG-SERVER-MIB:80: [5] {type-without-format}
> warning: type `T11ListIndex' has no format specification
> mibs/T11-FC-FABRIC-CONFIG-SERVER-MIB:90: [5] {type-without-format}
> warning: type `T11ListIndexPointer' has no format specification

For both of these, RFC 2579 says:

   The DISPLAY-HINT clause, which need not be present, ...

and RFC 4181 says:

   The DISPLAY-HINT clause is used [...]  Its presence is optional.

> 2. Some of the read-write objects have no DEFVAL defined -
> t11FcsFabricDiscoveryRangeLow, t11FcsFabricDiscoveryRangeHigh,
> t11FcsFabricDiscoveryStart
 
RFC 2578 says:

   The DEFVAL clause, which need not be present, ...
 
The only change to this in RFC 4181 is a situation where DEFVAL MUST NOT
be used. 

> 1. I was expecting the Security Considerations section of this document
> to include more details about the security issues related to the
> read-write objects in the MIB modules. While it is true that intentional
> or unintentional misconfiguration can lead to some kind of connectivity
> problems there are however differences in the level of threats generated
> by attacking fabric controls and generation of notifications. These need
> to be separately articulated IMO. 

So, how about I add:

 - the suppression of notifications (e.g., of unauthorized operations), and
 - the disruption of network operations due to the generation of unwanted
   notifications,

to the list of potential consequences ??

> 2. It is not clear to me how t11FLockTable entries work in the case of a
> non SNMP lock creation. How is a new row protected so that it will not
> be manipulated by CLI while in SNMP creation and the other way? If there
> are some assumptions about a common underCreation state, they need to be
> clearly articulated. 

FC-GS-5 specifies how locks are created on receipt of an SSB,
To avoid a conflict, the MIB needed to define how a lock can be
created via SNMP, such that SNMP-management could modify the Zone
Database without interference from the in-band management protocol,
and vice-versa.  While defining a mechanism for SNMP, it seemed like a
good idea to allow for locks by the CLI.

A row in the table for the CLI works in the same way as a row in the
table for the in-band management protocol, i.e., if a row in the
t11FLockTable is created by SNMP, its value of t11FLockInitiatorType =
'snmp'.  If a row has its value of t11FLockInitiatorType ='cli' or 'ssb',
then it cannot be deleted by SNMP.  So, there are no "assumptions about a
common underCreation state".

> 3. I do not have the T11 reference at hand, but I wonder why objects
> like t11FLockRejectReasonCodeExp have a SYNTAX of OCTET STRING. In any
> case, I would suggest a DISPLAY-HINT clause for these. 
 
t11FLockRejectReasonCodeExp is a 1-byte hexadecimal value, with an
ASCII string associated which each assigned value to indicate its meaning.
So, if the list were stable, this would be an enumerated INTEGER.
However, new reason codes get defined periodically, and it's unlikely
that this WG will get re-chartered frequently enough to keep the
enumerated values listed in the MIB uptodate.  Nor do we want to impose
a burden on IANA to assign new values, when new values are already being
assigned in T11 and documented in T11 specifications.  Instead, the
object has been defined an an "OCTET STRING (SIZE(1))" with a REFERENCE
clause which points to the most recent spec for assigned values.

So, I think that if anything is missing here, it's that there is no
explicit indication in this MIB that values which will not yet assigned
but will be assigned in future revisions of the Fibre Channel spec will
then be valid in this object.  Would you like me to append to the
REFERENCE clause, something like:

         ... or its successor"

In regard to a DISPLAY-HINT, there are two possible ways to display
a value of this object: either as a hex value, or as the relevant ASCII
string from the T11 spec.  My preference is for the ASCII string, but
there's no way to express that in a DISPLAY-HINT, and a DISPLAY-HINT
is optional.  Do you want me to add some text to the DESCRIPTION clause
to explain this ??

> 4. In T11ZoningName, what does 'letter' mean - ASCII only or
> internationalized as in SnmpAdminString? 
 
The REFERENCE clause points to section 6.4.8.1 of FC-GS-5, and
section 6.4.8.1.2 says:

   The Name Value field shall contain the ASCII characters that specify
   the name, not including any required fill bytes. Names shall adhere
   to the following rules:
    ...
    c) The first character of a given name shall be a letter. A letter
    is defined as either an upper case (A-Z) character or a lower case
    (a-z) character; and
    ...

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 18 Sep 2006 18:59:28 -0700 (PDT)

Dan,

> > > 2. It is not clear to me how t11FLockTable entries work in 
> > the case of 
> > > a non SNMP lock creation. How is a new row protected so 
> > that it will 
> > > not be manipulated by CLI while in SNMP creation and the 
> > other way? If 
> > > there are some assumptions about a common underCreation state, they 
> > > need to be clearly articulated.
> > 
> > To avoid a conflict, the MIB needed to define how a lock can 
> > be created via SNMP, such that SNMP-management could modify 
> > the Zone Database without interference from the in-band 
> > management protocol, and vice-versa.  While defining a 
> > mechanism for SNMP, it seemed like a good idea to allow for 
> > locks by the CLI.
> > 
> > A row in the table for the CLI works in the same way as a row 
> > in the table for the in-band management protocol, i.e., if a 
> > row in the t11FLockTable is created by SNMP, its value of 
> > t11FLockInitiatorType = 'snmp'.  If a row has its value of 
> > t11FLockInitiatorType ='cli' or 'ssb', then it cannot be 
> > deleted by SNMP.  So, there are no "assumptions about a 
> OK, I understand this better now, although it's not easy reading for
> somebody not familiar with T11.  Two questions though:
> 
> - is it that 'it cannot be deleted by SNMP' or 'it cannot be deleted or
> modified by SNMP'? 

You're right -- I should change the words in t11FLockRowStatus's
DESCRIPTION to say "modified or deleted".

> - what happens if a write operation is attempted on t11FLockRowStatus
> while t11FLockInitiatorType ='cli' or 'ssb'?

An instance of t11FLockRowStatus *can* be deleted/modified under other
circumstances, but not while the value of t11FLockInitiatorType in the
same row has the value 'cli' or 'ssb'.

So, it would be more precise for the DESCRIPTION to say:

           A row of this table can be modified or deleted via this
           object only when the row's value of t11FLockInitiatorType
           is 'snmp'."

> > t11FLockRejectReasonCodeExp is a 1-byte hexadecimal value, 
> > with an ASCII string associated which each assigned value to 
> > indicate its meaning.
> > However, new reason codes get defined periodically, and it's 
> > unlikely that this WG will get re-chartered frequently enough 
> > to keep the enumerated values listed in the MIB uptodate.  
> > Nor do we want to impose a burden on IANA to assign new 
> > values, when new values are already being assigned in T11 and 
> > documented in T11 specifications.  Instead, the object has 
> > been defined an an "OCTET STRING (SIZE(1))" with a REFERENCE 
> > So, I think that if anything is missing here, it's that there 
> > is no explicit indication in this MIB that values which will 
> > not yet assigned but will be assigned in future revisions of 
> > the Fibre Channel spec will then be valid in this object.  
> > Would you like me to append to the REFERENCE clause, something like:
> > 
> >          ... or its successor"
> 
> Obviously there is a slight interoperability problem here, and I am not
> sure that the IESG would like such a solution. Where does someone need
> to look to see what is the more recent successor? Would not the overhead
> of an IANA maintained TC be justified for such a case? 

No, I don't believe so.  A user who can't find the latest T11 spec, is
not going to know what a new reason code means anyway.  This is the
equivalent of an Internet user who can't find the latest RFC.  With the
current definition, IANA is not involved.  Getting IANA involved is not
only extra overhead, but it also increases the need for coordination,
and consequently, it increases the chance of a screw-up in the
coordination of changes between multiple organizations.

The way that it is defined at present is simple, and that's good :-).

> > In regard to a DISPLAY-HINT, there are two possible ways to 
> > display a value of this object: either as a hex value, or as 
> > the relevant ASCII string from the T11 spec.  My preference 
> > is for the ASCII string, but there's no way to express that 
> > in a DISPLAY-HINT, and a DISPLAY-HINT is optional.  Do you 
> > want me to add some text to the DESCRIPTION clause to explain this ??
> 
> One more reason to use a TC. 

I see the opposite, i.e., the fact that a DISPLAY-HINT is not rich
enough to express the desired hint is one more reason not to use a TC.

> > The REFERENCE clause points to section 6.4.8.1 of FC-GS-5, 
> > and section 6.4.8.1.2 says:
> > 
> Can we copy this text here? I believe that it's better to be redundant
> then use such a common noun as 'letter' and assume that the writer of a
> future application will read the reference. 

The only information in the text I quoted, that's not already in the
DESCRIPTION is the fact that it is an ASCII letter.  So, yes, I'll
change "letter" to "ASCII letter" and then it will no longer be a
common noun.

Keith.

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 26 Sep 2006 11:12:36 -0700 (PDT)

Bert,

In order to make further progress in updating the text of the I-D's,
there are two loose ends that I would like to resolve.

One is:

> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: Keith McCloghrie <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [imss] WG Last Call: draft-ietf-imss-fc-fcs-mib-00.txt
> Date: Wed, 6 Sep 2006 14:51:38 +0200 
> 
> ...
>
> But is a URL normally represented by UTF-8?
> I doubt it?
> 
> I know that (RFC 2788) has:
> 
>   -- Uniform Resource Locators are stored in URLStrings.
> 
>   URLString ::= TEXTUAL-CONVENTION
>       DISPLAY-HINT "255a"
>       STATUS current
>       DESCRIPTION
>           "A Uniform Resource Locator represented in accordance
>            with RFCs 1738 and 2368, presented in the NVT ASCII
>            charset defined in RFC 854."
> Would that not be more appropriate?

Yes, I am changing t11FcsMgmtAddr's syntax to be URLString.

The other loose end is:

> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: [email-masked], [email-masked]
> Date: Thu, 7 Sep 2006 17:50:44 +0200
> Cc: [email-masked]

I think the issue is that the current text in the MIB is not explicit
enough in explaining when rows exist in the table.  In reviewing your
comments and determining how to update the text to address them, I'm
now planning to provide a more explicit explanation by adding this text
to the DESCRIPTION of the t11FLockTable:

           Each entry in this table represents either:

           1) a current fabric lock,
           2) an in-progress attempt, requested via SNMP, to setup
              a lock, or
           3) a failed attempt, requested via SNMP, to setup a lock.

           If an entry is created via t11FLockRowStatus but the
           attempt to obtain the lock fails, then the entry continues
           to exist until it is deleted via t11FLockRowStatus, or
           it is overwritten by the lock being established via
           a means other than SNMP, but note that rows created via
           SNMP are not retained over restarts."

A purist might argue that this design has a single table for two functions:
1) for current locks, and 2) SNMP attenpts to setup a lock, which should
be kept in separate tables, so that the "overwritten by the lock being
established via a means other than SNMP" could not happen, but I don't
think the "overwritten" is a large enough issue to warrant the extra
complication of two tables.  D'you agree ?

So, I see the addition of the above text as a clarification, not as a change.

Keith.