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:[EMAIL PROTECTED]
> Sent: Monday, June 23, 2008 6:26 PM
> To: Romascanu, Dan (Dan)
> Cc: Keith McCloghrie; Francis Dupont; [email protected];
> [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art