On Oct 5, 2022, at 11:36 AM, Peter Thomassen <pe...@desec.io> wrote:
>
> On 10/5/22 20:25, Paul Hoffman wrote:
>>> On 10/5/22 19:56, Paul Hoffman wrote:
>>>> I propose to replace that paragraph with:
>>>> What we today call "DNSSEC" is the DNSSEC specification defined in
>>>> {{RFC4033}}, {{RFC4034}}, and {{RFC4035}}.
>>>> However, earlier incarnations of DNSSEC were thinly deployed and
>>>> significantly less
>>>> visible than the current DNSSEC specification.
>>>
>>> I think that's much better, but it remains vague in that it leaves open
>>> what those other versions were.
>>>
>>> I know there are some RFCs that defined KEY records etc. Is that's what's
>>> meant? Perhaps we should add something like:
>>>> For the historic record of these, see RFC 2535 and related documents.
>>>
>>> (Or whatever is the appropriate set of documents.)
>> Given that we don't have clear version numbers, I would kinda prefer not to
>> do that. Does RFC 2535 represent a clear description of an earlier
>> incarnation/version of DNSSEC? It doesn't feel that way to me.
> I wasn't around at that time, so I don't know. Based on the fact that the
> current incarnation was dubbed version 3, I assumed that other revisions can
> be pointed to more or less precisely. Apologies if I misunderstood.
>
> My point is precisely that if we can't pinpoint what we mean by "earlier
> incarnations", the text shouldn't sound like they were stable versions that
> were merely thinly deployed.I fully agree that they shouldn't sound like stable versions, thus my use of the vague word "incarnations". I'm happy to use a different word that is even less version-like. > So, my suggestion would be that if we know what those incarnations are, let's > add references so people can dig further if they are interested. If we can't > point to a specification and/or don't know what those incarnations are, I > think it would be better to say they "... were not fully specified and saw > only little deployment" or not talk about them at all. I think we have to talk about them a bit so that the reader doesn't ask the question "how come there are DNSSEC RFCs that vastly pre-date 4033?". --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
