Skip to main content

Formally Deprecating Some ICMPv4 Message Types
draft-gp-obsolete-icmp-types-iana-01

Revision differences

Document history

Date Rev. By Action
2013-04-04
01 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2013-03-27
01 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2013-03-06
01 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2013-03-04
01 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on Authors
2013-02-26
01 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2013-02-25
01 (System) IANA Action state changed to Waiting on Authors from In Progress
2013-02-25
01 (System) RFC Editor state changed to EDIT
2013-02-25
01 (System) Announcement was received by RFC Editor
2013-02-25
01 (System) IANA Action state changed to In Progress
2013-02-25
01 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2013-02-25
01 Amy Vezza IESG has approved the document
2013-02-25
01 Amy Vezza Closed "Approve" ballot
2013-02-25
01 Amy Vezza Ballot writeup was changed
2013-02-21
01 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Tina Tsou.
2013-02-21
01 Cindy Morgan State changed to Approved-announcement to be sent from IESG Evaluation
2013-02-20
01 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded for Wesley Eddy
2013-02-19
01 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-02-19
01 Sean Turner [Ballot comment]
Let's publish this!
2013-02-19
01 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2013-02-18
01 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley
2013-02-18
01 Benoît Claise
[Ballot comment]
No objection to the publication of this document, but I would like to propose an improvement.

I understand that the title is "Formally …
[Ballot comment]
No objection to the publication of this document, but I would like to propose an improvement.

I understand that the title is "Formally Deprecating Some ICMPv4 Message Types", but, while reading the document, I've been wondering: do we have identical assignments for ICMPv6? If yes, should we deprecate them as well? If yes, is it done in a different document?
So I double checked: none of the ICMPv4 Message Type you want to deprecate are registered in ICMPv6. Good news. Why not share this good news with a sentence or two in this document?
2013-02-18
01 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-02-18
01 Adrian Farrel [Ballot comment]
Enough already! Publish and move on.
2013-02-18
01 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2013-02-18
01 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-02-16
01 Pete Resnick
[Ballot comment]
We should approve this document either way. However, I'd like to hear from the rest of the IESG: Because we didn't precisely follow …
[Ballot comment]
We should approve this document either way. However, I'd like to hear from the rest of the IESG: Because we didn't precisely follow the instructions in http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html for announcements of status changes, have we given sufficient notice of the move of RFC 1788 to Historic, or should we put out an additional 4-week Last Call on "RFC 1788 to Historic" for the 3/28 telechat? This document does call out the move to Historic in the abstract and it was Last Called (and got feedback), so perhaps this is sufficient. But it's not exactly what we said we would do.

One other thing, simply for clarity: The document shouldn't ask the *RFC Editor* to make the change to Historic; that's something that the IESG should generate a Protocol Action for. So, can you please make the following simple changes:

Abstract
OLD
  and requests the RFC Editor to change the status of RFC1788
  to "Historic".
NEW
  and requests that the status of RFC1788 be changed to "Historic".

Introduction
OLD
  and requests the RFC Editor to change the status of RFC1788
  to "Historic".
NEW
  and requests that the status of RFC1788 be changed to "Historic".

OLD
  requests the RFC Editor to change the status of RFC1788 to
  "Historic".
NEW
  requests that the status of RFC1788 be changed to "Historic".

Section 4:
OLD
  This document requests the RFC Editor to change the status of
  [RFC1788] to "Historic".
NEW
  This document requests that the status of [RFC1788] be changed to
  "Historic".
2013-02-16
01 Pete Resnick Ballot comment text updated for Pete Resnick
2013-02-15
01 Pete Resnick
[Ballot comment]
I'm sorry. Really really sorry. I cringe to have noticed a missed procedural point (and I can't wait for Robert to finish the …
[Ballot comment]
I'm sorry. Really really sorry. I cringe to have noticed a missed procedural point (and I can't wait for Robert to finish the status-change feature in the tracker so that we don't have to do this again):

http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html says:

If a document (whatever its intended status) moves another document to "Historic" status, the Last Call should go out saying, "Last Call: to Informational and RFC XXXX to Historic", the document should be handled as a Protocol Action on the IESG agenda using IESG Protocol Action procedures, and a "Protocol Action" announcement should be sent out when the document is approved.

Oops.

I think the easy solution is simply to approve this document, and put out a 4-week (yes, 2026 says it has to be) Last Call on "RFC 1788 to Historic" for the 3/28 telechat.
2013-02-15
01 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-02-15
01 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-02-14
01 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded for Robert Sparks
2013-02-14
01 Ron Bonica State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-02-14
01 (System) State changed to Waiting for AD Go-Ahead from In Last Call
2013-02-13
01 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-02-12
01 Pearl Liang
IANA has reviewed draft-gp-obsolete-icmp-types-iana-01 and has the following comments:

We understand that, upon approval of this document, there is a single
IANA action which must …
IANA has reviewed draft-gp-obsolete-icmp-types-iana-01 and has the following comments:

We understand that, upon approval of this document, there is a single
IANA action which must be completed.

In the ICMP Type Numbers subregistry of the Internet Control Message Protocol (ICMP) Parameters registry located at:

http://www.iana.org/assignments/icmp-parameters

fifteen ICMP Type Numbers will be marked as deprecated. The list of fifteen to be deprecated is as follows:

Alternate Host Address (Type 6)
Information Request (Type 15)
Information Reply (Type 16)
Address Mask Request (Type 17)
Address Mask Reply (Type 18)
Traceroute (Type 30)
Datagram Conversion Error (Type 31)
Mobile Host Redirect (Type 32)
IPv6 Where-Are-You (Type 33)
IPv6 I-Am-Here (Type 34)
Mobile Registration Request (Type 35)
Mobile Registration Reply (Type 36)
Domain Name Request (Type 37)
Domain Name Reply (Type 38)
SKIP (Type 39)

We understand that this is the only action required to be completed upon
approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
2013-02-11
01 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms
2013-02-09
01 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-02-03
01 Barry Leiba [Ballot comment]
I think it would be fine for this to be Informational, and I'm also happy with its being Standards Track.
2013-02-03
01 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-01-25
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tina Tsou
2013-01-25
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tina Tsou
2013-01-24
01 Ron Bonica Ballot has been issued
2013-01-24
01 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2013-01-24
01 Ron Bonica Created "Approve" ballot
2013-01-24
01 Ron Bonica Placed on agenda for telechat - 2013-02-21
2013-01-17
01 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2013-01-17
01 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2013-01-17
01 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Formally Deprecating Some ICMPv4 Message Types) to …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Formally Deprecating Some ICMPv4 Message Types) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Formally Deprecating Some ICMPv4 Message Types'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-02-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  A number of ICMPv4 message types have become obsolete in practice,
  but have never been formally deprecated.  This document deprecates
  such ICMPv4 message types, thus cleaning up the corresponding IANA
  registry.  Additionally, it updates RFC792 and RFC950, obsoletes
  RFC1788, and requests the RFC Editor to change the status of RFC1788
  to "Historic".




The file can be obtained via
http://datatracker.ietf.org/doc/draft-gp-obsolete-icmp-types-iana/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-gp-obsolete-icmp-types-iana/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-01-17
01 Amy Vezza State changed to In Last Call from Last Call Requested
2013-01-17
01 Ron Bonica Last call was requested
2013-01-17
01 Ron Bonica Last call announcement was generated
2013-01-17
01 Ron Bonica Ballot approval text was generated
2013-01-17
01 Ron Bonica State changed to Last Call Requested from AD Evaluation
2013-01-16
01 Cindy Morgan
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?  Why is
> this the proper …
> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?  Why is
> this the proper type of RFC?  Is this type of RFC indicated in the
> title page header?
>
>      This document is intended for publication as a Propose Standard.
>      This is because it updates existing protocol documents.
>
> (2) 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
>
>    A number of ICMPv4 message types have become obsolete in practice,
>    but have never been formally deprecated.  This document deprecates
>    such ICMPv4 message types, thus cleaning up the corresponding IANA
>    registry.  Additionally, it updates RFC792 and RFC950, obsoletes
>    RFC1788, and requests the RFC Editor to change the status of
> RFC1788
>    to "Historic".
>
>  Working Group Summary
>
>    This document was not considered by any IETF Working Group.
>    It was generated as an individual submission when it was
>    realized that in obsoleting unused ICMP code points certain
>    RFCs would also need to be updated or obsoleted.
>
>  Document Quality
>
>    This document does a clear job of laying out the changes
>    it makes.  As it is marking unused protocol identifiers
>    as deprecated, there is no implementation of this document,
>    nor of most of the items it references.
>
>  Personnel
>
>    Joel Halpern is the Docment Shepherd for this Individual Submission
>    document.  Ron Bonica is the sponsoring AD.
>
> (3) Briefly describe the review of this document that was performed by
> the Document Shepherd.  If this version of the document is not ready
> for publication, please explain why the document is being forwarded to
> the IESG.
>
>      While reading the document, the shepherd checked the individual
>      references in the IANA registry, and checked the defining
>      documents ad their states for accuracy.  The document is clear,
>      accurate, and appears ready for publication.
>
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?
>
>      The document shepherd dos not have any concerns about the reviews.
>      Given the nature of this document, there is no special need for
>      additional breadth or depth of review, beyond that which will
>      naturally occur as part of IETF last call.
>
> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that
> took place.
>
>    There are no specialized reviews needed for this document.
>
> (6) Describe any specific concerns or issues that the Document Shepherd
> has 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 interested
> community has discussed those issues and has indicated that it still
> wishes to advance the document, detail those concerns here.
>
>      The document shepherd has no concerns with this document, and
> knows
>      of no controversial issues with it.
>
> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of BCP 78
> and BCP 79 have already been filed. If not, explain why.
>
>      Yes.
>
> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any discussion and conclusion regarding the IPR
> disclosures.
>
>      No.
>
> (9) How solid is the consensus of the interested community behind this
> document? Does it represent the strong concurrence of a few
> individuals, with others being silent, or does the interested community
> as a whole understand and agree with it?
>
>      This is an individual submission which has not been discussed in
>      a working group.  As such, there is no established IETF or WG
>      consensus for or against this document at this time.  The authors,
>      shepherd, and sponsoring AD think it is a good idea.
>
> (10) 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 publicly available.)
>
>      No, there have been no threats of appeal or other indications of
>      discontent, extreme or otherwise, with this document at this
> point.
>
> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-
> Drafts Checklist). Boilerplate checks are not enough; this check needs
> to be thorough.
>
>      This document complies with the requirements on Internet Drafts.
>
> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type reviews.
>
>      There are no relevant formal review criteria.
>
> (13) Have all references within this document been identified as either
> normative or informative?
>
>      References are classed appropriately and explicitly into
>      normative and informative.
>
> (14) 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 plan for their completion?
>
>      All normative references in this document reference published
> RFCs.
>
> (15) Are there downward normative references references (see RFC 3967)?
> If so, list these downward references to support the Area Director in
> the Last Call procedure.
>
>      There is a normative reference to RFC 792.  That does not appear
>      to be a downref, as RFC 792 would now be considered Standards
> Track,
>      although it was published before there was such a distinction.
>      There are no other downward normative references in this document.
>
> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header, listed
> in the abstract, and discussed in the introduction? If the RFCs are not
> listed in the Abstract and Introduction, explain why, and point to the
> part of the document where the relationship of this document to the
> other RFCs is discussed. If this information is not in the document,
> explain why the interested community considers it unnecessary.
>
>      This document obsoletes RFC 1788 and updates RFCs 792 and 950.
>      These are identified in the document header, Abstract, and
>      Introduction.  The document also changes the status of RFC 1788
>      to historic, which is noted in the Abstract and Introduction.
>
> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes
> are associated with the appropriate reservations in IANA registries.
> Confirm that any referenced IANA registries have been clearly
> identified. Confirm that newly created IANA registries include a
> detailed specification of the initial contents for the registry, that
> allocations procedures for future registrations are defined, and a
> reasonable name for the new registry has been suggested (see RFC 5226).
>
>      This document is primarily concerned with giving clear
> instructions
>      to IANA to deprecate certain codes points.  The text does so
>      clearly.  The IANA considerations section recapitulates this in an
>      accurate and concise fashion.
>
> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find
> useful in selecting the IANA Experts for these new registries.
>
>      There are no new IANA registries created by this document.
>
> (19) Describe reviews and automated checks performed by to validate
> sections of the document written in a formal language, such as XML
> code, BNF rules, MIB definitions, etc.
>
>      There is no formal language material in this document.
2013-01-16
01 Cindy Morgan Notification list changed to : fgont@si6networks.com, cpignata@cisco.com, draft-gp-obsolete-icmp-types-iana@tools.ietf.org, jmh@joelhalpern.com
2013-01-16
01 Cindy Morgan Note added 'Joel Halpern (jmh@joelhalpern.com) is the Docment Shepherd'
2013-01-16
01 Ron Bonica State changed to AD Evaluation from Publication Requested
2013-01-16
01 Ron Bonica Ballot writeup was changed
2013-01-16
01 Ron Bonica Ballot writeup was generated
2013-01-16
01 Ron Bonica Assigned to Operations and Management Area
2013-01-16
01 Ron Bonica IESG process started in state Publication Requested
2013-01-16
01 Ron Bonica Intended Status changed to Proposed Standard from None
2013-01-16
01 Ron Bonica Stream changed to IETF from None
2013-01-16
01 Ron Bonica Shepherding AD changed to Ronald Bonica
2013-01-15
01 Fernando Gont New version available: draft-gp-obsolete-icmp-types-iana-01.txt
2013-01-11
00 Fernando Gont New version available: draft-gp-obsolete-icmp-types-iana-00.txt