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

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-babel-rtt-extension and RFC 9616, changed IESG state to RFC Published)

[Ballot comment]
Thanks for updating the document, this is not well described the issues raised in the discusses.

Comment:
  - I think this sentence is unnecessary and suggest to remove it, it says -

        this is the case in most networks known to the authors, but might not necessarily be the case in networks built over exotic link technologies.

Nit:

s/application /Application , in Section 1.1  title.

[Ballot comment]
Thank you for addressing my DISCUSS (archived below for hysterical raisins):

"First off, let me start by saying that I like the general idea and concept in this document, but, like others, I think that it needs more formalism.

One major concern of mine is that it says: "Updates: 8967 (if approved)"

The shepherds writeup notes that this document is Standards Track because it needs to update a Standards Track document, but no-where in the document does it actually say **how** it updates RFC8967.
Perhaps the header intended to say that the documents updates RFC8966? Even if that is the case, the document doesn't actually say **how** it updates it... The Abstract should say "This document updates RFC896X by fooing the bar and twiddling the baz." (or similar)"

[Ballot discuss]
After discussion with the IESG and another review of the document, I understand quite a bit more and would like to withdraw most of the DISCUSS points.

Ultimately, I'd just like a clearer statement that Section 4 is non-normative and nodes are free to use any method to compute RTT from samples, and cost from RTT, as that doesn't prevent convergence of the protocols. As with any Distance-vector protocol, if cost computation is not uniform you will get some silly results.

[Ballot comment]
- Is there any notion of RTT variance, jitter, or other statistical properties in this framework? ISTM to me that 20 ms RTT + 50 ms variance is a worse link than 40ms RTT + 2ms variance.

[Ballot discuss]
Roman pointed something out that I'd like to develop a little further.

Section 3.3 includes:

  ... For these reasons, very old timestamps or nonsensical timestamps MUST NOT be used to yield RTT samples.

  We suggest the following algorithm to achieve that. When a node receives a packet containing a Hello and an IHU, it SHOULD compare ...

SHOULD creates a decision for an implementer; what comes after could be completely ignored if the implementer decides that's appropriate in the circumstances, and in theory it won't harm interoperability.  I don't understand the choice being presented; why, if I'm following the suggestion presented, would I not do what it says?

I suggest you take out "it SHOULD".  The entire paragraph is a suggestion anyway; there's no need for normative choices to be presented.

But the reason I'm raising this to a DISCUSS is because the section appears to assert a MUST NOT, but then buttress it by a handful of SHOULD NOTs.  The latter are confusing because I could in theory choose to disregard them and yet still comply with the MUST NOT.  Is that correct?  I feel like some clarification would be of benefit here.

[Ballot discuss]
Be strong and of a good courage; be ye not afraid, neither be thou dismayed by this DISCUSS position.
Instead, take heart and readeth https://www.ietf.org/blog/handling-iesg-ballot-positions/ , which contains many words on handling ballots.
For, as it sayeth upon the lid of the tin: "A DISCUSS ballot is a request to have a discussion"...



First off, let me start by saying that I like the general idea and concept in this document, but, like others, I think that it needs more formalism.

One major concern of mine is that it says: "Updates: 8967 (if approved)"

The shepherds writeup notes that this document is Standards Track because it needs to update a Standards Track document, but no-where in the document does it actually say **how** it updates RFC8967.
Perhaps the header intended to say that the documents updates RFC8966? Even if that is the case, the document doesn't actually say **how** it updates it... The Abstract should say "This document updates RFC896X by fooing the bar and twiddling the baz." (or similar)

[Ballot discuss]
- I support Rob's DISCUSS on the status of this document, and would like to expand on it a bit. I can support this document, with a few modifications, as experimental, but there are huge gaps in a standards-track spec. If, per the shepherd writeup, this has been successfully deployed for years, there are numerous implementation details that are missing.
Specifically:
o In (3.3) and (4), there is a weak non-normative suggestion of an algorithm, rather than a standard way of doing things.
o (4.1) There is an allusion to a perfectly reasonable TCP-like smoothing algorithm in [DELAY-BASED], but this is an informative reference and the algorithm is not actually described in the text.
o (4.1) "Other algorithms have also been considered, such as a moving average or a moving minimum, but we have not evaluated their behaviour." This does not strike me as the maturity level of a proposed standard. Furthermore, the TCP-like algorithm is a computationally efficient approximation of a moving average!

- If this document moves to Experimental, there should be a description of what the experiment is, including dependent (algorithm? cost function parameters?) and independent variables.

- Given how loosely defined this spec is, does it matter if different nodes select different magic numbers and/or algorithms?

- I would like to amplify Zahed's COMMENT to a DISCUSS. As these RTT measurements are not communicated beyond one hop, is RTT-based routing limited to the next hop? Is there even a way to measure RTT over multiple hops? If so, how is this done scalably?

(I will note that another approach would simply take local link-layer delay/RTT measurements and communicate them as link costs using the normal process, which would be much easier and tolerant of implementation variances)

[Ballot comment]
- Is there any notion of RTT variance, jitter, or other statistical properties in this framework? ISTM to me that 20 ms RTT + 50 ms variance is a worse link than 40ms RTT + 2ms variance.

- Assuming, as is likely, this document goes for significant rework, I suggest an early TSVART review.

[Ballot discuss]

# Éric Vyncke, INT AD, comments for draft-ietf-babel-rtt-extension-05

Thank you for the work put into this document.

Please find below one blocking DISCUSS points (super easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Donald Eastlake for the shepherd's write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Antoine Fressancourt, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-babel-rtt-extension-05-intdir-telechat-fressancourt-2024-02-12/ (and I have read the interaction with Juliusz)

Please note that Pascal Thubert is the IoT directorate reviewer (at my request) and you may want to consider this iot-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-babel-rtt-extension/reviewrequest/18839/

I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

## Abstract

Please address the id-nits detected issue:

```
  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC8967, but the
    abstract doesn't seem to mention this, which it should.
```

[Ballot comment]
# COMMENTS (non-blocking)

## Generic question

It seems that the assumption is that the transmission delay is symmetric. Is it always the case ? I.e., could it be possible that A->B is faster than B->A ? E.g., the good old ADSL has different serialisation time and the same may also happy with Wi-Fi.

Does babel also handle average transmission queue length/delay as input ?

## Section 3.1

Is the Receive timestamp also modulo 2**32 ? Perhaps worth specifying.

## Section 3.2

Like noted by other ADs, please expand 'IHU' at first use.

## Section 3.4

While I like the useful implementation note, should there be a reference to CLOCK_MONOTONIC ?

## Section 4

As noted by other ADs, I also find strange to use the word "experimental" in a standard track document. Suggest rewriting this part using other terms.

## Section 6.2

About the discussion when the Length field is larger than 8, I would strongly suggest to also ignore the TLV as the timestamps length cannot be asserted, i.e., the first octet of receive timestamp could actually be part of the origin timestamp.

# NITS (non-blocking / cosmetic)

## µs or microsecond

Suggest to use either "µs" or "microsecond" but not both forms in the same document.

[Ballot discuss]
Thanks for working on this specification. It seems like a oversight from us that it didn't get any TSVART review at the earlier stage of this document.

I have following issues to discuss -

# I support Rob's discuss that it is not clear why this is published as standard track document. Apart from what Rob pointed out, there is another place where the experimental nature of this specification is obvious. In section 1 it says -

    "We believe that this protocol may be useful in other situations than the one described above, such as when running Babel in a congested wireless mesh network or over a complex link layer that performs its own routing; the fine granularity of the timestamps used (1µs) should make it possible to experiment with RTT-based metrics on this kind of link layers."

  This shows lack of confidence on the results and request for more experiments. As RTT-based route selection can end up having negative impacts by overloading  and congesting low RTT routes, we must run enough experiments and have enough data to declare it safe for the Internet. I am lacking the those information.

# This specification does not specify the relation to other loss-based metric and hop-count metric based strategies. I can imagine a network where low RTT can be emitted at the cost of packet loss. Will this RTT-based strategy be safe to use?

# How would this RTT-based strategy will co-exists with other strategies those are deployed already as claimed in this specification? This specification need to guide the implementers about what to consider when selecting the routing strategy and how the strategies can co-exits.

# The periodicity of HELLO message is not clear to me. This is an important piece of information that should be derived from proper experiments as we don't want the HELLO message to overload the route or path. The discussion on when to stop sending those HEllO messages is required.  Also the frequency of the HELLO message might help adjusting the clock drift, as it is an important aspect of the accuracy of the algorithm.

[Ballot comment]
I was also wondering how does A calculate the RTT towards D via B and C? does it only computes the RTT between itself and B and compares with that with C, or does it some how knows the whole end to end RTT? this part is also under specified or I have certainly missed it.

[Ballot discuss]
Thanks to Shivan Sahib for the SecDir review.

I agree with Shivan's concern about privacy here. Perhaps something more can be said in the document? Maybe a Privacy Considerations section? Should a client using a VPN add some random range delay for privacy? Should it just say/act with something very slow to "opt out" of this entirely so the only information leaked is "not local"? eg cause it to be like 1000ms ? Is there another way to opt-out? Eg by refusing to answer as per this draft that could be recommended ?

I'm also worried about malicious clients sending pre-emptive IHUs and lying about the RTT, and thus making themselves the preferred gateway. This could be avoided by adding a random COOKIE in the RTT timer request. Is there a reason why not to take this extra security step? (I'm not a Babel expert, so it is possible my envisioned scenario is not possible)

[Ballot discuss]
Hi,

Thanks for this document.  I've balloted "discuss" on this document because I would like to have a discussion with the responsible AD and other ADs as to whether Standards Track is the right classification for this document based on the text below, where it seems like a key part of the solution is only experimental.  I appreciate that this document is also defining new TLVs, but the pertinent IANA registry policy is only specification required, and there is also reserved IANA values for experimental TLVs that could also be used, if appropriate.

(1) p 7, sec 4.  RTT-based route selection

  In this section, we describe an algorithm that integrates smoothing
  and hysteresis and has been shown to behave well both in simulation
  and experimentally over the Internet [DELAY-BASED].  While
  implementations MAY use this algorithm, it is considered
  experimental, since we do not currently have a theoretical
  understanding of its behaviour, and in particular we do not know by
  how much it could be simplified without impairing its functionality.

Regards,
Rob

[Ballot comment]
# Internet AD comments for draft-ietf-babel-rtt-extension-05
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S3.2

* Up to you, but it occurs to me that in this final paragraph you might also
  note that any routers using NTP can manage their clock drift, further
  minimizing the likelihood of impacting the RTT calculation described here.

### S4.1

* Even within an Experimental subsection within a Standards Track document,
  itself a bit unusual, it seems odd to have text like "our implementation"
  and "we have/have not ...".  Can this be reworded to avoid giving the
  impression that there's an IETF-approved implementation?  Perhaps something
  like "At least one implementation", "One or more implementations are known
  to ...", or something?

## Nits

### S1

* "this kind of link layers" -> "these kinds of link layers"?

[Ballot comment]
Thank you to Shivan Sahib for the SECDIR review.

** Section 3.3.

  We suggest the following algorithm to achieve that.  When a node
  receives a packet containing a Hello and an IHU, it SHOULD compare
  the current local time t2 with the Origin Timestamp contained in the
  IHU;

Consider if you want to formally “RECOMMEND” this algorithm, rather than “suggest”.

(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.