[Ntp] Antw: [EXT] Re: Mirja Kühlewind's Discuss on draft-ietf-ntp-using-nts-for-ntp-24: (with DISCUSS and COMMENT)

[Ulrich Windl <[e-mail]>]

>>> Marcus Dansarie <[e-mail]> schrieb am 24.03.2020 um 18:20 in
Nachricht
<12104_1585070439_5E7A4166_12104_203_1_8f11bdb7-3526-279e-799e-42255928695c@dans
rie.se>:
> Responses inline.
> 
> Kind regards,
> Marcus
> 
> 
> On 2020-03-24 17:35, Mirja Kuehlewind wrote:
>> Given you didn’t define what “treated as an error means” I don’t see a 
> difference. If you received an error you can either abort the connection, or

> you can e.g. log the error and go on knowing that a certain function might 
> not be available. I don’t see what additional value a warning gives you and

> most other protocols I know are usually fine with only having errors (and no

> warning). Without further guidance about what warnings should be used for, 
> I’m afraid this function will not be very useful (and it could be added
later 
> in needed). However, this is not a problem and again just a comment, you may

> or may not consider in the final version.
> 
> I agree with you in principle here. We are reluctant to make technical
> changes at this late point in the process. Also, it is better to keep
> the record in the draft and not need it than to remove it and find out
> we need it later.
> 
> 
>> So if you only send the ID 0 and don’t set the critical bit, you may just 
> never get a reply…? Not sure if I can imagine a scenario where that is
useful 
> but I guess it’s also not a problem.
> 
> If you only send ID 0, the setting of the critical bit doesn't really
> matter. Provided the request is complete and syntactically correct, the
> only difference is what message the server will respond with if it
> doesn't support ID 0. Critical bit set will yield a "Unrecognized
> Critical Record" Error in return. Critical bit cleared will yield an
> empty "NTS Next Protocol Negotiation" in return.
> 
> 
>> Not sure what you mean, the MTU should be a function of the path, no? But 
> maybe I lost track here. All I was proposing is to add a reference to some 
> other RFC to provide more information about the actual limits for IPv4.
> 
> Ok! Do you know of an RFC with guidance for this? If so, I'd be happy to
> include it and I'm sure the other authors wouldn't mind either.

I'm absolutely no expert on this, but you might consider:
RFC 1063 (IP MTU Discovery Options) from 1988
RFC 1191 (Path MTU Discovery) from 1990, flagged as draft standard
All other documents I found refer to TCP (see attachmnent that was created
from my own little private database)

Regards,
Ulrich