Re: [Ntp] NTS IANA request

["[e-mail]" <[e-mail]>]

Harlan,

Saying something is “total rubbish” is not actionable by the working 
group. You have several other options in this case…

You can indicate that you don’t agree with the technical points being 
made either individually or as a set.

Or, you can indicate that you don’t agree with the statement that the 
working group has concluded the specific points made.

If you don’t have time to comment on specific questions you can 
indicate that as well.

But I ask you, and all working group members to maintain a certain level 
of professionalism on the mailing list.

Thank you!
Karen

On 6 Jun 2019, at 23:24, Harlan Stenn wrote:

> My response was intended to be a technical response.
>
> I don't have the time or the desire to refute all of the wrong claims 
> in
> this thread.
>
> H
>
> On 6/6/2019 8:23 PM, [e-mail] wrote:
>> Harlan,
>>
>> As we have discussed privately, this type of email response is not 
>> helpful.
>> Please limit your comments on the mailing list to specific technical
>> concerns.
>>
>> Thank you!
>> Karen
>>
>> On 6 Jun 2019, at 17:42, Harlan Stenn wrote:
>>
>>> As best as I can tell, the following is total rubbish.
>>>
>>> H
>>>
>>> On 6/6/2019 11:28 AM, Daniel Franke wrote:
>>>> As a slight tangent, we never concluded the discussion as to what
>>>> we're going to do about the fact that so many ISPs are dropping
>>>> 123/udp traffic with payloads larger than 48 bytes. I think we got 
>>>> as
>>>> far as concluding:
>>>>
>>>> 1. We're never going to persuade enough ISPs to change their 
>>>> policy,
>>>> making 123/udp basically doomed.
>>>> 2. NTS-KE's port negotiation record gives us all the mechanism we 
>>>> need
>>>> in order to run NTP-with-NTS over an alternate port.
>>>>
>>>> But that left an unresolved question: do we allocate a fixed 
>>>> alternate
>>>> UDP port, or should servers ask the OS for a dynamic port and then 
>>>> use
>>>> NTS-KE to advertise whatever the OS assigns to them? Both choices 
>>>> have
>>>> firewall-related drawbacks. If we use a fixed port, we risk landing
>>>> ourselves right back in the same situation we're in today with 123. 
>>>> At
>>>> minimum, to protect ourselves from this, the NTF would have to 
>>>> commit
>>>> to adding some code to ntpd such that it will refuse to ever send 
>>>> mode
>>>> 6 or 7 responses over the new port no matter what configuration the
>>>> user gives it. (Yes, mode 6 too, because mode 6 still amplifies, 
>>>> just
>>>> not as severely as mode 7 does). If we use a dynamic port, then it
>>>> becomes much harder for ISPs to block us, but it also becomes 
>>>> harder
>>>> for corporate firewalls with a default-deny-all policy to let us
>>>> through.
>>>>
>>>> On Thu, Jun 6, 2019 at 1:06 PM Salz, Rich <[e-mail]> wrote:
>>>>>
>>>>>>    I'm strongly opposed to modifying NTS-KE to involve sending 
>>>>>> a
>>>>>> STARTTLS
>>>>>     as a first step of the handshake. I don't want to make a 
>>>>> breaking
>>>>>     change to a protocol that's passed WGLC and has four 
>>>>> interoperating
>>>>>     implementations in order to accommodate a protocol that has
>>>>> never been
>>>>>     implemented and whose specification consists of three vague
>>>>> sentences
>>>>>     in an unadopted and expired I-D.
>>>>>
>>>>> I wasn't strongly advocating either mechanism, just trying to
>>>>> explain how things could share a port if that's what we wanted to 
>>>>> do.
>>>>>
>>>>> For the record, since I see no definition of NTP/TLS, I am in 
>>>>> favor
>>>>> of assigning 123/TCP to NTS.
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> ntp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ntp
>>>>
>>>
>>> -- 
>>> Harlan Stenn, Network Time Foundation
>>> http://nwtime.org - be a Member!
>>>
>>> _______________________________________________
>>> ntp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ntp
>>
>
> -- 
> Harlan Stenn, Network Time Foundation
> http://nwtime.org - be a Member!