Living Documents

Evolving Documents

IETF105 - Montreal, 2019-0 V0.1

Checkpoint Drafts

Checkpoint Documents

Note Well

Disclaimers

• This is an idea / concept
  • It's not a hill worth dying on
  • .... far more discussion than we'd been expecting
• Many different use cases
  • One size does not fit all
  • One solution will not fit all
  • Possibly one solution suitable for many though

Stable Checkpoint is not carved in stone...

RSEs views...

• Interesting idea that has potential to improve the quality of RFCs published
• If this means fewer RFCs are published, that's OK
• None of this is in the official purview of the RFC Editor (but we really like the idea of producing ever-higher quality technical documents)

Use Cases

1. Operational documents
2. WG Support documents
3. Implementation documents
4. External documents
5. Protocol documents

Operational Documents

• This is where this started
• These are "advice", not protocol
• Changes frequently, not "worth" creating new RFC
  • V1: "you should filter routes using IRR"
  • V2: "you should filter routes using IRR and RPKI"
  • V3: "you should rank RPKI data over IRR"
• Terminology documents:
  • ​RFC7719 - DNS Terminology (Dec 2015)
  • RFC8499 - DNS Terminology (Jan 2019)
  • draft-hoffman-dns-terminology-ter-01...
• Hitchhikers Guide to... [SIP, DNS]

Implementation Documents

• QUIC / HTTPBIS name specific drafts as "implementation" drafts.
• Github document indicates which features are tested at each interop event.
• TSV tried to use Status Reports in the datatracker for similar functions. 
• A standard way of indicating the "state of play" for new implementers  would be useful. 

This is a different use case - not covered here.

WG Support documents

• Use case documents
• Requirements documents
• Lessons learned (we tried X, if failed like this...)
• Long term documents

Probably covered...

External documents

• This was an earlier use-case, based on an earlier mechanism
• A "stable" link to an external thing
• Not addressed in this design

Not covered

"Protocol" Documents

• Don't do this
• Trying to figure out how to mitigate this

AKA - end runs around the process...

Explicitly not supported

History / background

Abandoned mechanisms...

#1

Abandoned mechanisms...

#2

DataTracker Tag

• Easy to do
• Doesn't imply too much stability
• Hard for external people to understand

Currently proposed...

#3

Encoding in the name

• Easy to do
• Follows the "name changes when adopted" paradigm
  • draft-bob-grow-bar-19 -> draft-ietf-grow-bar-00 
  • draft-ietf-grow-bar-12 -> GROW-5 version 2
  • draft-ietf-grow-bar-22 -> GROW-5 version 3
  • GROW-5 redirect to latest (GROW-5 version 3)
• RFCs may not normatively reference IDs.
  • RFCs MAY NOT reference checkpoint docs
• "checkpoints" never become RFCs
  • the "underlying" document might
• Easy for external people to understand
• The term "checkpoint" may still imply more than intended

DRAFT disclaimer...

*************************************************
* This ID reflects the understanding of the WG that this
* version is stable enough to experiment with. Feedback
* will be considered by the WG, and potentially
* incorporated into an RFC (if published).
* It *has not* received IETF review, it is not an RFC, it
* is not set in stone. It is a snapshot in time of the
* current views, and is, like any ID, subject to change.
* This version of the document may not be used as
* reference material or cited.  If you build a test / PoC 
* implementation from this understand that it is all
* subject to change, YMMV, no warranty expressed or
* implied, etc etc etc.
*******************************************************

If so, how so?

1. A web page listing these?
2. A tag in the datatracker?
3. Encoding in the name?
   1. draft-checkpoint-grow-03
   2. checkpoint-ietf-grow-03
   3. GROW-3

• draft-bob-grow-bar-19 -> draft-ietf-grow-bar-00 
• draft-ietf-grow-bar-12 -> GROW-5 version 1
• draft-ietf-grow-bar-22 -> GROW-5 version 2
• GROW-5 always redirect to latest (GROW-5 version 3)
• If draft-ietf-grow-bar becomes RFC, GROW-5 redirects to that RFC

Example

Questions...

• Worth further discussion?
• What does "marking" a document mean?
  • How do we mark a document?
• What about only for Ops Area?