Control Messages Protocol for Use with Network Time Protocol Version 4
draft-ietf-ntp-mode-6-cmds-11

[Ballot discuss]
[updating version to which ballot position applies, since the -11 does not
seem to have addressed the core topics.    Furthermore, a 20- or 24-**bit**
authenticator will have its own problems to cover, though 20- or 24-**byte**
authenticators would be more reasonable.]

There seems to be an internal inconsistency regarding the format of the
data payload: at the start of Section 4 we see that "When present, the
data field contains a list of identifiers or assignments in the form
<>[=<>],<>[=<>],...  where
<> is the ASCII name of a system or peer variable specified
in RFC 5905 and <> is expressed as a decimal, hexadecimal or
string constant in the syntax of the C programming language", but later
on we see that the Read Status reply "contains a list of binary-coded
pairs <> <>, one for each currently
defined association.  The "binary-coded" (with, apparently, implicit
length) seems at odds with the ASCII key/value assignment pairs.

The description of the Configure(8) command as "The command data is
parsed and applied as if supplied in the daemon configuration file"
lacks any reference to what that format is or how one might know what
format the peer expects.  This does not seem sufficiently specified so
as to admit interoperable implementation.

The description of the Read MRU(10) command also seems underspecified.
What name=value pairs affect the selection of records (and how)?  Is
there a particular name used with name=value pair for the returned
nonce, or how is the returned nonce framed?  If it's
implementation-specific, say so.

The only currently specified authentication scheme for these commands
appears to be DES-CBC-MAC, from Appendix C of RFC 1305.  (RFC 5905
suggests that existing implementations, however, use a different
keyed-MD5 scheme that is similarly flawed.)  As a CBC-MAC, this
mechanism is subject to an extension attack, allowing an attacker to
observe an existing valid packet and construct a forged packet with
valid MAC by appending additional data at the end.  This, therefore,
fails to actually provide the key property of authentication.  There are
additional fundamental issues with the NTP authentication format
(independently of the DES-CBC-MAC scheme), which may not quite rise to
DISCUSS-level, and accordingly are listed in the COMMENT section.

[Ballot discuss]
[updating version to which ballot position applies, since the -10 does not
seem to have addressed the core topics.    Furthermore, a 20- or 24-**bit**
authenticator will have its own problems to cover, though 20- or 24-**byte**
authenticators would be more reasonable.]

There seems to be an internal inconsistency regarding the format of the
data payload: at the start of Section 4 we see that "When present, the
data field contains a list of identifiers or assignments in the form
<>[=<>],<>[=<>],...  where
<> is the ASCII name of a system or peer variable specified
in RFC 5905 and <> is expressed as a decimal, hexadecimal or
string constant in the syntax of the C programming language", but later
on we see that the Read Status reply "contains a list of binary-coded
pairs <> <>, one for each currently
defined association.  The "binary-coded" (with, apparently, implicit
length) seems at odds with the ASCII key/value assignment pairs.

The description of the Configure(8) command as "The command data is
parsed and applied as if supplied in the daemon configuration file"
lacks any reference to what that format is or how one might know what
format the peer expects.  This does not seem sufficiently specified so
as to admit interoperable implementation.

The description of the Read MRU(10) command also seems underspecified.
What name=value pairs affect the selection of records (and how)?  Is
there a particular name used with name=value pair for the returned
nonce, or how is the returned nonce framed?  If it's
implementation-specific, say so.

The only currently specified authentication scheme for these commands
appears to be DES-CBC-MAC, from Appendix C of RFC 1305.  (RFC 5905
suggests that existing implementations, however, use a different
keyed-MD5 scheme that is similarly flawed.)  As a CBC-MAC, this
mechanism is subject to an extension attack, allowing an attacker to
observe an existing valid packet and construct a forged packet with
valid MAC by appending additional data at the end.  This, therefore,
fails to actually provide the key property of authentication.  There are
additional fundamental issues with the NTP authentication format
(independently of the DES-CBC-MAC scheme), which may not quite rise to
DISCUSS-level, and accordingly are listed in the COMMENT section.

[Ballot comment]
Thanks for resolving the document status confusion.

I found the same typos Roman did.  A quick pass with a spell checker might speed things through the RFC Editor slightly.

[Ballot comment]
I have noticed a number of additions but also changes compared to 1305, for example regarding the code points
* Operation Code
* System Event Code,
* Peer Selection,
* Peer Event Code,
* Clock Status/Clock Code.

I have read:
  The goal of this document is to provide a
  current, but historic, description of the control messages as
  described in RFC 1305 and any additional commands implemented in NTP.

Which I interpret as 1305 being the main constituant of this document, plus some additional elements of specifications. Therefore, finding new stuff compared to 1305 isn't totally surprising but still, it is not clear to me where do the additions come from, and what explains the changes compared to 1305.

[Ballot comment]
I support Murray’s DISCUSS.

To add to the discussion: It’s not clear to me why either a Historic or an Informational RFC is needed, to repeat information that is in an Obsolete RFC.  It would be one thing if these were for current implementation, but the draft is clear that they’re not.  Then why isn’t it sufficient that they are documented in 1305?  Why does there need to be a non-Obsolete RFC that has them?

[Ballot comment]
I support Murray’s DISCUSS.

With a document of this type, I am not sure if all of these type codes and bit settings should be IANA registries or not.

Sec 4 references Fig. 2 but I think you mean Fig. 1.

In sec 6, please replace “whitelist” with “allowlist” or other equivalent term.

[Ballot comment]
I support Murray’s DISCUSS.

With a document of this type, I am not sure if all of these type codes and bit settings should be IANA registries or not.

Sec 4 references Fig. 2 but I think you mean Fig. 1.

In sec 6, please replace “whitelist” with “allowlist” or other equivalent term.

[Ballot discuss]
There seems to be an internal inconsistency regarding the format of the
data payload: at the start of Section 4 we see that "When present, the
data field contains a list of identifiers or assignments in the form
<>[=<>],<>[=<>],...  where
<> is the ASCII name of a system or peer variable specified
in RFC 5905 and <> is expressed as a decimal, hexadecimal or
string constant in the syntax of the C programming language", but later
on we see that the Read Status reply "contains a list of binary-coded
pairs <> <>, one for each currently
defined association.  The "binary-coded" (with, apparently, implicit
length) seems at odds with the ASCII key/value assignment pairs.

The description of the Configure(8) command as "The command data is
parsed and applied as if supplied in the daemon configuration file"
lacks any reference to what that format is or how one might know what
format the peer expects.  This does not seem sufficiently specified so
as to admit interoperable implementation.

The description of the Read MRU(10) command also seems underspecified.
What name=value pairs affect the selection of records (and how)?  Is
there a particular name used with name=value pair for the returned
nonce, or how is the returned nonce framed?  If it's
implementation-specific, say so.

The only currently specified authentication scheme for these commands
appears to be DES-CBC-MAC, from Appendix C of RFC 1305.  (RFC 5905
suggests that existing implementations, however, use a different
keyed-MD5 scheme that is similarly flawed.)  As a CBC-MAC, this
mechanism is subject to an extension attack, allowing an attacker to
observe an existing valid packet and construct a forged packet with
valid MAC by appending additional data at the end.  This, therefore,
fails to actually provide the key property of authentication.  There are
additional fundamental issues with the NTP authentication format
(independently of the DES-CBC-MAC scheme), which may not quite rise to
DISCUSS-level, and accordingly are listed in the COMMENT section.

[Ballot comment]
Depending on how my discuss points are resolved, I may have to switch to
Abstain, as I cannot support publication of a document as status other
than historic that makes a normative reference to the obsolete RFC 1305
for the authenticator format/procedures.

In general, many of the descriptions for particlar codepoints are
single-word or single-line descriptions that do not provide enough
detail to give confidence of interoperable implementation; in some cases
("kernel loop discipline status changed") they are tied to particular
implementation strategies that are not universally applicable.

The considerations of BCP 201 with respect to algorithm agility appear
to be quite relevant, with the 96-bit authenticator format locking us
into at best 64 bits of MAC, which is fairly weak for Internet use, and
32 bits of key identifier.  This presents its own problems, as 32 bits
is too small for a value that is unilaterally assigned by many/all
participants and expected to be globally unique, but is rather large for
a key identifier space that is centrally managed for use within a single
administrative domain.  (The currently specified DES-CBC checksum from
RFC 1305 is, of course, considered insecure at this point, as with all
things single-DES.)

I see we defer to RFC 1305 for key management, which also defers the
matter as out of scope, but the considerations of BCP 107 seem to remain
relevant even in that case.

This document seems to be discussing a protocol over UDP that includes
its own fragmentation mechanism; would the UDP Usage Guidelines of RFC
8085 (BCP 145) not be applicable?

I see that there has been substantial previous discussion about this
document's intended status, with the change to Informational from
Historic occurring only recently.  The body text, however, still has
several references to "historical record" and other "historic" things
that don't seem quite right in an Informational document.  In light of
the protocol flaws mentioned in my Discuss section, my personal stance
is that Historic is the most appropriate status, though it would also be
reasonable to publish an Informational document on "the Network Time
Foundation's implementation of NTP mode 6 control commands".

Section 1.1

  Most control functions involve sending a command and receiving a
  response, perhaps involving several fragments.  The sender chooses a
  distinct, nonzero sequence number and sets the status field and "R"
  and "E" bits to zero.  [...]

It may be worth a reference to draft-gont-numeric-ids-sec-considerations
(I am AD-sponsoring this document) for the generation of these sequence
numbers, though maybe the actual definition of the field in Section 2 is
the better place from which to make such a reference.  (Also for the
Associate ID, it looks like.)

Section 3

I note that the order of word formats in the figure does not match the
subsection order.

Section 3.1

nit: the table entry for System Event Code 9 seems to be missing a word
("end"?).

  System Event Counter (Count): This is a four-bit integer indicating
  the number of system events occurring since the last time the System
  Event Code changed.  Upon reaching 15, subsequent events with the
  same code are not counted.

I get the impression from reading this (and similar text in subsequent
sections) that the "events" in question are exactly the behavior
specific to the event code in question, but it is hard to be sure when
it's left implicit.

Section 3.2

  A peer status word is returned in the status field of a response to a
  read status, read variables or write variables command and appears
  also in the list of association identifiers and status words returned
  by a read status command with a zero association identifier.  The

Given that this is the "Peer Status Word" section, shouldn't this be
"non-zero association identifier"?

  Peer Status (Status): This is a five-bit code indicating the status
  of the peer determined by the packet procedure, with bits assigned as
  follows:

We could probably spend a few more words saying that the bit being set
to 1 indicates the "true"/"yes" form of the meaning.

    |  6  | no reply (only used with one-shot ntpd -q)            |

It doesn't really seem appropriate to hardcode implementation details
("ntpd -q") here.

    |  13  | popcorn spike suppressed by peer clock filter register |

"popcorn spike" seems to appear only in the code skeleton of RFC 5905
and is not otherwise a defined term.  I do see a note in
draft-ietf-ntp-ntpv4-algorithms but we don't reference that document at
all; as such, this sems like jargon that's not appropriate for the
protocol spec.

Section 3.3

    |      0      | clock operating within nominals                  |

In the vein of my previous comment about "event" ambiguity, what event
would happen to cause the counter to increment while this is the clock
code?

Section 4

  Commands consist of the header and optional data field shown in
  Figure 2.  When present, the data field contains a list of

I think this is actually Figure 1.

  identifiers or assignments in the form
  <>[=<>],<>[=<>],...  where

Please clarify whether the comma is a literal comma as separator (or
what separator is used between key/value pairs), and also whether any
escaping might be needed if certain characters need to appear in the
<> portion.

  language.  Where no ambiguity exists, the <169>sys.<170> or
  <169>peer.<170> prefixes can be suppressed.  Whitespace (ASCII

Are the <169>/<170> mangled charset conversion issues?  (I'm not sure
which charset, though!)  Also appears later around '.'.

  guidelines defined in [RFC5952].  Timestamps, including reference,
  originate, receive and transmit values, as well as the logical clock,
  are represented in units of seconds and fractions, preferably in
  hexadecimal notation.  Delay, offset, dispersion and distance values
  are represented in units of milliseconds and fractions, preferably in
  decimal notation.  All other values are represented as-is, preferably
  in decimal notation.

(side note) a bit surprising to see the mixed hex/decimal preference.

  Read Clock Variables (4): The command data field is empty or contains
  a list of identifiers separated by commas.  The association
  identifier selects the system clock variables or peer clock variables
  in the same way as in the Read Variables command.  The response
  includes the requested clock identifier and status word and the data
  field contains a list of clock variables and values, including the
  last timecode message received from the clock.

Where is the format of the "timecode message received from the clock"
specified?  Is it a binary or ASCII encoding?

Is there a list or registry for what the variables in question are?

  significant.  Implementations should include sanity timeouts which
  prevent trap transmissions if the monitoring program does not renew
  this information after a lengthy interval.

Can we give some more concrete guidance on what constitutes a "lengthy
interval"?  Days?

  Save Configuration (9): Write a snapshot of the current configuration
  to the file name supplied as the command data.  Further, the command
  is refused unless a directory in which to store the resulting files
  has been explicitly configured by the operator.

This file is still on the NTP server, right?

  Read ordered list (11): Retrieves an ordered list.  If the command
  data is empty or the seven characters "ifstats" the associated
  statistics, status and counters for each local address are returned.
  If the command data is the characters "addr_restrictions" then the
  set of IPv4 remote address restrictions followed by the set of IPv6
  remote address restrictions (access control lists) are returned.

This phrasing suggests that the command data is just the "name" part, not
a full "name=value" expression that was previously claimed to be the
format for the data section.

Section 6

I think it may be worth specifically calling out the trap mechanism as a
DoS vector as well as the generic "NTP control messages as DDoS vector"
discussion -- AFAICT spoofed UDP packets can register any number of
trap recipients and then a storm of outgoing packets can be prompted by
causing the trap condition.  (If there was only one registered trap
address/port active at any given time, this would be less of a concern,
but that doesn't seem to be the case.)

(There is also a related risk in terms of causing the NTP server to hold
all the state for so many trap registrations, but the state per address
seems relatively small.)

We should probably talk about the situation where a given message has
multiple name=value pairs for the same name, as security issues can
result when the parties disagree about which is to be used.  (Having
this rejected entirely as a protocol error is a fine option.)

There are probably some privacy considerations for some of the commands'
responses, e.g., the MRU gives information about who is using the
server, etc.

  However, this document argues that an NTP host must authenticate all
  control queries and not just ones that overwrite these variables.
  Alternatively, the host can use a whitelist to explicitly list IP
  addresses that are allowed to control query the clients.  These

What does "this document argues that" mean?  Is it a MUST-level
requirement?  (If so, then the text in the description of the Read
ordered list(11) command about "this opcode requires authentication" is
redundant and should be removed.)

Also, authentication does not inherently imply authorization; I think we
should say something about the server's authorization policy.

Also, we generally do not consider IP ACLs to be a security mechanism
(absent, e.g., IPsec), even if they can still have utility as a
front-line filtering option.

      *  In the client/server mode, the client stores its local time
        when it sends the query to the server in its xmt peer variable.
        This variable is used to perform TEST2 to non-cryptographically

What is TEST2/where is it documented?

  o  The mode 6 and 7 messages are vulnerable to replay attacks
      [CVE-Replay].  If an attacker observes mode 6/7 packets that
      modify the configuration of the server in any way, the attacker
      can apply the same change at any time later simply by sending the
      packets to the server again.  The use of the nonce (Request Nonce
      command) provides limited protection against replay attacks.

We seem to only document the usage of the Nonce for the Read MRU(10)
command, but the anti-replay functionality is generally useful.
Additional description of actual/intended nonce usage would be
beneficial.

  NTP best practices recommend configuring ntpd with the no-query
  parameter.  The no-query parameter blocks access to all remote

This is written in an implementation-specific manner and should be
rewritten to describe the protocol behavior -- "NTP best practices"
relate to the protocol, not the specific implementation.

  configuration of the hosts in certain scenarios.  Such hosts tend to
  use firewalls or other middleboxes to blacklist certain queries
  within the network.

There has been quite a bit of recent discussion on ietf@ relating to
terminology choices, as relates to "blacklist"/"whitelist" and other
terms.  I hope that the authors' usage of the term (both here and in
subsequent paragraphs) is an informed decision in light of those
community discussions.

Appendix A

  The format of the NTP Remote Facility Message header, which
  immediately follows the UDP header, is shown in Figure 3.  Following
  is a description of its fields.  Bit positions marked as zero are
  reserved and should always be transmitted as zero.

(I don't see any fields marked thusly; just the one "MBZ" field that has
its own description.)

  Implementation : The version number of the implementation that
  defined the request code used in this message.  An implementation
  number of 0 is used for a Request Code supported by all versions of
  the NTP daemon.  The value 255 is reserved for future extensions.

What is "the NTP daemon"?  A particular implementation?

  Data : A variable-sized field containing request/response data.  For
  requests and responses, the size in octets must be greater than or
  equal to the product of the number of data items (Count) and the size
  of a data item (Size).  For requests, the data area is exactly 40

I suggest saying more specifically which size it is that "must be
greater [...]".

[Ballot discuss]
I find myself in agreement with Eric Vyncke's remarks about a document claiming to provide "current but historic" protocol details.  Is this because NTPv3 is still in use?  But the title talks about NTPv4.  Shouldn't this document have "Historic" status?  The shepherd writeup says that's the intent, but that's not what the document's title page says.

Let's sort this out.

[Ballot comment]
** Section 4.  Can “Whitespace (ASCII) non-printing format effectors)” be specified more precisely?

** Section 6.  Per “… the host can use a whitelist to explicitly list IP addresses …”, consider s/whitelist/allow-list/

** References
-- Section 1.2.  Add an information reference for ntpdc

-- Section 6.  Add an informative reference for ntpd

** Editorial Nits

-- Global. Typo. s/developement/development/

-- Section 2. Typo. s/Conains/Contains/

-- Section 2.  Per “… this contains the authenticator information defined in Appendix C of RFC 1305”, please make RFC1305 a reference.

-- Section 4.  Typo.  s/managment/management/

-- Section 6.  Typo. s/atacks/attacks/

-- Appendix A.  Typo. s/reponse/response/

-- Appendix A.  Editorial. s/more then one packet/more than one packet/

[Ballot comment]
Thank you for the work put into this document.

First, I must admit that this is the first time I see an IETF stream informational document for the specification of a control protocol used by an obsoleted RFC 1305. This document is much easier to read than the appendix B of RFC 1305 and the author takes care to write that this spec is not mandatory to implement but I really wonder why this document exists ?

Moreover the abstract says "The goal of this document is to provide a current, but historic, " so why not publishing this document as 'historic' rather than 'informal' (datatracker seems to allow this modification).

Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs) and some NITs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1.1 --
Suggest to replace 'IP' by 'IPv4' in 'IP hosts are not required to reassemble datagrams larger than 576' + add some text that this document applies the same limitation to IPv6.

-- Section 2 --
Possibly linked to my lack of understanding of the purpose of this document, but, if applicable only to NTPv3, then should the Version number clearly specified to be 3 ?

-- Section 3.2 --
Suggest to add 'bit' after 'Peer Status' in the table headings to make it clear.

-- Section 4 --
It will probably be useful to expand 'MRU' at first use.

In the "Read ordered list (11):" it is not clear how the entries are ordered in the case of "ifstats" is it per local address ? Are IPv4 addresses before IPv6 addresses ?

-- Appendix A --
Is there a reason why the mode 7 is in the appendix and not in the main body ?


== NITS ==

-- Section 2 --
s/Conains/Contains/

-- Section 4 --
Should there be a comma in 'seven characters "ifstats" the associated' before 'the associated' ?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-ntp-mode-6-cmds-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-06-15):

From: The IESG
To: IETF-Announce
CC: ntp@ietf.org, ek.ietf@gmail.com, ntp-chairs@ietf.org, draft-ietf-ntp-mode-6-cmds@ietf.org, Karen O'Donoghue , odonoghue@isoc.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Control Messages Protocol for Use with Network Time Protocol Version 4) to Historic RFC


The IESG has received a request from the Network Time Protocol WG (ntp) to
consider the following document: - 'Control Messages Protocol for Use with
Network Time Protocol Version 4'
  as Historic RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-06-15. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the structure of the control messages that
  were historically used with the Network Time Protocol before the
  advent of more modern control and management approaches.  These
  control messages have been used to monitor and control the Network
  Time Protocol application running on any IP network attached
  computer.  The information in this document was originally described
  in Appendix B of RFC 1305.  The goal of this document is to provide a
  current, but historic, description of the control messages as
  described in RFC 1305 and any additional commands implemented in NTP.

  The publication of this document is not meant to encourage the
  developement and deployment of these control messages.  This document
  is only providing a current reference for these control messages
  given the current status of RFC 1305.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ntp-mode-6-cmds/



No IPR declarations have been submitted directly on this I-D.

This is the publication request and document shepherd write up for:

Control Messages Protocol for Use with Network Time Protocol Version 4
draft-ietf-ntp-mode-6-cmds-07

Prepared by: Karen O’Donoghue, 21 May 2020 

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Historic

This is a historic RFC to document a set of control messages that were left out of the the update to RFC 1305, RFC 5905.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes the structure of the control messages that were historically used with the Network Time Protocol before the advent of more modern control and management approaches.  These control messages have been used to monitor and control the Network Time Protocol application running on any IP network attached computer.  The information in this document was originally described in Appendix B of RFC 1305.  The goal of this document is to provide a current, but historic, description of the control messages as described in RFC 1305 and any additional commands implemented in NTP.

The publication of this document is not meant to encourage the developement and deployment of these control messages.  This document is only providing a current reference for these control messages given the current status of RFC 1305.

Working Group Summary:

The document has working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item.

Document Quality:
 
This document has been reviewed and revised several times during its development. There were no specific external expert reviews conducted. It has been stable for a long time and awaiting document shepherd writeup.
 
Personnel: 

Karen O'Donoghue is acting as the Document Shepherd.  Erik Kline is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
 
The document shepherd has followed the working group process and reviewed the final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
 
The document shepherd does not have any concerns about the reviews that were performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document does not require any special reviews beyond those planned during the IESG review process.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
 
The Document Shepherd is comfortable with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

There are no IPR filings on this document. The document shepherd has requested confirmation from all the authors that they are in full conformance with the provisions of BCP78 and BCP79 with respect to IPR disclosures.
 
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There are no IPR disclosures for this document.
 
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents strong WG consensus. It is an old and deployed technology, and this is an effort to rectify an oversight in the development of RFC 5905.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.

There have been no threats of anyone appealing the documents.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The document shepherd ran ID nits and found a few minor warnings that can be fixed on the next iteration. They are related to the fact that the draft has been waiting for the shepherd for so long.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no formal review criteria for this document.
 
(13) Have all references within this document been identified as either normative or informative?

All references are tagged as normative or informative.
 
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are completed.
 
(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of any existing RFCs. It does however complete the obsoleting of RFC 1305.
 
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA requests in this document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new IANA registries requested in this document.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There were no automated checks on formal language.

This is the publication request and document shepherd write up for:

Control Messages Protocol for Use with Network Time Protocol Version 4
draft-ietf-ntp-mode-6-cmds-07

Prepared by: Karen O’Donoghue, 21 May 2020 

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Historic

This is a historic RFC to document a set of control messages that were left out of the the update to RFC 1305, RFC 5905.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

This document describes the structure of the control messages that were historically used with the Network Time Protocol before the advent of more modern control and management approaches.  These control messages have been used to monitor and control the Network Time Protocol application running on any IP network attached computer.  The information in this document was originally described in Appendix B of RFC 1305.  The goal of this document is to provide a current, but historic, description of the control messages as described in RFC 1305 and any additional commands implemented in NTP.

The publication of this document is not meant to encourage the developement and deployment of these control messages.  This document is only providing a current reference for these control messages given the current status of RFC 1305.

Working Group Summary:

The document has working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item.

Document Quality:
 
This document has been reviewed and revised several times during its development. There were no specific external expert reviews conducted. It has been stable for a long time and awaiting document shepherd writeup.
 
Personnel: 

Karen O'Donoghue is acting as the Document Shepherd.  Erik Kline is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
 
The document shepherd has followed the working group process and reviewed the final document and feels this document is ready for IESG review.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
 
The document shepherd does not have any concerns about the reviews that were performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

This document does not require any special reviews beyond those planned during the IESG review process.
 
(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.
 
The Document Shepherd is comfortable with this document.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

There are no IPR filings on this document. The document shepherd has requested confirmation from all the authors that they are in full conformance with the provisions of BCP78 and BCP79 with respect to IPR disclosures.
 
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

There are no IPR disclosures for this document.
 
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The document represents strong WG consensus. It is an old and deployed technology, and this is an effort to rectify an oversight in the development of RFC 5905.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director.

There have been no threats of anyone appealing the documents.
 
(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The document shepherd ran ID nits and found a few minor warnings that can be fixed on the next iteration. They are related to the fact that the draft has been waiting for the shepherd for so long.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no formal review criteria for this document.
 
(13) Have all references within this document been identified as either normative or informative?

All references are tagged as normative or informative.
 
(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

All normative references are completed.
 
(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

There are no downward normative references.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of any existing RFCs. It does however complete the obsoleting of RFC 1305.
 
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA requests in this document.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

There are no new IANA registries requested in this document.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

There were no automated checks on formal language.