Subject: [Danish] Revised charter based on recent discussions

From: Wes Hardaker <[email-masked]>
Date: Sun, 18 Jul 2021 15:21:38 -0700

Folks,

We are scheduled to have a BOF during IETF 111.  Since there has been
only a few messages indicating support for the creation of the WG and
the charter, we'll likely be having a charter discussion rather than
getting real work done on clearly identifying the architecture and
corresponding problem space (bullet 1 of the charter items).

I've updated my copy of the charter in my github page [1], based on
recent wording concerns and submitted a PR #6 [2] to MCR's github
repository.  Reviews appreciated, and more importantly: concrete changes
you would like to make (OLD/NEW or PRs or ...).

Finally, if you think this space is something the IETF should take on we
certainly need to hear more from people that believe this is an
important problem to be solved, and if so how you're willing to help.
(but even if you aren't committing to help, we at least need people that
want to participate in discussions to say so).  Silence, in the IETF,
does not achieve consensus :-/

[1] https://github.com/hardaker/danish-bof/tree/2021-07-18-charter-revision
[2] https://github.com/mcr/danish-bof/pull/6

-- 
Wes Hardaker
USC/ISI

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Jul 2021 09:33:51 -0400

> you would like to make (OLD/NEW or PRs or ...).

Merged.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Russ Housley <[email-masked]>
Date: Wed, 21 Jul 2021 11:32:35 -0400

In the problem statement:

The text says: "...establishing trust in public keys from lower levels in a PKI tree."  This assumes a hierarchy, and some PKI implementations use a mesh.  I suggest: "...establishing trust in certified public keys."

Editorial suggestion: replace "What DANE did not define is how services can authenticate connecting clients." with "However, DANE did not define authentication for TLS client identities."

In the Scope of work:

Question: While TLS 1.3 is being rapidly deployed, there is still a lot of TLS 1.2 in use.  So, why limit to coordination with the TLS WG to one version of the protocol?

in the Deliverables:

I think it is pretty clear what goes in two of the documents, but the previous sections do not really say what will land in the architecture document.

Russ

> On Jul 18, 2021, at 6:21 PM, Wes Hardaker <[email-masked]> wrote:
> 
> 
> Folks,
>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 21 Jul 2021 12:57:50 -0700

Submitted most of your changes as PR #7:

https://github.com/mcr/danish-bof/pull/7

> I think it is pretty clear what goes in two of the documents, but the
> previous sections do not really say what will land in the architecture
> document.

That is true.  Do you feel like more specification needs to be made in
order for the charter to be usable? 
-- 
Wes Hardaker
USC/ISI

---

From: Russ Housley <[email-masked]>
Date: Wed, 21 Jul 2021 16:01:00 -0400

> order for the charter to be usable? 

It only matters it things become contentions.  In that situation, clarity about what is in scope and what is not are very useful to the WG Chairs.

Russ

---

From: Jacques Latour <[email-masked]>
Date: Mon, 26 Jul 2021 13:44:18 +0000

Charter looks much better now.
I support for the formation of the DANISH group, willing to contribute, review, and edit drafts.
Jacques

CLASSIFICATION:CONFIDENTIAL

> -----Original Message-----
> From: Danish <[email-masked]> On Behalf Of Russ Housley
> Sent: July 21, 2021 11:33 AM
> To: Wes Hardaker <[email-masked]>
> Cc: [email-masked]
> Subject: [EXT] Re: [Danish] Revised charter based on recent discussions
> 
> The text says: "...establishing trust in public keys from lower levels in a PKI
> tree."  This assumes a hierarchy, and some PKI implementations use a mesh.
> I suggest: "...establishing trust in certified public keys."
> 
> Editorial suggestion: replace "What DANE did not define is how services can
> authenticate connecting clients." with "However, DANE did not define
> authentication for TLS client identities."
> 
> 
> In the Scope of work:
> 
> Question: While TLS 1.3 is being rapidly deployed, there is still a lot of TLS
> 1.2 in use.  So, why limit to coordination with the TLS WG to one version of
> the protocol?
> 
> 
> in the Deliverables:
> 
> I think it is pretty clear what goes in two of the documents, but the previous
> sections do not really say what will land in the architecture document.
> 
> Russ
> 
> > repository.  Reviews appreciated, and more importantly: concrete
> > changes you would like to make (OLD/NEW or PRs or ...).
> >
> > Finally, if you think this space is something the IETF should take on
> > we certainly need to hear more from people that believe this is an
> > (but even if you aren't committing to help, we at least need people
> > that want to participate in discussions to say so).  Silence, in the
> > IETF, does not achieve consensus :-/
> >
> > [1]
> > https://github.com/hardaker/danish-bof/tree/2021-07-18-charter-revisio
> > n [2] https://github.com/mcr/danish-bof/pull/6
> >
> > --
> > Wes Hardaker
> > USC/ISI
> 
> --
> Danish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/danish