DLEP Credit-Based Flow Control Messages and Data Items
draft-ietf-manet-dlep-credit-flow-control-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-03-26
|
13 | Ronald in 't Velt | Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, … Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control Document History 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? This document is part of a cluster of four which together specify a credit-base flow control extension to the Dynamic Link Exchange Protocol (DLEP, RFC8175). The companion documents are: - draft-ietf-manet-dlep-traffic-classification, - draft-ietf-manet-dlep-da-credit-extension, - draft-ietf-manet-dlep-ether-credit-extension. There was strong consensus early on in the WG that it would be beneficial to have a Flow Control extension to DLEP that is more sophisticated than the Control-Plane-based Pause approach specified in RFC 8651. Most of the remaining discussion revolved around how to best structure and modularize the specification. (See answer to question 2). 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There was discussion (rather than controversy) on how the functional elements of credit-based flow control should be distributed over separate documents. Between IETF 100 and IETF 103, the specification went from being contained in a single document to being broken down into four separate ones. Traffic Classification was split off, because it is considered a generic mechanism that can be useful for other purposes than flow control alone. draft-ietf-manet-dlep-da-credit-extension was the original monolithic specification, that was reduced to merely defining the Extension Type value after Message and Data Item definitions were moved to draft-ietf-manet-dlep-credit-flow-control and draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of Ethernet frames instead of DS fields in IP packets as an alternative way of distinguishing flows made it necessary to define an additional Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The motivation for having both Extension Type values in different documents is to allow implementers of DLEP to specify exactly which extensions they support by means of RFC numbers. The TSV ART reviewer commented that draft-ietf-manet-dlep-da-credit-extension was very light on content and strongly suggested to merge this document into draft-ietf-manet-dlep-traffic-classification. (At the time, draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to TSV ART early review). The WG considered this suggestion around IETF 113 and again at IETF 115, but decided that reasons for the four-way split were still valid and to therefore stick to that structure. 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)? This document's shepherd has no knowledge of existing implementations. Since this document (and its companions) describes an extension to DLEP (RFC 8175), a starting point for an implementation could be the open source DLEP library, to which David Wiggins (one of the authors of this document) was the main contributor: https://github.com/mit-ll/LL-DLEP . There has been some discussion on the mailing list on how to implement the router side of credit-based flow control (in Linux, specifically): https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/ Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. A TSV ART Early Review took place. Main concern was the split in three different documents. (See answer to question 2). Some additional issues have been resolved. 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. A RtgDir review still needs to take place. None of the other expert reviews mentioned (MIB Doctor, etc.) apply to this document. 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 does not contain a YANG module. 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, etc. This document contains no formal language. The shepherd has carefully reviewed this draft, as documented at https://mailarchive.ietf.org/arch/msg/manet/Knm_a-HXt_5i9xlRAnfp7jhLkds/ These comments have been resolved. Document Shepherd Checks 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? Shepherd has not identified any such issues. 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 document and its companion documents specify a more sophisticated and fine-grained flow control mechanism than the one defined in RFC 8651 (which is a Proposed Standard). Moreover, credit-based flow control is an explicit work item on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was not (and was criticized for that reason during IESG review). 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 statements at https://mailarchive.ietf.org/arch/msg/manet/GZPzumdxzHMIGY_zcnT1milVz0w/ https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/ https://mailarchive.ietf.org/arch/msg/manet/RCZuga54SM4-lDkXJ5ETM-qUQP0/ A similar statement from Stan Ratliff is not available, because he passed away in October 2019, before the request for IPR statements was posted to the MANET WG mailing list. 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. Sadly, two of the authors, Stan Ratliff and David Wiggins, are no longer with us. 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 document adheres to the naming convention for Internet-Drafts. The document contains all the required sections. 15. Should any informative references be normative or vice-versa? The shepherd believes the references to be categorized correctly. 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 (or RFC-to-be, in one case). 17. Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them. There are no downward normative 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? This document has a normative reference to one of its companion documents (see answer to question 1), draft-ietf-manet-dlep-traffic-classification, which is assumed to go through post-WG review and processing steps alongside it. 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 (together with its companion documents, see answer to question 1) defines an extension to RFC 8175, in the same way as RFC 8629, RFC 8651, RFC 8703 and RFC 8757 do, but it does not change the status of RFC 8175 or any other RFC. 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 adds two entries to the existing DLEP Message Registry named "Message Values" and five entries to the existing DLEP Data Item Registry named "Data Item Type Values". Additions to both existing registries are in ranges with a "Specification Required" policy. This document does not create new IANA registries. The requested actions in the IANA Considerations Section (section 5) have been found to be consistent with the body of the document. 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 does not create new IANA registries. |
2024-03-16
|
13 | Ronald in 't Velt | WORK IN PROGRESS Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, … WORK IN PROGRESS Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control Document History 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? This document is part of a cluster of four which together specify a credit-base flow control extension to the Dynamic Link Exchange Protocol (DLEP, RFC8175). The companion documents are: - draft-ietf-manet-dlep-traffic-classification, - draft-ietf-manet-dlep-da-credit-extension, - draft-ietf-manet-dlep-ether-credit-extension. There was strong consensus early on in the WG that it would be beneficial to have a Flow Control extension to DLEP that is more sophisticated than the Control-Plane-based Pause approach specified in RFC 8651. Most of the remaining discussion revolved around how to best structure and modularize the specification. (See answer to question 2). 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There was discussion (rather than controversy) on how the functional elements of credit-based flow control should be distributed over separate documents. Between IETF 100 and IETF 103, the specification went from being contained in a single document to being broken down into four separate ones. Traffic Classification was split off, because it is considered a generic mechanism that can be useful for other purposes than flow control alone. draft-ietf-manet-dlep-da-credit-extension was the original monolithic specification, that was reduced to merely defining the Extension Type value after Message and Data Item definitions were moved to draft-ietf-manet-dlep-credit-flow-control and draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of Ethernet frames instead of DS fields in IP packets as an alternative way of distinguishing flows made it necessary to define an additional Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The motivation for having both Extension Type values in different documents is to allow implementers of DLEP to specify exactly which extensions they support by means of RFC numbers. The TSV ART reviewer commented that draft-ietf-manet-dlep-da-credit-extension was very light on content and strongly suggested to merge this document into draft-ietf-manet-dlep-traffic-classification. (At the time, draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to TSV ART early review). The WG considered this suggestion around IETF 113 and again at IETF 115, but decided that reasons for the four-way split were still valid and to therefore stick to that structure. 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)? This document's shepherd has no knowledge of existing implementations. Since this document (and its companions) describes an extension to DLEP (RFC 8175), a starting point for an implementation could be the open source DLEP library, to which David Wiggins (one of the authors of this document) was the main contributor: https://github.com/mit-ll/LL-DLEP . There has been some discussion on the mailing list on how to implement the router side of credit-based flow control (in Linux, specifically): https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/ Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. A TSV ART Early Review took place. Main concern was the split in three different documents. (See answer to question 2). Some lesser issue are being resolved. 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. A RtgDir review still needs to take place. None of the other expert reviews mentioned (MIB Doctor, etc.) apply to this document. 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 does not contain a YANG module. 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, etc. This document contains no formal language. The shepherd has carefully reviewed this draft, as documented at https://mailarchive.ietf.org/arch/msg/manet/Knm_a-HXt_5i9xlRAnfp7jhLkds/ (**as WG participant**) These comments have been resolved. Document Shepherd Checks 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? Shepherd has not identified any such issues. 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 document and its companion documents specify a more sophisticated and fine-grained flow control mechanism than the one defined in RFC 8651 (which is a Proposed Standard). Moreover, credit-based flow control is an explicit work item on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was not (and was criticized for that reason during IESG review). 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 statements at https://mailarchive.ietf.org/arch/msg/manet/GZPzumdxzHMIGY_zcnT1milVz0w/ https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/ https://mailarchive.ietf.org/arch/msg/manet/RCZuga54SM4-lDkXJ5ETM-qUQP0/ A similar statement from Stan Ratliff is not available, because he passed away in October 2019, before the request for IPR statements was posted to the MANET WG mailing list. 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. Sadly, two of the authors, Stan Ratliff and David Wiggins, are no longer with us. 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 document adheres to the naming convention for Internet-Drafts. The document contains all the required sections. 15. Should any informative references be normative or vice-versa? The shepherd believes the references to be categorized correctly. 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 (or RFC-to-be, in one case). 17. Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them. There are no downward normative 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? This document has a normative reference to one of its companion documents (see answer to question 1), draft-ietf-manet-dlep-traffic-classification, which is assumed to go through post-WG review and processing steps alongside it. 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 (together with its companion documents, see answer to question 1) defines an extension to RFC 8175, in the same way as RFC 8629, RFC 8651, RFC 8703 and RFC 8757 do, but it does not change the status of RFC 8175 or any other RFC. 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 adds two entries to the existing DLEP Message Registry named "Message Values" and five entries to the existing DLEP Data Item Registry named "Data Item Type Values". Additions to both existing registries are in ranges with a "Specification Required" policy. This document does not create new IANA registries. The requested actions in the IANA Considerations Section (section 5) have been found to be consistent with the body of the document. 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 does not create new IANA registries. WORK IN PROGRESS |
2024-03-04
|
13 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-13.txt |
2024-03-04
|
13 | Tess Hyden | Posted submission manually |
2024-01-12
|
12 | (System) | Document has expired |
2023-12-20
|
12 | Ronald in 't Velt | WORK IN PROGRESS Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, … WORK IN PROGRESS Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control Document History 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? This document is part of a cluster of four which together specify a credit-base flow control extension to the Dynamic Link Exchange Protocol (DLEP, RFC8175). The companion documents are: - draft-ietf-manet-dlep-traffic-classification, - draft-ietf-manet-dlep-da-credit-extension, - draft-ietf-manet-dlep-ether-credit-extension. There was strong consensus early on in the WG that it would be beneficial to have a Flow Control extension to DLEP that is more sophisticated than the Control-Plane-based Pause approach specified in RFC 8651. Most of the remaining discussion revolved around how to best structure and modularize the specification. (See answer to question 2). 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There was discussion (rather than controversy) on how the functional elements of credit-based flow control should be distributed over separate documents. Between IETF 100 and IETF 103, the specification went from being contained in a single document to being broken down into four separate ones. Traffic Classification was split off, because it is considered a generic mechanism that can be useful for other purposes than flow control alone. draft-ietf-manet-dlep-da-credit-extension was the original monolithic specification, that was reduced to merely defining the Extension Type value after Message and Data Item definitions were moved to draft-ietf-manet-dlep-credit-flow-control and draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of Ethernet frames instead of DS fields in IP packets as an alternative way of distinguishing flows made it necessary to define an additional Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The motivation for having both Extension Type values in different documents is to allow implementers of DLEP to specify exactly which extensions they support by means of RFC numbers. The TSV ART reviewer commented that draft-ietf-manet-dlep-da-credit-extension was very light on content and strongly suggested to merge this document into draft-ietf-manet-dlep-traffic-classification. (At the time, draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to TSV ART early review). The WG considered this suggestion around IETF 113 and again at IETF 115, but decided that reasons for the four-way split were still valid and to therefore stick to that structure. 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)? This document's shepherd has no knowledge of existing implementations. Since this document (and its companions) describes an extension to DLEP (RFC 8175), a starting point for an implementation could be the open source DLEP library, to which David Wiggins (one of the authors of this document) is the main contributor: https://github.com/mit-ll/LL-DLEP . There has been some discussion on the mailing list on how to implement the router side of credit-based flow control (in Linux, specifically): https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/ Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. A TSV ART Early Review took place. Main concern was the split in three different documents. (See answer to question 2). Some lesser issue are being resolved. 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. A RtgDir review still needs to take place. None of the other expert reviews mentioned (MIB Doctor, etc.) apply to this document. 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 does not contain a YANG module. 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, etc. This document contains no formal language. The shepherd has carefully reviewed this draft, as documented at https://mailarchive.ietf.org/arch/msg/manet/Knm_a-HXt_5i9xlRAnfp7jhLkds/ (**as WG participant**) These comments have been resolved. Document Shepherd Checks 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? Shepherd has not identified any such issues. 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 document and its companion documents specify a more sophisticated and fine-grained flow control mechanism than the one defined in RFC 8651 (which is a Proposed Standard). Moreover, credit-based flow control is an explicit work item on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was not (and was criticized for that reason during IESG review). 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/manet/GZPzumdxzHMIGY_zcnT1milVz0w/ https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/ (IPR statement by Bow-Nan Cheng is still pending, but his affiliation is the same as that of David Wiggins; it therefore seems unlikely that the former is aware of IPR of which the latter is not aware). 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. Sadly, Stan Ratliff is no longer with us. 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 document adheres to the naming convention for Internet-Drafts. The document contains all the required sections. 15. Should any informative references be normative or vice-versa? The shepherd believes the references to be categorized correctly. 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 (or RFC-to-be, in one case). 17. Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them. There are no downward normative 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? This document has a normative reference to one of its companion documents (see answer to question 1), draft-ietf-manet-dlep-traffic-classification, which is assumed to go through post-WG review and processing steps alongside it. 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 (together with its companion documents, see answer to question 1) defines an extension to RFC 8175, in the same way as RFC 8629, RFC 8651, RFC 8703 and RFC 8757 do, but it does not change the status of RFC 8175 or any other RFC. 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 adds two entries to the existing DLEP Message Registry named "Message Values" and five entries to the existing DLEP Data Item Registry named "Data Item Type Values". Additions to both existing registries are in ranges with a "Specification Required" policy. This document does not create new IANA registries. The requested actions in the IANA Considerations Section (section 5) have been found to be consistent with the body of the document. 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 does not create new IANA registries. WORK IN PROGRESS |
2023-11-29
|
12 | Ronald in 't Velt | WORK IN PROGRESS Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, … WORK IN PROGRESS Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control Document History 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? This document is part of a cluster of four which together specify a credit-base flow control extension to the Dynamic Link Exchange Protocol (DLEP, RFC8175). The companion documents are: - draft-ietf-manet-dlep-traffic-classification, - draft-ietf-manet-dlep-da-credit-extension, - draft-ietf-manet-dlep-ether-credit-extension. There was strong consensus early on in the WG that it would be beneficial to have a Flow Control extension to DLEP that is more sophisticated than the Control-Plane-based Pause approach specified in RFC 8651. Most of the remaining discussion revolved around how to best structure and modularize the specification. (See answer to question 2). 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There was discussion (rather than controversy) on how the functional elements of credit-based flow control should be distributed over separate documents. Between IETF 100 and IETF 103, the specification went from being contained in a single document to being broken down into four separate ones. Traffic Classification was split off, because it is considered a generic mechanism that can be useful for other purposes than flow control alone. draft-ietf-manet-dlep-da-credit-extension was the original monolithic specification, that was reduced to merely defining the Extension Type value after Message and Data Item definitions were moved to draft-ietf-manet-dlep-credit-flow-control and draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of Ethernet frames instead of DS fields in IP packets as an alternative way of distinguishing flows made it necessary to define an additional Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The motivation for having both Extension Type values in different documents is to allow implementers of DLEP to specify exactly which extensions they support by means of RFC numbers. The TSV ART reviewer commented that draft-ietf-manet-dlep-da-credit-extension was very light on content and strongly suggested to merge this document into draft-ietf-manet-dlep-da-credit-extension. (At the time, draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to TSV ART early review). The WG considered this suggestion around IETF 113 and again at IETF 115, but decided that reasons for the four-way split were still valid and to therefore stick to that structure. 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)? This document's shepherd has no knowledge of existing implementations. Since this document (and its companions) describes an extension to DLEP (RFC 8175), a starting point for an implementation could be the open source DLEP library, to which David Wiggins (one of the authors of this document) is the main contributor: https://github.com/mit-ll/LL-DLEP . There has been some discussion on the mailing list on how to implement the router side of credit-based flow control (in Linux, specifically): https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/ Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. A TSV ART Early Review took place. Main concern was the split in three different documents. (See answer to question 2). Some lesser issue are being resolved. 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. A RtgDir review still needs to take place. None of the other expert reviews mentioned (MIB Doctor, etc.) apply to this document. 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 does not contain a YANG module. 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, etc. This document contains no formal language. The shepherd has carefully reviewed this draft, as documented at https://mailarchive.ietf.org/arch/msg/manet/Knm_a-HXt_5i9xlRAnfp7jhLkds/ (**as WG participant**) These comments have been resolved. Document Shepherd Checks 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? Shepherd has not identified any such issues. 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 document and its companion documents specify a more sophisticated and fine-grained flow control mechanism than the one defined in RFC 8651 (which is a Proposed Standard). Moreover, credit-based flow control is an explicit work item on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was not (and was criticized for that reason during IESG review). 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/manet/GZPzumdxzHMIGY_zcnT1milVz0w/ https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/ (IPR statement by Bow-Nan Cheng is still pending, but his affiliation is the same as that of David Wiggins; it therefore seems unlikely that the former is aware of IPR of which the latter is not aware). 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. Sadly, Stan Ratliff is no longer with us. 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 document adheres to the naming convention for Internet-Drafts. The document contains all the required sections. 15. Should any informative references be normative or vice-versa? The shepherd believes the references to be categorized correctly. 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 (or RFC-to-be, in one case). 17. Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them. There are no downward normative 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? This document has a normative reference to one of its companion documents (see answer to question 1), draft-ietf-manet-dlep-traffic-classification, which is assumed to go through post-WG review and processing steps alongside it. 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 (together with its companion documents, see answer to question 1) defines an extension to RFC 8175, in the same way as RFC 8629, RFC 8651, RFC 8703 and RFC 8757 do, but it does not change the status of RFC 8175 or any other RFC. 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 adds two entries to the existing DLEP Message Registry named "Message Values" and five entries to the existing DLEP Data Item Registry named "Data Item Type Values". Additions to both existing registries are in ranges with a "Specification Required" policy. This document does not create new IANA registries. The requested actions in the IANA Considerations Section (section 5) have been found to be consistent with the body of the document. 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 does not create new IANA registries. WORK IN PROGRESS |
2023-07-25
|
12 | Ronald in 't Velt | WORK IN PROGRESS Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control Document History 1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, … WORK IN PROGRESS Shepherd writeup on draft-ietf-manet-dlep-credit-flow-control Document History 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? This document is part of a cluster of four which together specify a credit-base flow control extension to the Dynamic Link Exchange Protocol (DLEP, RFC8175). The companion documents are: - draft-ietf-manet-dlep-traffic-classification, - draft-ietf-manet-dlep-da-credit-extension, - draft-ietf-manet-dlep-ether-credit-extension. There was strong consensus early on in the WG that it would be beneficial to have a Flow Control extension to DLEP that is more sophisticated than the Control-Plane-based Pause approach specified in RFC 8651. Most of the remaining discussion revolved around how to best structure and modularize the specification. (See answer to question 2). 2. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? There was discussion (rather than controversy) on how the functional elements of credit-based flow control should be distributed over separate documents. Between IETF 100 and IETF 103, the specification went from being contained in a single document to being broken down into four separate ones. Traffic Classification was split off, because it is considered a generic mechanism that can be useful for other purposes than flow control alone. draft-ietf-manet-dlep-da-credit-extension was the original monolithic specification, that was reduced to merely defining the Extension Type value after Message and Data Item definitions were moved to draft-ietf-manet-dlep-credit-flow-control and draft-ietf-manet-dlep-traffic-classification. Using IEEE 802.1Q fields of Ethernet frames instead of DS fields in IP packets as an alternative way of distinguishing flows made it necessary to define an additional Extension Type value in draft-ietf-manet-dlep-ether-credit-extension. The motivation for having both Extension Type values in different documents is to allow implementers of DLEP to specify exactly which extensions they support by means of RFC numbers. The TSV ART reviewer commented that draft-ietf-manet-dlep-da-credit-extension was very light on content and strongly suggested to merge this document into draft-ietf-manet-dlep-da-credit-extension. (At the time, draft-ietf-manet-dlep-ether-credit-extension had not yet been subjected to TSV ART early review). The WG considered this suggestion around IETF 113 and again at IETF 115, but decided that reasons for the four-way split were still valid and to therefore stick to that structure. 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)? This document's shepherd has no knowledge of existing implementations. Since this document (and its companions) describes an extension to DLEP (RFC 8175), a starting point for an implementation could be the open source DLEP library, to which David Wiggins (one of the authors of this document) is the main contributor: https://github.com/mit-ll/LL-DLEP . There has been some discussion on the mailing list on how to implement the router side of credit-based flow control (in Linux, specifically): https://mailarchive.ietf.org/arch/msg/manet/MPTLhKgaljq1BRdjE_dEk9x1YhI/ Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. A TSV ART Early Review took place. Main concern was the split in three different documents. (See answer to question 2). Some lesser issue are being resolved. 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. A RtgDir review still needs to take place. None of the other expert reviews mentioned (MIB Doctor, etc.) apply to this document. 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 does not contain a YANG module. 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, etc. This document contains no formal language. The shepherd has carefully reviewed this draft, as documented at https://mailarchive.ietf.org/arch/msg/manet/Knm_a-HXt_5i9xlRAnfp7jhLkds/ (**as WG participant**) These comments have been resolved. Document Shepherd Checks 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? Shepherd has not identified any such issues. 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 document and its companion documents specify a more sophisticated and fine-grained flow control mechanism than the one defined in RFC 8651 (which is a Proposed Standard). Credit-based flow control is an explicit work item on the WG's charter, whereas Control-Plane-Based Pause (RFC 8651) was not (and was criticized for that reason during IESG review). 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/manet/GZPzumdxzHMIGY_zcnT1milVz0w/ https://mailarchive.ietf.org/arch/msg/manet/itiAXwQ7dQaerG43rTH6SXNiDdY/ (IPR statement by Bow-Nan Cheng is still pending, but his affiliation is the same as that of David Wiggins; it therefore seems unlikely that the former is aware of IPR of which the latter is not aware). 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 document adheres to the naming convention for Internet-Drafts. The document contains all the required sections. 15. Should any informative references be normative or vice-versa? The shepherd believes the references to be categorized correctly. 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 (or RFC-to-be, in one case). 17. Are there any normative downward references (see RFC 3967, BCP 97)? If so, list them. There are no downward normative 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? This document has a normative reference to one of its companion documents (see answer to question 1), draft-ietf-manet-dlep-traffic-classification, which is assumed to go through post-WG review and processing steps alongside it. 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 (together with its companion documents, see answer to question 1) defines an extension to RFC 8175, in the same way as RFC 8629, RFC 8651, RFC and RFC 8757 do, but it does not change the status of RFC 8175 or any other RFC. 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 adds two entries to the existing DLEP Message Registry named "Message Values" and five entries to the existing DLEP Data Item Registry named "Data Item Type Values". Additions to both existing registries are in ranges with a "Specification Required" policy. This document does not create new IANA registries. The requested actions in the IANA Considerations Section (section 5) have been found to be consistent with the body of the document. 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 does not create new IANA registries. WORK IN PROGRESS |
2023-07-25
|
12 | Ronald in 't Velt | Notification list changed to ronald.intvelt@tno.nl because the document shepherd was set |
2023-07-25
|
12 | Ronald in 't Velt | Document shepherd changed to Ronald in 't Velt |
2023-07-11
|
12 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-12.txt |
2023-07-11
|
12 | Jenny Bui | Posted submission manually |
2023-01-30
|
11 | (System) | Document has expired |
2022-07-29
|
11 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-11.txt |
2022-07-29
|
11 | Jenny Bui | Posted submission manually |
2022-02-24
|
10 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-10.txt |
2022-02-24
|
10 | (System) | Posted submission manually |
2021-11-19
|
09 | David Black | Request for Early review by TSVART Completed: On the Right Track. Reviewer: David Black. Sent review to list. |
2021-10-30
|
09 | Ronald in 't Velt | Tag Awaiting Expert Review/Resolution of Issues Raised set. Tag Awaiting External Review/Resolution of Issues Raised cleared. |
2021-10-30
|
09 | Ronald in 't Velt | Under TSV-ART review |
2021-10-30
|
09 | Ronald in 't Velt | Tag Awaiting External Review/Resolution of Issues Raised set. |
2021-10-30
|
09 | Ronald in 't Velt | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2021-10-30
|
09 | Ronald in 't Velt | Changed consensus to Yes from Unknown |
2021-10-30
|
09 | Ronald in 't Velt | Intended Status changed to Proposed Standard from None |
2021-10-27
|
09 | Magnus Westerlund | Request for Early review by TSVART is assigned to David Black |
2021-10-27
|
09 | Magnus Westerlund | Request for Early review by TSVART is assigned to David Black |
2021-10-26
|
09 | Ronald in 't Velt | Requested Early review by TSVART |
2021-10-26
|
09 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-09.txt |
2021-10-26
|
09 | (System) | Posted submission manually |
2021-06-21
|
08 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-08.txt |
2021-06-21
|
08 | (System) | Posted submission manually |
2021-06-07
|
07 | (System) | Document has expired |
2020-12-04
|
07 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-07.txt |
2020-12-04
|
07 | (System) | Posted submission manually |
2020-06-03
|
06 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-06.txt |
2020-06-03
|
06 | (System) | Posted submission manually |
2020-05-22
|
05 | (System) | Document has expired |
2019-11-19
|
05 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-05.txt |
2019-11-19
|
05 | (System) | Posted submission manually |
2019-09-07
|
04 | (System) | Document has expired |
2019-03-11
|
04 | Justin Dean | Draft has been stable within the WG for some time. WG agreed to last call at IETF 103. |
2019-03-11
|
04 | Justin Dean | IETF WG state changed to In WG Last Call from WG Document |
2019-03-06
|
04 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-04.txt |
2019-03-06
|
04 | (System) | New version approved |
2019-03-06
|
04 | (System) | Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , Stan Ratliff , David Wiggins , Bow-Nan Cheng |
2019-03-06
|
04 | Lou Berger | Uploaded new revision |
2019-02-03
|
03 | (System) | Document has expired |
2018-08-02
|
03 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-03.txt |
2018-08-02
|
03 | (System) | New version approved |
2018-08-02
|
03 | (System) | Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , David Wiggins , Bow-Nan Cheng |
2018-08-02
|
03 | Lou Berger | Uploaded new revision |
2018-06-26
|
02 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-02.txt |
2018-06-26
|
02 | (System) | New version approved |
2018-06-26
|
02 | (System) | Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , David Wiggins , Bow-Nan Cheng |
2018-06-26
|
02 | Lou Berger | Uploaded new revision |
2018-06-15
|
01 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-01.txt |
2018-06-15
|
01 | (System) | New version approved |
2018-06-15
|
01 | (System) | Request for posting confirmation emailed to previous authors: manet-chairs@ietf.org, Lou Berger , David Wiggins , Bow-Nan Cheng |
2018-06-15
|
01 | Lou Berger | Uploaded new revision |
2018-05-14
|
00 | Lou Berger | New version available: draft-ietf-manet-dlep-credit-flow-control-00.txt |
2018-05-14
|
00 | (System) | WG -00 approved |
2018-05-01
|
00 | Lou Berger | Set submitter to "Lou Berger ", replaces to (none) and sent approval email to group chairs: manet-chairs@ietf.org |
2018-05-01
|
00 | Lou Berger | Uploaded new revision |