Subject: [Asdf] Kicking off ASDF

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Aug 2020 21:20:28 +0200

As we now have > 50 subscribers assembled on the mailing list, I think we can start doing work here.

Thank you all again for helping making the BOF a success.
We got a clear mission to complete and agree the charter proposal now.

The proposal is at:

https://github.com/one-data-model/ietf108

There is one pull request for the charter at:

https://github.com/one-data-model/ietf108/pull/3

You can approve that PR if you like; if there are no objections, I would like to merge this one at the end of the week.

Please read the charter and submit issues/pull requests where we need further improvement — we were reasonably happy during the BOF already and should make changes only where needed.  As always, it is worth discussing PRs in issues (or here) before submitting them (typos excluded).

		.oOo.

We cannot really start work as a Working Group until chartered: We cannot make decisions without Working Group Chairs that call consensus on issues.  This does not have to stop us from doing work.

The SDF draft is at:

https://github.com/one-data-model/SDF

One Data Model people have a number of feature requests that we should have a look at now.  It would be good to have an SDF 1.1 by October that addresses some of these requests, and to keep up an approximately bi-monthly rhythm of releases (modulo holiday times).  

This should be driven by what we consider best practice in creating/converting data models — we have about 15 ecosystems that we can pick and choose ideas from.  We also need to check how these features can be picked up by the tools; I expect that once the features gel a bit, and before they are fully crystallized, we will see implementations in the tools (https://github.com/one-data-model/tools as well as ecosystem specific).

Some github issues will now be opened by people who already have experienced limitations of SDF 1.0 that should be addressed; of course, other people can submit issues, too.  We can have a discussion right in the github issues, or, for more fundamental decisions to be taken, also here in the mailing list.  It will probably take a little until we have pull requests based on these issues; we can discuss these then and, by the time the discussion solidifies, we might have a WG.

I’m looking forward to SDF 1.1, and the further work of the ASDF WG-to-be!

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Tue, 4 Aug 2020 13:08:33 -0700

How much leeway is there for modifications of the first round of the SDF document?  It seems possible that changes could "break" the current collections of model descriptions.  If this is not within the of possibility it needs to be so stated.

Jim

-----Original Message-----
From: Asdf <[email-masked]> On Behalf Of Carsten Bormann
Sent: Tuesday, August 4, 2020 12:20 PM
To: [email-masked]
Subject: [Asdf] Kicking off ASDF

The proposal is at:

		.oOo.

The SDF draft is at:

Grüße, Carsten

-- 
Asdf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asdf

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 4 Aug 2020 22:39:24 +0200

Hi Jim,

> How much leeway is there for modifications of the first round of the SDF document?  It seems possible that changes could "break" the current collections of model descriptions.  If this is not withi…

As I said in the BOF, most of these models are generated from ecosystem sources by tools, so if there is a breaking change that doesn’t reduce the domain, it should be possible to get the tools to adjust.  Of course other materials such as tutorials decay with these changes, and touching the tools is work, so there should be a reason for the change.  But overall I think this specification is malleable to an extent rarely seen.

In the end, layering backpack on backpack will make the tools hard to maintain and brittle, so we really care about getting the simplifications and refactorings possible with each change.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Aug 2020 18:07:17 -0400

> One Data Model people have a number of feature requests that we should
    > have a look at now.  It would be good to have an SDF 1.1 by October
    > that addresses some of these requests, and to keep up an approximately
    > bi-monthly rhythm of releases (modulo holiday times).

1) What would you call a "release" here?

2) Are there important ODM member deadlines, meetings or processes that we
   should consider in our milestone process?

3) Would SDF be a single document, or a base document plus extensions?
   Are there parts that we can rapidly gain consensus on and publish, with
   discussion about the other parts?
   Or does draft-onedm-t2trg-sdf-00 represent the consensus part already, and
   there is some "freezer" of other things which were removed during the
   OneDM part of the effort?

    > Some github issues will now be opened by people who already have
    > experienced limitations of SDF 1.0 that should be addressed; of course,
    > other people can submit issues, too.  We can have a discussion right in
    > the github issues, or, for more fundamental decisions to be taken, also
    > here in the mailing list.  It will probably take a little until we have
    > pull requests based on these issues; we can discuss these then and, by
    > the time the discussion solidifies, we might have a WG.

    > I’m looking forward to SDF 1.1, and the further work of the ASDF WG-to-be!

Should publishing 1.0 ASAP be a goal, or should we just do 1.1?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Aug 2020 18:12:39 -0400

Carsten Bormann <[email-masked]> wrote:
    > We cannot really start work as a Working Group until chartered: We
    > cannot make decisions without Working Group Chairs that call consensus
    > on issues.  This does not have to stop us from doing work.

I have some questions about paragraph two of the core of the charter:
https://github.com/one-data-model/ietf108/issues/5

   } In the process, some smaller pieces may become usable independently from
   } SDF itself and its applications. JSON Path (similar to, but different in
   } scope from JSON Pointer documented in RFC6901) might be an example for
   } such a spin-off specification -- it is currently defined on a website
   } and would benefit from a more formal definition so it can be used in
   } discovery processes involving SDF models.

The web site in question is, I think: https://jsonpath.com/ ?
             https://goessner.net/articles/JsonPath/
             https://restfulapi.net/json-jsonpath/  <- seems most authoritative

Is it a goal to do this work in ASDF?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Aug 2020 18:25:15 -0400

{didn't open issues for this}

  } The ASDF WG will work closely with the CBOR WG, home of the CDDL
  } specification. It will also engage the still active mailing list of the
  } dormant JSON WG. Recent proposals to form an IRTF formal description
  } techniques (FDT) Research Group may lead to another collaboration
  } partner. The Thing-to-Thing Research Group (T2TRG) and its WISHI program
  } can be instrumental in engaging researchers and other SDOs in this space,
  } or instance W3C WoT, which is working on Thing Description Templates and
  } related specifications.

I can't really agree or disagree with any of this :-)
Can we split this up a bit?

1> The ASDF WG will work closely with the CBOR WG, home of the CDDL
1> specification.

While we are using CDDL to define the structure, I'm unclear what the back
and forth that ASDF will have with CBOR here.  Are there pieces in CDDL that
are missing that this model will motivate adding to CDDL?

2> It will also engage the still active mailing list of the
2> dormant JSON WG.

Is this about json-path, and/or json-schema?

3> Recent proposals to form an IRTF formal description
3> techniques (FDT) Research Group may lead to another collaboration
3> partner.

Where are these proposals occuring, and at one point will they conclude, and
is the timing of this important, critical, or optional to the process?

4> The Thing-to-Thing Research Group (T2TRG) and its WISHI program
4> can be instrumental in engaging researchers and other SDOs in this space,
4> or instance W3C WoT, which is working on Thing Description Templates and
4> related specifications.

This part seems rather aspirational.  All sorts of communications are
important and beneficial, but is there some kind of implied liason activity,
or some kind of cross-WG/RG last-call that is implied?

I don't see any effect from just deleting this paragraph from the charter :-)

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 Aug 2020 09:18:51 +0200

> I don't see any effect from just deleting this paragraph from the charter :-)

I completely agree.

However, relationship to other groups usually comes up in charter discussion, and this paragraph was intended to provide a landscape.  These links may be obvious to us, but maybe not to others joining the work.

But I would expect the WG to act on this landscape independent of whether it is exposed in the charter or not.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 Aug 2020 09:25:15 +0200

> are missing that this model will motivate adding to CDDL?

That has already happened (the .feature feature).
I could imagine the SDF work will continue to be a fertile ground for further improving the usability of CDDL in specs of this kind.

> Is this about json-path, and/or json-schema?

Probably more about json data definition (which includes the json-schema.org proposals that have been inspiring the SDF data definition components).

> Where are these proposals occuring,

[email-masked]

> and at one point will they conclude,

Good question.

> and

Entirely optional.

> or some kind of cross-WG/RG last-call that is implied?

T2TRG is not engaging in formal liaisons.  It *is* working on getting people to talk (e.g., last week the discussion we had on Azure DTDL).  For ASDF, getting information from the various ecosystems trying to get their models expressed in SDF is vital — preferably in the form of people from these ecosystems taking part in the work, but ASDF people taking part in the communications is a good second best.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 Aug 2020 09:40:26 +0200

On 2020-08-08, at 00:07, Michael Richardson <[email-masked]> wrote:
> Signed PGP part

An Internet-Draft that is specifically marked as such (often called “implementation draft” in other groups).
The intention would be to reach a periodic milestone where OneDM people and ASDF agree that a specific I-D is useful as a basis for further OneDM work, e.g., by using that I-D for validating models in the OneDM playground and convergence processes, and by ecosystem tool builders modifying their tools to target that I-D in their conversion processes (which is what enables breaking changes).

This could be done in a tick-tock style, with a feature I-D and then a period of stabilizing that, so -02 could be SDF 1.1, -04 1.2, and so on.

>   should consider in our milestone process?

See above.  I am not aware of any specific deadlines.  OneDM meets weekly at the moment, and I would expect us to have some personal overlap that facilitates communication.  I’m not sure we have all the details of making OneDM’s convergence process work in the presence of a periodic SDF spec release process; I would expect the mutual benefit from making that work to motivate OneDM to work on these.

> 3) Would SDF be a single document, or a base document plus extensions?

More on the side of a single document.  A spec language for protocol bindings might be a conceivable extension.

>   discussion about the other parts?

The consensus we have on SDF 1.0 is based on existing input from ecosystem SDOs; it is also based on understanding that the current limitations will be addressed by further work.  So I don’t think we should be publishing anything quickly now.

>   OneDM part of the effort?

See above.  No freezer, but we did take out some elements that were meant to support protocol bindings that might go into that other document.

> Should publishing 1.0 ASAP be a goal, or should we just do 1.1?

1.0 was “published” as an Internet-Draft.  I don’t think we should aim for RFC status until we have at least a handful of SDOs that have put the majority of their relevant models through the process.  1.0 is intended to be quickly superseded by 1.1, and that might happen a couple more times until returns start to diminish.

This rapid iterative process may be a bit unusual for IETF.  
I’d assume we can stabilize the SDF core at 1.3 or 1.4 enough to go for RFC.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 8 Aug 2020 09:45:33 +0200

> Probably more about json data definition (which includes the json-schema.org proposals that have been inspiring the SDF data definition components).

…and it is probably worth pointing out that, while SDF itself is notated in JSON (and thus benefits from CDDL), the data models that SDF describes cannot be limited just to the expressive gamut of JSON data.  So a JSON data definition format such as those proposed at json-schema.org can be an inspiration, but cannot on its own solve the entire problem.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 10 Aug 2020 14:51:12 +0200

> Is it a goal to do this work in ASDF?

That was not the feedback from the DISPATCH WG on 2020-07-27:

https://www.ietf.org/proceedings/108/minutes/minutes-108-secdispatch-04

(Scroll forward to
## JSONPath standardi\[sz]ation - Carsten Bormann
)

We now have a mailing list, [email-masked], that needs a kick-off.
The idea is to come up with a proposed charter there, and propose that back to the dispatch mailing list for a final charter.  If that process is successful, there would be two independent WGs — which makes sense, as at least initially JSONPath will focus on JSON only.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Aug 2020 09:10:59 -0400

> The intention would be to reach a periodic milestone where OneDM people
    > and ASDF agree that a specific I-D is useful as a basis for further
    > OneDM work, e.g., by using that I-D for validating models in the OneDM
    > playground and convergence processes, and by ecosystem tool builders
    > modifying their tools to target that I-D in their conversion processes
    > (which is what enables breaking changes).

I'm not exactly thrilled about having an I-D hang around for a long time like this.

    > This could be done in a tick-tock style, with a feature I-D and then a
    > period of stabilizing that, so -02 could be SDF 1.1, -04 1.2, and so
    > on.

I'm even less thrilled about assigning version numbers to "Work-in-progress"
If we could iterate on RFCs faster, would that also work?

It seems to me that maybe we should fork/multiprocess:
  (1) take current document, SDF 1.0, kick it off as Informational<*>
     and go out to get reviews and approvals immediately.

  (2) simultaenously, start on 1.1/1.2 as you suggest, pulling in the
     review comments into that document as we go, producing a -bis
     document late next year.

<*> - this is the typical publish externally developed spec as Informational,
    then revise it within the IETF, and publish as "standard".
    But, I think that the SDF document might always be Informational :-)

I think that we could reserve a point prior to RFC publication of (1) at
which we might decide not to publish 1.0.

I big concern I have, thinking about publication, is that I think that the
subject matter is sufficiently esoteric compared to, say, BGP extensions or
IMAP extensions, that getting reviewers who aren't already involved with
OneDM will be difficult.

    > See above.  I am not aware of any specific deadlines.  OneDM meets
    > weekly at the moment, and I would expect us to have some personal
    > overlap that facilitates communication.  I’m not sure we have all the
    > details of making OneDM’s convergence process work in the presence of a
    > periodic SDF spec release process; I would expect the mutual benefit
    > from making that work to motivate OneDM to work on these.

okay, thank you.
Basically, you are saying that we can self-impose/self-organize deadlines.

    > The consensus we have on SDF 1.0 is based on existing input from
    > ecosystem SDOs; it is also based on understanding that the current
    > limitations will be addressed by further work.  So I don’t think we
    > should be publishing anything quickly now.

    > 1.0 was “published” as an Internet-Draft.  I don’t think we should aim
    > for RFC status until we have at least a handful of SDOs that have put
    > the majority of their relevant models through the process.  1.0 is
    > intended to be quickly superseded by 1.1, and that might happen a
    > couple more times until returns start to diminish.

    > I’d assume we can stabilize the SDF core at 1.3 or 1.4 enough to go for RFC.

I understand your concern about "release.0" issue, and that you wish to
validate things.  I want to point out that this is precisely the difference
between Proposed Standard (1.0) and Internet Standard (1.1).

Personally, I have been pushing back loudly against continued grade deflation
in the IETF process.   So I would personally be loath to put this into a charter.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Aug 2020 09:18:11 -0400

Barry, I'm uncomfortable with a plan to have more than implementation draft
as a WIP.   While it seems that this where the IETF has evolved to, I'm
really not sure that planning it this way is in the right spirit.

I would significantly prefer to iterate at PS, but the hurdles seem higher
than ever.  I'd love to be wrong!
Maybe someone has some 3933 process experiment ideas that could be done.

    > period of stabilizing that, so -02 could be SDF 1.1, -04 1.2, and so

...

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Aug 2020 09:20:20 -0400

> ## JSONPath standardi\[sz]ation - Carsten Bormann

Ah, I was unaware that this had happened.
As I understand, you previously said that we would not need to normatively
depend upon the results: we'd include just enough text to get by.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Aug 2020 17:06:39 +0200

Hi Michael,

> I'm not exactly thrilled about having an I-D hang around for a long time like this.

Maybe you should tell the HTTP/2, QUIC, … groups.

This works well when there is a closely knit community that actually has made a commitment to follow through on the updates.  (I remember draft-martini vs. draft-kompella etc. for counter-examples, where drafts escaped into products…)

> If we could iterate on RFCs faster, would that also work?

Maybe, but this is not our ocean to boil...

>     and go out to get reviews and approvals immediately.

That is exactly *not* the point.  This would make it look like specifiers get to choose between all the RFCs that we drop.  Internet-Drafts are “obsoleted” (expired) much more solidly than RFCs ever are.

>     review comments into that document as we go, producing a -bis

We want to be faster than that!

>    then revise it within the IETF, and publish as "standard".

Yes, and, again, that is *not* the model here.
People will not stick to SDF 1.0 when there is a better SDF 1.1, and the historical interest in document what SDF 1.0 was is rather limited.

>    But, I think that the SDF document might always be Informational :-)

That is not the intention either.  We do want to converge to something that is stable.  (Which still will have extensions.)

> which we might decide not to publish 1.0.

We do not want to “publish” (as an RFC) 1.0.

> IMAP extensions, that getting reviewers who aren't already involved with

I’m seeing that danger, but I’m also seeing good cross-area review in other places.  We will have to seek out for that.

> Basically, you are saying that we can self-impose/self-organize deadlines.

Given the personnel overlap, I think we’ll get communication about important outside milestones.  (I still remember vividly a CES deadline we blew as the CoRE WG.)

>> 1.0 was “published” as an Internet-Draft.  I don’t think we should a

1.4 might be an Internet Standard, if 1.3 becomes a Proposed Standard (or the numbers could be 1.12 and 1.8; let’s see).

> in the IETF process.   So I would personally be loath to put this into a charter.

I understand the sentiment.
I still think this is a good way to run this, for *this* specific effort.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 19 Aug 2020 17:15:23 +0200

Picking out this one:

On 2020-08-19, at 17:06, Carsten Bormann <[email-masked]> wrote:
> 
>> So I would personally be loath to put this into a charter.

Do we have to?  I think the WG can define (and modify, as needed) its mode of operation and its rhythm; that does not need to be part of the charter.

I’m asking because I believe we should send off the charter to our AD soon, so we need to find out whether there is anything left that needs to be added.

Grüße, Carsten

---

From: Niklas Widell <[email-masked]>
Date: Wed, 19 Aug 2020 20:23:33 +0000

On 2020-08-19, 17:15, "ASDF on behalf of Carsten Bormann" <[email-masked] on behalf of [email-masked]> wrote:

    Picking out this one:

If it is not needed, I don't think we should describe in detail in the charter the future evolution steps of SDF beyond what we can see now (i.e., a IETF-ed  version of SDF 1.0  with potentially some of the existing OneDM feature requests folded in as well as changes based on requirements from "new" ecosystems). That SDF will then continue to grow expressiveness is most likely, but how that is best done (via new main spec versions or via extension/companion specs) should be left for future decision. 

That said, IMHO the charter covers the currently envisioned work (assuming removal of JSON path paragraph (except first sentence) as per issue #5) so I'd also like it have submitted to AD as soon as possible. 

Cheers, 
Niklas

---

From: Barry Leiba <[email-masked]>
Date: Wed, 19 Aug 2020 17:31:37 -0400

Michael, have a chat with Mark Nottingham: this is what httpbis did and
quic is doing, and it worked very effectively for them.  There are benefits
to having a version in a PS RFC, then making the next version a new PS RFC
that Obsoletes the first, and so on.  There are also benefits to hashing
things out during document development of the first PS RFC.  The working
group will have to weigh those, and see which side comes up heavier.  Mark
will have good input for that decision, I think.

Barry

On Wed, Aug 19, 2020 at 9:18 AM Michael Richardson <[email-masked]>
wrote:

>     > An Internet-Draft that is specifically marked as such (often called
>
>     > “implementation draft” in other groups).
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Aug 2020 21:23:57 -0400

> Do we have to?  I think the WG can define (and modify, as needed) its
    > mode of operation and its rhythm; that does not need to be part of the
    > charter.

    > I’m asking because I believe we should send off the charter to our AD
    > soon, so we need to find out whether there is anything left that needs
    > to be added.

yes, I also feel the urge for some speed here.
But, I think it's just you and I for the last two weeks though.
Will it pick up again September 1, or is everyone just dead from [email-masked]?
(I'm not reading that thread)
I guess I thought this pandemic August would be different than other August lulls.

I wonder if there a useful place for an Experimental status document?

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Aug 2020 07:00:27 +0200

> On 2020-08-20, at 03:23, Michael Richardson <[email-masked]> wrote:
> 
> 

Maybe charter smithing is just not everyone’s favorite pastime.
(And maybe the charter is pretty much done?)

> I guess I thought this pandemic August would be different than other August lulls.

It certainly is, with all the time on the balcony :-)
(It also is ten degrees warmer.)

> I wonder if there a useful place for an Experimental status document?

I think we are way beyond “Experimental”.

When do you create an “Experimental” protocol in the IETF?

(1) If you want to conduct an experiment (Research!) and need a common specification for that.

(1a) If you want to document an experiment, or are in the IRTF :-)

(2) If you want to put out something as a proposal, and expect that will be replaced by the real thing after some thinking later (RFC 2414 and RFC 3390, RFC 3940 and RFC 5740, …).

(2a) If your protocol development fizzled out, but you still want to document it (RFC 8548).

(3) If you are not sure about the harm you are creating (damaging the Internet) and want to get by the IESG anyway.

SDF 1.0 might have been “experimental”.  But we do not plan to publish anything but the real thing.  By the time we do this, we expect to have most of the data models of a dozen or so ecosystems represented in SDF and being used for organizing the convergence in OneDM.  That is no longer an experiment.

		.oOo.

Back to the charter work: I created https://github.com/one-data-model/ietf108/pull/6 to actually address https://github.com/one-data-model/ietf108/issues/5
Please check whether that correctly reflects the change needed.

Grüße, Carsten

---

From: Niklas Widell <[email-masked]>
Date: Thu, 20 Aug 2020 07:37:45 +0000

NW> Also, there was pretty much solid support at the BoF and people seemed to be pretty happy with the charter non-review, so while need to get the formalities right I'm not sure there is much opposition to expect. 

...

NW> +1. People intend to use SDF in production  

    Back to the charter work: I created https://protect2.fireeye.com/v1/url?k=2389322f-7d299ce2-238972b4-866132fe445e-d48714306b8b7b1e&q=1&e=8d4c29c5-08e2-4875-9cc3-105b18aecc83&u=https%3A%2F%2Fgithub.com%2Fone-data-model%2Fietf108%2Fpull%2F6 to actually address https://protect2.fireeye.com/v1/url?k=0b2138b5-55819678-0b21782e-866132fe445e-f074afc3a39448bd&q=1&e=8d4c29c5-08e2-4875-9cc3-105b18aecc83&u=https%3A%2F%2Fgithub.com%2Fone-data-model%2Fietf108%2Fissues%2F5
    Please check whether that correctly reflects the change needed.

NW> While the JSONpath part could be removed, I thought the first sentence ("In the process, some smaller pieces may become usable independently from SDF itself and its applications.") still made sense

    Grüße, Carsten

Cheers, 
Niklas

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 20 Aug 2020 09:57:24 +0200

> NW> While the JSONpath part could be removed, I thought the first sentence ("In the process, some smaller pieces may become usable independently from SDF itself and its applications.") still made s…

It sure made sense, but I’d expect it to be considered too open-ended to survive a charter discussion.

Grüße, Carsten

---

From: "Wouter van der Beek (wovander)" <[email-masked]>
Date: Thu, 20 Aug 2020 09:21:04 +0000

Hi Carsten, Michael,

Is everything now sorted to submit the charter?
e.g. who is taking that action?

Kind Regards,
Wouter

-----Original Message-----
From: ASDF <[email-masked]> On Behalf Of Carsten Bormann
Sent: Thursday, August 20, 2020 8:57 AM
To: Niklas Widell <[email-masked]>
Cc: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Asdf] Kicking off ASDF

Grüße, Carsten

-- 
ASDF mailing list
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Aug 2020 13:34:42 -0400

> e.g. who is taking that action?

Hi, Niklas and I are taking responsibility.
At this point, we can't tell "silence == no objections" from
                             "silence == everyone on vacation"

I think that we need some additional text around the proposed idea to call
Implementation Drafts.

I would like some additional feedback on other ways of organizing the work,
but I've heard Carsten's preference loudly.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Aug 2020 13:44:34 -0400

Barry Leiba <[email-masked]> wrote:
    > quic is doing, and it worked very effectively for them.

Yes, I know that they did this.
I believe it works because the parties involved are
  a) funded to implement Internet-Drafts (not just discuss)
  b) actively deploy/test, with the understanding that it may break
  c) includes implementers that have both significant client and server properties

My impression is that this mostly applies to ASDF as well, although (c) is irrelevant.

    > There are benefits to having a version in a PS RFC, then making the
    > next version a new PS RFC that Obsoletes the first, and so on.

This is was how RFC1310/RFC1602/RFC2026/etc. intended, and it seems that it
has again gotten unstuck, pushing WGs like httpbis and quic AND ASDF to take
this approach.   It seems that every 15 years, the process becomes ossified.

As Carsten says, it's not our WG's purpose to try to fix the IESG, I guess we
just have to work around things.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Aug 2020 19:56:24 +0200

> I think that we need some additional text around the proposed idea to call

In the charter?

Being the lazy Bremen citizen I am [1], I now tried to steal from the HTTPBIS and QUIC charters here.  Nothing about that in the charter.  Could that be a mode of operation that the WG decides, without formal IESG agreement?

Grüße, Carsten

[1] https://de.wikipedia.org/wiki/Sieben_Faulen

---

From: Barry Leiba <[email-masked]>
Date: Fri, 21 Aug 2020 16:12:08 -0400

> just have to work around things.

Well, it's not for the working group to fix the IESG or the IETF in
general, but it *is* for the working group to decide how the working
group should operate.  If the working group, by rough consensus,
thinks that publishing a PS spec with the intention of replacing it
after more "running code" experience, then that's what the working
group should do.  If it's the rough consensus that going through
implementation experience during the development of the first PS spec
is the better way, then that's what should happen.  It's up to the
working group, and I'm behind either approach.

Barry

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Aug 2020 18:55:03 -0400

> Being the lazy Bremen citizen I am [1], I now tried to steal from the
    > HTTPBIS and QUIC charters here.  Nothing about that in the charter.
    > Could that be a mode of operation that the WG decides, without formal
    > IESG agreement?

I'm thinking that it fits into the initial milestones.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 22 Aug 2020 07:47:03 +0200

> I'm thinking that it fits into the initial milestones.

Sounds good.

Like this?

## Initial Milestones

There is only one deliverable, the SDF specification.
It is not currently foreseen that this will be split into multiple
documents, but that is also not excluded.
The plan is to evolve the specification in a regular rhythm, with a
new Implementation Draft available about bi-monthly.

* SDF specification ("SDF 1.0"), WG document adopted, September 2020
* SDF specification ("SDF 1.1"), Implementation Draft, November 2020
* SDF specification ("SDF 1.2"), Implementation Draft, February 2020
* (continuing in the rhythm...)
* SDF specification ("SDF 1.n"), PS to IESG, September 2021

Now https://github.com/one-data-model/ietf108/pull/7

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Aug 2020 17:22:18 -0400

CB> Sounds good.

    CB> Like this?

    CB> ## Initial Milestones

    CB> There is only one deliverable, the SDF specification.
    CB> It is not currently foreseen that this will be split into multiple
    CB> documents, but that is also not excluded.
    CB> The plan is to evolve the specification in a regular rhythm, with a
    CB> new Implementation Draft available about bi-monthly.

    CB> * SDF specification ("SDF 1.0"), WG document adopted, September 2020
    CB> * SDF specification ("SDF 1.1"), Implementation Draft, November 2020
    CB> * SDF specification ("SDF 1.2"), Implementation Draft, February 2020
    CB> * (continuing in the rhythm...)
    CB> * SDF specification ("SDF 1.n"), PS to IESG, September 2021

So, in that rhythm (~3 months), it would be:
    1.3     May 2021
    1.4     Sept 2021, PS to IESG
??

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 24 Aug 2020 07:26:40 +0200

>    1.4     Sept 2021, PS to IESG

Well, bi-monthly is not tri-monthly.  I tried to refrain from prognosticating the exact version number we’ll go to IESG with, but if we manage to keep up the rhythm, it would be 1.6.  (I actually think it is more likely that we’ll slow down at the end when getting asymptotic.)

.oOo.

Michael has approved the pull request, any other takers?
I think this is the last thing we need to do before submitting the proposed charter.

Approve (or comment) at:
https://github.com/one-data-model/ietf108/pull/7

Grüße, Carsten