Come up with a meaningful plan for "living document" that contains what's now in Section 8

[SpencerDawkins]

From @evyncke

Living document concept is coming often as a topic for the IETF documents... and we have yet to find a right way of doing it. Expect a lot of discussions on this area and I have no solution to offer. Rather than using a tiny URL, why not a github one (hoping to have more control on it). We can probably live with this pending issue until the IESG evaluation. As the responsible AD, I will probe other IESG/IAB members for their best current advice on this topic.

[SpencerDawkins]

Dear @squarooticus and @ldaigle, cc: @evyncke who, I think, is holding the baton for this issue (but I can't assign it to him in Github)

1. We note that the TAO of the IETF is published as a web page, as described in RFC 6722. We could do the same.
2. A related possibility would be that the IETF create a subdomain mops.ietf.org (or something similar) where we can redirect a stable URL to "the right place".
3. Depending on when there would be a github subdomain in a domain we control ("github.ietf.org"?), as long as we control the domain, Github would be awesome.
4. We have discussed tinyURL, and that was rejected because the tinyURL domain may not be stable long-term.
5. Many other possibilities for a document which would be updated periodically have been suggested at least as far back as 2002 in Spencer's recollection, so let's pick something that works, OK? 😜

[evyncke]

One big question is of course whether this living document will still be "alive" even after MOPS WG is closed.

If not, then the easy solution is just one page in this repo (knowing that the IETF secretariat will always have admin right on it).

[squarooticus]

I like the idea of some kind of IETF-owned domain with a redirect that, at least for the foreseeable future, will point to the head revision of a single markdown file in a MOPS repo. The redirect at least means that if the IETF transitions away from GitHub that we won't have to create errata wherever the URL is embedded. Is there a straightforward way to make that happen? If so, who would/should I work with on (e.g.) the secretariat or tools team side?

[evyncke]

So, an IETF-owned tiny URL ? There is an IESG meeting mid-May (which is kind of late for this doc) where I put this 'living doc' item on the agenda. In this case, the only issue is WHO will take care of updating the redirect and the document when the MOPS WG is eventually closed. -éric From: Kyle Rose ***@***.***> Reply to: ietf-wg-mops/draft-ietf-mops-streaming-opcons ***@***.***> Date: Monday, 11 April 2022 at 17:01 To: ietf-wg-mops/draft-ietf-mops-streaming-opcons ***@***.***> Cc: Eric Vyncke ***@***.***>, Mention ***@***.***> Subject: Re: [ietf-wg-mops/draft-ietf-mops-streaming-opcons] Come up with a meaningful plan for "living document" that contains what's now in Section 8 (Issue #114) I like the idea of some kind of IETF-owned domain with a redirect that, at least for the foreseeable future, will point to the head revision of a single markdown file in a MOPS repo. The redirect at least means that if the IETF transitions away from GitHub that we won't have to create errata wherever the URL is embedded. Is there a straightforward way to make that happen? If so, who would/should I work with on (e.g.) the secretariat or tools team side? — Reply to this email directly, view it on GitHub<#114 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABC32HYE5Q3L24HFNYPTXSDVEQ47NANCNFSM5SXEBIBA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[squarooticus]

IANA seems like the right organization, though there might need to be a new function added to it for dealing with this kind of maintenance request.

[evyncke]

The "N" in IANA is about numbers though :-) But, they already do maintain some YANG modules (mainly related to numbers again). From: Kyle Rose ***@***.***> Reply to: ietf-wg-mops/draft-ietf-mops-streaming-opcons ***@***.***> Date: Monday, 11 April 2022 at 17:22 To: ietf-wg-mops/draft-ietf-mops-streaming-opcons ***@***.***> Cc: Eric Vyncke ***@***.***>, Mention ***@***.***> Subject: Re: [ietf-wg-mops/draft-ietf-mops-streaming-opcons] Come up with a meaningful plan for "living document" that contains what's now in Section 8 (Issue #114) IANA seems like the right organization, though there might need to be a new function added to it for dealing with this kind of maintenance request. — Reply to this email directly, view it on GitHub<#114 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABC32H4GPTQ25PE5T5P442LVEQ7Q3ANCNFSM5SXEBIBA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[squarooticus]

Well, "RFC" somehow means "You're too late to comment", so... 🤷‍♂️😉

[acbegen]

In this case, the only issue is WHO will take care of updating the redirect and the document when the MOPS WG is eventually closed.

That is the whole point behind the living document. It has not been too long since I wrote that living document but there are already some changes I would like to make. So, yes, this document could be living even long after MOPS is gone (as long as there are people who would like to maintain it).

Now I have two final comments on this:

1. Please let us decide and move on. This discussion has been dragging without any affirmative action for so long. The document has been ready (some minor things remaining) and we should ship it. If the group decides not to have a living document, that is fine, we keep the current version in there and accept the fact that the document will be less useful in a few years.
2. If we decide to have it, it should be something easy to update and maintain. If maintaining it will take too many cycles (permissions from various people/groups), nobody will likely do it.

Really, if the IETF does not accept some external URLs for a list of informative documents and cannot provide a meaningful tool to us, let's drop the whole thing.

[GrumpyOldTroll]

I don't (fully) agree with "let's decide and move on".

I agree we should not be long about it, but given the IETF doesn't currently have a well-defined process for maintaining a living document, it's reasonable to do a little work to help define one that will work for our use case and that comes with a plan for when we're not maintaining it. But it will probably take a bit of work that goes beyond merely deciding, since that work hasn't been done for us already.

So in the interest of doing that remaining bit of work, I'll suggest a few characteristics for the process and structure for the doc as a straw man proposal:

• The RFC should contain a single url with a domain under ietf.org or mops.ietf.org, and with a "/mops/" path element. (Perhaps also a "/streaming-opcons" element.)
  • At publication, the url should 301 redirect to a github pages location for a page inside a repo under the mops organization (https://github.com/ietf-wg-mops)
  • The url redirect can be updated as appropriate with wg or iesg consensus to use a different landing page plus a note to the ietf.org website maintainer.
• When the wg closes the IESG should delegate maintenance to a named set of experts (similar to expert review iana registries)
  • We could prepare a fallback html page now, saying "This is the fallback page indicating the living document for RFC XXX is no longer maintained and has been decommissioned. If you believe you've reached this document in error, please contact mops-chairs@ietf.org or the IESG." and leave it in the right location, but have it overridden with the 301.

And for content maintenance:

• The document should contain instructions for suggesting updates, to be confirmed by wg consensus on the mailing list (e.g. "This document is maintained by the mops working group, to suggest updates please write to mops@ietf.org with your suggestions and justification.")
• The document should be auto-scanned for dead links and they should be removed (automatically?) after a grace period (~1 week-ish?)
• The doc should include a link to older versions of itself (pointing to the github archive, which contains history) but should not be a hard requirement in the case we move to a different platform.

I expect there's some refinements that could improve this, but I think this would more or less do what it needs to, doesn't sound too burdensome, and defines a path for graceful degradation.

[evyncke]

May I suggest to be down to the ground ? I.e., we still have several steps:

1. finish the revised I-D based on the AD review
2. 2-week IETF last call
3. IESG telechat
4. 2-4 months before AUTH48

As long as the doc is not at AUTH48, editorial changes can be done. E.g., replacing a github.com/ietf-wg-mops/ URL into whatever (such as a 'IETF tiny URL').

In short, my proposal would be:

1. move everything that is 'living' in a .MD (or whatever) on in github.com/ietf-wg-mops/
2. add this reference in the I-D
3. let's hope that the IESG has a longer-term solution end of May, implemented before IETF-114

[acbegen]

Ok lets do what @evyncke says and hope the ietf can come up with something by auth48.

[SpencerDawkins]

This sounds perfect.

I might add that @acbegen did a LOT of the work on collecting the current contents of Section 8, and I certainly haven't read and formed an opinion on every resource, so naming two smart people we trust to maintain this "living resource" seems consistent with the way it was collected in the first place.

And, best of all, we don't need to describe how it's maintained in the RFC.

[SpencerDawkins]

The editors will yank Section 8 and put it in a separate markdown document, in (for now) the same repo as this draft, which will then point to that URL.

All of the angst about living documents can rest peacefully with the IESG. Best wishes to @evyncke.

[evyncke]

This sounds reasonable to me. At least for this document, still hoping that with the IESG we will come with a generic solution.

Thank you for the discussion

[SpencerDawkins]

@evyncke, do you think we're OK to close this issue?

(recognizing that if the discussions within the IESG about "living documents" go much better than we have any right to expect, we may be reopening this issue to do whatever the IESG thinks we should do)

[evyncke]

@SpencerDawkins indeed, the current I-D 'living part' is good enough to go IMHO.

[SpencerDawkins]

@evyncke - I'll close this issue for now, since we've been through IESG Evaluation (modulo Discuss and comments).