Re: [Lake] edhoc end game: detailed plan

[Sean Turner <[e-mail]>]

Sorry if I’ve missed this in another email, but is the plan to close the WG (not the list) once EDHOC is published as an RFC?

spt

> On Nov 29, 2022, at 16:43, Stephen Farrell <[e-mail]> wrote:
> 
> Signed PGP part
> 
> Hi all,
> 
> This is to confirm the plan for finishing edhoc as was agreed
> at IETF 115, but now with a few more concrete steps having
> been taken, so more detail "filled in"...
> 
> Just to reprise the overall process here:
> 
> - We're done with WGLC but have a few things to finalise (see
>  below); once those are handled (hopefully by Monday) the
>  chairs plan to hit the "publication requested" button which
>  means asking our area director (AD) to proceed towards an
>  IETF last call
> - Our AD (Paul) will likely want to do his own review as well
>  before he starts that IETF last call, and there can be a
>  bit of delay on that depending how busy the AD happens to
>  be at the time (they really do lead busy lives:-)
> - IETF last call (LC) is a two week period where IETF
>  participants who've not been engaged with the WG are
>  invited to comment. (Such comments are a good thing that
>  often improve drafts a lot or catch non-obvious things)
> - When IETF LC spans a holiday period, those are often
>  extended to 4 weeks or so (because we do want to get those
>  comments)
> - In parallel, we'll start getting directorate reviews (i.e.
>  secdir review etc)
> - Once all IETF LC comments etc are handled then we'll be
>  asking our AD to put the draft on an IESG agenda for
>  approval, generating more IESG comments we'll need to
>  handle, after which it'll head to the RFC editor queue
>  and then it'll pop out as an RFC a couple of months
>  later
> 
> So there's a way to go, but we're near the end of the WG's
> work on edhoc nonetheless as all those steps tend to take
> a *lot* less time than things have taken so far.
> 
> So, the immediate specifics:
> 
> Draft-18 [1] should include all the WGLC comment resolutions
> as agreed at IETF 115 and/or discussed subsequently on the
> list or in github. Please review the diff [2] to check that
> the editors have done that correctly in your view.
> 
> We also agreed at IETF 115 to give some people a chance to
> propose a PR with a state machine description. We now have
> that at [3] and need to decide to include it as an appendix
> (so that'd go in a draft-19) or to leave that out for now
> and maybe include it in another draft (such as [4]). The
> sense of the WG I think was to include it if it's clearly
> correct but leave it out for now if we're not sure. Let's
> try decide that by the end of week, (before the end of
> Dec 4th), so please say if you'd like that PR merged or not.
> (If there's ambiguity that'd take a while to fix, I'd ask
> you to consider suggesting we omit it rather than wait,
> my reasoning for that being that if we wait, other stuff
> will turn up that needs more discussing...;-)
> 
> Meanwhile, please do also take the opportunity to do more
> reviews of [1] - we can still treat any/all suggestions as
> IETF last call comments. (But please don't re-raise any
> issues already resolved in the WG.)
> 
> Mališa will be acting as document shepherd, so he'll be
> helping our capable authors negotiate the above steps. I'll
> be doing another chair-review of the draft before Monday
> as well. (Any nits from that can be handled during or
> after IETF LC though.)
> 
> With a bit of luck we may get IETF LC done by the very
> early new year, but that depends on our AD's queue and
> his doing his own review of the draft, so we'll have to
> wait and see how the timing goes.
> 
> Now... isn't that all very simple? :-)
> 
> Cheers,
> Stephen.
> 
> [1] https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-18
> [2] https://www.ietf.org/rfcdiff?url1=draft-ietf-lake-edhoc-17&url2=draft-ietf-lake-edhoc-18&difftype=--html
> [3] https://github.com/lake-wg/edhoc/pull/373
> [4] https://datatracker.ietf.org/doc/draft-ietf-lake-traces/
> <OpenPGP_0x5AB2FAF17B172BEA.asc>
> 
>