Re: [Lake] 1 week 2nd WGLC on requirements and scoping text

Hello Stephen,

I am also happy with this text and I support the working group moving
forward in the proposed way.

Best regards,
Ivaylo

On Mon, Jun 1, 2020 at 9:51 AM Eduardo Ingles (UM) <eduardo.ingles@um.es>
wrote:

> Hi Stephen,
>
> I'm happy with this text.
> I support the working group moving forward.
>
> Regards,
> Eduardo Inglés.
> El 24/05/2020 a las 23:07, Stephen Farrell escribió:
>
> Hi all,
>
> First: my apologies for taking so long on this. (I got
> sidetracked by an unexpected project.)
>
> ISTM we have pretty good, if rough, consensus on enough of
> the text to proceed, but with one important part that needs
> checking. (See below.)
>
> I'd like to start a 1 week 2nd WGLC with the main focus
> being to establish whether we have rough consensus on the
> scoping text below. (Which can be see in context at [2].)
> That text was the main outcome of our virtual meeting last
> month.
>
> So, please send mail to the list saying if you are happy
> enough to proceed on this basis. If you are not, then I'd
> appreciate if you could suggest alternate text with as
> few changes as possible.
>
> This 2nd WGLC closes on June 1st. If I see rough
> consensus to proceed at that point, I'll plan to start a
> call for adoption for the edhoc draft. If not, we'll have
> to discuss how to proceed with our AD, as I think that
> would mean that the WG is very badly stuck.
>
> The scoping text added was:
>
>    As illustrated above, the setting is much more diverse
>    in terms of credentials and trust anchors than that of
>    the unconstrained web.  In order to deliver a timely
>    result, there is a need to initially focus on what is
>    considered most important at the time of writing: RPK
>    (by reference and value) and certificate by reference.
>    Information about validity of a certificate may be
>    omitted from the AKE if available over unconstrained
>    links.  The case of transporting certificate validation
>    information over the AKE may be specified in the initial
>    phase if there is a lightweight solution that matches
>    existing standards and tools.
>
>    A subsequent extension beyond the initial focus may be
>    inevitable to maintain a homogenous deployment without
>    having to implement a mix of AKE protocols, for example,
>    to support the migration path described above.  The AKE
>    needs to make clear the scope of cases analysed in the
>    initial phase, and that a new analysis is required for
>    additional cases.
>
> Thanks,
> Stephen.
>
> [1] https://tools.ietf.org/html/draft-ietf-lake-reqs-03
> [2] https://tools.ietf.org/html/draft-ietf-lake-reqs-03#section-2.2.1
>
>
> --
> Eduardo Inglés Sánchezeduardo.ingles@um.es
>
> Department of Information and Communication Engineering
> Faculty of Computer Science
> University of Murcia
> 30100 Murcia, Spain
>
> --
> Lake mailing list
> Lake@ietf.org
> https://www.ietf.org/mailman/listinfo/lake
>