Re: [openpgp] Éric Vyncke's No Objection on draft-ietf-openpgp-crypto-refresh-12: (with COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya,

Answering the shepherd-like questions...

On 13/12/2023 09:59, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-openpgp-crypto-refresh-12: No Objection

Thanks!

> # COMMENTS (non-blocking)
> 
> ## The most concise shepherd's write-up
> 
> The justification for the intended status is just "PS"... not even expanded...

It seemed obvious:-) If you'd like it in more words, this is
adding new crypto as a revision of a complex spec that has
lots of history and significant deployment so PS seems like
the only sensible target.

> ## Abstract
> 
> Isn't the 2nd paragraph (especially the first sentence) applicable to all
> standards track document? I.e., why not removing it ? 

It's inherited from RFC4880, and RFC2440 before that, so probably best
left in I'd say, mostly on the basis that (as a chair) I don't want to
re-open the document except as is really necessary.

> (and I have noted the
> very rough consensus about this I-D based on the shepherd write-up).

Not sure "very rough" is right in this case so maybe the write-up was
a bit misleading (sorry if so). There's good consensus among currently
active WG participants, which includes a set of implementers. The issue
is that the main contributor to one important implementation no longer
support the draft. That's a shame IMO, but doesn't make the consensus
very rough.


> ## Section 3.5
> 
> Should another time epoch be specified ? Using the 1970 Unix epoch will cause a
> problem in 2038, a not too distant future. Why didn't this revised OpenPGP
> propose alternative epoch ?

Answered already.

> 
> ## IANA registries
> 
> Should this I-D be an opportunity to reserve some registry values for a FCFS
> allocation ?

The WG did not discuss FCFS, but did explicitly discuss lowering the bar
for registration of new codepoints in many registries. I'd be surprised
though if there was consensus to take that as far as FCFS registrations.
That's fairly consistent with many other crypto related registries where
we generally only want to get as "loose" as specification required, e.g.
to avoid registration of codepoints for snake-oil or secret algorithms,
which FCFS would permit.

Cheers,
S.