Relaxed Packet Counter Verification for Babel MAC Authentication
draft-ietf-babel-mac-relaxed-05
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
05 | Gunter Van de Velde | Request closed, assignment withdrawn: Joel Jaeggli Last Call OPSDIR review |
2024-01-26
|
05 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2024-01-16
|
(System) | Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-babel-mac-relaxed and RFC 9467, changed IESG state to RFC … Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-babel-mac-relaxed and RFC 9467, changed IESG state to RFC Published) |
|
2024-01-09
|
05 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2023-08-16
|
05 | (System) | RFC Editor state changed to AUTH48 |
2023-06-26
|
05 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2023-06-23
|
05 | (System) | RFC Editor state changed to EDIT |
2023-06-23
|
05 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2023-06-23
|
05 | (System) | Announcement was received by RFC Editor |
2023-06-23
|
05 | (System) | IANA Action state changed to In Progress |
2023-06-23
|
05 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2023-06-23
|
05 | Amy Vezza | IESG has approved the document |
2023-06-23
|
05 | Amy Vezza | Closed "Approve" ballot |
2023-06-23
|
05 | Amy Vezza | Ballot approval text was generated |
2023-06-22
|
05 | Andrew Alston | Having looked at the update I believe that all comments have been addressed and this can now proceed |
2023-06-22
|
05 | Andrew Alston | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2023-06-12
|
05 | Juliusz Chroboczek | New version available: draft-ietf-babel-mac-relaxed-05.txt |
2023-06-12
|
05 | (System) | New version approved |
2023-06-12
|
05 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , Toke Hoeiland-Joergensen |
2023-06-12
|
05 | Juliusz Chroboczek | Uploaded new revision |
2023-05-25
|
04 | (System) | Removed all action holders (IESG state changed) |
2023-05-25
|
04 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation |
2023-05-25
|
04 | Lars Eggert | [Ballot comment] # GEN AD review of draft-ietf-babel-mac-relaxed-04 CC @larseggert Thanks to Stewart Bryant for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/aNc5ylceFw8dsLWBPxoFDGU5xVw). … [Ballot comment] # GEN AD review of draft-ietf-babel-mac-relaxed-04 CC @larseggert Thanks to Stewart Bryant for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/aNc5ylceFw8dsLWBPxoFDGU5xVw). ## Comment ### Missing "Updates" explanation This document updates RFC8967, but does not seem to include explanatory text about this in the abstract. ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Stray characters The text version of this document contains these HTML entities, which might indicate issues with its XML source: `ö` ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool |
2023-05-25
|
04 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
2023-05-24
|
04 | Paul Wouters | [Ballot comment] Thanks to Christian Huitema for the excellent secdir review. The abstract should state this document Updates RFC 8967 Suggestion: … |
2023-05-24
|
04 | Paul Wouters | [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters |
2023-05-24
|
04 | Éric Vyncke | [Ballot comment] Thanks to the authors for a nice fix to a "simple" problem. Thanks also to Donald Eastlake for the shepherd write-up. |
2023-05-24
|
04 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2023-05-23
|
04 | Roman Danyliw | [Ballot comment] Thank you to Christian Huitema for the SECDIR review. ** Section 3.1. In this updated text, there doesn’t appear to be an explicit … [Ballot comment] Thank you to Christian Huitema for the SECDIR review. ** Section 3.1. In this updated text, there doesn’t appear to be an explicit explanation that PCm is the multicast counter and the PCu is the unicast counter. ** Section 4. I concur with Christian Huitema’s SECDIR recommendation to add clarifying text on why multiple PCs aren’t an issue. Extracting from the review with editorial liberty: OLD The procedures described in this document do not change the security properties described in Section 1.2 of RFC 8967. NEW The procedures described in this document do not change the security properties described in Section 1.2 of RFC 8967. Since unicast and multicast packets can be reliably distinguished by examining the destination IP address (which is copied in the pseudo-header included in the computation of the MAC TLV), the use of separate PCs does not allow an on-path adversary to capture a unicast packet with a PC TLV larger than the highest multicast PC TLV, and replay it as a multicast packet (or vice versa). ** Section 4. Given this opportunity to update RFC8967, the SECDIR reviewer points out an opportunity to note an attack via a compromised node and that the attacks through compromised node or compromised credential can persist until they are detected and the network administrator restarts the network using new credentials. Considering adding such cautionary text. |
2023-05-23
|
04 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2023-05-21
|
04 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
2023-05-19
|
04 | Martin Duke | [Ballot comment] One nit, which requires no reply: the first sentence in the Introduction makes two statements and then says that “this assumption” is not … [Ballot comment] One nit, which requires no reply: the first sentence in the Introduction makes two statements and then says that “this assumption” is not valid. Perhaps rearrange to make it clear what is invalid? |
2023-05-19
|
04 | Martin Duke | Ballot comment text updated for Martin Duke |
2023-05-19
|
04 | Martin Duke | [Ballot comment] One nit, which requires no reply: the first sentence makes two statements and then says that “this assumption” is not valid. Perhaps rearrange … [Ballot comment] One nit, which requires no reply: the first sentence makes two statements and then says that “this assumption” is not valid. Perhaps rearrange to make it clear what is invalid? |
2023-05-19
|
04 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2023-05-18
|
04 | Zaheduzzaman Sarker | [Ballot comment] Thanks for working on this update. Thanks to Kyle Rose for the TSVART review. I have one comment and I believe it will … [Ballot comment] Thanks for working on this update. Thanks to Kyle Rose for the TSVART review. I have one comment and I believe it will improve the document if addressed - - Maintaining Multiple highest PC is RECOMMENDED and window-based validation is OPTIONAL. It would be very helpful to explain the reasoning behind these choices for the implementers. |
2023-05-18
|
04 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
2023-05-17
|
04 | Warren Kumari | [Ballot comment] Thank you for writing this document - in addition to explaining the problem nicely, it is well written and explains the solution nicely. … [Ballot comment] Thank you for writing this document - in addition to explaining the problem nicely, it is well written and explains the solution nicely. Thank you |
2023-05-17
|
04 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2023-05-17
|
04 | John Scudder | [Ballot Position Update] New position, Yes, has been recorded for John Scudder |
2023-05-15
|
04 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2023-05-08
|
04 | Murray Kucherawy | [Ballot comment] The RECOMMENDED in Section 3.2 is curious, especially since it's referring to the default value. Do we need any guidance here about when … [Ballot comment] The RECOMMENDED in Section 3.2 is curious, especially since it's referring to the default value. Do we need any guidance here about when one might legitimately pick a different value? Or what's the impact if I pick something else such that a BCP 14 keyword is needed here? |
2023-05-08
|
04 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2023-05-08
|
04 | Thomas Fossati | Request for Telechat review by IOTDIR Completed: Ready. Reviewer: Thomas Fossati. Sent review to list. |
2023-05-08
|
04 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Thomas Fossati |
2023-05-08
|
04 | Ines Robles | Assignment of request for Telechat review by IOTDIR to Pascal Thubert was rejected |
2023-05-06
|
04 | Ines Robles | Request for Telechat review by IOTDIR is assigned to Pascal Thubert |
2023-05-03
|
04 | Éric Vyncke | Requested Telechat review by IOTDIR |
2023-05-03
|
04 | Jim Guichard | [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard |
2023-05-03
|
04 | Andrew Alston | Placed on agenda for telechat - 2023-05-25 |
2023-05-03
|
04 | Andrew Alston | Ballot has been issued |
2023-05-03
|
04 | Andrew Alston | [Ballot Position Update] New position, Yes, has been recorded for Andrew Alston |
2023-05-03
|
04 | Andrew Alston | Created "Approve" ballot |
2023-05-03
|
04 | Andrew Alston | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2023-05-03
|
04 | Andrew Alston | Ballot writeup was changed |
2023-04-27
|
04 | Stewart Bryant | Request for Last Call review by GENART Completed: Ready. Reviewer: Stewart Bryant. Sent review to list. |
2023-04-17
|
04 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2023-04-14
|
04 | Kyle Rose | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Kyle Rose. Sent review to list. |
2023-04-13
|
04 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2023-04-13
|
04 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-babel-mac-relaxed-04, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-babel-mac-relaxed-04, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Specialist |
2023-04-12
|
04 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joel Jaeggli |
2023-04-11
|
04 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Kyle Rose |
2023-04-09
|
04 | Christian Huitema | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Christian Huitema. Review has been revised by Christian Huitema. |
2023-04-08
|
04 | Christian Huitema | Request for Last Call review by SECDIR Completed: Not Ready. Reviewer: Christian Huitema. Sent review to list. |
2023-04-06
|
04 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christian Huitema |
2023-04-06
|
04 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2023-04-04
|
04 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2023-04-04
|
04 | Amy Vezza | The following Last Call announcement was sent out (ends 2023-04-18): From: The IESG To: IETF-Announce CC: andrew-ietf@liquid.tech, babel-chairs@ietf.org, babel@ietf.org, d3e3e3@gmail.com, draft-ietf-babel-mac-relaxed@ietf.org … The following Last Call announcement was sent out (ends 2023-04-18): From: The IESG To: IETF-Announce CC: andrew-ietf@liquid.tech, babel-chairs@ietf.org, babel@ietf.org, d3e3e3@gmail.com, draft-ietf-babel-mac-relaxed@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Relaxed Packet Counter Verification for Babel MAC Authentication) to Proposed Standard The IESG has received a request from the Babel routing protocol WG (babel) to consider the following document: - 'Relaxed Packet Counter Verification for Babel MAC Authentication' 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 last-call@ietf.org mailing lists by 2023-04-18. 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 This document relaxes packet verification rules defined in the Babel MAC Authentication protocol in order to make it more robust in the presence of packet reordering. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-babel-mac-relaxed/ No IPR declarations have been submitted directly on this I-D. |
2023-04-04
|
04 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2023-04-04
|
04 | Andrew Alston | Last call was requested |
2023-04-04
|
04 | Andrew Alston | Last call announcement was generated |
2023-04-04
|
04 | Andrew Alston | Ballot approval text was generated |
2023-04-04
|
04 | Andrew Alston | Ballot writeup was generated |
2023-04-04
|
04 | (System) | Changed action holders to Andrew Alston (IESG state changed) |
2023-04-04
|
04 | Andrew Alston | IESG state changed to Last Call Requested from Publication Requested |
2022-11-29
|
04 | Donald Eastlake | 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? … 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There is solid support for this draft in the WG. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No. 3. 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. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)? There are two independent implementations, babeld and BIRD. See https://mailarchive.ietf.org/arch/msg/babel/W5k5WNWp4A6KuOUmmrlvCPY-wr4/ 5. Does this document need review from other IETF working groups or external organizations? No. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. An early RTGDIR review was done as posted here https://mailarchive.ietf.org/arch/msg/rtg-dir/ilzmanO9BZapxLGmiSMgNnYvgUk/ The comments in that review has been resolved. 7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342? This document contains no YANG modules. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, ASN.1 modules, etc. Document Shepherd Checks. This document contains no formal language. The Shepherd has carefully reviewed this draft a few times, most recently as documented at https://mailarchive.ietf.org/arch/msg/babel/HQjK4TKnEqC-yI8YPt3De5QOm2g/ These comments have been resolved. 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. Do any such issues remain that would merit specific attention from subsequent reviews? Not that I can see.. 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Standards Track as indicated on the title page. This is appropriate for a document that updates a Standards Track protocol (RFC 8967). 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by BCP 78 and BCP 79 have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. See IPR statments at https://mailarchive.ietf.org/arch/msg/babel/MBKqQLx-rzKIvCBXXudpnjv1RY8/ https://mailarchive.ietf.org/arch/msg/babel/1Y9YGWKViPRsI_3GdoD4rlcRN4Y/ It appears that no IPR is being claimed. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. Implicitly as per question 12 above. 14. Identify any remaining I-D nits in this document. (See the idnits tool and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. The nits check incorrectly complains about "non-ASCII" characters in the draft. The draft correctly contains characters such as é and ø. 15. Should any informative references be normative or vice-versa? I believe the references are correctly categorized. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? All normative references are to RFCs. 17. Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them. There are no downward references. 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? There are no such reference. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. This document does not change the status of any other RFC but it does Update RFC 8967. 20. 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 aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126). This document requires no IANA actions. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. This document creates no IANA registries. |
2022-11-29
|
04 | Donald Eastlake | Responsible AD changed to Andrew Alston |
2022-11-29
|
04 | Donald Eastlake | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2022-11-29
|
04 | Donald Eastlake | IESG state changed to Publication Requested from I-D Exists |
2022-11-29
|
04 | Donald Eastlake | Document is now in IESG state Publication Requested |
2022-11-29
|
04 | Donald Eastlake | 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? … 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? There is solid support for this draft in the WG. 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? No. 3. 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. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as RFC 7942 recommends) or elsewhere (where)? There are two independent implementations, babeld and BIRD. See https://mailarchive.ietf.org/arch/msg/babel/W5k5WNWp4A6KuOUmmrlvCPY-wr4/ 5. Does this document need review from other IETF working groups or external organizations? No. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. An early RTGDIR review was done as posted here https://mailarchive.ietf.org/arch/msg/rtg-dir/ilzmanO9BZapxLGmiSMgNnYvgUk/ The comments in that review has been resolved. 7. If the document contains a YANG module, has the final version of the module been checked with any of the recommended validation tools for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC 8342? This document contains no YANG modules. 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, ASN.1 modules, etc. Document Shepherd Checks. This document contains no formal language. The Shepherd has carefully reviewed this draft a few times, most recently as documented at https://mailarchive.ietf.org/arch/msg/babel/HQjK4TKnEqC-yI8YPt3De5QOm2g/ These comments have been resolved. 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? Yes. 10. Several IETF Areas have assembled lists of common issues that their reviewers encounter. Do any such issues remain that would merit specific attention from subsequent reviews? Not that I can see.. 11. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Standards Track as indicated on the title page. This is appropriate for a document that updates a Standards Track protocol (RFC 8967). 12. Has the interested community confirmed that any and all appropriate IPR disclosures required by BCP 78 and BCP 79 have been filed? If not, explain why. If yes, summarize any discussion and conclusion regarding the intellectual property rights (IPR) disclosures, including links to relevant emails. See IPR statments at https://mailarchive.ietf.org/arch/msg/babel/MBKqQLx-rzKIvCBXXudpnjv1RY8/ https://mailarchive.ietf.org/arch/msg/babel/1Y9YGWKViPRsI_3GdoD4rlcRN4Y/ It appears that no IPR is being claimed. 13. Has each Author or Contributor confirmed their willingness to be listed as such? If the number of Authors/Editors on the front page is greater than 5, please provide a justification. Implicitly as per question 12 above. 14. Identify any remaining I-D nits in this document. (See the idnits tool and the checkbox items found in Guidelines to Authors of Internet-Drafts). Simply running the idnits tool is not enough; please review the entire guidelines document. The nits check incorrectly complains about "non-ASCII" characters in the draft. The draft correctly contains characters such as é and ø. 15. Should any informative references be normative or vice-versa? I believe the references are correctly categorized. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? All normative references are to RFCs. 17. Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them. There are no downward references. 18. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If they exist, what is the plan for their completion? There are no such reference. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. This document does not change the status of any other RFC but it does Update RFC 8967. 20. 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 aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see RFC 8126). This document requires no IANA actions. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. This document creates no IANA registries. |
2022-11-29
|
04 | Juliusz Chroboczek | New version available: draft-ietf-babel-mac-relaxed-04.txt |
2022-11-29
|
04 | (System) | New version approved |
2022-11-29
|
04 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , Toke Hoeiland-Joergensen |
2022-11-29
|
04 | Juliusz Chroboczek | Uploaded new revision |
2022-11-09
|
03 | Juliusz Chroboczek | New version available: draft-ietf-babel-mac-relaxed-03.txt |
2022-11-09
|
03 | (System) | New version approved |
2022-11-09
|
03 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , Toke Hoeiland-Joergensen |
2022-11-09
|
03 | Juliusz Chroboczek | Uploaded new revision |
2022-10-26
|
02 | Ben Niven-Jenkins | Request for Early review by RTGDIR Completed: Has Nits. Reviewer: Ben Niven-Jenkins. Sent review to list. |
2022-10-13
|
02 | Haomian Zheng | Request for Early review by RTGDIR is assigned to Ben Niven-Jenkins |
2022-10-13
|
02 | Haomian Zheng | Request for Early review by RTGDIR is assigned to Ben Niven-Jenkins |
2022-10-12
|
02 | Donald Eastlake | Requested Early review by RTGDIR |
2022-09-30
|
02 | Donald Eastlake | Started a few days ago. Draft has good support and is not controversial. |
2022-09-30
|
02 | Donald Eastlake | IETF WG state changed to In WG Last Call from WG Document |
2022-08-29
|
02 | Juliusz Chroboczek | New version available: draft-ietf-babel-mac-relaxed-02.txt |
2022-08-29
|
02 | (System) | New version approved |
2022-08-29
|
02 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , Toke Hoeiland-Joergensen |
2022-08-29
|
02 | Juliusz Chroboczek | Uploaded new revision |
2022-08-01
|
01 | Donald Eastlake | Changed consensus to Yes from Unknown |
2022-08-01
|
01 | Donald Eastlake | Updated Proposed Standard RFC 8967. |
2022-08-01
|
01 | Donald Eastlake | Intended Status changed to Proposed Standard from None |
2022-08-01
|
01 | Donald Eastlake | Notification list changed to d3e3e3@gmail.com because the document shepherd was set |
2022-08-01
|
01 | Donald Eastlake | Document shepherd changed to Donald E. Eastlake 3rd |
2022-06-11
|
01 | Juliusz Chroboczek | New version available: draft-ietf-babel-mac-relaxed-01.txt |
2022-06-11
|
01 | (System) | New version approved |
2022-06-11
|
01 | (System) | Request for posting confirmation emailed to previous authors: Juliusz Chroboczek , babel-chairs@ietf.org |
2022-06-11
|
01 | Juliusz Chroboczek | Uploaded new revision |
2022-05-22
|
00 | (System) | This document now replaces draft-chroboczek-babel-mac-relaxed instead of None |
2022-05-22
|
00 | Juliusz Chroboczek | New version available: draft-ietf-babel-mac-relaxed-00.txt |
2022-05-22
|
00 | (System) | New version approved |
2022-05-22
|
00 | Juliusz Chroboczek | Request for posting confirmation emailed to submitter and authors: Juliusz Chroboczek |
2022-05-22
|
00 | Juliusz Chroboczek | Uploaded new revision |