Security Automation and Continuous Monitoring (SACM) Requirements
draft-ietf-sacm-requirements-18

[Ballot comment]
Thanks for addressing my DISCUSS position and other comments. I am clearing my DISCUSS under the expectation that an upcoming revision will include the changes that have been discussed in email. I am keeping the first comment below for posterity, but I don't expect any action on it.


- I agree with the other abstain positions that the content in this draft doesn't seem to warrant publication as an RFC. I'm not going to abstain over it, since I think that sort of discussion should occur at charter or milestone adoption time.

[Ballot comment]
Hi Nancy,
> Hi Benoit,
> Thanks for the review and feedback.  Please see further comments below:
>
> On 6/21/17, 4:00 AM, "Benoit Claise (bclaise)"  wrote:   
>    ----------------------------------------------------------------------
>    COMMENT:
>    ----------------------------------------------------------------------
>   
>    -    3.  The information model MUST accommodate the interoperable
>            addition of new data types and/or schemas.
>   
>    I guess that you want to say: The data model MUST ...
>    See RFC 3444
> [NCW] The group actually debated “information model” vs “data model” extensively and
> decided on this language.
>   
>    -
>    Reading G-003, G-004, G-012, it seems like you want to be able to select your
>    "transport", with your own requirements.
>
>    However, I guess that, practically, you'll select a data model and the
>    transport will be obvious. MIB module => UDP IFPIX information elemeents =>
>    UDP/DTLS. Yeah, the specs say SCTP/TCP, but in practice ... YANG module, either
>    NETCONF => TCP/SSH or RESTCONF => HTTPS Not sure I believe into a single
>    transport to rules them all, where "them" is all the different data model
>    source of information. This was already my feedback during your previous
>    interim meeting (where I presented yangcatalog.org): your information model
>    draft is basically of a mix of elements already specified in IPFIX, YANG
>    module, MIB module. How do you consolidate all this?
> [NCW] There will be data models that are only suitable for specific transfer models
> and specific transport layers (ROLIE for example as a discovery lends itself better at
> an HTTP and not so much in MIB).  The Information model is meant to be a “raw”
> definition of elements/attributes that can them be mapped into specific data models
> (the group for instance is looking at SWID, others are looking at netconf) etc….
>   
>    Same remark with "2.5 requirements for data model operations".
>    You select your data model and the data model operations are given/specified
>    already Let's say: IPFIX. From there you have a push mechanism only (as opposed
>    to pull). Let's say: YANG module. From there you select NETCONF or NETCONF, and
>    the operations are already specified.
> [NCW] In essence, that is correct.
>   
>    -
>      The SACM information model MUST include the
>        ability to discover and negotiate the use of a particular data model
>        or any data model.
>   
>    What does it mean "negotiate"?
>    Either an end point supports a data model or it doesn't, no?
>
>    Same remark for:
>        DM-007  Data Model Negotiation: The interfaces and actions in the
>        data model MUST include capability negotiation to enable discovery
>        of supported and available data types and schemas.
> [NCW] In this context, “Negotiate” is the means by which two parties can agree on the data model to be used.
> The “means” could be data model and/or transfer protocol specific….but the intent is to enable that thru
> The abstraction to allow for that should be in the Information model definition.

>
>
>   
>    - Read the following one multiple times, and I still don't understand it:
>        IM-005  Data Lifetime Management: The information model MUST provide
>        a means to allow data models to include data lifetime management.
> [NCW] It is really meant to be a means by which the consumer of the information can know when that data may be obsoleted (updated, changed or removed).
What about trying to make the text clear(er)?
>
>   
>    -
>    The SACM information model represents an abstraction for "what"
>        information can be communicated and "how" it is to be represented and
>        shared.
>   
>    Not sure it's aligned with RFC3444:
>                  IM                --> conceptual/abstract model
>                  |                    for designers and operators
>        +----------+---------+
>        |          |        |
>        DM        DM        DM    --> concrete/detailed model
>                                        for implementors
>
> [NCW] We really have tried….if it isn’t clear, I am open to making it more so but
> the resulting draft and definitions come from much debate and final agreement from the WG.

What I considered to be an easy COMMENT turned out more complicated that I thought. I guess that we'll agree to disagree.
I don't feel that this data model/information model discussion will be resolved to my OPS-view satisfaction.
I can't support this document publication and I don't want to spend energy to try to convince people for this COMMENT
Since I don't want to be in the way, I'll ABSTAIN.

Regards, Benoit

[Ballot discuss]
(Resending because I forgot to hit the "send email" button this first time. No other change.)

The SACM charter requires the group to " whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. " If that is reflected anywhere in the requirements, I missed it. (which is possible.) In particular, I think section 2.6 needs to include requirements to favor use of existing "transfer protocols".  (As written, T-001 seems almost tailored to counter arguments to "just use HTTP".)

[Ballot comment]
I generally dislike "requirements" documents, as most WG are not going to check final protocol against requirements. However I can see that such documents can be sometimes useful.

I have some specific comments on Section 2.6. It generally looks very confused on transport protocol versa transfer protocol, which I don't think are synonyms:

2.6.  Requirements for SACM Transport Protocols

I think you meant "Transfer Protocol" in the section title, as my understanding that "SACM transfer protocol" != "SACM transport protocol"?

  The term SACM transfer protocol is intended to be distinguished from
  underlying layer 3 and 4 protocols such as TCP/IP, operating at an
  equivalent level as the hyperText transfer protocol (HTTP).  The SACM
  transfer protocol is focused on moving data and performing necessary
  access control operations; it is agnostic to the data model
  operations.

  The requirements for SACM transport protocols include:

Again, do you mean "transfer protocol" here?

(snip)

  T-003  Data Confidentiality: SACM transfer protocols MUST be able to
    support data confidentiality.  SACM transport protocols MUST ensure

Do you really mean "transport protocol" above? This will rule out both TCP and UDP.

    data protection for data in transit (e.g. by encryption) to provide
    confidentiality, integrity, and robustness against protocol-based
    attacks.  Note that while the transport MUST be able to support data
    confidentiality, implementations MAY provide a configuration option
    that enables and disables confidentiality in deployments.
    Protection for data at rest is not in scope for transport protocols.

Again, "transfer protocols"?

    Data protection MAY be used for both privacy and non-privacy
    scenarios.

[Ballot comment]
I see little value in spending RFC editor resources on publishing this document, but don't feel strongly enough about it to abstain. I would be happy to see this document declared as having been useful for the working group's internal purposes, and having already served the entirety of its purpose, not progressed to an RFC.

[Ballot discuss]
The SACM charter requires the group to " whenever reasonable and possible, reuse existing protocols, mechanisms, information and data models. " If that is reflected anywhere in the requirements, I missed it. (which is possible.) In particular, I think section 2.6 needs to include requirements to favor use of existing "transfer protocols".  (As written, T-001 seems almost tailored to counter arguments to "just use HTTP".)

[Ballot comment]
General:

- I agree with the other abstain positions that the content in this draft doesn't seem to warrant publication as an RFC. I'm not going to abstain over it, since I think that sort of discussion should occur at charter or milestone adoption time.

- I don't think the contents of this draft warrant the use of 2119 keywords. While I think it reasonable to sometimes use 2119 keywords to add precision and clarity to requirements on standards work, many of the requirements in this draft seem vague and hand-wavy. All-caps MUSTs and SHOULDs only serve to give the appearance of precision and verifiability. I mention a few more glaring instances in my detailed comments, but those are not exhaustive.

Specifics:

- 1.1, 2nd paragraph: If you stick with using normative keywords, but want to disclaim lower case versions, please consider switching to the boilerplate from RFC 8174.

- 2.1 (and rest of document): I assume the requirements numbering scheme means something. It would be helpful to describe that scheme prior to use.

- g-001: "SACM MUST allow
    implementations to use their own extensions; either proprietary data
    models, protocols or extensions to SACM data models or protocols
    could be used though they are not considered to be SACM compliant."

That seems to say that SACM must allow extensions, but those extensions would not be considered compliant. That seems like a contradiction. As worded with the MUST, it seems like it says SACM cannot prevent implementations from doing non-interoperable things.

- G-002: This is the whole point of IETF processes. It seems odd to state it as a requirement.

- g-003: It seems like you are using "datagram" in an unconventional way. A definition would help.

- g-004: "...MUST be suitably specified..." is vague and unverifiable.

- G-005: "For interoperability and
    scope boundary,"
I don't understand what "scope boundary" means in that clause.

- G-006: Is this a requirement for e2e protection? It seems like it is, but the description is vague. In particular, I cannot tell if the mention of middleboxes is to say that middleboxes should not be able to read or modify traffic, or if it is to say that middleboxes may be part of the architecture and actually need that sort of access. (Also, the requirement title says "integrity", but the text seems to be about both integrity and confidentiality.)

- G-015: "... accommodate considerations such as geographic,
    regulatory, operational and federations..." seems vague for use with a MUST.

- ARCH-004: "The fact that a centralized or
    decentralized deployment is used SHOULD be invisible to a consumer."
Can you elaborate on why? Might not a consumer want to consider the nature of a data source?

- 2.6: The section switches between saying "transport protocols" and "transfer protocols" Please be consistent.

- T-001: I think this needs some elaboration, or a citation to elaboration somewhere else. Otherwise, it seems like this assertion opens the door for a lot of complexity and lack of interoperability.

[Ballot comment]
I do see the value of writing up the requirements to guide further work in the WG, but I do not see that value of publishing them in a standalone RFC. I would have much preferred the requirements to be included in the other WG deliverables (as Alvaro and Terry have noted). I do respect the WG's intent to publish and I am abstaining to move out of the way.

[Ballot comment]
I spent a while trying to figure out how to ballot on this - I personally see value in requirements, use-cases and similar (informational) documents - they help newcomers to the technology understand how and why it is shaped as it is. This document is also (kind of) mentioned in the charter ("A document or documents describing the SACM Architecture. This will include protocol requirements and their associated use cases as well as a description ..." , and so I've decided on Yes

However, there are still some comments / nits which should be addressed, including:

Abstract:
"The requirements and scope are based on the agreed upon use cases." -- what use cases / agreed upon by whom? (Missing ref).

1. Introduction
"Today’s environment of rapidly-evolving security threats highlights the need to automate the sharing of security information (such as posture information) while protecting user information as well as the systems that store, process, and transmit this information." - "... user information as well as the systems" -> "user information and the systems" ? Not sure if this is better....

2.  Requirements
I got somewhat lost in "A SACM transport protocol is one that runs on top of L3 protocols such as TCP/IP or L4 protocols such as HTTP, carries operations (requests / responses), and moves data." - perhaps "A SACM transport protocol is one that runs on top of L3 protocols (such as TCP/IP) or L4 protocols (such as HTTP), carries operations (requests / responses), and moves data."

3: "With the information model defining assets and attributes to facilitate the guidance, collection, and assessment of posture, these are some of the tasks that should be considered:" - the "With" and "these" feel unrelated. I'm not really sure how they are supposed to tie together, so I cannot suggest text.

G-001
"2.  The query language MUST allow for general inquiries, as well as expression of specific attributes or relationships between attributes to follow; the retrieval of specific information ..." -- I don't really understand the "to follow"; can it be struck?

G-002
"Interoperability: The data models, protocols, and transports  must be specified with enough details to ensure interoperability." -- I really don't understand the point of saying this - are you expecting that if you *didn't* say this that people would intentionally create models without enough detail? Is this just a "motherhood and apple pie" statement?

G-006
"Mechanisms for this protection are unspecified but should include industry best practices such as encrypted storage, encrypted transports, data checksums, etc. " -- the list of best practices seems harmful;  if you provide a list people will implicitly assume it is exhaustive, and industry best practices change over time. Also, what is a "data checksum"? I'm assuming you mean something "cryptographic checksums" or "secure hash" - a data checksum implies something like a simple CRC. I'd suggest just dropping the "such as..." list.

IM-004
"Data Model Identification: The information model MUST provide a means to uniquely identify each data model uniquely." - you really really want this to be unique, don't you :-P

5.2.  Privacy Considerations
"In addition to identity and SACM capabilities information disclosure, the use of time stamps or other attributes that can be used as identifiers especially as they are coupled with an identity can be further used to determine a target endpoint or user’s behavioral patterns." -- this sentence could use some work. I agree with what it is trying to say, but it is long and confusing. Perhaps:
"In addition to identity and SACM capabilities information disclosure, the use of time stamps (or other attributes that can be used as identifiers) could be further used to determine a target endpoint or user’s behavioral patterns." -- I *think* that that maintains the meaning, but is clearer.

"Data confidentiality can provide some level of privacy but may fall short where unecessary data is still transmitted." - "unnecessary" (typo)

[Ballot comment]
I too don't see the particular value of having this published as an RFC, but understand that the WG may view it differently. I offer the comments below for what they're worth.

I think the document sows confusion in its use of the terms "transport protocol" and "transfer protocol." They appear to be used interchangeably (maybe? I'm not actually entirely sure), there seem to be claims that HTTP is a L4 transport protocol, and although the terms "SACM transport protocol" and "SACM transfer protocol" are used and vaguely defined in the draft, they are not defined in the terminology document. If this document goes forward it seems like an edit pass to clarify what is meant with these terms each time they are used, and their relationship to what we typically think of as a "transport protocol," is warranted.

I would have thought target location information would be specifically called out in Section 5.2.

I have not seen a response to the Gen-ART review.

[Ballot comment]
-    3.  The information model MUST accommodate the interoperable
        addition of new data types and/or schemas.

I guess that you want to say: The data model MUST ...
See RFC 3444

-
Reading G-003, G-004, G-012, it seems like you want to be able to select your "transport", with your own requirements.

However, I guess that, practically, you'll select a data model and the transport will be obvious.
MIB module => UDP
IFPIX information elemeents => UDP/DTLS. Yeah, the specs say SCTP/TCP, but in practice ...
YANG module, either NETCONF => TCP/SSH or RESTCONF => HTTPS
Not sure I believe into a single transport to rules them all, where "them" is all the different data model source of information.
This was already my feedback during your previous interim meeting (where I presented yangcatalog.org):
your information model draft is basically of a mix of elements already specified in IPFIX, YANG module, MIB module.
How do you consolidate all this?

Same remark with "2.5 requirements for data model operations".
You select your data model and the data model operations are given/specified already
Let's say: IPFIX. From there you have a push mechanism only (as opposed to pull).
Let's say: YANG module. From there you select NETCONF or NETCONF, and the operations are already specified.

-
The SACM information model MUST include the
    ability to discover and negotiate the use of a particular data model
    or any data model.

What does it mean "negotiate"?
Either an end point supports a data model or it doesn't, no?

Same remark for:
  DM-007  Data Model Negotiation: The interfaces and actions in the
    data model MUST include capability negotiation to enable discovery
    of supported and available data types and schemas.

- Read the following one multiple times, and I still don't understand it:
  IM-005  Data Lifetime Management: The information model MUST provide
    a means to allow data models to include data lifetime management.

-
The SACM information model represents an abstraction for "what"
  information can be communicated and "how" it is to be represented and
  shared.

Not sure it's aligned with RFC3444:
              IM                --> conceptual/abstract model
              |                    for designers and operators
  +----------+---------+
  |          |        |
  DM        DM        DM    --> concrete/detailed model
                                  for implementors

[Ballot comment]
I am balloting ABSTAIN on this document as I don't see strong value in a set of requirements as a standalone document added to the RFC series. I appreciate it's an extension of the use-cases document and a WG milestone but it reads like the architecture and info model is already done (and indeed WG revisions of that work look mature). In which case I STRONGLY urge that the 10 pages of requirements be placed (as required) in appendices of the milestone documents (information-model, data-model, protocol/Interface, architecture etc). This maintains the rationale for the designs in question and aids the reader in comprehension of the work.

That said, with ABSTAIN positions, I am not blocking publication of this document and I shall leave it to the responsible AD to adjudicate.

[Ballot comment]
    *  Large datagrams: It is possible that the size of posture
      assessment information can vary from a single assessment that is
      small in size to a very large datagram or a very large set of
      assessments (up to multiple gigabytes in size).

I would consider saying "message" here, because I usually think of "datagram" as ~= packet/IP datagram.

[Ballot comment]
I am ABSTAINing because I don't see publication value for this document given that the architecture and the information model are already done (or at least in an advanced state).  I understand the interest of the WG to document the requirements as an RFC, so I won't stand in the way of publication.

Having said that, if the original intent was for this document to be used as input for the development of the architecture, consider updating some of the text so that there's no mix of "timing": the text should probably read as if the architecture/information model don't exist yet; there are no references to them (which is good), but the text makes some mention of them... For example:

Section 2 (Requirements) says that it "describes the requirements used by SACM to assess and compare candidate data models, interfaces, and protocols, to suit the SACM architecture."  I'm guessing that "will be used", and that "by SACM" refers to the WG (SACM by itself is used extensively throughout).  Note that the end says "to suit the architecture", which sounds like the architecture is a foregone conclusion and the requirements are just for the rest.

Also in Section 2: "SACM defines an architecture and information model focused on addressing the needs for determining, sharing, and using posture information via Posture Information Providers and Posture Information Consumers mediated by a Controller."  I didn't check, but this sounds like a quick description of the architecture and information model -- both of which would be developed based on this document.

[Ballot comment]
I'm following along with Mirja's Abstain, although I'm balloting No Objection.

I'm looking at

T-005  Transport Reliability: SACM transfer protocols MUST provide
    reliable delivery of data.  This includes the ability to perform
    fragmentation and reassembly, and to detect replays.  The SACM
    transfer may take advantage of reliability features in the network
    transport; however, the network transport may be unreliable (e.g.
    UDP), in which case the SACM transport running over the unreliable
    network transport is responsible for ensuring reliability (i.e. by
    provisions such as confirmations and re-transmits).
   
and wondering why you'd want to run SACM transfer protocols over UDP in the first place (and, assuming there's a fabulous reason to do that, why you wouldn't run those protocols over UDP in all cases).

This is a No Objection position, but please recognize that these protocols would be simpler if they were running over TCP.

[Ballot comment]
I'm following along with Mirja's Abstain, although I'm balloting No Objection.

I'm looking at

T-005  Transport Reliability: SACM transfer protocols MUST provide
    reliable delivery of data.  This includes the ability to perform
    fragmentation and reassembly, and to detect replays.  The SACM
    transfer may take advantage of reliability features in the network
    transport; however, the network transport may be unreliable (e.g.
    UDP), in which case the SACM transport running over the unreliable
    network transport is responsible for ensuring reliability (i.e. by
    provisions such as confirmations and re-transmits).
   
and wondering why you'd want to run SACM transfer protocols over UDP in the first place (and, assuming there's a fabulous reason to do that, why you wouldn't run those protocols under UDP in all cases).

This is a No Objection position, but please recognize that these protocols would be simpler if they were running over TCP.

[Ballot comment]
I abstain because I don’t think there is a achievable value in publishing this document in the RFC series (for consumption outside the wg). However, I also don’t understand why there is a requirement to support multiple transport protocols, including potentially UDP. I don’t think this is worth a discuss on this document but if SACM plans to invent a new transport (over UDP) instead of just using TCP which seems more than appropriate, it needs a real justification for that (which is at least in this document not at all given)!

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

The IANA Services Operator has reviewed draft-ietf-sacm-requirements-15.txt, 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
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: sacm-chairs@ietf.org, sacm@ietf.org, odonoghue@isoc.org, Karen O'Donoghue , draft-ietf-sacm-requirements@ietf.org, Kathleen.Moriarty.ietf@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Security Automation and Continuous Monitoring (SACM) Requirements) to Informational RFC


The IESG has received a request from the Security Automation and
Continuous Monitoring WG (sacm) to consider the following document:
- 'Security Automation and Continuous Monitoring (SACM) Requirements'
  as Informational 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
ietf@ietf.org mailing lists by 2017-06-05. 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 defines the scope and set of requirements for the
  Secure Automation and Continuous Monitoring (SACM) architecture, data
  model and transport protocols.  The requirements and scope are based
  on the agreed upon use cases.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/ballot/


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

draft-ietf-sacm-requirements shepherd write-up

(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?

This document is being requested for publication as an Informational RFC. It provides requirements for the Secure Automation and Continuous Monitoring (SACM) architecture, data model, and transport protocols. The intended status is shown on the title page.

(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 defines the scope and set of requirements for the Secure Automation and Continuous Monitoring (SACM) architecture, data model and transport protocols.  The requirements and scope are based on the agreed upon use cases.

Working Group Summary:

The document has clear 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 many times. It is well written and clear. There were no specific external expert reviews conducted.

Personnel:

Karen O'Donoghue is acting as the Document Shepherd.  Kathleen 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 as a set of requirements to drive the SACM working group efforts in the future. The documents represent the consensus of the working group.

(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?

The authors have confirmed that they have dealt with all appropriate 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.

No IPR disclosures have been filed that reference 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.

(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 copyright year in the IETF Trust and authors Copyright Line does not      match the current year   
-- The document date (December 27, 2016) is 131 days in the past.  Is this intentional?
This is an artifact of the delay in writing the shepherd report. The document was published in December 2016. When revised based on comments received, the dates will be correct.

== Outdated reference: A later version (-12) exists of draft-ietf-sacm-terminology-11 
This is also an artifact of the delay in writing the shepherd report. It will be corrected when a final way forward for the terminology reference is determined.

(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?

There is currently a normative reference to a work in progress document (Birkholz, H., Lu, J., Strassner, J., and N. Cam-Winget, "Secure Automation and Continuous Monitoring (SACM) Terminology", draft-ietf-sacm-terminology-11 (work in progress), September 2016.) As part of the shepherd review, I am not sure how to proceed here, and I look to the AD for guidance. Since the intention is not to finish the terminology document anytime soon, it should not be listed as a normative reference.

(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 in the document.

(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 will not change the status of any existing RFC.

(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 new IANA considerations contained 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 considerations contained 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 are no formal language sections in this document.

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

UDP Checksum Complement in the Network Time Protocol (NTP)
draft-ietf-ntp-checksum-trailer-03.txtdraft-ietf-ntp-checksum-trailer

Prepared by: Karen OÕDonoghue, 3 Feb 2016

(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?

This document is being requested for publication as an Experimental RFC as properly indicated on the top of the document. This document results in no changes to the NTP protocol.

(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:

The Network Time Protocol (NTP) allows clients to synchronize to a time server using timestamped protocol messages. To facilitate accurate timestamping, some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing NTP packet during transmission. Since these packets are transported over UDP, the UDP checksum field is then updated to reflect this modification. This document proposes an extension field that includes a 2-octet Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets of the packet rather than in the UDP checksum field.

Working Group Summary:

The document has clear working group consensus for publication, and has been reviewed by several WG participants since its initial adoption as a working group item. This document is similar to the ÒUDP Checksum Complement in OWAMP and TWAMPÓ (draft-ietf-ippm-checksum-trailer-05.txt) in the IPPM working group.

Document Quality:
Ê
This document has been reviewed and revised several times during its development. There were no specific external expert reviews conducted.
Ê
Personnel:Ê

Karen O'Donoghue is acting as the Document Shepherd.Ê Brian Haberman 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 as a simple definition of an experimental NTP extension header to support a checksum complement. The documents represent the consensus of the working group.

(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?

The authors have confirmed that they have dealt with all appropriate 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 is one IPR disclosure made that is relevant to this document. This disclosure is in line with IETF policy for IPR used in IETF documents.
https://datatracker.ietf.org/ipr/2369/
Ê
(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.
Ê
(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 ID nits tool was run with the following results:
Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).

The warning are both related to the fact the document was last updated in Oct 2015. The comment refers to a missing reference that will be fixed in the next update of the document ([NTP] --> [NTPv4])

(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 RFC.
Ê
(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 new IANA considerations contained 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 considerations contained 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 are no formal language sections in this document.