Re: [Gen-art] (full) review of draft-ietf-imss-fc-fcsp-mib-02.txt

["Romascanu, Dan (Dan)" <[e-mail]>]

These look good to me. 

I assume you meant neighbor, etc. 

Also, there are a number of edits suggested by David in his
proto-shepherd write-up concerning references, I guess these should be
added as well (see  below). 

Dan

---------------

[1] In Normative References
OLD
[FC-SP]
    "Fibre Channel - Security Protocols (FC-SP)", ANSI INCITS xxx-200x,
    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, T11/Project
    1570-D, February 2007.

[2] In numerous REFERENCE clauses throughout the MIB modules
OLD
    REFERENCE
          "INCITS xxx/200x, T11/Project 1570-D/Rev 1.8,
          Fibre Channel - Security Protocols (FC-SP),
          13 June 2006, Appendix A.3.1, tables A.23, A.25."
NEW
    REFERENCE
          "ANSI INCITS 426-2007, T11/Project 1570-D,
          Fibre Channel - Security Protocols (FC-SP),
          February 2007, Appendix A.3.1, tables A.23, A.25."
NOTE
The section references (Appendix A.3.1, ...) are different
for each REFERENCE clause, and need to be preserved.

[3] In a couple of REFERENCE clauses in the MIB modules
OLD
          " - Fibre Channel - Framing and Signaling-2 (FC-FS-2),
          INCITS xxx/200x, Project T11/1619-D Rev 1.01,
          8 August 2006, section 9.3.
NEW
          " - Fibre Channel - Framing and Signaling-2 (FC-FS-2),
          ANSI INCITS 424-2007, Project T11/1619-D,
          February 2007, section 9.3.
NOTE
The section references (section 9.3) are different
for each REFERENCE clause, and need to be preserved.
--------------- 

> -----Original Message-----
> From: Keith McCloghrie [mailto:[e-mail]] 
> Sent: Monday, June 23, 2008 6:26 PM
> To: Romascanu, Dan (Dan)
> Cc: Keith McCloghrie; Francis Dupont; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: (full) review of draft-ietf-imss-fc-fcsp-mib-02.txt
> 
> Dan,
> 
> > If you can suggest the necessary edits using the OLD/NEW 
> style, we can 
> > already include them in the tracker write-up. Please also include 
> > whatever edits resulted from my review.  The document will 
> be placed 
> > for approval on the agenda of the upcoming telechat which 
> is scheduled 
> > for 7/3.
>  
> How about the below.
> 
> Thanks,
> Keith.
> ===================
> 
> Insertion after the picture in section 3.4.4, on page 15:
> 
>   OLD:
> 
>   NEW:
> 
>     Note that the arrows in the picture above are used to indicate the
>     movement of "data", rather than the direction of "messages", e.g.,
>     for a "Get" (with no data) in one direction which invokes a
>     "Response" (typically with data) in the reverse direction, the
>     diagram has arrows only for the "with data" direction.
> 
> Line 4 on page 30:
> 
>   OLD:
>            'stale' to this object is an error ('wrongValue')."
> 
>   NEW:
>            'stale' to this object is an error (e.g., 'wrongValue')."
> 
> Near the bottom of page 67:
> 
>   OLD:
>            is an error ('wrongValue')."
> 
>   NEW:
>            is an error (e.g., 'wrongValue')."
> 
> At bottom of page 115:
> 
>   OLD:
>            Writing any other value into this object is a
>            ('wrongValue') error.
>  
>   NEW:
>            Writing any other value into this object is an error
>            (e.g., 'wrongValue').
> 
> Middle of page 121:
>  
>   OLD:
>            or 'stale' to this object is a ('wrongValue') error."
> 
>   NEW:
>            or 'stale' to this object is an error (e.g.,
>            'wrongValue')."
> 
> In Reference section, for IPSP-IKE-ACTION on page 236:
> 
>   OLD:
>          nn.txt, work-in-progress, October 2006.
> 
>   NEW:
>          02.txt, work-in-progress, October 2006.
> 
> In references section, for IPSP-IPSEC-ACTION on page 236:
> 
>   OLD:
>          nn.txt, work-in-progress, October 2006.
> 
>   NEW:
>          02.txt, work-in-progress, October 2006.
> 
> Section 3.2, middle of page 11:
> 
>   OLD:
> 
>     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 ...
> 
>   NEW:
> 
>     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., Host 
> Based Adapters)
>     by ...
> 
> Title of section 7:
> 
>   OLD: 
> 
>      Acknowledgements
> 
>   NEW:
> 
>      Acknowledgements
> 
> 
> In section 3.4.7, at bottom of page 17 through top of page 18:
> 
>   OLD:
> 
>     The Enhanced Commit Service [FC-SW-4] is used to perform Fabric
>     operations as and when necessary (see table 144 of [FC-SP]).  Each
>     server session begins and ends, with a SSB request and a 
> SSE request
>     respectively, sent ...
> 
>   NEW:
> 
>     The Enhanced Commit Service [FC-SW-4] is used to perform Fabric
>     operations as and when necessary (see table 144 of [FC-SP]).
>     Many of these operations are named as if they were acronyms,
>     e.g.,  SSB for Server Session Begin; SSE for Server Session End;
>     SW_ILS for Switch Fabric Internal Link Services; EACA for Enhanced
>     Acquire Change Authorization; ERCA for Enhanced Release Change
>     Authorization; SFC for Stage Fabric Configuration.
> 
>     Each server session begins and ends, with a SSB request and a SSE
>     request respectively, sent ...
> 
>     
> In Section 4.9, at bottom of page 25:
> 
>   OLD:
>                                       ...  Note that while these
>    suppressions prevent the the network being flooded with ...
> 
>   NEW:
>                                       ...  Note that while these
>    suppressions prevent the network being flooded with ...
> 
> Lines 3 & 4 on page 30:
> 
>   OLD:
>                                                             ... of the
>            the identified MIB objects. 
> 
>   NEW:
>                                                             ... of the
>            identified MIB objects. 
> 
> 
> In t11FcSpAuRejDirection's DESCRIPTION, on page 58:
> 
>   OLD:
>            "An indication of whether the the rejection was sent or
>            received by the identified entity.
> 
>   NEW:
>            "An indication of whether the rejection was sent or
>            received by the identified entity.
> 
> On page 217:
> 
>   OLD:
>            If the corresponding instance of t11FcSpSaTSelSpiDirection
>            has the value 'egress', then this object contains the
>            the value ...
> 
>   NEW:
>            If the corresponding instance of t11FcSpSaTSelSpiDirection
>            has the value 'egress', then this object contains the
>            value ...
> 
> In t11FcSpPoSwConnAllowedNameType's DESCRIPTION, on page 99:
> 
>   OLD:
>             - allowed by 'nodeName' and 'portname',
> 
>   NEW:
>             - allowed by 'nodeName' and 'portName',
> 
> In t11FcSpSaIfTerminateAllSas's DESCRIPTION, on page 183:
> 
>   OLD:
>            terminate all outsanding Security Associations on this
> 
>   NEW:
>            terminate all outstanding Security Associations on this
> 
> Near bottom of page 89:
> 
>   OLD:
>            between this Switch and neighbour Switches must be
>   NEW:
>            between this Switch and neighbo?r Switches must be
> 
> Middle of page 129:
> 
>   OLD:
>            between this Switch and neighbour Switches must be
>   NEW:
>            between this Switch and neighbo?r Switches must be
> 
> Middle of page 54:
> 
>   OLD:
>            neighbouring entity, i.e., not rejected by an AUTH_Reject
>   NEW:
>            neighbo?ring entity, i.e., not rejected by an AUTH_Reject
> 
> 
> 
_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art