IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters
draft-eastlake-rfc5342bis-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-10-18
|
05 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-10-07
|
05 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-09-17
|
05 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2013-09-13
|
05 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-09-13
|
05 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-09-11
|
05 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-08-30
|
05 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent |
2013-08-30
|
05 | (System) | RFC Editor state changed to EDIT |
2013-08-30
|
05 | (System) | Announcement was received by RFC Editor |
2013-08-30
|
05 | (System) | IANA Action state changed to In Progress |
2013-08-30
|
05 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-08-30
|
05 | Amy Vezza | IESG has approved the document |
2013-08-30
|
05 | Amy Vezza | Closed "Approve" ballot |
2013-08-30
|
05 | Amy Vezza | Ballot approval text was generated |
2013-08-29
|
05 | Joel Jaeggli | iana discussion completed |
2013-08-29
|
05 | Joel Jaeggli | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2013-08-29
|
05 | Joel Jaeggli | [Ballot comment] clearing due to completion of dicussion with iana. old comment: minor adjustment due to feedback provided by ieee rac is needed. since this … [Ballot comment] clearing due to completion of dicussion with iana. old comment: minor adjustment due to feedback provided by ieee rac is needed. since this doesn't not impact IETF assignments I think it's fine. imho I reviewed and I do not belive that it impacts the consensus we already have. from donald. From -04 to -05 Re-cast informational material about relevant IEEE assignment policies to take into account the planned changes by the IEEE Registraion Authority as per [RAC-OUIdraft]. Add a sentence forshadowing the future possibility of EUI-128 MAC addresses. Add InfiniBand as example of EUI-64 use. Minor editorial changes. |
2013-08-29
|
05 | Joel Jaeggli | [Ballot Position Update] Position for Joel Jaeggli has been changed to Yes from Discuss |
2013-08-15
|
05 | Donald Eastlake | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2013-08-15
|
05 | Donald Eastlake | New version available: draft-eastlake-rfc5342bis-05.txt |
2013-08-15
|
04 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2013-08-15
|
04 | Joel Jaeggli | [Ballot discuss] holding a discuss to get the new rev in to deal with ieee text and outstanding iana issue |
2013-08-15
|
04 | Joel Jaeggli | [Ballot Position Update] Position for Joel Jaeggli has been changed to Discuss from Yes |
2013-08-15
|
04 | Amanda Baber | IANA Review state changed to IANA - Not OK from IANA OK - Actions Needed |
2013-08-15
|
04 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-08-13
|
04 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to Yes from No Objection |
2013-08-12
|
04 | Joel Jaeggli | [Ballot comment] minor adjustment due to feedback provided by ieee rac is needed. since this doesn't not impact IETF assignments I think it's fine. imho … [Ballot comment] minor adjustment due to feedback provided by ieee rac is needed. since this doesn't not impact IETF assignments I think it's fine. imho I reviewed and I do not belive that it impacts the consensus we already have. from donald. From -04 to -05 Re-cast informational material about relevant IEEE assignment policies to take into account the planned changes by the IEEE Registraion Authority as per [RAC-OUIdraft]. Add a sentence forshadowing the future possibility of EUI-128 MAC addresses. Add InfiniBand as example of EUI-64 use. Minor editorial changes. |
2013-08-12
|
04 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2013-08-12
|
04 | Joel Jaeggli | [Ballot comment] minor adjustment due to feedback provided by ieee rac is needed. since this doesn't not impact IETF assignments I think it's fine. imho … [Ballot comment] minor adjustment due to feedback provided by ieee rac is needed. since this doesn't not impact IETF assignments I think it's fine. imho I reviewed and I do not belive that it impacts the consensus we already have. From -04 to -05 Re-cast informational material about relevant IEEE assignment policies to take into account the planned changes by the IEEE Registraion Authority as per [RAC-OUIdraft]. Add a sentence forshadowing the future possibility of EUI-128 MAC addresses. Add InfiniBand as example of EUI-64 use. Minor editorial changes. |
2013-08-12
|
04 | Joel Jaeggli | Ballot comment text updated for Joel Jaeggli |
2013-08-09
|
04 | David Black | Request for Telechat review by GENART Completed: Ready. Reviewer: David Black. |
2013-08-08
|
04 | Jean Mahoney | Request for Telechat review by GENART is assigned to David Black |
2013-08-08
|
04 | Jean Mahoney | Request for Telechat review by GENART is assigned to David Black |
2013-07-26
|
04 | Ted Lemon | [Ballot comment] What's the point of Appendix B? If it's to have a restricted list of only IETF allocations, should the IANA be maintaining this … [Ballot comment] What's the point of Appendix B? If it's to have a restricted list of only IETF allocations, should the IANA be maintaining this list, since what's in this document is doomed to become out of date? I don't find a list like this on the IANA web site. I don't specifically object to Appendix B; I just think that if these lists are useful, they ought to be maintained. Give that Joe's draft has passed IETF last call, I think my DISCUSS is moot, so I'm dropping it. Former DISCUSS: Based on Donald's response to the below point, I realize that I should have entered this as a DISCUSS, so I am correcting that mistake. Here't the original text of the comment: What is the purpose of section 5.2? It seems out of place with respect to the rest of this document. I can't really object to it, since what it says is true, but it seems inappropriate to mention IANA RRTYPE assignments in a document about 802 code points. Here's my further explanation of the problem: The use of these RRtypes is not documented in any IETF publication, so documenting it in this one is precedent-setting. Given that there has been substantial controversy about these RRtypes on the IETF mailing list (although it seems to be in a lull at the moment), publishing a reference to them in a completely unrelated document seems inappropriate. This document is an individual submission with a clear focus on documenting IEEE 802 code points. Knowing the authors, I think it is reasonable to assume that it has gotten sufficient review from experts on IEEE 802 code points, and that the consensus of the IETF on those points is valid. That it additionally documents a DNS RRTYPE code point suggests to me that this section likely slipped under the radar and got no expert review from DNS experts, and that in fact this particular text does not represent any meaningful IETF consensus. This DISCUSS can be cleared either by removing the text that documents these two RRtypes, or by doing a new last call on the IETF mailing list that specifically points out that this draft documents these two RRtypes. It may be that there is a similar problem relating to the AFN allocation. It seems similarly unrelated, but probably isn't controversial, so it may be that this part of section 5.2 is not problematic. I will not object if this part of section 5.2 is kept, even if no new consensus call is done. |
2013-07-26
|
04 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss |
2013-07-04
|
04 | Joel Jaeggli | Adjusted to match draft-jabley-dnsext-eui48-eui64-rrtypes since it looks like that will clear it's second ietf last call with no outstanding complaints. (after three revs and a … Adjusted to match draft-jabley-dnsext-eui48-eui64-rrtypes since it looks like that will clear it's second ietf last call with no outstanding complaints. (after three revs and a second last call) |
2013-07-04
|
04 | Joel Jaeggli | State changed to IESG Evaluation from IESG Evaluation::AD Followup |
2013-07-04
|
04 | Joel Jaeggli | Telechat date has been changed to 2013-08-15 from 2013-07-18 |
2013-07-04
|
04 | Joel Jaeggli | Telechat date has been changed to 2013-07-18 from 2013-06-13 |
2013-06-13
|
04 | Barry Leiba | [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss |
2013-06-13
|
04 | Donald Eastlake | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2013-06-13
|
04 | Donald Eastlake | New version available: draft-eastlake-rfc5342bis-04.txt |
2013-06-13
|
03 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation |
2013-06-13
|
03 | Cindy Morgan | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Cindy Morgan |
2013-06-13
|
03 | Ted Lemon | [Ballot discuss] Based on Donald's response to the below point, I realize that I should have entered this as a DISCUSS, so I am correcting … [Ballot discuss] Based on Donald's response to the below point, I realize that I should have entered this as a DISCUSS, so I am correcting that mistake. Here't the original text of the comment: What is the purpose of section 5.2? It seems out of place with respect to the rest of this document. I can't really object to it, since what it says is true, but it seems inappropriate to mention IANA RRTYPE assignments in a document about 802 code points. Here's my further explanation of the problem: The use of these RRtypes is not documented in any IETF publication, so documenting it in this one is precedent-setting. Given that there has been substantial controversy about these RRtypes on the IETF mailing list (although it seems to be in a lull at the moment), publishing a reference to them in a completely unrelated document seems inappropriate. This document is an individual submission with a clear focus on documenting IEEE 802 code points. Knowing the authors, I think it is reasonable to assume that it has gotten sufficient review from experts on IEEE 802 code points, and that the consensus of the IETF on those points is valid. That it additionally documents a DNS RRTYPE code point suggests to me that this section likely slipped under the radar and got no expert review from DNS experts, and that in fact this particular text does not represent any meaningful IETF consensus. This DISCUSS can be cleared either by removing the text that documents these two RRtypes, or by doing a new last call on the IETF mailing list that specifically points out that this draft documents these two RRtypes. It may be that there is a similar problem relating to the AFN allocation. It seems similarly unrelated, but probably isn't controversial, so it may be that this part of section 5.2 is not problematic. I will not object if this part of section 5.2 is kept, even if no new consensus call is done. |
2013-06-13
|
03 | Ted Lemon | [Ballot comment] What's the point of Appendix B? If it's to have a restricted list of only IETF allocations, should the IANA be maintaining this … [Ballot comment] What's the point of Appendix B? If it's to have a restricted list of only IETF allocations, should the IANA be maintaining this list, since what's in this document is doomed to become out of date? I don't find a list like this on the IANA web site. I don't specifically object to Appendix B; I just think that if these lists are useful, they ought to be maintained. |
2013-06-13
|
03 | Ted Lemon | Ballot comment and discuss text updated for Ted Lemon |
2013-06-13
|
03 | Ted Lemon | [Ballot discuss] Based on Donald's response to the below point, I realize that I should have entered this as a DISCUSS, so I am correcting … [Ballot discuss] Based on Donald's response to the below point, I realize that I should have entered this as a DISCUSS, so I am correcting that mistake. Here't the original text of the comment: What is the purpose of section 5.2? It seems out of place with respect to the rest of this document. I can't really object to it, since what it says is true, but it seems inappropriate to mention IANA RRTYPE assignments in a document about 802 code points. Here's my further explanation of the problem: The use of these RRtypes is not documented in any IETF publication, so documenting it in this one is precedent-setting. Given that there has been substantial controversy about these RRtypes on the IETF mailing list (although it seems to be in a lull at the moment), publishing a reference to them in a completely unrelated document seems inappropriate. This document is an individual submission with a clear focus on documenting IEEE 802 code points. Knowing the authors, I think it is reasonable to assume that it has gotten sufficient review from experts on IEEE 802 code points, and that the consensus of the IETF on those points is valid. That it additionally documents a DNS RRTYPE code point suggests to me that this section likely slipped under the radar and got no expert review from DNS experts, and that in fact this particular text does not represent any meaningful IETF consensus. This DISCUSS can be cleared either by removing the text that documents these two RRtypes, or by doing a new last call on the IETF mailing list that specifically points out that this draft documents these two RRtypes. It may be that there is a similar problem relating to the AFN allocation. It seems similarly unrelated, but probably isn't controversial, so it may be that this part of section 5.2 is not problematic. I will not object if this part of section 5.2 is kept, even if no new consensus call is done. |
2013-06-13
|
03 | Ted Lemon | [Ballot comment] What's the point of Appendix B? If it's to have a restricted list of only IETF allocations, should the IANA be maintaining this … [Ballot comment] What's the point of Appendix B? If it's to have a restricted list of only IETF allocations, should the IANA be maintaining this list, since what's in this document is doomed to become out of date? I don't find a list like this on the IANA web site. I don't specifically object to Appendix B; I just think that if these lists are useful, they ought to be maintained. |
2013-06-13
|
03 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to Discuss from No Objection |
2013-06-13
|
03 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-06-13
|
03 | Ted Lemon | [Ballot comment] What is the purpose of section 5.2? It seems out of place with respect to the rest of this document. I can't really … [Ballot comment] What is the purpose of section 5.2? It seems out of place with respect to the rest of this document. I can't really object to it, since what it says is true, but it seems inappropriate to mention IANA RRTYPE assignments in a document about 802 code points. What's the point of Appendix B? If it's to have a restricted list of only IETF allocations, should the IANA be maintaining this list, since what's in this document is doomed to become out of date? I don't find a list like this on the IANA web site. I don't specifically object to Appendix B; I just think that if these lists are useful, they ought to be maintained. |
2013-06-13
|
03 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2013-06-13
|
03 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-06-12
|
03 | Adrian Farrel | [Ballot comment] Thank you for including section 1.1 which helped my review considerably. --- Maybe reversing the order of sections 1.1 and 1.2 would make … [Ballot comment] Thank you for including section 1.1 which helped my review considerably. --- Maybe reversing the order of sections 1.1 and 1.2 would make 1.1 easier to read. --- ([RFC5342] had a requirement for parallel unicast and multicast assignments under some circumstances even when both types were not applied for. That requirement has proven impractical and is eliminated in this document.) s/both types were/one of the types was/ --- IANA always sends the Template to an appointed Expert. If the Expert recuses themselves or is non-responsive, IANA may choose an alternative appointed Expert or, if none are available, will contact the IESG. s/none are/none is/ --- I am unwarrantedly bothered by the presence of Appendix B. I struggle to see that it serves any purpose except to provide a secondary and potentially conflicting source of information compared to the registries. Would the authors consider removing it and leaving the pointers to the registries as the only source of information? |
2013-06-12
|
03 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-06-12
|
03 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-06-12
|
03 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-06-12
|
03 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-06-11
|
03 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2013-06-11
|
03 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2013-06-11
|
03 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2013-06-11
|
03 | Stephen Farrell | [Ballot discuss] This should be easy to sort out, but if its vague then I'd be worried we might be setting up a future conflict … [Ballot discuss] This should be easy to sort out, but if its vague then I'd be worried we might be setting up a future conflict between the IESG and an expert, so: I'm not at all clear when exactly "IESG ratification" is supposed to happen. Can you clarify? How big is very large? Apologies if its stated somewhere and I missed it:-) |
2013-06-11
|
03 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-06-10
|
03 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2013-06-10
|
03 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-06-10
|
03 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-06-09
|
03 | Barry Leiba | [Ballot discuss] David Black's GenART review notes a typo in Section 3.2, which the author is aware of: 00-00-0E-00-42 should be 00-00-5E-00-42 This DISCUSS is … [Ballot discuss] David Black's GenART review notes a typo in Section 3.2, which the author is aware of: 00-00-0E-00-42 should be 00-00-5E-00-42 This DISCUSS is holding that point, until there's a document rev or an RFC Editor note. I otherwise have no objection.... |
2013-06-09
|
03 | Barry Leiba | [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba |
2013-06-08
|
03 | Joel Jaeggli | Placed on agenda for telechat - 2013-06-13 |
2013-06-08
|
03 | Joel Jaeggli | Changed consensus to Yes from Unknown |
2013-06-08
|
03 | Joel Jaeggli | Ballot has been issued |
2013-06-08
|
03 | Joel Jaeggli | [Ballot Position Update] New position, Yes, has been recorded for Joel Jaeggli |
2013-06-08
|
03 | Joel Jaeggli | Created "Approve" ballot |
2013-06-08
|
03 | Joel Jaeggli | Ballot writeup was changed |
2013-06-08
|
03 | Joel Jaeggli | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2013-06-07
|
03 | Donald Eastlake | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2013-06-07
|
03 | Donald Eastlake | New version available: draft-eastlake-rfc5342bis-03.txt |
2013-06-05
|
02 | David Black | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: David Black. |
2013-06-04
|
02 | Pearl Liang | IESG/Authors/WG Chairs: Cc: Expert Dan Romascanu IANA has reviewed draft-eastlake-rfc5342bis-02. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to … IESG/Authors/WG Chairs: Cc: Expert Dan Romascanu IANA has reviewed draft-eastlake-rfc5342bis-02. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA has reviewed this Internet-Draft which contains significant documentation and changes to registration rules in the IEEE 802 Parameters registry. Upon approval of this document, IANA intends to work with the author to implement both the actions requested in section 5 of the current draft, but also ensure that the IEEE 802 Parameters registry is made consistent with the remainder of the draft (Sections 2, 3, and 4). 1) In reference to the "IANA 64-bit MAC Addresses" registry at http://www.iana.org/assignments/ethernet-numbers, the IANA Considerations section says the following: "The IANA 64-bit MAC tables currently shows modified EUI-64 addresses because the note above the tables specifies a prefix of 02-00-5E or 03-00-5E. The tables should list both those prefixes, indicating that these prefixes produce modified EUI-64 addresses for use in constructing IPv6 address and indicating that prefixes of 00-00-5E or 01-00-5E produce 64-bit MAC addresses." We're not sure exactly what this list of prefixes should look like. Rather than adding prefixes to the existing table of registrations, are we instead being asked to create a new table underneath the title "IANA 64-bit MAC Addresses," and just above the sub-registry itself, that will list 00-00-5E, 01-00-5E, 02-00-5E, 03-00-5E, and their uses? If so, would it make more sense to create a table for all prefixes under "IANA MAC ADDRESS BLOCK" and leave the note that goes with each sub-registry intact, except to add text describing 00-00-5E and 01-00-5E to the note that goes with the "IANA 64-bit MAC Addresses" sub-registry? Either way, please provide the exact text you want for the table(s). (Also, if you want us to add text to the "IANA 64-bit MAC Addresses" note rather than remove it, please provide the exact text.) 2) Should this document be added as a reference for "IANA MAC ADDRESS BLOCK," along with [RFC5342], and the registration procedure changed from "see [RFC5342]" to "Expert Review (Expert may request IESG Approval)"? 3) Section 5.2 assigns two MAC Address AFNs. Where is the AFN registry? Is it the existing registry called IANA MAC ADDRESS BLOCK? However, the registries are using this format '00-00-00 to 7F-FF-FF' (example) for addresses. Can we ask the authors to supply the above format for the two suggested values, 16389 and 16390? 4) IANA does not have a mechanism that will trigger an alarm when the available space for either multicast or unicast EUI-48 identifiers under OUI 00-00-5E have been 90% or more exhausted. We can add a note to the registry pointing out that this will need to be done, but it would be better if this were the expert's responsibility. 5) Has IANA made the assignment in section 3.2, "00-00-0E-00-42"? This isn't included in the IANA Considerations section, but it also doesn't appear to be listed in http://www.iana.org/assignments/ethernet-numbers. 6) Section 5.3 mentioned an "Informational IANA Web Page Material". We suggest that the authors should include the title of the information registry "IEEE 802 Numbers" in the text for clarity purposes. 7) The current IANA Considerations section is unclear to us The authors should clearly put in the IANA Considerations section what exactly they want changed. Changes in the registry? New assignments? Modifications to existing assignments? Reference changes? We understand that the above actions are all the IANA actions required 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. This message is only to confirm what actions will be performed. |
2013-06-04
|
02 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2013-06-04
|
02 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-05-23
|
02 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Charlie Kaufman. |
2013-05-16
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Charlie Kaufman |
2013-05-16
|
02 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Charlie Kaufman |
2013-05-09
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
2013-05-09
|
02 | Jean Mahoney | Request for Last Call review by GENART is assigned to David Black |
2013-05-07
|
02 | (System) | IANA Review state changed to IANA - Review Needed from IANA - Review Needed |
2013-05-07
|
02 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2013-05-07
|
02 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IANA Considerations and IETF Protocol and … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters) to Best Current Practice The IESG has received a request from an individual submitter to consider the following document: - 'IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters' as Best Current Practice 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-06-04. 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 Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses some use of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), provides some values for use in documentation, and obsoletes RFC 5342. The file can be obtained via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-eastlake-rfc5342bis/ballot/ No IPR declarations have been submitted directly on this I-D. |
2013-05-07
|
02 | Cindy Morgan | State changed to In Last Call from Last Call Requested |
2013-05-07
|
02 | Joel Jaeggli | Last call was requested |
2013-05-07
|
02 | Joel Jaeggli | Last call announcement was generated |
2013-05-07
|
02 | Joel Jaeggli | Ballot approval text was generated |
2013-05-07
|
02 | Joel Jaeggli | Ballot writeup was generated |
2013-05-07
|
02 | Joel Jaeggli | State changed to Last Call Requested from AD Evaluation |
2013-05-07
|
02 | Joel Jaeggli | consistent with rfc5342 requires IANA review, consensus call |
2013-05-07
|
02 | Joel Jaeggli | State changed to AD Evaluation from Publication Requested |
2013-05-06
|
02 | Joel Jaeggli | 02 revision addressed review concerns |
2013-05-06
|
02 | Joel Jaeggli | State changed to Publication Requested from AD is watching |
2013-05-06
|
02 | Joel Jaeggli | Changed document writeup |
2013-05-02
|
02 | Donald Eastlake | New version available: draft-eastlake-rfc5342bis-02.txt |
2013-04-30
|
01 | Joel Jaeggli | Document shepherd changed to Joel Jaeggli |
2013-04-22
|
01 | Joel Jaeggli | IESG process started in state AD is watching |
2013-04-22
|
01 | Joel Jaeggli | Shepherding AD changed to Joel Jaeggli |
2013-04-22
|
01 | Joel Jaeggli | Stream changed to IETF from None |
2013-04-22
|
01 | Joel Jaeggli | Shepherding AD changed to Joel Jaeggli |
2013-04-22
|
01 | Joel Jaeggli | Intended Status changed to Best Current Practice from None |
2013-04-22
|
01 | Joel Jaeggli | Shepherding AD changed to Joel Jaeggli |
2013-04-20
|
01 | Donald Eastlake | New version available: draft-eastlake-rfc5342bis-01.txt |
2013-04-15
|
00 | Donald Eastlake | New version available: draft-eastlake-rfc5342bis-00.txt |