Skip to main content

Definitions of Managed Objects for Internet Fibre Channel Protocol (iFCP)
draft-ietf-ips-ifcp-mib-07

Revision differences

Document history

Date Rev. By Action
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Margaret Wasserman
2012-08-22
07 (System) post-migration administrative database adjustment to the Yes position for Allison Mankin
2005-10-24
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-10-18
07 Amy Vezza IESG state changed to Approved-announcement sent
2005-10-18
07 Amy Vezza IESG has approved the document
2005-10-18
07 Amy Vezza Closed "Approve" ballot
2005-10-18
07 Allison Mankin State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Allison Mankin
2005-10-18
07 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to Yes from Discuss by Allison Mankin
2005-10-17
07 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2005-10-13
07 Margaret Cullen [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Discuss by Margaret Wasserman
2005-10-13
07 Allison Mankin
[Ballot discuss]
I will monitor for Notes to the RFC Editor handling Margaret's Discuss:

I have some questions about the structure of the ifcpSessionAttributesTable.  There …
[Ballot discuss]
I will monitor for Notes to the RFC Editor handling Margaret's Discuss:

I have some questions about the structure of the ifcpSessionAttributesTable.  There are two things that I am wondering about:

(1) Why does the table separately list the ip addresses and ports of both ends of the TCP connection, rather than referencing an entry in the TCP connection table? 

(2) Why does it allow the use of DNS names for the addresses on both ends? 

There are at least three problems that I can see with the current structure:

(a) This table is duplicating (rather than referencing) information in the TCP connection table with no explanation of why the duplication is needed and/or how/why/if this information would ever differ from what is in the TCP connection table.

(b) I can see the possibility of using a DNS name for the remote end, but not for the local end.  Under what circumstances would a DNS name be used to identify the local end of a connection? 

(c) If you use a DNS address for either end of the connection (which may point to multiple A/AAAA records, may not resolve to the same addresses from all places and/or may no longer resolve to the same address as it did at session establishment), I'm not sure how you know which IP addresses to use to find the corresponding TCP connection table entry.

I think that all of this could be resolved by removing the six overlapping objects (2 IP addresses, 2 IP address types and 2 ports) and instead including an OID object that points to the TCP connection table entry, but there might also be other ways to address these concerns.
2005-10-13
07 Bert Wijnen [Ballot Position Update] New position, Yes, has been recorded for Bert Wijnen by Bert Wijnen
2005-10-13
07 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to Discuss from Yes by Allison Mankin
2005-10-13
07 (System) [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by IESG Secretary
2005-10-13
07 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-10-13
07 Margaret Cullen
[Ballot discuss]
I have some questions about the structure of the ifcpSessionAttributesTable.  There are two things that I am wondering about:

(1) Why does the …
[Ballot discuss]
I have some questions about the structure of the ifcpSessionAttributesTable.  There are two things that I am wondering about:

(1) Why does the table separately list the ip addresses and ports of both ends of the TCP connection, rather than referencing an entry in the TCP connection table? 

(2) Why does it allow the use of DNS names for the addresses on both ends? 

There are at least three problems that I can see with the current structure:

(a) This table is duplicating (rather than referencing) information in the TCP connection table with no explanation of why the duplication is needed and/or how/why/if this information would ever differ from what is in the TCP connection table.

(b) I can see the possibility of using a DNS name for the remote end, but not for the local end.  Under what circumstances would a DNS name be used to identify the local end of a connection? 

(c) If you use a DNS address for either end of the connection (which may point to multiple A/AAAA records, may not resolve to the same addresses from all places and/or may no longer resolve to the same address as it did at session establishment), I'm not sure how you know which IP addresses to use to find the corresponding TCP connection table entry.

I think that all of this could be resolved by removing the six overlapping objects (2 IP addresses, 2 IP address types and 2 ports) and instead including an OID object that points to the TCP connection table entry, but there might also be other ways to address these concerns.
2005-10-13
07 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2005-10-12
07 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-10-12
07 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2005-10-11
07 Allison Mankin [Note]: 'draft -07 responded to Bert''s Last Call comments.
PROTO shepherd: David Black black_david@emc.com' added by Allison Mankin
2005-10-11
07 Margaret Cullen [Ballot Position Update] New position, Discuss, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-10-11
07 (System) State Changes to IESG Evaluation from IESG Evaluation by system
2005-10-06
07 Allison Mankin [Note]: 'draft -07 responded to Bert''s Last Call comments.' added by Allison Mankin
2005-10-06
07 Allison Mankin State Changes to IESG Evaluation from IESG Evaluation - Defer by Allison Mankin
2005-10-06
07 Allison Mankin State Change Notice email list have been change to , , kzm@cisco.com from , ,
2005-10-06
07 Allison Mankin [Note]: 'This' added by Allison Mankin
2005-10-06
07 (System) New version available: draft-ietf-ips-ifcp-mib-07.txt
2005-09-30
07 (System) Removed from agenda for telechat - 2005-09-29
2005-09-28
07 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2005-09-28
07 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2005-09-28
07 Allison Mankin State Changes to IESG Evaluation - Defer from IESG Evaluation - Defer::Revised ID Needed by Allison Mankin
2005-09-27
07 Russ Housley [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Undefined by Russ Housley
2005-09-27
07 Russ Housley [Ballot comment]
Please delete the second paragraph of the Abstract prior to publication.
2005-09-27
07 Russ Housley [Ballot Position Update] New position, Undefined, has been recorded for Russ Housley by Russ Housley
2005-09-27
07 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-09-27
07 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-09-26
07 Allison Mankin [Ballot Position Update] New position, Yes, has been recorded for Allison Mankin
2005-09-26
07 Allison Mankin Ballot has been issued by Allison Mankin
2005-09-26
07 Allison Mankin Created "Approve" ballot
2005-09-26
07 Allison Mankin State Changes to IESG Evaluation - Defer::Revised ID Needed from IESG Evaluation by Allison Mankin
2005-09-26
07 Allison Mankin [Note]: 'Last Call ends 9/22 - Last Call comments by Bert as notes to rfc editor (midnight)
' added by Allison Mankin
2005-09-23
07 Allison Mankin State Changes to IESG Evaluation from Waiting for Writeup by Allison Mankin
2005-09-22
07 (System) State has been changed to Waiting for Writeup from In Last Call by system
2005-09-22
07 Allison Mankin [Note]: 'Last Call ends 9/22 - Last Call comments by Bert as notes to rfc editor (midnight)' added by Allison Mankin
2005-09-22
07 Allison Mankin Placed on agenda for telechat - 2005-09-29 by Allison Mankin
2005-09-22
07 Allison Mankin [Note]: 'Last Call ends 9/22 - Last Call comments by Bert as notes to rfc editor by Friday' added by Allison Mankin
2005-09-08
07 Michelle Cotton IANA Last Call Comments:
Upon approval of this document the IANA will assign 1 transmission number located at the following registry:
http://www.iana.org/assignments/smi-numbers
2005-09-08
07 Amy Vezza Last call sent
2005-09-08
07 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2005-09-08
07 Allison Mankin Last Call was requested by Allison Mankin
2005-09-08
07 Allison Mankin State Changes to Last Call Requested from Expert Review::AD Followup by Allison Mankin
2005-09-08
07 (System) Ballot writeup text was added
2005-09-08
07 (System) Last call text was added
2005-09-08
07 (System) Ballot approval text was added
2005-09-08
07 Allison Mankin [Note]: 'Bert has given LC go-ahead; his current comments are Last Call comments.' added by Allison Mankin
2005-09-05
07 Bert Wijnen
Below is my review of revision 6.

Summary:
- as far as I am concerned this is good enuf to do IETF Last Call.
  …
Below is my review of revision 6.

Summary:
- as far as I am concerned this is good enuf to do IETF Last Call.
  And then you can consider the below as the first IETF Last Call
  comments to be addressed.

- Did the WG agree with all the changes made from rev 05 to rev 06?
  There were quite some changes that I think need to be verified
  to have consensus in the WG.

Bert

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Monday, September 05, 2005 00:33
To: Kevin Gibbons; kzm@cisco.com; Ipswg (E-mail)
Cc: mrm@macfaden.com; Mike MacFaden (E-mail); Black_David@emc.com;
ElizabethRodriguez@ieee.org; mankin@psg.com; Scott Kipp; Larry Hofer; G
D Ramkumar; Charles Monia (email); Josh Tseng;
travos@nortelnetworks.com; Jayesh Gada; Annie Wang; Joe White
Subject: MIB Doctor review: draft-ietf-ips-ifcp-mib-06.txt


Sorry that it took so long to get back to this

Summary:
- as far as I am concerned this is good enuf to do IETF Last Call.
  And then you can consider the below as the first IETF Last Call
  comments to be addressed.

- Did the WG agree with all the changes made from rev 05 to rev 06?
  There were quite some changes that I think need to be verified
  to have consensus in the WG.

More details:
Looks much better than last time I reviewed.

- In the cases where you use STorageType, the DESCRIPTION clause
  MUST specify for which columns read-write acces is needed in
  case of a permanent row (RFC2579 explains this in the DESCRIPTION
  clause of the STorageType TC. Keith knows all about this.

- ZeroBasedCounterxx definitions do have text
    "since  the iFCP connection was first established."
  Although at startup they start from zero, they can wrap around,
  and so you cannot assume that the value is always "since..."
  I would just remove the "since ..." clause of each of those
  sentences in your MIB module.
 
- The have a discontinuity timer, in which you describe that
  it acts as the discontinuity timer for all ZeroBaseCounters
  However, formally you must specify in the DESCRIPTION clause of
  EACH such counter which object is the discontinuity timer.
  Keith knows all about this. Maybe it is too much of a CLR
  (Crappy Little Rule). So I won't block on it. But...

  By the way, a wraparound is NOT considered a discontinuity.

Issues with references and citations (not really a MIB Doctor
specific issue, but rather a generic issues):

  !! Missing citation for Normative reference:
  P001 L1331: 1    [ENTMBV3]  Bierman, A., and McCloghrie, K.,
                  "Entity MIB (Version

  !! Missing citation for Informative reference:
  P001 L1377: 7    [FC-FS]    Fibre Channel Framing and Signaling Interface,

  !! Missing citation for Informative reference:
  P001 L1380: 0    [FC-GS]    Fibre Channel - Generic Services, NCITS 348-2000.

  !! Missing citation for Normative reference:
  P001 L1323: 3    [IFCP001]  Charles Monia, Rod Mullendore, Franco Travostino,

  !! Missing citation for Normative reference:
  P001 L1338: 8    [RFC2021]  S. Waldbusser, "Remote Network Monitoring 
                              Management

  !! Missing citation for Normative reference:
  P001 L1348: 8    [RFC2571]  D. Harrington, R. Presuhn, and B. Wijnen, "An

By the way, RFC2571 has been obsoleted (a long time ago already) by
RFC3411.

  !! Missing citation for Normative reference:
  P001 L1341: 1    [RFC2856]  A. Bierman, K. McCloghrie, "Textual Conventions for

  !! Missing citation for Normative reference:
  P001 L1334: 4    [RFC3291]  M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder

by the wau, RFC3291 has been obsoleted byh RFC4001

A good way to include a citation is to add some prelimenary
text just nbefore the MIB module aka:

  The following MIB module imports from XXX-MIB [RFCxxxx],
  YYY-MIB [RFCyyyy] and ....

I guess you get the gist.

Bert
2005-09-05
07 Bert Wijnen State Change Notice email list have been change to , , from ,
2005-09-05
07 Bert Wijnen
[Note]: 'Bert Wijnen MIB Doctor (AD Followup sub-state means Expert Review re-review by Bert); Bert did re-review and posted comments to authors and IPS wg …
[Note]: 'Bert Wijnen MIB Doctor (AD Followup sub-state means Expert Review re-review by Bert); Bert did re-review and posted comments to authors and IPS wg list. Allison with WG chair(s) to decide what next step is.' added by Bert Wijnen
2005-08-02
07 Allison Mankin [Note]: 'Bert Wijnen MIB Doctor (AD Followup sub-state means Expert Review re-review by Bert)' added by Allison Mankin
2005-08-02
07 Allison Mankin State Changes to Expert Review::AD Followup from Expert Review by Allison Mankin
2005-02-01
06 (System) New version available: draft-ietf-ips-ifcp-mib-06.txt
2003-06-15
07 Allison Mankin State Changes to Expert Review from Publication Requested by Mankin, Allison
2003-03-27
07 Allison Mankin Intended Status has been changed to Proposed Standard from None
2003-03-12
07 Jacqueline Hargest
From: Elizabeth Rodriguez [mailto:ElizabethRodriguez@ieee.org]

Hi Allison, Scott,

The iFCP MIB (draft-ietf-ips-ifcp-mib-05.txt) is now ready for AD
review.

It has passed WG …
From: Elizabeth Rodriguez [mailto:ElizabethRodriguez@ieee.org]

Hi Allison, Scott,

The iFCP MIB (draft-ietf-ips-ifcp-mib-05.txt) is now ready for AD
review.

It has passed WG last call, has been reviewed for nits and by our MIB
advisior Keith McCloghrie.

Keith has one comment against the draft, but we feel that this can be
addressed during revisions resulting from AD review or IESG review.

The comment is:

For draft-ietf-ips-ifcp-mib-05.txt, it now contains (twice) in the

Security section:

  "Changing the following object values, with a MAX-ACCESS of read-

    write, may cause ..."

the "with" really ought to be "which have", but is this sufficient to

require another go round?  I don't think so; so this is ready also.

Thanks,

Elizabeth Rodriguez & David Black
2003-03-12
07 Jacqueline Hargest Draft Added by Hargest, Jacqueline
2003-03-05
05 (System) New version available: draft-ietf-ips-ifcp-mib-05.txt
2003-03-03
04 (System) New version available: draft-ietf-ips-ifcp-mib-04.txt
2002-10-10
03 (System) New version available: draft-ietf-ips-ifcp-mib-03.txt
2002-08-29
02 (System) New version available: draft-ietf-ips-ifcp-mib-02.txt
2002-05-23
01 (System) New version available: draft-ietf-ips-ifcp-mib-01.txt
2001-10-31
00 (System) New version available: draft-ietf-ips-ifcp-mib-00.txt