Support for Adjustable Maximum Router Lifetimes per Link
draft-ietf-6man-maxra-04
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-02-20
|
04 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-01-16
|
04 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-01-08
|
04 | Martin Stiemerling | Closed request for Telechat review by TSVART with state 'Overtaken by Events' |
2017-12-20
|
04 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2017-12-05
|
04 | (System) | IANA Action state changed to No IC from In Progress |
2017-12-05
|
04 | (System) | IANA Action state changed to In Progress |
2017-12-05
|
04 | (System) | RFC Editor state changed to EDIT |
2017-12-05
|
04 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2017-12-05
|
04 | (System) | Announcement was received by RFC Editor |
2017-12-05
|
04 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2017-12-05
|
04 | Amy Vezza | IESG has approved the document |
2017-12-05
|
04 | Amy Vezza | Closed "Approve" ballot |
2017-12-05
|
04 | Suresh Krishnan | RFC Editor Note was changed |
2017-12-04
|
04 | Suresh Krishnan | RFC Editor Note was changed |
2017-12-04
|
04 | Suresh Krishnan | RFC Editor Note was changed |
2017-12-04
|
04 | Suresh Krishnan | RFC Editor Note for ballot was generated |
2017-12-04
|
04 | Suresh Krishnan | RFC Editor Note for ballot was generated |
2017-12-04
|
04 | Amy Vezza | Ballot approval text was generated |
2017-11-30
|
04 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
2017-11-30
|
04 | Spencer Dawkins | [Ballot comment] Everyone likely knows this, but is it worth adding a suggestion to retry rejected RAs with a Router Lifetime of more than 9000 … [Ballot comment] Everyone likely knows this, but is it worth adding a suggestion to retry rejected RAs with a Router Lifetime of more than 9000 seconds, with a new RA that uses 9000 seconds? 5. Host Behavior Legacy hosts on a link with updated routers may have issues with a Router Lifetime of more than 9000 seconds. In the few implementations we have tested with general purpose operating systems, there does not seem to be any issues with setting this field to more than 9000, but there might be implementations that incorrectly (since RFC4861 requires receivers to handle any value) reject such RAs. I think this meshes with Mirja's suggestion to state whether 9000 is still the default ... |
2017-11-30
|
04 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2017-11-29
|
04 | Adam Roach | [Ballot comment] Thanks for addressing my discuss and comment. I find the formulation in the document being updated problematic, but you've done a deft job … [Ballot comment] Thanks for addressing my discuss and comment. I find the formulation in the document being updated problematic, but you've done a deft job of not repeating the error in this document. |
2017-11-29
|
04 | Adam Roach | Ballot comment text updated for Adam Roach |
2017-11-29
|
04 | Adam Roach | [Ballot comment] [Based on a conversation with the sponsoring AD regarding the nature of the text in the next version of the document, I'm moving … [Ballot comment] [Based on a conversation with the sponsoring AD regarding the nature of the text in the next version of the document, I'm moving my previous DISCUSS text into a comment and trusting him to take care of the ambiguity prior to publication.] Lacking a formal definition of "between," the following normative statement is ambiguous: "AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535." Normative statements cannot be ambiguous. Please clarify whether this is an inclusive "between" or an exclusive "between." Section 4 contains: As explained in Section 3, the relationship between MaxRtrAdvInterval and AdvDefaultLifetime must be chosen to take into account the probability of packet loss. The use of a non-normative "must" here indicates that you probably want to update your RFC2119 boilerplate to be RFC8174 boilerplate. |
2017-11-29
|
04 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss |
2017-11-29
|
04 | Ben Campbell | [Ballot comment] Editorial Comments: - Abstract: Please mention the fact this updates 4861 in the abstract. - Given that there are at least a few … [Ballot comment] Editorial Comments: - Abstract: Please mention the fact this updates 4861 in the abstract. - Given that there are at least a few "should" and "must" instances in lower case, please consider using the boilerplate from 8174 rather than 2119. |
2017-11-29
|
04 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2017-11-29
|
04 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2017-11-28
|
04 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
2017-11-28
|
04 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2017-11-28
|
04 | Suresh Krishnan | New version available: draft-ietf-6man-maxra-04.txt |
2017-11-28
|
04 | (System) | New version approved |
2017-11-28
|
04 | (System) | Request for posting confirmation emailed to previous authors: Andrew Yourtchenko , Jouni Korhonen , Suresh Krishnan , Erik Nordmark , Samita Chakrabarti |
2017-11-28
|
04 | Suresh Krishnan | Uploaded new revision |
2017-11-28
|
03 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2017-10-26
|
03 | Adam Roach | [Ballot discuss] Lacking a formal definition of "between," the following normative statement is ambiguous: "AdvDefaultLifetime MUST either be zero (the router is not to be … [Ballot discuss] Lacking a formal definition of "between," the following normative statement is ambiguous: "AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535." Normative statements cannot be ambiguous. Please clarify whether this is an inclusive "between" or an exclusive "between." |
2017-10-26
|
03 | Adam Roach | Ballot discuss text updated for Adam Roach |
2017-10-24
|
03 | Terry Manderson | Telechat date has been changed to 2017-11-30 from 2017-10-26 |
2017-10-24
|
03 | Adam Roach | [Ballot discuss] I'm concerned that this normative statement is ambiguous (2nd paragraph of section 4), and that the ambiguity around allowed values may lead to … [Ballot discuss] I'm concerned that this normative statement is ambiguous (2nd paragraph of section 4), and that the ambiguity around allowed values may lead to interop issues: AdvDefaultLifetime MUST either be zero (the router is not to be used as a default router) or be a value between MaxRtrAdvInterval and 65535. From the text in section 3, I infer that MaxRtrAdvInterval is *not* an allowed value. From the "no greater than 65535" language, I infer that 65535 *is* an allowed value. Please ensure that your normative statement here is very clear about whether "between" is intended to include its high and low limits as acceptable values. |
2017-10-24
|
03 | Adam Roach | [Ballot comment] Section 4 contains: As explained in Section 3, the relationship between MaxRtrAdvInterval and AdvDefaultLifetime must be chosen to take into account … [Ballot comment] Section 4 contains: As explained in Section 3, the relationship between MaxRtrAdvInterval and AdvDefaultLifetime must be chosen to take into account the probability of packet loss. The use of a non-normative "must" here indicates that you probably want to update your RFC2119 boilerplate to be RFC8174 boilerplate. |
2017-10-24
|
03 | Adam Roach | [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach |
2017-10-24
|
03 | Warren Kumari | [Ballot comment] I like what the document does, but it could really really do with a good editing pass; I've sent some nits / comments … [Ballot comment] I like what the document does, but it could really really do with a good editing pass; I've sent some nits / comments to Suresh off-list. Some bits I was unable to parse, but I trust Suresh to fix them. I'm a bit surprised it doesn't mention RFC7772 - it feels very related to me, but I may just be wrong! |
2017-10-24
|
03 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2017-10-24
|
03 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2017-10-24
|
03 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2017-10-23
|
03 | Suresh Krishnan | [Ballot comment] I am an author. |
2017-10-23
|
03 | Suresh Krishnan | [Ballot Position Update] New position, Recuse, has been recorded for Suresh Krishnan |
2017-10-21
|
03 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2017-10-20
|
03 | Eric Rescorla | [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from No Record |
2017-10-19
|
03 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2017-10-17
|
03 | Eric Rescorla | [Ballot comment] I'm just testing something, and wanted to get a protocol trace. Will look at draft later. |
2017-10-17
|
03 | Eric Rescorla | Ballot comment text updated for Eric Rescorla |
2017-10-16
|
03 | Mirja Kühlewind | [Ballot comment] Just one quick question to double-check: Are the defaut values in RFC4861 still recommended or not? Maybe note this in the text to … [Ballot comment] Just one quick question to double-check: Are the defaut values in RFC4861 still recommended or not? Maybe note this in the text to avoid any confusion! Also, as already noted in the sphepherd write-up, the abstract should mention the update. |
2017-10-16
|
03 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2017-10-16
|
03 | Mirja Kühlewind | Requested Telechat review by TSVART |
2017-10-11
|
03 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2017-09-27
|
03 | Terry Manderson | Placed on agenda for telechat - 2017-10-26 |
2017-09-27
|
03 | Terry Manderson | IESG state changed to IESG Evaluation from Waiting for Writeup |
2017-09-27
|
03 | Terry Manderson | Ballot has been issued |
2017-09-27
|
03 | Terry Manderson | [Ballot Position Update] New position, Yes, has been recorded for Terry Manderson |
2017-09-27
|
03 | Terry Manderson | Created "Approve" ballot |
2017-09-27
|
03 | Terry Manderson | Ballot writeup was changed |
2017-09-15
|
03 | Meral Shirazipour | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. |
2017-09-15
|
03 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2017-09-14
|
03 | Rich Salz | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Rich Salz. Sent review to list. |
2017-09-07
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2017-09-07
|
03 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2017-09-07
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rich Salz |
2017-09-07
|
03 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Rich Salz |
2017-09-06
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Mahesh Jethanandani. |
2017-09-04
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani |
2017-09-04
|
03 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Mahesh Jethanandani |
2017-09-01
|
03 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2017-09-01
|
03 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-6man-maxra-03, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has reviewed draft-ietf-6man-maxra-03, which is currently in Last Call, and has the following comments: We have a question about this document: We understand that this document updates RFC 4861, which is the reference for a number of registrations and registries at https://www.iana.org/assignments/icmpv6-parameters. Should this document be listed as an additional or replacement reference for any of those registrations/registries? If not, 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. Thank you, Amanda Baber Lead IANA Services Specialist |
2017-09-01
|
03 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2017-09-01
|
03 | Amy Vezza | The following Last Call announcement was sent out (ends 2017-09-15): From: The IESG To: IETF-Announce CC: ipv6@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-maxra@ietf.org, otroan@employees.org, terry.manderson@icann.org … The following Last Call announcement was sent out (ends 2017-09-15): From: The IESG To: IETF-Announce CC: ipv6@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-maxra@ietf.org, otroan@employees.org, terry.manderson@icann.org, 6man-chairs@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Support for adjustable maximum router lifetimes per-link) to Proposed Standard The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Support for adjustable maximum router lifetimes per-link' 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 2017-09-15. 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 The neighbor discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements from a router interface as well as the maximum router lifetime. It also allows the limits to be overridden by link-layer specific documents. This document allows for overriding these values on a per-link basis. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ballot/ No IPR declarations have been submitted directly on this I-D. |
2017-09-01
|
03 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2017-09-01
|
03 | Amy Vezza | Last call announcement was changed |
2017-08-31
|
03 | Terry Manderson | Last call was requested |
2017-08-31
|
03 | Terry Manderson | Ballot approval text was generated |
2017-08-31
|
03 | Terry Manderson | Ballot writeup was generated |
2017-08-31
|
03 | Terry Manderson | IESG state changed to Last Call Requested from AD Evaluation |
2017-08-31
|
03 | Terry Manderson | Last call announcement was generated |
2017-08-09
|
03 | Terry Manderson | IESG state changed to AD Evaluation from Publication Requested |
2017-07-26
|
03 | Henrik Levkowetz | Notification list changed to bob.hinden@gmail.com, otroan@employees.org from Robert Hinden <bob.hinden@gmail.com>, Ole Trøan <otroan@employees.org> |
2017-07-24
|
03 | Bob Hinden | Notification list changed to Robert Hinden <bob.hinden@gmail.com>, Ole Trøan <otroan@employees.org> from Robert Hinden <bob.hinden@gmail.com> |
2017-07-24
|
03 | Terry Manderson | Shepherding AD changed to Terry Manderson |
2017-07-24
|
03 | Bob Hinden | Title : Support for adjustable maximum router lifetimes per-link Authors : Suresh Krishnan … Title : Support for adjustable maximum router lifetimes per-link Authors : Suresh Krishnan Jouni Korhonen Samita Chakrabarti Erik Nordmark Andrew Yourtchenko Filename : draft-ietf-6man-maxra-03.txt Pages : 6 Date : 2017-07-03 (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? Proposed Standard This is appropriate as this document updates a standards track RFC. Standards Track is indicated on the title page header and abstract. (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: The neighbor discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements from a router interface as well as the maximum router lifetime. It also allows the limits to be overridden by link-layer specific documents. This document allows for overriding these values on a per-link basis. Working Group Summary: There is support for this document in the 6MAN working group. Several issues were raised during the w.g. last call. These issues are resolved in the current draft. There is a concensus to advance this document. Document Quality: The quality of the document is good, it has received adequate review in the working group on the mailing list and at several 6man sessions at IETF meetings. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Bob Hinden Responsible AD: Terry Manderson (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. The document Shepard has followed the process in the working group, followed the discussion in the working group, and thinks that the issues raised have been resolved in the current draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (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. No, N/A (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 WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns. (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, all of the authors have confirmed that there is no IPR and full conformance with BCP78 and BCP79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures have been filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a good consensus around this document. There has been active discussion on the mailing list and at 6man face to face sessions. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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 appeals have been threatened, nor is there any extreme discontent. (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. The only ID Nit is that the abstract needs to mention that RFC4861 is updated. This will be fixed in the next version. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? The document has a separate Normative and Information reference section. References are characterized correctly. (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? No, all references are 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. N/A (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 WG considers it unnecessary. This document will not change the status of any other RFCs. It does update RFC4861, and this is noted in the header. It needs to be added to the Abstract when the next version is published. (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). There are no IANA actions in the document. (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. N/A (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
2017-07-24
|
03 | Bob Hinden | Responsible AD changed to Suresh Krishnan |
2017-07-24
|
03 | Bob Hinden | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2017-07-24
|
03 | Bob Hinden | IESG state changed to Publication Requested |
2017-07-24
|
03 | Bob Hinden | IESG process started in state Publication Requested |
2017-07-24
|
03 | Bob Hinden | Changed document writeup |
2017-07-17
|
03 | Bob Hinden | Notification list changed to Robert Hinden <bob.hinden@gmail.com> |
2017-07-17
|
03 | Bob Hinden | Document shepherd changed to Robert M. Hinden |
2017-07-17
|
03 | Bob Hinden | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
2017-07-17
|
03 | Bob Hinden | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-07-03
|
03 | Suresh Krishnan | New version available: draft-ietf-6man-maxra-03.txt |
2017-07-03
|
03 | (System) | Forced post of submission |
2017-07-03
|
03 | (System) | Request for posting confirmation emailed to previous authors: Andrew Yourtchenko , Suresh Krishnan , Jouni Korhonen , Erik Nordmark , Samita Chakrabarti , 6man-chairs@ietf.org |
2017-07-03
|
03 | Suresh Krishnan | Uploaded new revision |
2017-05-30
|
02 | Ole Trøan | Tag Revised I-D Needed - Issue raised by WGLC set. |
2017-03-09
|
02 | Suresh Krishnan | New version available: draft-ietf-6man-maxra-02.txt |
2017-03-09
|
02 | (System) | New version approved |
2017-03-09
|
02 | (System) | Request for posting confirmation emailed to previous authors: Andrew Yourtchenko , Suresh Krishnan , Jouni Korhonen , Erik Nordmark , Samita Chakrabarti |
2017-03-09
|
02 | Suresh Krishnan | Uploaded new revision |
2017-01-09
|
01 | (System) | Document has expired |
2016-12-21
|
01 | Bob Hinden | Changed consensus to Yes from Unknown |
2016-12-21
|
01 | Bob Hinden | Intended Status changed to Proposed Standard from None |
2016-12-21
|
01 | Bob Hinden | This last call will end on 11 January 2017. |
2016-12-21
|
01 | Bob Hinden | IETF WG state changed to In WG Last Call from WG Document |
2016-07-08
|
01 | Suresh Krishnan | New version available: draft-ietf-6man-maxra-01.txt |
2015-12-14
|
00 | Ole Trøan | This document now replaces draft-krishnan-6man-maxra instead of None |
2015-12-09
|
00 | Suresh Krishnan | New version available: draft-ietf-6man-maxra-00.txt |