Re: [Ntp] Call for Adoption: draft-mlichvar-ntp-alternative-port

[Dhruv Dhody <[e-mail]>]

Hi Miroslav,

On Wed, Sep 16, 2020 at 8:23 PM Miroslav Lichvar <[e-mail]> wrote:
>
> On Mon, Sep 07, 2020 at 12:43:48PM +0530, Dhruv Dhody wrote:
> > Hi WG,
> >
> > I support adoption. Some comments, nits, and queries to improve the I-D -
>
> Again, thanks for the comments. A new version of the draft is here:
>
> https://www.ietf.org/id/draft-mlichvar-ntp-alternative-port-02.txt
>
> > Please state it clearly in the abstract what text in RFC 5905 is being
> > updated. This should also be spelled out clearly in the body.
>
> I've described the new text as an addition to the section 9.1 of RFC
> 5905. It doesn't seem like a very good fit to me, but I couldn't find
> a better place. Suggestions are welcome.
>

What you added looks good to me.

> > ~ Please add a reference for NTS
>
> There already was a reference for NTS. Did you mean it should be
> moved, or was it something else?
>

I missed that reference in section 1. Just expand NTS there and we are
good to go.

> > * Query
> > ~ You state that autokey is not expected to be used, but what happens if it is?
>
> If a server has Autokey enabled, it must not respond to Autokey
> requests on the alternative port. That should follow from the
> specified restrictions.
>

Do you see value in adding some text? The mention on auto-key in the
introduction with just -

   The first group of modes typically does not allow any traffic
   amplification, i.e. the response is not larger than the request.  An
   exception is Autokey specified in RFC 5906 [RFC5906].  Autokey is
   rarely supported on public NTP servers.

gives the impression that auto-key is not used, and no information on
what happens if it is.

> > ~ There are instances of SHOULD in the text (see paragraphs 4 and 5 in
> > section 2), but I am not sure in which conditions that behavior is not
> > expected, maybe you could be clear about them, or do they need to be
> > MUST?
>
> I'm not quite sure which SHOULDs you find unclear. Some of them are
> meant to prevent existing implementations from breaking the new
> specification and the rest is just meant to be a recommendation,
> allowing different algorithms to be implemented for selecting and
> switching between the ports.
>

I understand.

I am wondering if it is better to differentiate between older
implementation that does not support ALTPORT with new ones that do.
And, perhaps say things like - "An NTP server that supports ALTPORT
MUST receive requests in the client mode on both the PORT (123) and
ALTPORT (TBD) ports."  A case of an NTP server that does not support
ALTPORT is already covered by the existing text in RFC 5905.

Thanks!
Dhruv


> --
> Miroslav Lichvar
>