<div dir="auto"><br>
<br>
On Thu, Jun 4, 2020 at 7:11 AM Hal Murray via devel <<a href="mailto:devel@ntpsec.org" target="_blank" rel="noreferrer">devel@ntpsec.org</a>> wrote:<br>
><br>
> >>   Step 1 will be to listen on both old and new port #<br>
> >>   Step 2 is to switch the client side to default to the new port #.<br>
> >>   Step 3 is to stop listening on the old port #.<br>
> >> Plan B is to merge them all 3 steps and tolerate the brokenness until<br>
> >> everybody switches to the new port number.<br>
><br>
> <a href="mailto:mark.atwood@ntpsec.org" target="_blank" rel="noreferrer">mark.atwood@ntpsec.org</a> said:<br>
> > Let's do plan B, but with config options for operators that want to listen on<br>
> > the old port.<br>
><br>
> You are missing a key word in there.  Listen "in addition" or "instead"?<br>
><br>
> When I first read your message, I assumed you meant in addition since instead<br>
> doesn't really make sense to me.  But maybe I'm missing something and<br>
> "instead" is what you have in mind.<br>
><br>
> I really don't want to support listening on 2 ports as more than a temporary<br>
> hack.<br>
><br>
> How about we go through steps 1, 2, and 3 with me just sending email when I<br>
> push the changes?  If the RFC comes out first, we just skip to the end.<br>
<br>
Cloudflare will support plan A or B. We're also hoping to emit a coordinated set of announcements and work on evangelizing when RFC.<div dir="auto"><br>
><br>
><br>
> --<br>
> These are my opinions.  I hate spam.<br>
><br>
><br>
><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@ntpsec.org" target="_blank" rel="noreferrer">devel@ntpsec.org</a><br>
> <a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a><br>
<br>
<br>
<br>
-- <br>
"Man is born free, but everywhere he is in chains".<br>
--Rousseau.<br></div></div>