Deprecation of the Internet Fibre Channel Protocol (iFCP) Address Translation Mode
RFC 6172

Received changes through RFC Editor sync (changed abstract to 'Changes to Fibre Channel have caused the specification of the Internet Fibre Channel Protocol (iFCP) address translation mode to become incorrect. Due to the absence of usage of iFCP address translation mode, it is deprecated by this document. iFCP address transparent mode remains correctly specified.

iFCP address transparent mode has been implemented and is in current use; therefore, it is not affected by this document.

This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of the Fibre Channel Internet Protocol (FCIP). [STANDARDS-TRACK]')

[Ballot comment]
"This document also records the state of Protocol Number 133, which was
allocated for a pre-standard version of FCIP."

According to the title it is: "Assigned Internet Protocol Numbers"

With only about half of these values available, it would be good if drafts such as this could take firmer steps to recover values that are effectively unused?

[Ballot comment]
I cleared my Discuss since it is clear that IANA correctly understands what to do.

I still think there may be value in adding a little clarification to the IANA section to identify which registry is being manipulated.

[Ballot discuss]
"This document also records the state of Protocol Number 133, which was allocated for a pre-standard version of FCIP."

What Protocol Number?

Question for the IESG  - with only about half of these values available, should we expect drafts such as this to be taking steps to recover values that are effectively unused?

[Ballot discuss]
I find the IANA section a little unhelpful.

It would be really good to include the name of the registry so that
people can find the referenced code point. I had a quick look and I
could not work out which registry was intended.

Since I can't see an IANA comment in the email archive, I am going to
hold this Discuss pending confirmation that they know what action to
perform.

IANA understands that, upon approval of this document, there is a single
action that IANA must complete.

In the Protocol Numbers registry located at:

http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

the entry for decimal value 133 (FC) should have the reference revised.
Where it previously said:

[Murali_Rajagopal]

It will now say:

[Murali_Rajagopal][RFC-to-be]

IANA understands that this the only action required upon approval of the
document.

Please make a note to better describe "track changes in Fibre Channel", ***IF*** a revised ID is needed in the future. Don't bother doing a new revision for this.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Tom Talpey (STORM WG co-chair), yes, yes.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Yes, no.

The document has been reviewed by numerous WG members and by other
members of the Fibre Channel standards community.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document raised only constructive suggestions and no dissent during
its WG review. It enjoys full consensus.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews.

The document passes all current full id-nit checks. Several "possible downref"
normative reference notices are emitted, but are correct (and are not downrefs).
A detailed reading by the shepherd yields no questions or comments.

The document defines no protocol and requires no formal review thereof.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The references are appropriately split. The normative references are appropriate
currently-published RFCs, ANSI/INCITS and ISO/IEC Fibre Channel standards, and
the IANA IP protocol number registry.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during IESG Evaluation?

Yes. The document lists a single IANA consideration, to add the document as
a reference from an existing IANA-allocated IP protocol number.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
This brief document serves to analyze, justify and record the deprecation
of the never-implemented and now-incorrect specification of iFCP address
translation mode. The document also records the state of Internet Protocol
Number 133, which was allocated for a pre-standard version of FCIP.

Working Group Summary
There was no controversy and full consensus during the entire process.
The document was updated only to enhance clarity, based on comments
received.

Document Quality
The document is of high quality and the states of both protocols
were well-researched by the authors prior to publication.