Shepherd writeup
rfc8263-07

Shepherd write-up for draft-weis-gdoi-rekey-ack-05

> (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 requested for publication as a Standards Track RFC with AD sponsorship.

The document defines a protocol extension to RFC 6407 which is itself a Standards Track document.
Thus, Standards track is appropriate for this document as indicated on the title page.

Notes:
1. Although this document defines an extension to RFC 6407 it does not Update that RFC because
   it is not a requirement that future implementations of RFC 6407 include the function described
   in this document.

2. This document is advanced for publication as AD sponsored because there is no current WG
   dedicated to this work, but the work is very definitely within the purview of the IETF.

> (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 Group Domain of Interpretation (GDOI) defined in RFC 6407 includes the ability for a Group
Controller/Key Server (GCKS) to provide a set of current Group Member (GM) devices with additional
security associations (e.g., to rekey expiring security associations).  GDOI meets the requirement
of the Multicast Security (MSEC) Group Key Management Architecture (RFC 4046), and defines both a
Registration Protocol and Rekey Protocol.

Usually the GCKS does not require a notification that the group member actually received the policy.
However, in some cases it is beneficial for a GCKS to be told by each receiving GM that it received
the rekey message and by implication has reacted to the policy contained within.

This memo adds the ability of a GCKS to request the GM devices to return an acknowledgement of receipt
of its rekey message, and specifies the acknowledgement method.

> Working Group Summary

This document is not the product of a WG there being no working group for which this work is
specifically in scope.  The MSEC WG would have been the logical place for the work, but it closed
several years ago.

Attempts to gather interest in the Security Area and specifically the IPSECME WG were not successful.

That said, there were no responses indicating controversy about or objection to the technical work.

> Document Quality

Two vendor implementations are "in the pipe".
Review has been light other than the shepherd's review (q.v.). However, the document is short and
simple.

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

I reviewed -04 and found a number of points that needed clarification, and some nits.
These have been fixed in -05 to my satisfaction.
I had no issues with the substance of the technical solution.

> (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that
>     have been performed?

More would have been good, but given the implementation status and the simplicity of the work, I
think it is OK.

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

No.

> (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 interested community has discussed those issues
>     and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

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

All authors have confirmed to me by email.

> (8) Has an IPR disclosure been filed that references this document? If so, summarize any discussion
>     and conclusion regarding the IPR disclosures.

IPR has been disclosed at https://datatracker.ietf.org/ipr/2217/
There has been not public discussion of this IPR that I am aware of.
The license terms are "MAD"

> (9) How solid is the consensus of the interested community behind this document? Does it represent
>     the strong concurrence of a few individuals, with others being silent, or does the interested
>     community as a whole understand and agree with it?

The community of interest is very small. It appears to be limited to the implementers at two vendors,
and the operators at one service provider. They are all represented as co-authors.

> (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please
>      summarise the areas of conflict in separate email messages to the Responsible Area Director.
>      (It should be in a separate email because this questionnaire is publicly available.)

No threats.

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

Nits are clean except for a warning about a reference to RFC 2408 that has been obsoleted.
See item 14).

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

N/A

> (13) Have all references within this document been identified as either normative or informative?

Yes

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

This document has a normative reference to RFC 2408.
RFC 2408 was obsoleted by RFC 4306 which was itself obsoleted by RFC 5996, which was obsoleted in its
turn by RFC 7296.

However, a normative reference to RFC 2408 seems right, as follows...

When RFC 2408 was obsoleted it was assumed that the only interesting user of ISAKMP was IKE and since
IKEv1 was being replaced by IKEv2 it appeared to make sense to obsolete the base RFCs (RFC 2407, 2408,
2409).

At the time, GDOI was still using RFC 2408 and RFC 2409, and no attempt was made to update/obsolete
the GDOI spec. (Hearsay has it that the security ADs at the time said that this was OK.)

So the questions are:
- Why not make a reference to RFC 7296 from this document?
  Unfortunately, the namespaces and payload formats are not all identical, and the protocols
  themselves are very different.
- Why not move GDOI to IKEv2 instead of IKEv1?
  Firstly, this would be a substantial piece of work.
  Secondly, there are GDOI-based VPN deployments (and a specific one that exercises the authors) that
  need to be kept functional rather than subjected to a major upgrade.
  Lastly, there is a GDOI-like protocol based on IKEv2 that may see implementation and deployment one
  day (https://tools.ietf.org/html/draft-yeung-g-ikev2-11) thereby replacing GDOI, but that is not
  ready for action yet.

Hence the reference seems good.

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

N/A

> (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 interested community considers it unnecessary.

N/A

> (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).


My review gave rise to some updates.
All good now.

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

This documnt defines two new registries (see Section 8) that use "Specification Required" as the
assignment policy. That implies the use of expert Review as described in RFC 5226.

DEs should be familiar with ISAKMP.


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

N/A
Back