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

[Black_David at emc.com]

> > 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 documents done by this WG.

Ok, here goes ...

OLD: 
           "INCITS xxx/200x, T11/Project 1570-D/Rev 1.8,
           Fibre Channel - Security Protocols (FC-SP), 13 June 2006,

NEW: 
           "Fibre Channel - Security Protocols (FC-SP), INCITS 426-2007,


OLD:
           " - Fibre Channel - Framing and Signaling-2 (FC-FS-2),
           INCITS xxx/200x, Project T11/1619-D Rev 1.01,
           8 August 2006,

NEW:
           " - Fibre Channel - Framing and Signaling-2 (FC-FS-2),
           INCITS 424-2007,

OLD:
[FC-SP]
     "Fibre Channel - Security Protocols (FC-SP)", ANSI INCITS xxx-2002,
     http://www.t11.org/t11/stat.nsf/upnum/1570-d, T11/Project
     1570-D/Rev 1.8, 13 June 2003.

NEW:
[FC-SP]
     "Fibre Channel - Security Protocols (FC-SP)", ANSI INCITS 426-2007,
     http://www.t11.org/t11/stat.nsf/upnum/1570-d, June 2006.


There are multiple instances of each of the first two changes.  The
third change corrects a reference citation.

It looks like we'll need one more version of this draft after IETF
Last Call is complete (June 19); these changes can be made at that
time.

Thanks,
--David (imss WG chair)
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: imss-bounces at ietf.org [mailto:imss-bounces at ietf.org] On 
> Behalf Of Keith McCloghrie
> Sent: Friday, June 06, 2008 10:46 AM
> To: dromasca at avaya.com
> Cc: imss at ietf.org
> Subject: Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-mib-02.txt
> 
> 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
imss at ietf.org
https://www.ietf.org/mailman/listinfo/imss