Hi Joe,
Thanks for all the time you have put into this exchange.
I'm taking a close look at Section 7. IIUC, the router function language you refer to is in Section 7.2. Section 7.2 begins by saying
"The requirements in this section are a repetition of requirements that apply to IP routers in general, and might not apply to implementations of IP proxying that rely on external software for routing."
Is the common-sense reading of this that it's not "part of the tunnel spec", and therefore that this won't complicate draft-ietf-intarea-tunnels needlessly?
Martin
Hi, David,I’m fine with how the congestion control issue has been resolved.I think the doc should include some discussion of how it would be used, which can include a router bundled with implementations.However, my advice to the INTAREA ADs is that router functions must not be included *as part of the tunnel spec*. I don’t want to have to add this to draft-ietf-intarea-tunnels as a counterexample or with updates.Joe—Dr. Joe Touch, temporal epistemologistOn Apr 20, 2023, at 10:26 AM, David Schinazi <dschinazi.ietf@xxxxxxxxx> wrote:Hi Joe,Thank you for the very productive discussion around this draft. We've landed the majority of your feedback as changes into the document that are reflected in draft-ietf-masque-connect-ip-12. However, there remain two points:1) inclusion of text that applies to routers that we see as important implementer advice instead of implementation-specific advice about TUN interfaces2) whether disabling congestion control is a MAY or a SHOULDAnd for those, we're going to have to agree to disagree. The conversation was definitely interesting, but at this point I don't think we'll reach agreement on them.Thanks,David
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
