[Ntp] Mohamed Boucadair's Discuss on draft-ietf-ntp-roughtime-17: (with DISCUSS and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-ntp-roughtime-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Watson and Marcus,

Thank you for the effort put into this specification.

Thanks to Nick Buraglio for the OPSDIR. Although there is public record, I
appreciate that the authors have considered that review.

Please find below an easy-to-fix DISCUSS point:

# Experimental Scope

RFC8126 says:

   When code points are set aside for Experimental Use, it's important
   to make clear any expected restrictions on experimental scope.  For
   example, say whether it's acceptable to run experiments using those
   code points over the open Internet or whether such experiments should
   be confined to more closed environments.

Please consider updating the document to take into account that guidance.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# I support Any’s comments on the need to have some prose about the experiment.
I also support both Andy’s and Roman’s comments on IANA considerations.

# I also think many of the SHOULD need some check, but for some of them I think
that this is acceptable as these may be actualy parts to be further assessed as
part of any future experimentations that would play with this spec. You may say
so early in the document to warrant implementers/those who will deploy.

# Abstract

I suggest we make this change to convey that this is experimental as abstracts
can be used out of the doc context/metadata

OLD:
   This document describes Roughtime, a protocol that aims to achieve two
   things:

NEW:
   This document describes Roughtime, an experimental protocol that aims to
   achieve two goals:

# Ordering

CURRENT:
   The version numbers MUST NOT repeat and MUST be sorted in ascending
   numerical order.

There are several such requirements in the doc. Is there any implication if the
receiving side detect mis ordering?

# Available servers

OLD:
   To carry out a Roughtime measurement, a client SHOULD be equipped
   with a list of servers, a minimum of three of which are operational
   and not run by the same parties.

NEW:
   To carry out a Roughtime measurement, a client MUST be made available (by
   configuration or discovery) with a list of servers. It is RECOMMENDED that a
   minimum of three such servers are operational and not run by the same
   parties.

Cheers,
Med