Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-mib-02.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-mib-02.txt
Thanks for the answer - see in-line.
Regards,
Dan
> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm at cisco.com]
> Sent: Friday, June 06, 2008 5:46 PM
> To: Romascanu, Dan (Dan)
> 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
> aFrom imss-bounces at ietf.org Wed Jun 11 09:04:20 2008
Return-Path: <imss-bounces at ietf.org>
X-Original-To: imss-archive at optimus.ietf.org
Delivered-To: ietfarch-imss-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id D21BC3A6886;
Wed, 11 Jun 2008 09:04:20 -0700 (PDT)
X-Original-To: imss at core3.amsl.com
Delivered-To: imss at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 08C313A6879
for <imss at core3.amsl.com>; Wed, 11 Jun 2008 09:04:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.626
X-Spam-Level:
X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5
tests=[AWL=-0.027, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id HRIAI8uDCTux for <imss at core3.amsl.com>;
Wed, 11 Jun 2008 09:04:18 -0700 (PDT)
Received: from co300216-co-outbound.avaya.com
(co300216-co-outbound.net.avaya.com [198.152.13.100])
by core3.amsl.com (Postfix) with ESMTP id AE3613A6886
for <imss at ietf.org>; Wed, 11 Jun 2008 09:04:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,625,1204520400"; d="scan'208";a="130856560"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5])
by co300216-co-outbound.avaya.com with ESMTP; 11 Jun 2008 12:04:43 -0400
X-IronPort-AV: E=Sophos;i="4.27,625,1204520400"; d="scan'208";a="216893297"
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14])
by co300216-co-erhwest-out.avaya.com with ESMTP;
11 Jun 2008 12:04:42 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 11 Jun 2008 18:04:40 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04CE3BF8 at 307622ANEX5.global.avaya.com>
In-Reply-To: <200806061445.HAA25946 at cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [imss] AD Review for draft-ietf-imss-fc-fcsp-mib-02.txt
Thread-Index: AcjH5HfOdl57ixv9Qk+TsJ6vvifm3QD9pn3Q
References: <no.id> from "Romascanu, Dan (Dan)" at Jun 05,
2008 04:50:31 PM <200806061445.HAA25946 at cisco.com>
From: "Romascanu, Dan (Dan)" <dromasca at avaya.com>
To: "Keith McCloghrie" <kzm at cisco.com>
Cc: imss at ietf.org
Subject: Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-mib-02.txt
X-BeenThere: imss at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Internet and Management Support for Storage Working Group
<imss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/imss>,
<mailto:imss-request at ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/imss>
List-Post: <mailto:imss at ietf.org>
List-Help: <mailto:imss-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imss>,
<mailto:imss-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: imss-bounces at ietf.org
Errors-To: imss-bounces at ietf.org
Thanks for the answer - see in-line.
Regards,
Dan
> -----Original Message-----
> From: Keith McCloghrie [mailto:kzm at cisco.com]
> Sent: Friday, June 06, 2008 5:46 PM
> To: Romascanu, Dan (Dan)
> 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 whsking 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.
>
> > 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.)
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?
>
> 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.
OK.
>
> > 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.
OK.
>
> > 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 ...
OK
>
> > -- 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-Iether 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.
>
> > 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.)
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?
>
> 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.
OK.
>
> > 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.
OK.
>
> > 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 ...
OK
>
> > -- 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-ACTIOKE-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 ??
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
>
> 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.
OK
>
> > 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.
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.
>
> Keith.
>
_______________________________________________
imss mailing list
imss at ietf.org
https://www.ietf.org/mailman/listinfo/imss
N].
>
> 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
>
> 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.
OK
>
> > 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.
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.
>
> Keith.
>
_______________________________________________
imss mailing list
imss at ietf.org
https://www.ietf.org/mailman/listinfo/imss
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
