Delay-based Metric Extension for the Babel Routing Protocol
draft-ietf-babel-rtt-extension-04

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-babel-rtt-extension-04. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Babel Sub-TLV Types registry in the Babel Routing Protocol registry group located at:

https://www.iana.org/assignments/babel/

the existing early registration for:

Type: 3
Name: Timestamp

will be made permanent and its reference changed to [ RFC-to-be ].

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-10-11):

From: The IESG
To: IETF-Announce
CC: Donald Eastlake , andrew-ietf@liquid.tech, babel-chairs@ietf.org, babel@ietf.org, d3e3e3@gmail.com, draft-ietf-babel-rtt-extension@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Delay-based Metric Extension for the Babel Routing Protocol) to Proposed Standard


The IESG has received a request from the Babel routing protocol WG (babel) to
consider the following document: - 'Delay-based Metric Extension for the
Babel Routing Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-10-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines an extension to the Babel routing protocol that
  measures the round-trip time (RTT) between routers and makes it
  possible to prefer lower latency links over higher latency ones.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-babel-rtt-extension/



No IPR declarations have been submitted directly on this I-D.

1.Does the working group (WG) consensus represent the strong
concurrence of a few individuals, with others being silent, or did it
reach broad agreement?

  There is broad support for this draft in the WG.

2.Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

4. For protocol documents, are there existing implementations of the
contents of the document?

  Yes.

5. Does this document need review from other IETF working groups or
external organizations?

  No.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  No such formal review required.

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?

  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.

  No such formal language exists in this draft.

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. (See Shepherd's review here:
https://mailarchive.ietf.org/arch/msg/babel/5FDtAT-0y5gZ9w-t8MQhiwoulnw/
  all comments in which have been resolved.)

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?
https://trac.ietf.org/trac/iesg/wiki/ExpertTopics

  Nothing pops out as need special attention. The draft has had an
  early Routing Directorate review. See
https://datatracker.ietf.org/doc/review-ietf-babel-rtt-extension-03-rtgdir-early-halpern-2023-07-18/

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)?

  Standards Track as it updates Proposed Standard RFC 8966 and
  describes a protocol change that has been in successful use for
  several years.

12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed?

  Yes, see
https://mailarchive.ietf.org/arch/msg/babel/fqqucGWKpjtnK2prCBX60OHCyfI/
https://mailarchive.ietf.org/arch/msg/babel/o7nDNTn0cDWE96BT1snIKJ5GmCA/
https://mailarchive.ietf.org/arch/msg/babel/Bwt_0_YUw8lYis0owgN-ReB65nY/

13. If yes, summarize any discussion and conclusion regarding the
intellectual property rights (IPR) disclosures, including links to
relevant emails. If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  There was no discussion regarding intellectual property because no
  such IPR has been disclosed. There are 2 authors on the title page.

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.
https://www6.ietf.org/tools/idnits/

  The I-D nits tools complains about non-ASCII characters but these
  are all legitimate characters in names or the like. The Updates
  header on the title page should say 8966 rather than 8967 but
  this is expected to be fixed during resolution of AD/Directorate
  comments.

15. Should any informative references be normative or vice-versa?

  No. References are correctly classified as normative or informative.

16. List any normative references that are not freely available to
anyone.

  All normative references are standards track RFCs and so freely
  available.

17. Are there any normative downward references (see RFC 3967, BCP
97)?

  No.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

  No.

19. Will publication of this document change the status of any
existing RFCs?

  No.

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.

  Tht IANA Considerations for this document correctly only specify the
  assignment of a single code point from the already existing babel
  Sub-TLV Types registry. Since this is Expert Review, the type has
  already been assigned as shown in the document.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear?

  No IANA registries created.
 

1.Does the working group (WG) consensus represent the strong
concurrence of a few individuals, with others being silent, or did it
reach broad agreement?

  There is broad support for this draft in the WG.

2.Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

4. For protocol documents, are there existing implementations of the
contents of the document?

  Yes.

5. Does this document need review from other IETF working groups or
external organizations?

  No.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  No such formal review required.

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?

  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.

  No such formal language exists in this draft.

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. (See Shepherd's review here:
https://mailarchive.ietf.org/arch/msg/babel/5FDtAT-0y5gZ9w-t8MQhiwoulnw/
  all comments in which have been resolved.)

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?
https://trac.ietf.org/trac/iesg/wiki/ExpertTopics

  Nothing pops out as need special attention. The draft has had an
  early Routing Directorate review. See
https://datatracker.ietf.org/doc/review-ietf-babel-rtt-extension-03-rtgdir-early-halpern-2023-07-18/

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)?

  Standards Track as it updates Proposed Standard RFC 8966 and
  describes a protocol change that has been in successful use for
  several years.

12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed?

  Yes, see
https://mailarchive.ietf.org/arch/msg/babel/fqqucGWKpjtnK2prCBX60OHCyfI/
https://mailarchive.ietf.org/arch/msg/babel/o7nDNTn0cDWE96BT1snIKJ5GmCA/
https://mailarchive.ietf.org/arch/msg/babel/Bwt_0_YUw8lYis0owgN-ReB65nY/

13. If yes, summarize any discussion and conclusion regarding the
intellectual property rights (IPR) disclosures, including links to
relevant emails. If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  There was no discussion regarding intellectual property because no
  such IPR has been disclosed. There are 2 authors on the title page.

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.
https://www6.ietf.org/tools/idnits/

  The I-D nits tools complains about non-ASCII characters but these
  are all legitimate characters in names or the like. The Updates
  header on the title page should say 8966 rather than 8967 but
  this is expected to be fixed during resolution of AD/Directorate
  comments.

15. Should any informative references be normative or vice-versa?

  No. References are correctly classified as normative or informative.

16. List any normative references that are not freely available to
anyone.

  All normative references are standards track RFCs and so freely
  available.

17. Are there any normative downward references (see RFC 3967, BCP
97)?

  No.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

  No.

19. Will publication of this document change the status of any
existing RFCs?

  No.

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.

  Tht IANA Considerations for this document correctly only specify the
  assignment of a single code point from the already existing babel
  Sub-TLV Types registry. Since this is Expert Review, the type has
  already been assigned as shown in the document.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear?

  No IANA registries created.
 

1.Does the working group (WG) consensus represent the strong
concurrence of a few individuals, with others being silent, or did it
reach broad agreement?

  There is broad support for this draft in the WG.

2.Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

4. For protocol documents, are there existing implementations of the
contents of the document?

  Yes.

5. Does this document need review from other IETF working groups or
external organizations?

  No.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  No such formal review required.

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?

  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.

  No such formal language exists in this draft.

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. (See Shepherd's review here:
https://mailarchive.ietf.org/arch/msg/babel/5FDtAT-0y5gZ9w-t8MQhiwoulnw/
  all comments in which have been resolved.)

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?
https://trac.ietf.org/trac/iesg/wiki/ExpertTopics

  Nothing pops out as need special attention. The draft has had an
  early Routing Directorate review. See
https://datatracker.ietf.org/doc/review-ietf-babel-rtt-extension-03-rtgdir-early-halpern-2023-07-18/

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)?

  Standards Track as it updates Proposed Standard RFC 8966 and
  describes a protocol change that has been in successful use for
  several years.

12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed?

  Yes, see
https://mailarchive.ietf.org/arch/msg/babel/fqqucGWKpjtnK2prCBX60OHCyfI/
https://mailarchive.ietf.org/arch/msg/babel/o7nDNTn0cDWE96BT1snIKJ5GmCA/
https://mailarchive.ietf.org/arch/msg/babel/Bwt_0_YUw8lYis0owgN-ReB65nY/

13. If yes, summarize any discussion and conclusion regarding the
intellectual property rights (IPR) disclosures, including links to
relevant emails. If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  There was no discussion regarding intellectual property because no
  such IPR has been disclosed. There are 2 authors on the title page.

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.
https://www6.ietf.org/tools/idnits/

  The I-D nits tools complains about non-ASCII characters but these
  are all legitimate characters in names or the like.

15. Should any informative references be normative or vice-versa?

  No. References are correctly classified as normative or informative.

16. List any normative references that are not freely available to
anyone.

  All normative references are standards track RFCs and so freely
  available.

17. Are there any normative downward references (see RFC 3967, BCP
97)?

  No.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

  No.

19. Will publication of this document change the status of any
existing RFCs?

  No.

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.

  Tht IANA Considerations for this document correctly only specify the
  assignment of a single code point from the already existing abel
  Sub-TLV Types registry. Since this is Expert Review, the type has
  already been assigned as shown in the document.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear?

  No IANA registries created.
 

1.Does the working group (WG) consensus represent the strong
concurrence of a few individuals, with others being silent, or did it
reach broad agreement?

  There is broad support for this draft in the WG.

2.Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

4. For protocol documents, are there existing implementations of the
contents of the document?

  Yes.

5. Does this document need review from other IETF working groups or
external organizations?

  No.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  No such formal review required.

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?

  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.

  No such formal language exists in this draft.

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. (See Shepherd's review here:
https://mailarchive.ietf.org/arch/msg/babel/5FDtAT-0y5gZ9w-t8MQhiwoulnw/
  all comments in which have been resolved.)

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?
https://trac.ietf.org/trac/iesg/wiki/ExpertTopics

  Nothing pops out as need special attention. The draft has had an
  early Routing Directorate review. See
https://datatracker.ietf.org/doc/review-ietf-babel-rtt-extension-03-rtgdir-early-halpern-2023-07-18/

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)?

  Standards Track as it updates Proposed Standard RFC 8966 and
  describes a protocol change that has been in successful use for
  several years.

12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed?

  Yes, see
https://mailarchive.ietf.org/arch/msg/babel/fqqucGWKpjtnK2prCBX60OHCyfI/
https://mailarchive.ietf.org/arch/msg/babel/o7nDNTn0cDWE96BT1snIKJ5GmCA/
https://mailarchive.ietf.org/arch/msg/babel/Bwt_0_YUw8lYis0owgN-ReB65nY/

13. If yes, summarize any discussion and conclusion regarding the
intellectual property rights (IPR) disclosures, including links to
relevant emails. If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  There was no discussion regarding intellectual property because no
  such IPR has been disclosed. There are 2 authors on the title page.

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.
https://www6.ietf.org/tools/idnits/

  The I-D nits tools complains about non-ASCII characters but these
  are all legitimate characters in names or the like.

15. Should any informative references be normative or vice-versa?

  No. References are correctly classified as normative or informative.

16. List any normative references that are not freely available to
anyone.

  All normative references are standards track RFCs and so freely
  available.

17. Are there any normative downward references (see RFC 3967, BCP
97)?

  No.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

  No.

19. Will publication of this document change the status of any
existing RFCs?

  No.

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.

  Tht IANA Considerations for this document correctly only specify the
  assignment of a single code point from the already existing abel
  Sub-TLV Types registry. Since this is Expert Review, the type has
  already been assigned as shown in the document.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear?

  No IANA registries created.
 

1.Does the working group (WG) consensus represent the strong
concurrence of a few individuals, with others being silent, or did it
reach broad agreement?

  There is broad support for this draft in the WG.

2.Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme
discontent?

  No.

4. For protocol documents, are there existing implementations of the
contents of the document?

  Yes.

5. Does this document need review from other IETF working groups or
external organizations?

  No.

6. Describe how the document meets any required formal expert review
criteria, such as the MIB Doctor, YANG Doctor, media type, and URI
type reviews.

  No such formal review required.

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?

  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.

  No such formal language exists in this draft.

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. (See Shepherd's review here:
https://mailarchive.ietf.org/arch/msg/babel/5FDtAT-0y5gZ9w-t8MQhiwoulnw/
  all comments in which have been resolved.)

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?
https://trac.ietf.org/trac/iesg/wiki/ExpertTopics

  Nothing pops out as need special attention. The draft has had an
  early Routing Directorate review. See
https://datatracker.ietf.org/doc/review-ietf-babel-rtt-extension-03-rtgdir-early-halpern-2023-07-18/

11. What type of RFC publication is being requested on the IETF stream
(Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)?

  Standards Track as it updates Proposed Standard RFC 8966 and
  describes a protocol change that has been in successful use for
  several years.

12. Has the interested community confirmed that any and all
appropriate IPR disclosures required by BCP 78 and BCP 79 have been
filed?

  Yes, see
https://mailarchive.ietf.org/arch/msg/babel/fqqucGWKpjtnK2prCBX60OHCyfI/
https://mailarchive.ietf.org/arch/msg/babel/o7nDNTn0cDWE96BT1snIKJ5GmCA/
https://mailarchive.ietf.org/arch/msg/babel/Bwt_0_YUw8lYis0owgN-ReB65nY/

13. If yes, summarize any discussion and conclusion regarding the
intellectual property rights (IPR) disclosures, including links to
relevant emails. If the number of Authors/Editors on the front page is
greater than 5, please provide a justification.

  There was no discussion regarding intellectual property because no
  such IPR has been disclosed. There are 2 authors on the title page.

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.
https://www6.ietf.org/tools/idnits/

  The I-D nits tools complains about non-ASCII characters but these
  are all legitimate characters in names or the like.

15. Should any informative references be normative or vice-versa?

  No. References are correclty classified as normative or informative.

16. List any normative references that are not freely available to
anyone.

  All normative references are standards track RFCs and so freely
  available.

17. Are there any normative downward references (see RFC 3967, BCP
97)?

  No.

18. Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?

  No.

19. Will publication of this document change the status of any
existing RFCs?

  No.

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.

  Tht IANA Considerations for this document correctly only specify the
  assignment of a single code point from the already existing abel
  Sub-TLV Types registry. Since this is Expert Review, the type has
  already been assigned as shown in the document.

21. List any new IANA registries that require Designated Expert Review
for future allocations. Are the instructions to the Designated Expert
clear?

  No IANA registries created.
 

Draft is in good shape with good support. Will run WGLC a little longer as it will end during the refractory period before the July IETF Meeting in any case.