Re: [OPSAWG] [Qlog] adopting draft-gharris-opsawg-pcap and draft-tuexen-opsawg-pcapng

[Guy Harris <[e-mail]>]

On Jun 30, 2021, at 12:43 AM, Joe Clarke (jclarke) <jclarke=[e-mail]> wrote:

> Given how systemd is prone to considerable change, I'd think it would be
> best to leave that out.

"systemd" is at least two different things.  It started out as a replacement for the various versions of the UN*X "init" process in Linux, launching daemons on demand similarly to Darwin's launchd.  It then grew into a bigger project providing a bunch of other system daemons, written to assume that the systemd process handled the launching of other daemons.

One of the other daemons is journald, which is a syslogd replacement:

	https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html

The "systemd" block in pcapng is called the "systemd Journal Export Block"; it doesn't cover systemd as a whole, it just covers the format that journald uses to export entries from its log file.  The description of the export block points to the description of the export format:

	https://www.freedesktop.org/wiki/Software/systemd/export/

I can't state for certain that this format is intended to be extensible in a compatible fashion, so that it can be *extended* but won't be *incompatibly changed*, but that might end up being the case.

Given that the description of the systemd Journal Export Block largely punts the description of the format to the freedesktop.org page about the format, describing only a "wrapper" for a journal entry in the export format, it doesn't bother me *too* much to put it into the spec.

By the way, a few registries under

	https://www.iana.org/protocols

that I've looked out have some entries that point to RFCs and other entries that just have an email address for a contact.

Do any of those RFCs point to an external specification for most of the information about the item being discussed, similarly to what's the case for the systemd Journal Export Block?

Are there any registries that have "less than an RFC and more than a mailto: URL", i.e. that say more than just "ask this person, hopefully they're still around, still have that email address, and still remember what this entry in the registry was all about"?

> That said, the pull request language in -03 has
> me curious.  If someone were to raise a PR against this doc, that would
> be outside the IETF process.  Is the intent then that this would leave
> to a bis or other draft to update this document?  And if so, is that
> desirable, or would it be better to have this live in GitHub outside of
> the IETF process altogether (like the semver spec does)?

Is "the server spec" referring to the specifications that draft-claise-semver-00:

	https://tools.ietf.org/id/draft-claise-semver-00.html

is discussing?  That sounds as if it's handling the part of the process up to the submission of an I-D, and that the regular I-D -> RFC process takes effect once the spec is submitted as an I-D.  That document itself wasn't outside the IETF process, as it was an I-D (now expired), and the prices it described appeared to be for documents that eventually become handled by the IETF process.