idnits 2.17.1 draft-haynes-nfsv4-versioning-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'not RECOMMENDED' in this paragraph: o When a correction is made to a MANDATORY feature, the situation becomes one in which neither the old nor the new new version of the feature is MANDATORY. Instead, it is MANDATORY that a server support at least one of the two, while each is individually OPTIONAL. Although use of the corrected version is ultimately better, it is not RECOMMENDED, since the choice of which version to support if only one is supported will depend on the needs of clients, which may be slow to adopt the updated version. -- The document date (October 10, 2014) is 3486 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) ** Obsolete normative reference: RFC 3530 (Obsoleted by RFC 7530) == Outdated reference: A later version (-35) exists of draft-ietf-nfsv4-rfc3530bis-33 ** Obsolete normative reference: RFC 5661 (Obsoleted by RFC 8881) == Outdated reference: A later version (-41) exists of draft-ietf-nfsv4-minorversion2-27 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 T. Haynes 3 Internet-Draft Primary Data 4 Intended status: Standards Track D. Noveck 5 Expires: April 13, 2015 Dell 6 October 10, 2014 8 NFSv4 Version Management 9 draft-haynes-nfsv4-versioning-01 11 Abstract 13 This document describes the management of versioning within the NFSv4 14 family of protocols. It covers the creation of minor versions, the 15 addition of OPTIONAL features to existing minor versions, and the 16 correction of flaws in features already published as Proposed 17 Standards. The rules for minor versioning set out in this document 18 supersede the multiple sets of minor versioning rules in RFC3530 and 19 RFC5661. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 13, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Consolidation of the Minor Version Rules . . . . . . . . . . 3 64 4. The Minor Versioning Rules . . . . . . . . . . . . . . . . . 4 65 5. Extensions within Minor Versions . . . . . . . . . . . . . . 7 66 5.1. Feature Specification Documents . . . . . . . . . . . . . 7 67 5.2. Additional Informational Documents . . . . . . . . . . . 9 68 5.3. Relationship Between Minor Versioning and Extensions 69 within a Minor Version . . . . . . . . . . . . . . . . . 11 70 6. Correction of Existing Minor Versions and Features . . . . . 12 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 75 9.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 14 77 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 To address the requirement of an NFS protocol that can evolve as the 83 need arises, the Network File System (NFS) version 4 (NFSv4) protocol 84 contains the rules and framework to allow for future minor changes or 85 versioning. These versioning rules SHOULD maintain compatibility 86 with existing clients and servers. 88 A large portion of such changes will be part of new minor versions. 89 The COMPOUND procedure (see Section 14.2 of [RFC3530]) specfies the 90 minor version being used by the client. The CB_COMPOUND (see 91 Section 15.2 of [RFC3530]) procedure specifies the minor version 92 being used by the server on callbacks. 94 Each minor version is specified by one or more standards track RFC: 96 Minor version 0 is specified by [RFC3530] 97 Minor version 1 is specified principally by [RFC5661] 99 Minor version 2 is specified principally by [NFSv42]. 101 In addition to the creation of new minor versions, two other sorts of 102 versioning are discussed in this document: 104 o Addition of OPTIONAL features to existing minor versions. 106 o XDR-based extensions used to correct protocol bugs in existing 107 minor versions or associated features. 109 2. Terminology 111 A basic familiarity with the NFSv4 terminology is assumed in this 112 document, the reader is pointed to [RFC3530]. 114 3. Consolidation of the Minor Version Rules 116 Previously, versioning rules had been being maintained and specified 117 in the Standards Track RFCs, defining the individual minor versions. 118 As a result, versioning rules were modified on an ad hoc basis for 119 each new minor version. 121 This document defines a set of versioning rules, including rules for 122 minor version construction, that applies to the NFSv4 protocol as a 123 whole. The rules are subject to change but any such change should be 124 part of a standards track RFC obsoleting or updating this document. 126 This document supersedes the minor versioning rules appearing in the 127 minor version specification RFC's. As a result potential conflicts 128 among these documents should be addressed as follows: 130 o The specification of the actual protocols for minor versions 131 previously published as Proposed Standards take precedence over 132 minor versioning rules in either this document or in the minor 133 version specification RFC's. In other words, if the transition 134 from version A to version B violates a minor versioning rules, the 135 protocol stays as it is. 137 o Otherwise, any conflict between the minor versioning rules in this 138 document and those in minor version specification RFC's are to be 139 resolved based on the treatment in this document. 141 Future minor version specification documents should avoid specifying 142 minor versioning rules and reference this document in connection with 143 rules for minor versions. 145 4. The Minor Versioning Rules 147 The following items represent the basic rules for the development of 148 minor versions. 150 1. Procedures are not added or deleted. 152 To maintain the general Remote Procedure Call (RPC) model, NFSv4 153 minor versions will not add to or delete procedures from the NFS 154 program. 156 2. Minor versions may add operations to the COMPOUND and 157 CB_COMPOUND procedures. 159 The addition of operations to the COMPOUND and CB_COMPOUND 160 procedures does not affect the RPC model. 162 * Minor versions may append attributes to the bitmap4 that 163 represents sets of attributes and to the fattr4 that 164 represents sets of attribute values. 166 This allows for the expansion of the attribute model to allow 167 for future growth or adaptation. 169 * Minor version X must append any new attributes after the last 170 documented attribute. 172 Since attribute results are specified as an opaque array of 173 per-attribute, XDR-encoded results, the complexity of adding 174 new attributes in the midst of the current definitions would 175 be too burdensome. 177 3. Minor versions must not modify the structure of an existing 178 operation's arguments or results. 180 Again, the complexity of handling multiple structure definitions 181 for a single operation is too burdensome. New operations should 182 be added instead of modifying existing structures for a minor 183 version. 185 This rule does not preclude the following adaptations in a minor 186 version: 188 * adding bits to flag fields, such as new attributes to 189 GETATTR's bitmap4 data type, and providing corresponding 190 variants of opaque arrays, such as a notify4 used together 191 with such bitmaps 193 * adding bits to existing attributes like Access Control Lists 194 (ACL) that have flag words 196 * extending enumerated types (including NFS4ERR_*) with new 197 values 199 * adding cases to a switched union 201 4. Note that when adding new cases to a switched union, a minor 202 version must not make new cases be REQUIRED. While the 203 encapsulating operation may be REQUIRED, the new cases (the 204 specific arm of the discriminated union) is not. The error code 205 NFS4ERR_UNION_NOTSUPP is used to notify the client when the 206 server does not support such a case. 208 5. Minor versions must not modify the structure of existing 209 attributes. 211 6. Minor versions must not delete operations. 213 This prevents the potential reuse of a particular operation 214 "slot" in a future minor version. 216 7. Minor versions must not delete attributes. 218 8. Minor versions must not delete flag bits or enumeration values. 220 9. Minor versions may declare an operation MUST NOT be implemented. 222 Specifying that an operation MUST NOT be implemented is 223 equivalent to obsoleting an operation. For the client, it means 224 that the operation MUST NOT be sent to the server. For the 225 server, an NFS error can be returned as opposed to "dropping" 226 the request as an XDR decode error. This approach allows for 227 the obsolescence of an operation while maintaining its structure 228 so that a future minor version can reintroduce the operation. 230 1. Minor versions may declare that an attribute MUST NOT be 231 implemented. 233 2. Minor versions may declare that a flag bit or enumeration 234 value MUST NOT be implemented. 236 10. Minor versions may declare an operation to be OBSOLESCENT, which 237 indicates an intention to remove the operation (i.e., make it 238 MANDATORY TO NOT implement) in a subsequent minor version. Such 239 labeling is separate from the question of whether the operation 240 is REQUIRED or RECOMMENDED or OPTIONAL in the current minor 241 version. An operation may be both REQUIRED for the given minor 242 version and marked OBSOLESCENT, with the expectation that it 243 will be MANDATORY TO NOT implement in the next (or other 244 subsequent) minor version. 246 11. Note that the early notification of operation obsolescence is 247 put in place to mitigate the effects of design and 248 implementation mistakes, and to allow protocol development to 249 adapt to unexpected changes in the pace of implementation. Even 250 if an operation is marked OBSOLESCENT in a given minor version, 251 it may end up not being marked MANDATORY TO NOT implement in the 252 next minor version. In unusual circumstances, it might not be 253 marked OBSOLESCENT in a subsequent minor version, and never 254 become MANDATORY TO NOT implement. 256 12. Minor versions may downgrade features from REQUIRED to 257 RECOMMENDED, from RECOMMENDED to OPTIONAL, or from OPTIONAL to 258 MANDATORY TO NOT implement. Also, if a feature was marked as 259 OBSOLESCENT in the prior minor version, it may be downgraded 260 from REQUIRED to OPTIONAL from RECOMMENDED to MANDATORY TO NOT 261 implement, or from REQUIRED to MANDATORY TO NOT implement. 263 13. Minor versions may upgrade features from OPTIONAL to 264 RECOMMENDED, or RECOMMENDED to REQUIRED. Also, if a feature was 265 marked as OBSOLESCENT in the prior minor version, it may be 266 upgraded to not be OBSOLESCENT. 268 14. A client and server that support minor version X SHOULD support 269 minor versions 0 through X-1 as well. 271 15. Except for infrastructural changes, a minor version must not 272 introduce REQUIRED new features. 274 This rule allows for the introduction of new functionality and 275 forces the use of implementation experience before designating a 276 feature as REQUIRED. On the other hand, some classes of 277 features are infrastructural and have broad effects. Allowing 278 infrastructural features to be RECOMMENDED or OPTIONAL 279 complicates implementation of the minor version. 281 16. A client MUST NOT attempt to use a stateid, filehandle, or 282 similar returned object from the COMPOUND procedure with minor 283 version X for another COMPOUND procedure with minor version Y, 284 where X != Y. 286 5. Extensions within Minor Versions 288 An important goal of this document is to enable extensions to be made 289 to the set of features included in an existing minor version, without 290 the overhead attendant upon the creation of an entirely new minor 291 version. 293 5.1. Feature Specification Documents 295 Each such extension will be in the form of a working-group standards- 296 track document which defines a new optional feature. The definition 297 of the new feature may include one or more "feature elements" which 298 add to the existing XDR in ways already discussed in connection with 299 the creation of new minor versions. Other sorts of XDR modification 300 are not allowed. Feature elements include new operations, callbacks, 301 attributes, and enumeration values. The functionality of some 302 existing operations may be extended by the addition of new flags bits 303 in existing flag words and new cases in existing switched unions. 304 New error codes may be added but the set of valid error codes to be 305 returned by an operation is fixed, except that existing operations 306 may return new errors to respond to situations that only arise when 307 previously unused flag bits are set or when extensions to a switched 308 union are used. 310 Such an additional feature will become, for all intents and purposes, 311 part of the current NFSv4 minor version upon publication of the 312 description as a Proposed Standard, enabling such extensions to be 313 used by new client and server implementations without, as previously 314 required, a change in the value of the minor version field within the 315 COMPOUND operation. 317 The working group has two occasions to make sure that such features 318 are appropriate ones: 320 o At the time the feature definition document becomes a working 321 group document, the working group needs to determine, in addition 322 to the feature's general compatibility with NFSv4, that the XDR 323 assignments (i.e., additional values for operation callback and 324 attribute numbers, and for new flags and switch values to be added 325 to existing operations) associated with the new feature are 326 complete and do not conflict with those in the existing protocol 327 or those currently under development. 329 o At the time the working group document is complete, the working 330 group, in addition to normal document review, can and should look 331 at what prototype implementations of the feature have been done 332 and use that information to determine the work-ability and 333 maturity of the feature. 335 Such feature definition documents would contain a number of items, 336 following the pattern of the NFSv4.2 specification. The only 337 difference would be that while the NFSv4.2 specification defines a 338 number of features to be incorporated in NFSv4.2, the feature 339 definition documents would each define a single feature. 341 In addition to a general explanation of the feature in question, the 342 items to be included in such feature definition documents would be: 344 o Description of new operations (corresponding to Sections 16 and 17 345 of [NFSv42]). 347 o Description of any modified operations (corresponding to 348 Section 15 of [NFSv42]). 350 o Description of new attributes (corresponding to Section 13 of 351 [NFSv42]). 353 o Description of any added error codes (corresponding to 354 Section 12.1 of [NFSv42]). 356 o A summary description of all changes made by this feature to the 357 XDR definition of the protocol, including operation codes, 358 attribute numbers, added flag bits and enumeration values, and 359 request and response structures for new operations together with 360 the other XDR extensions needed to support them. 362 o A listing giving the valid errors for each new operation and 363 callback (corresponds to Sections 12.2 and 12.3 of [NFSv42]). 365 o A table giving for each new feature element its status (always 366 OPTIONAL), and its relationship to the feature being described 367 (i.e., REQUIRED for every implementation of the feature, or 368 OPTIONAL in the presence of the feature). This would be similar 369 to the material in Section 14 of [NFSv42] but it is restricted to 370 a single feature and expanded in scope to include all feature 371 elements. 373 o All of the Sections required for RFC publication, such as 374 "Security Considerations", "IANA considerations", etc. 376 Addition of features to an existing minor version will take advantage 377 of the existing NFSv4 infrastructure that allows optional features to 378 be added to new minor versions, but without in this case requiring 379 any change in the minor version number. Adding features in this way 380 will enable compatibility with existing clients and servers, who may 381 be unaware of the new feature. In particular: 383 o Existing server implementations will return NFS4ERR_NOTSUPP or 384 NFS4ERR_OP_ILLEGAL in response to any use of a new operation, 385 allowing the client to determine that the requested operation (and 386 potentially the feature in question) is not supported by the 387 server. 389 o Clients can determine whether particular new attributes are 390 supported by a given server by examining the value returned when 391 the supported_attr attribute is interrogated. 393 o New callbacks will only be sent to clients that have used the new 394 features associated with them, allowing existing clients to be 395 unaware of their existence. 397 o Existing server implementations that do not recognize new flag 398 bits will return NFS4ERR_INVAL, enabling the client to determine 399 that the new flag value is not supported by the server. 401 o Existing server implementations that do not recognize the new arm 402 of a switched union will return NFS4ERR_INVAL or 403 NFS4ERR_UNION_NOTSUPP, enabling the client to determine that the 404 the new union arm is not supported by the server. 406 o Error values returned to the client for all requests that do not 407 use new features will only be those previously allowed. Only when 408 the client uses a new feature will a previously invalid error 409 value be returned. 411 Given that some existing servers may have XDR parsing implementations 412 that cannot easily accommodate previously unknown operations or 413 switched union arms, clients should carefully determine whether 414 particular features are supported by the server before proceeding to 415 use them and need to be prepared to treat NFS4ERR_BADXDR as 416 indicating non-support of a new operation or switched union arm where 417 server support for a particular feature is being tested. 419 5.2. Additional Informational Documents 421 Additional documents will be required from time to time. The purpose 422 of these documents will be to organize existing material so that an 423 implementer will not have to scan a large set of feature definition 424 document or minor version specifications to find information being 425 sought. 427 The frequency of updates for such documents will be affected by 428 implementer needs and the ability to easily generate such documents, 429 preferably by automated means. These documents will be informational 430 documents whose purpose is to simplify use of the standards-track 431 documents. Some desirable elements would include: 433 o An updated XDR for the protocol as a whole including feature 434 elements from all features and minor versions accepted as Proposed 435 Standards. 437 o A consolidated list of XDR assignments of values (e.g., operation 438 codes, attribute numbers, error codes, new flag bits, enumeration 439 extensions) for all features under development (i.e., accepted as 440 working-group standards-track documents but not yet published or 441 abandoned). 443 o A list of all feature definition documents that have been approved 444 as working group documents but have not yet been approved as 445 Proposed Standards. 447 o A table mapping operations and callbacks to the most recent 448 document containing a description of that operation. 450 o A table mapping attributes to the most recent document containing 451 a description of that attribute. 453 o A table giving, for each operation in the protocol, the errors 454 that may validly be returned for that operation. If possible, it 455 would be desirable to give, as does [RFC5661], the operations 456 which may validly return each particular error. 458 o A table giving for each operation, callback, and attribute and for 459 each feature element in a published extension giving its status 460 OPTIONAL, REQUIRED, RECOMMENDED, MANDATORY to NOT implement), and 461 its relationship to the feature which allows its inclusion (i.e., 462 REQUIRED for every implementation of the feature, or OPTIONAL in 463 the presence of the feature). This would be similar to the 464 material in Section 14 of [NFSv42], expanded in scope to include 465 all feature elements, and updated to include all published 466 features that are part of the current NFSv4 minor version, at the 467 date of publication. 469 The informational documents described above are desirable, given that 470 minor versions beyond NFSv4.1 are not fully described in a single 471 document. Instead of a single document describing a minor version, 472 there will be a number and that number can be expected to grow, as 473 protocol development continues. 475 5.3. Relationship Between Minor Versioning and Extensions within a 476 Minor Version 478 Extensibility of minor version are governed by the following rules: 480 o Minor versions zero and one are not extensible. Each has a fixed 481 set of optional features as described in [RFC3530bis] and 482 [RFC5661]. 484 o Minor versions beyond one are presumed extensible as discussed 485 herein. However, any statement within the minor version 486 specification disallowing extension will cause that minor version 487 to be considered non-extensible. 489 o No new feature may be added to a minor version may be made once 490 the specification document document for a subsequent minor version 491 becomes a working group standards-track document. 493 Even when a minor version is non-extensible, or when a previous minor 494 version is closed to further extension, the features that it contains 495 are still subject to updates to effect protocol corrections. In many 496 cases, making an XDR change, in the form of an extension will be the 497 best way of correcting the issue. See Section 6 for details. 499 While making minor versions extensible will decrease the frequency of 500 new minor versions, it will not eliminate the need for them. In 501 particular: 503 o A new minor version will be required for any change in the status 504 of a feature element (i.e., an operation, callback, attribute, 505 added flag or switch case). For example, changes which make 506 feature elements Recommended, Required or Mandatory to Not 507 Implement will require a minor version. 509 o Any incompatible semantic change in the required or allowed 510 processing of an existing operation or attribute will require a 511 minor version. 513 o Any change that extends the set of errors returned that an 514 existing operation, with the exception noted above. New errors 515 may be added when the conditions that give rise to these new 516 errors cannot arise as long as new flag bits or switched union 517 arms are not used. I.e., when it is clear that existing client 518 cannot receive these errors. 520 o Any change in the mapping of feature elements to features will 521 require a minor version. For example, if a feature is to be split 522 into two separate features clients would no longer be able to 523 infer support for one operation from support for the other, in the 524 same way that had been done previously, invalidating logic in 525 existing clients. 527 6. Correction of Existing Minor Versions and Features 529 The possibility always exists that there will be a need to correct an 530 existing feature in some way, after the acceptance of that feature, 531 or a minor version containing it, as a Proposed Standard. While the 532 working group can reduce the probability of such situations arising 533 by waiting for running code before considering a feature as done, it 534 cannot reduce the probability to zero. As features are used more 535 extensively and interact with other features, previously unseen flaws 536 may be discovered and will need to be corrected. 538 Such corrections are best done in a bis document updating the RFC 539 defining the relevant feature definition document or minor version 540 specification. In making such correction, the working will have to 541 carefully consider how to assure interoperability with older clients 542 and servers. 544 Often, corrections can be done without changing the protocol XDR. 545 However, incompatible changes in server or client behavior should not 546 be mandated in order to avoid XDR changes. When XDR changes are 547 necessary as part of correcting a flaw, these should be done in a 548 manner similar to that used when implementing new minor versions or 549 features within them. In particular, 551 o Existing XDR structure may not be modified or deleted. 553 o XDR extensions to may be used to correct existing protocol 554 facilities in a manner similar to those used to add additional 555 OPTIONAL features. Such corrections may be done in an otherwise 556 non-extensible minor version, if the working group judges it 557 appropriate. 559 o When a correction is made to an OPTIONAL feature, the result is 560 similar to a situation in which there are two independent OPTIONAL 561 features. A server may choose to implement either or both. 563 o When a correction is made to a MANDATORY feature, the situation 564 becomes one in which neither the old nor the new new version of 565 the feature is MANDATORY. Instead, it is MANDATORY that a server 566 support at least one of the two, while each is individually 567 OPTIONAL. Although use of the corrected version is ultimately 568 better, it is not RECOMMENDED, since the choice of which version 569 to support if only one is supported will depend on the needs of 570 clients, which may be slow to adopt the updated version. 572 o When a correction is made to a RECOMMENDED feature, the situation 573 is similar to the case of a MANDATORY feature. Neither version is 574 RECOMMENDED, Neither the old nor the new version of the feature is 575 RECOMMENDED. Instead, it is RECOMMENDED that a server support at 576 least one of the two, while each is individually OPTIONAL. 578 o In all of the cases above, it is appropriate that the old version 579 of the feature, be considered OBSOLESCENT, with the expectation 580 that the working group might, in a later minor version, decide 581 that the older version is to become MANDATORY to NOT implement. 583 By doing things this way, the protocol with the XDR modification can 584 accommodate clients and servers that support either the corrected or 585 the uncorrected version of the protocol and also clients and servers 586 aware of and capable of supporting both alternatives. 588 o A client that supports only the earlier version of the feature 589 (i.e., an older unfixed client) can determine whether the server 590 it is connecting to supports the older version of feature. It is 591 capable of interoperating with older servers that support only the 592 unfixed protocol as well as ones that support both versions. 594 o A client that supports only the corrected version of the feature 595 (i.e., a new or updated client) can determine whether the server 596 it is connecting to supports the newer version of the feature. It 597 is capable of interoperating with newer servers that support only 598 the updated feature as well as ones that support both versions. 600 o A client that supports both the older and newer version of the 601 feature can determine which version of the particular feature is 602 supported by the server it is working with. 604 o A server that supports only the earlier version of the feature 605 (i.e., an older unfixed server) can only successfully interoperate 606 with older clients. However newer clients can easily determine 607 that the feature cannot be used on that server. 609 o A server that supports only the newer version of the feature 610 (i.e., a new or updated server) can only successfully interoperate 611 with newer clients. However, older clients can easily determine 612 that the feature cannot be used on that server. In the case of 613 OPTIONAL features, clients can be expected to deal with non- 614 support of that particular feature. 616 o A server that supports both the older and newer versions of the 617 feature can interopt with all client variants. 619 By using extensions in this manner, the protocol creates clear path 620 which preserves the functioning of existing clients and servers and 621 allowing client and server implementers to adopt the new version of 622 the feature at a reasonable pace. 624 7. Security Considerations 626 There are no security considerations in this document. 628 8. IANA Considerations 630 There are no IANA considerations in this document. 632 9. References 634 9.1. Normative References 636 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 637 Requirement Levels", March 1997. 639 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 640 Beame, C., Eisler, M., and D. Noveck, "Network File System 641 (NFS) version 4 Protocol", RFC 3530, April 2003. 643 [RFC3530bis] 644 Haynes, T. and D. Noveck, "Network File System (NFS) 645 version 4 Protocol", draft-ietf-nfsv4-rfc3530bis-33 (Work 646 In Progress), April 2014. 648 [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File 649 System (NFS) Version 4 Minor Version 1 Protocol", RFC 650 5661, January 2010. 652 9.2. Informative References 654 [NFSv42] Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- 655 nfsv4-minorversion2-27 (Work In Progress), September 2014. 657 Appendix A. Acknowledgments 659 Appendix B. RFC Editor Notes 661 [RFC Editor: please remove this section prior to publishing this 662 document as an RFC] 664 [RFC Editor: prior to publishing this document as an RFC, please 665 replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the 666 RFC number of this document] 668 Authors' Addresses 670 Thomas Haynes 671 Primary Data, Inc. 672 4300 El Camino Real Ste 100 673 Los Altos, CA 94022 674 USA 676 Phone: +1 408 215 1519 677 Email: thomas.haynes@primarydata.com 679 David Noveck 680 Dell 681 300 Innovative Way 682 Nashua, NH 03062 683 US 685 Phone: +1 781 572 8038 686 Email: dave_noveck@dell.com