Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-mib-02.txt

[Keith McCloghrie <[e-mail]>]

Hi Dan,

Thanks for your comments.  My responses are below.

> The document is mature and seems stable. As the comments in these review
> are relatively minor or editorial, I recommend sending the document to
> IETF Last Call, and consider these comments as LC comments, to be
> processed and fixed (if necessary) together with other LC comments. 
> 
> T1. Should not the arrows for Get Policy Summary and Get Policy Objects
> in the diagram in 3.4.4 be bi-directional? 

I think the I-D is correct because the diagram in 3.4.4 is meant to be
a copy of Figure 25 of FC-SP, and indeed it is a faithful copy in
respect to the directions of the "Get Policy Summary and Get Policy
Objects" arrows.  So, I think you're asking whether FC-SP has the
arrows in the correct direction(s), and I think the answer to that
question is:  the arrows indicate the movement of "data", rather than
of "messages".  In other words, a "Get" (with no data) goes in one
direction and a Response (typically with data) to the Get goes in the
reverse direction,  So, while the messages are bi-directional, the
diagram has arrows for the "with data", not for the "without data"
direction.

> T2. The DESCRIPTION clause of the T11FcSpHashCalculationStatus TC -
> 'Writing a value of 'correct' or 'stale' to this object is an error
> ('wrongValue')." As a MIB module could in theory be used with other
> protocols than SNMP a better formulation is 'Writing a value of
> 'correct' or 'stale' to this object is an error (SNMP 'wrongValue' or
> the equivalent in other protocols)."

If I recall correctly, Bert asked me to include "wrongValue", and you're
correct: I should have done so as an example. I'd prefer to change it
to be:

   'Writing a value of 'correct' or 'stale' to this object is an
    error (e.g., 'wrongValue')."

(Note that 'worngValue' is not correct for all versions of SNMP.)

> T3. Why is not T11FcSpAlphaNumName an SnmpAdminName with the appropriate
> size limitation? 
 
Because section 3.5 of RFC 2579 says:
                                                           Note that
   this means that the SYNTAX clause of a Textual Convention can not
   refer to a previously defined Textual Convention.

> T4. I do not see storage defined for t11FcSpPoOperTable and no
> storageType object either
 
Correct.  I don't believe they are not needed because:

1. This is a read-write (not read-create) table.

2. The two write-able objects in this table are both defined as:

           When read, the value of this object is always the zero-
           length string.

So, new values of these two objects are not persistent even for the
time taken for the SetRequest (e.g., much less than across restarts).

3. For the two remaining objects in the table, one is defined to
have the value 'none' when "activation/de-activation has not been
attempted since the last restart of the management system", and
the other is defined to be the zero-length string in that situation.
 
> E1. Running idnits results in the following references warnings: 
> 
> -- Obsolete informational reference (is this intentional?): RFC 2837
>      (Obsoleted by RFC 4044)
 
Yes, it's intentional.  The text reads:

   The first standardized MIB module for Fibre Channel [RFC2837] was
   focussed on Fibre Channel Switches.  It was obsoleted by the more
   generic Fibre Channel Management MIB [RFC4044] which defines basic
   information for Fibre Channel Nodes and Switches, including ...

>   -- No information found for draft-ietf-ipsp-ikeaction-mib-nn - is the
> name
>      correct?
>   -- No information found for draft-ietf-ipsp-ipsecaction-mib-nn - is
> the
>      name correct?
 
The names are correct because their numbers have been replaced by "nn"
so as to implictly refer to the most recent versions.  It was hoped that
these two documents would have progressed in advance of the FC-SP MIB,
but it looks like FC-SP MIB is about to overtake them.  The current
text which references them is:

   The management of certificates, Certification Authorities and
   Certificate Revocation Lists is the same in Fibre Channel networks as
   it is in other networks.  Therefore, this document does not define
   any MIB objects for such management.  Instead, this document assumes
   that appropriate MIB objects are defined elsewhere, e.g., in [IPSP-
   IPSEC-ACTION] and [IPSP-IKE-ACTION].

I don't know of alternate references, and it seems to me better to include
them here rather than not to have any references.  What would you suggest ??

> E2. Please expand the following acronyms at first occurrence: HBA, ESP,
> SAID

HBA - yes, I can expand HBA.
ESP - its first use, as an acronym, is already expanded -- when used as
      "ESP_Header" it is the name of a mechanism, i.e., not an acronym.
SAID - is the name of a field in a PDU, i.e., not an acronym.

> E3. Delete the comment on the SYNTAX line of the T11FcSpPrecedence
> definition

My preference would be to delete the range *and* the comment because I
think the range by itself is misleading.  That is, when I read a syntax
with an explicit range, my instinctive reaction is that a range other
than the default is being specified, which is untrue in this case
(because the default range is being used).  However, Bert insisted that
the range be included, and therefore to mitigate the risk of confusion,
I believe that:  if the range is necessary, then so is the comment.
However, I will remove the exclamation marks if you wish.

> E4.  Does the notation INCITS xxx/200x mean that the x values need to be
> filled in? In this case these values should be filled in until the time
> the document is submitted for approval to the IESG, or appropriate RFC
> Editor notes should be created to instruct the RFC Editor what to do. 
 
Correct.  David has provided the instructions to the RFC Editor for
these numbers in previous docuemnts done by this WG.

Keith.
_______________________________________________
imss mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/imss