Carsten Bormann wrote:
>> (I think that all of AH might fall into that, sadly)
> Also, when elevating a document to STD, it should not have errata.
> (See RFC20 for why I wrote “should not”, not “MUST NOT”.) RFC 4301 has
> 2 verified, 7 HFDU.
> Unfortunately, respinning a d
Paul Wouters wrote:
>> Generally, we'd need new documents if there are significant features
>> which have NEVER been useful/implemented, and we should drop them
>> first. (I think that all of AH might fall into that, sadly)
> I have tried to kill AH a number of times and failed.
Reviewer: Rich Salz
Review result: Ready
I'm the ARTART reviewer for this document. The kinds of things this directorate
looks for are described at https://wiki.ietf.org/group/art/TypicalARTAreaIssues
I found this wording initially confusing: "the sender in accordance with AH
([RFC4302] Section 3
On 2025-01-05, at 23:11, Michael Richardson wrote:
>
> okay, so do we need new documents,
No.
(But see below.)
> or can some just be blessed to STD via
> IESG action?
Yes.
(We did this with RFC20 == STD80, which was not quite a candidate for
respinning.)
> Probably we should make a list
>> Generally, we'd need new documents if there are significant features which
>> have NEVER been useful/implemented, and we should drop them first.
>> (I think that all of AH might fall into that, sadly)
>
> I have tried to kill AH a number of times and failed. I don't think we
> can strip it out
Hi Rich,
thank you for your review.
> Reviewer: Rich Salz
> Review result: Ready
>
> I'm the ARTART reviewer for this document. The kinds of things this
> directorate
> looks for are described at
> https://wiki.ietf.org/group/art/TypicalARTAreaIssues
>
> I found this wording initially confusi
On Sun, 5 Jan 2025, Michael Richardson wrote:
Do we want to cycle things separately? I think that ultimately, we won't.
New features that go into ESP need to be negotiated with IKEv2, so I'd put
them all into STD79.
Fair point.
Generally, we'd need new documents if there are significant fea
