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

From: Keith McCloghrie <[email-masked]>
Date: Fri, 6 Jun 2008 07:45:56 -0700 (PDT)

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
[email-masked]
https://www.ietf.org/mailman/listinfo/imss

---

From: [email-masked]
Date: Tue, 10 Jun 2008 18:49:20 -0400

> 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
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Keith McCloghrie
> Sent: Friday, June 06, 2008 10:46 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-mib-02.txt
> 
> Hi Dan,
> 
> >   -- 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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 11 Jun 2008 18:04:40 +0200

Thanks for the answer - see in-line. 

Regards,

Dan

> From: Keith McCloghrie [mailto:[email-masked]] 
> Sent: Friday, June 06, 2008 5:46 PM
> To: Romascanu, Dan (Dan)
> Cc: [email-masked]
> > 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.

Then a few explanatory words near the diagram would help readers like me
who are unaware of the convention. 

> correct: I should have done so as an example. I'd prefer to 
> change it to be:
> 

Well, SNMPv3 IS SNMP nowadays, but I would not argue too much as long as
'wrongValue' is indicated as an example only. 

> 
> > T3. Why is not T11FcSpAlphaNumName an SnmpAdminName with the 
> > appropriate size limitation?
>  

OK. 

> 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.

OK. 

>    information for Fibre Channel Nodes and Switches, including ...

OK

> 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:
> 
> 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 ??

Just replace nn with 02 which is the latest version of the ipsp MIB
documents to make idnits happy. I am not too optimistic about their
fate, but I agree that a reader should be able to find out in the future
what were the assumptions that were made at the time the documents were
written. 

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

OK

> 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, 

OK

> 
> > 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.

David's mail clarifies these.