Re: [Asdf] Kicking off ASDF

[Carsten Bormann <[e-mail]>]

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…)

>> 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?

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

> 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.

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.

>  (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.

We want to be faster than that!

> <*> - this is the typical publish externally developed spec as Informational,
>    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.)

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

We do not want to “publish” (as an RFC) 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.

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.

> 
>>> 2) Are there important ODM member deadlines, meetings or processes that we
>>> 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.
> 
> okay, thank you.
> 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.)

> 
>>> 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.
> 
>>> Are there parts that we can rapidly gain consensus on and publish, with
>>> 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.
> 
>>>> 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?
> 
>> 1.0 was “published” as an Internet-Draft.  I don’t think we should a
>> 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.
> 
> 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).

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).

> 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.

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

Grüße, Carsten