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 |