[Dawn] Re: A reworked draft charter for DAWN

[Kehan Yao <[e-mail]>]

Hi Wes,

Thank you very much for your detailed explanations and responses to my
questions. They are very clear, have addressed my concerns, and are largely
consistent with what I had anticipated.

I have reviewed the two document links you provided. The DIEM charter is
indeed very concise, and I noticed one particular point: in its
deliverables section, it explicitly emphasises “strictly in this order,”
whereas the DAWN charter does not include such a requirement. I think that
is entirely reasonable, and we can decide how to handle the sequencing
based on the working group’s actual progress later on.

RFC 5434 is also very well written. I have excerpted two statements that I
believe are particularly relevant to the current BOF preparation stage:

*“Alternatively, a specific case should be made about why the charter, as
it is written, is the best one, in spite of the stated opposition.”*
This is helpful in reminding us that a charter does not have to be perfect,
but if it can be clearly executed, it is acceptable to have some opposing
views.

*“It goes without saying that a charter with shortcomings (no matter how
seemingly trivial to fix) will not achieve consensus if folk still have
issues with the specific wording.”*
This reinforces that discussions on specific wording are still necessary
and worthwhile.

Thank you again for your guidance.

Best regards,
Kehan

Wes Hardaker <[e-mail]> 于2026年6月24日周三 07:13写道：

> Kehan Yao <[e-mail]> writes:
>
> Hi Kehan,  Responses to your questions inline.
>
> As a reminder, it is up to the group (not me) to decide what charter
> they want the IESG to consider.  Having said that, we need to be careful
> about properly writing the charter to be tractable, achievable, and
> scope constrained.  It does not need to specify every little potential
> corner case or expected outcome -- it should scope the problem and give
> a hint to the expected outcome (more on that below).  The IESG ADs
> actually pointed us to the DIEM charter [1] to consider modeling ours
> after -- note how short and to the point it is, while still allowing
> flexibility in the results.
>
> >  1. 1. The updated charter has removed multiple procedural documents.
>
> Note that deliverables do not mean "these exact documents".  It could be
> that some of those deliverables may produce multiple documents (and the
> IESG hopefully understands this, as its common).  Instead the
> deliverables speaks more to "topics that must be considered".  Thus, for
> things like the information model or use case gaps, if the WG decides
> these are needed and adopts documents that include them, they can be
> considered part of either the Architecture or Protocol documents, for
> example.  In particular, I'd expect the Information Model to be part of
> one of those.  But, it could be published as a separate RFC or included
> in a larger one (the final WG will need to decide that).  Similarly,
> many times requirements and gap analysis type documents are written up
> for WGs but are never formally published -- they just serve as the basis
> of discussion.  That, too, should be up to the WG to decide in the long
> run about whether formal publication (and its overhead) is needed or
> not.
>
> The end goal: describe the problem that needs to be solved, not the
> exact pieces that will be needed to solve it.
>
> >  2. The revised charter explicitly adds a protocol specification as
> >  one deliverable. The -01 version contained a clause stating that
> >  extensions to existing IETF protocols need to be coordinated with the
> >  relevant owning working groups. Would it be appropriate to keep this
> >  wording within the revised charter?
>
> There is a section at the bottom that talks about the need for
> coordination, which is a bit more typical than putting into the
> deliverables themselves unless that's a known very direct overlap.
>
> >  With DNS proposed as the baseline starting point, does that imply we
> >  can move directly into protocol development based on a DNS-based
> >  architecture?
>
> The current charter does *not* intend to say that DNS will be the
> baseline starting point.  It says the DNS needs to be considered as a
> "likely initial protocol".  If the WG decides that's the wrong starting
> point, I do not believe it goes against the current charter to discard
> that as the right solution.
>
> >  □ - If we need to formalize a complete extended discovery
> >  architecture for DAWN, would the architecture document be finalized
> >  prior to, or after the protocol specification work?
>
> IMHO, that is up to the working group to decide in the long run. This
> particular topic (AI in general) is recognized as changing rapidly, and
> if we introduce significant delays into the exact timing required within
> the charter, it may significantly affect the viability of this work
> being recognized and used. The original charter had a strict order which
> can significantly impede rapid progress.
>
> If the working group seems aligned on an architecture, then I don't see
> the harm in the protocol document being worked on simultaneously. Having
> said that, it will be up to the group (both the BOF and the eventual WG)
> to convince IESG that their planned execution will work.
>
> >  1. - The current text reads “within a collaborating organization”.
> Shouldn't it be “within
> >     collaborating organizations” instead?
>
> Good point.
>
> >  2. - The DAWN terminology draft does not yet include a definition for
> “discovery server”. This term
> >     may refer to a component belonging to the architecture. Could we
> either rephrase the content to
> >     avoid referencing “discovery server”, or add a formal definition of
> this term to our terminology
> >     document later on?
>
> Let me close by saying: the BoF chairs are simply here to help you hold
> a successful BoF [2], as we've been through the process many times and can
> offer guidance on what will work and what won't.  It's actually up to
> the BoF participants to decide what should be put into the charter.  If
> everyone wants a wide open charter, we can certainly submit that at the
> end, but the likelihood of getting approval to create the WG will be a
> lot lower.  And the next opportunity for a BoF to hold one again to try
> and get consensus is November.  And you only get two chances as well :-/
> [this is simplifying things a bit, but is generally right]
>
>
> [1]: https://datatracker.ietf.org/wg/diem/about/
> [2]: https://datatracker.ietf.org/doc/rfc5434/
>
> Note: [2] is very worth reading.
>
> --
> Wes Hardaker
> Google
>