On Jun 30, 2021, at 12:43 AM, Joe Clarke (jclarke)
<[email protected]> 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.
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
