Ballot for draft-ietf-babel-rtt-extension
Discuss
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
Many thanks to authors to have addressed all DISCUSS items and considered the feedbacks provided.
# 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"?
Thanks for addressing my DISCUSS issue. I support Robert's, Warren's, and Eric's DISCUSS positions.
I support the existing discusses.
Thanks for the updates. I have updated my ballot to “no objection”.
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”.
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)"
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.
Thanks for addressing my previous DISCUSS and for replying/addressing my previous COMMENTs. See: https://mailarchive.ietf.org/arch/msg/babel/4jq-6zRjfSdKRgCuzI1G8j5NT3k/
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.
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