Shepherd writeup
rfc7234-26

[ Note that this report uses the alternate template as requested by the
AD
http://trac.tools.ietf.org/group/iesg/trac/wiki/
DraftShepherdWriteupWgAlternate ]

1. Summary

Mark Baker is the document shepherd. Barry Leiba is the responsible Area
Director.

draft-ietf-httpbis-p6-cache specifies the caching semantics of HTTP
messages and the conformance criteria for HTTP caches. The document
seeks Proposed Standard status as it attempts to obsolete (along with
the other draft-ietf-httpbis drafts) a previous standards track document
(RFC2616) and was developed under the compatibility constraints of the
working group charter.

Note that this document is part of a set, which should be reviewed together:

* draft-ietf-httpbis-p1-messaging
* draft-ietf-httpbis-p2-semantics
* draft-ietf-httpbis-p4-conditional
* draft-ietf-httpbis-p5-range
* draft-ietf-httpbis-p6-cache
* draft-ietf-httpbis-p7-auth
* draft-ietf-httpbis-method-registrations
* draft-ietf-httpbis-authscheme-registrations

2. Review and Consensus

Many of the experts in HTTP caching, representing some of the most
widely used implementations, were active participants in the working
group. Most of the discussions involved this core group of people, with
additional reviews and contributions by other experienced practitioners
and developers.

Discussion was relatively moderate, with the number of issues raised
being in the middle of the pack of the set of httpbis documents. The
participants in the discussions tended to be the same core of caching
experts, though with other experts in related topics, or those with
valuable experience to share, commonly contributing. External reviews
were not abundant, but due to the highly specific skill set required for
a full review, and the fact that many of the people in industry with
that skill set were participants in the working group, this shouldn't be
considered either surprising or a problem.

Only a small proportion of the issues required a prolonged discussion,
but in each case, consensus was reached through reasoned arguments
grounded in implementation experience using proposed text. I recall no
case where consensus could even be considered "rough", as discussions
were held back not primarily by strong disagreement, but by factors such
as detailed wordsmithing of complex descriptions, or a lack of
information with which a decision could be made (commonly, information
about deployed implementation behaviour, or some aspect of the history
of the protocol's development which needed to be unearthed). Issue
486[1] is a recent example of how some of the more complex discussions
went;

 [1]
 http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/thread.html
 #msg1040

3. Intellectual Property

Each editor has confirmed that they have no direct, personal knowledge
of any IPR related to this document.

4. Other Points

The document contains no normative downward references.

The document creates a new IANA registry for cache directives, and
requires that registration be done per "IETF Review" (RFC 5226 sec 4.1).
The choice for this option was based on its similarity to other
registries created by other httpbis documents and the potential for
complex interactions and potential interference between other
directives. No specific review of this registry was requested or
performed prior to last call. The prose describing registration review
does request that specific edge cases of new directives be documented,
where the list of edge cases was derived from the group's recent
experience in clarifying the meaning of many of the existing directives.

A registry for warning codes is also created. It also uses "IETF Review"
but for reasons of consistency and the ability to add section
references. There are none of the same complexities with new warning
codes as there are with cache directives so no review considerations are
provided. No specific review of this registry was requested prior to
last call.

The document populates both of its own registries with some existing
terms using internal references, but also updates the HTTP header field
registry for its five headers, with updated references from this
document.
Back