idnits 2.17.00 (12 Aug 2021) /tmp/idnits57303/draft-hunt-dhcpv6-clarify-mrc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3315, but the abstract doesn't seem to directly say this. It does mention RFC3315 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3315, updated by this document, for RFC5378 checks: 1995-02-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 13, 2009) is 4845 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ENOKIHARA' is defined on line 135, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Duplicate reference: RFC3315, mentioned in 'ENOKIHARA', was also mentioned in 'RFC3315'. -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. 'ENOKIHARA') (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Hunt 3 Internet-Draft ISC 4 Updates: 3315 (if approved) February 13, 2009 5 Intended status: Standards Track 6 Expires: August 17, 2009 8 DHCPv6 MRC Clarification 9 draft-hunt-dhcpv6-clarify-mrc-00 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 17, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 The definition of the Maximum Retransmission Count (MRC) variable 49 described in RFC 3315 is clarified to resolve an ambiguity. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 4 60 6.2. Informative References . . . . . . . . . . . . . . . . . . 4 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1. Introduction 65 Section 14 of RFC 3315 [RFC3315] has an ambiguous definition of the 66 Maximum Retransmission Count (MRC) variable. The existing text says: 68 MRC specifies an upper bound on the number of times a client may 69 retransmit a message. Unless MRC is zero, the message exchange 70 fails once the client has transmitted the message MRC times. 72 The conflicting use of the words "transmit" and "retransmit" has led 73 to two different understandings of the MRC variable. Some 74 implementations use it to limit the total number of transmissions a 75 client may send, including the initial one. Others count only 76 subsequent retransmissions. This has caused problems with formal 77 acceptance testing. 79 We favor the second interpretation as a better match to the name of 80 the variable. (If MRC had been intended to include the original 81 transmission in its counter, it would have been called the Maximum 82 Transmission Count instead.) 84 2. Recommendations 86 In section 14 of RFC 3315 [RFC3315], the definition of MRC should be 87 read as follows: 89 MRC specifies an upper bound on the number of times a client may 90 retransmit a message after the initial transmission has taken 91 place. Unless MRC is zero, client transmissions end after the 92 client has transmitted the message a total of MRC + 1 times. 94 Future revisions of RFC 3315 should include this language. 96 Note that in this interpretation, the special meaning of MRC = 0 97 (indicating no limit) makes it impossible to use MRC to limit the 98 client to a single transmission and no retransmissions. This 99 inflexibility is unfortunate, but avoids a need to change the 100 variable name for clarity. 102 If a single transmission is required, MRD can be used instead, to 103 limit the total time the client spends transmitting to a period less 104 than the first retransmission timeout. In this scenario, IRT must 105 exceed MRD by an amount greater than the random factor added when 106 calculating the first RT. As an example, if MRD is set to one second 107 and IRT to two seconds, the first RT will never be lower than 1.9 108 seconds, and so a second transmission will never take place. 110 3. Acknowledgments 112 The ambiguity discussed in this document was first noted by Hideshi 113 Enokihara on the DHCWG mailing list. 115 Jeremy Reed and David Hankins of ISC provided editorial feedback. 117 4. IANA Considerations 119 This document requests no IANA actions. 121 5. Security Considerations 123 None. 125 6. References 127 6.1. Normative References 129 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 130 and M. Carney, "Dynamic Host Configuration Protocol for 131 IPv6 (DHCPv6)", RFC 3315, July 2003. 133 6.2. Informative References 135 [ENOKIHARA] 136 Enokihara, H., "Petty question regarding MRC in RFC3315", 137 2007, . 140 Author's Address 142 Evan Hunt 143 ISC 144 950 Charter St. 145 Redwood City, CA 94063 146 USA 148 Email: each@isc.org