[Ntp] Antwort: Re: WGLC - draft-ietf-ntp-ntpv5-requirements

[[e-mail]]

Dear James, dear all,

I find this a bit difficult - after all, the intended status for the RFC is 'informational', and so I guess less stringent criteria apply.

Also, the document started out as an effort to strictly report on the WG's consensus on what would be needed for NTPv5 (as an upcoming standards track document).

The issue is: little of that seems reflected in the current requirements draft, definitely not obvious to a new reader.

The document never (?) seems to state that it intends to report WG consensus; it constantly uses requirement keywords (MUST, SHOULD etc.) like a specification would; it rarely (and never with an explicit explanation, IIRC) talks about an upcoming standards track document that it is supposed to support.

This lack of clarifying the document's overall role (supporting the creation of the actual NTPv5 spec later by reporting the WG's current consensus on what's required), in and of itself, is a blocking issue (#1) for me.

Also, in some cases, I still feel that the text as-is could leave a reader more confused rather than informed - this applies to our criticisms of Sections 2 (Use Cases...) and 3 (Threat Analysis...) and 4.4 (Timescales) and 4.5 (Leap Seconds).

That makes reworking these sections (could be as simple as taking it out, e.g. in the case of Section 3) another set of blocking issues (#2a, #2b, #2c, #2d) for me.

Lastly, there are a few instances where I feel the documents's original role of merely reporting on WG consensus creates situations where there are just logical inconsistencies - demands that run counter to one another but are just listed as important, back-to-back.

Basically, if the WG once decided that eating cake is desirable, and on another occasion decided that having cake is desirable, the result would be that we report that the WG has decided that it wants to eat its cake and then still wants to have it, too.

This mostly applies to Section 4, namely:

- 4.1 Resource Management as described seems to run counter to 4.2 Data Minimization

- 4.1 Resource Management as described also seems to run counter to 4.8 Security

- In 4.8 Security, requiring upgradeability seems to run counter to ruling out downgrade attacks

The least that I think needs to be done (in order for this document to be informative) is to explicitly point out that these items might run counter to one another; ideally, we should of course settle on an overall consensus that we are sure is without internal inconsistencies.

Treating these in some way is another set of blocking issues (#3a, #3b, #3c) for me.

I also really, really would like 4.8 (Security) to state that the specification must settle on one security option and require all implementations to support it, lest there might still be unsecured traffic.

But I guess the section doesn't rule this out, either, so we could still just do this in the actual NTPv5 spec - so it's not strictly speaking a blocking issue for me, I would just strongly prefer this addition.

I hope I reflected Martin's opinions here as well, but I wasn't able to closely coordinate this with him in time other than having access to his own reply email draft.

Perhaps some fruitful discussion can be had tomorrow at the interim meeting :) 

Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB)
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.: [phone]
E-Mail: [e-mail]
__________________________________________

-----"ntp" <[e-mail]> schrieb: -----

An: [e-mail]
Von: "James" <[e-mail]>
Gesendet von: "ntp" <[e-mail]>
Datum: 12.12.2023 15:59
Kopie: [e-mail]
Betreff: Re: [Ntp] WGLC - draft-ietf-ntp-ntpv5-requirements

Thank you for clarifying.

Can you please specify exactly which points must be addressed in order for yourselves to support advancement to the IESG.

- J

> On 12 Dec 2023, at 15:49, [e-mail] wrote:
>
> Hello James,
>
> I'm sorry, I think I really was being unclear:
> At least most points would have to be adressed first for us to support advancement to IESG.
> I was just trying to express that we fundamentally agree with the effort and want a document based on this version to go forward.
>
>
> Besten Gruß / Kind regards,
> Kristof Teichel
>
> __________________________________________
>
> Dr.-Ing. Kurt Kristof Teichel
> Physikalisch-Technische Bundesanstalt (PTB)
> Arbeitsgruppe 4.42 "Zeitübertragung"
> Bundesallee 100
> 38116 Braunschweig (Germany)
> Tel.:        [phone]
> E-Mail:   [e-mail]
> __________________________________________
>
>
>
> Von:        "James" <[e-mail]>
> An:        [e-mail]
> Kopie:        [e-mail], "Karen ODonoghue" <[e-mail]>, [e-mail]
> Datum:        12.12.2023 15:08
> Betreff:        Re: [Ntp] WGLC - draft-ietf-ntp-ntpv5-requirements
> Gesendet von:        "ntp" <[e-mail]>
>
>
>
> Kristof and Martin,
>
> Thanks for your review. I'll provide responses to the points you've raised in a separate mail, however there's one point of clarification I think needs to be addressed first:
>
> > On 12 Dec 2023, at 14:27, [e-mail] wrote:
> >
> > To be clear: we want an adapted document to advance and to be submitted to the IESG (not to hold up the process or anything).
>
> I'm sorry but this statement is unclear to me given the current state of the process.
>
> Do you believe version -03 as it stands is ready to be submitted to the IESG, or do you think any or all of the points you've raised must be addressed in order for submission to the IESG?
>
> - J
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp
>
>

_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ntp