> b) Is step 3b (a short RFC that points to a specific version of an
> expired draft) acceptable? If not, what would be needed, given that
> the original author didn't want to progress their document?
When it comes to using a cryptographic algorithm in DNSSEC there are two parts
in the specificati
On Thu, 16 Jan 2025, Philip Homburg wrote:
b) Is step 3b (a short RFC that points to a specific version of an
expired draft) acceptable? If not, what would be needed, given that
the original author didn't want to progress their document?
When it comes to using a cryptographic algorithm in DNSS
In your letter dated Thu, 16 Jan 2025 11:40:22 -0500 (EST) you wrote:
>> We can assume that cryptographic algorithms will be developed outside the
>> IETF and that by the time we make such an algorithm a SHOULD or RECOMMENDED
>a
>> stable reference will be avaliable. So the thing the IETF needs to
On Thu, Jan 16, 2025 at 3:57 PM Paul Hoffman wrote:
> On Jan 16, 2025, at 12:26, Tim Wicinski wrote:
> >
> > (wearing no hats and perhaps less common sense)
> >
> > One thing I've not seen mentioned in this discussion on IETF standards
> track documents is Implementations and Interoperability.
>
(wearing no hats and perhaps less common sense)
One thing I've not seen mentioned in this discussion on IETF standards
track documents is Implementations and Interoperability.
I am sure everyone will say "of course we won't take something to SHOULD or
RECOMMENDED without implementations and intero
On Jan 16, 2025, at 12:26, Tim Wicinski wrote:
>
> (wearing no hats and perhaps less common sense)
>
> One thing I've not seen mentioned in this discussion on IETF standards track
> documents is Implementations and Interoperability.
> I am sure everyone will say "of course we won't take someth
