Re: [Roll-bier-dt] Fwd: Bier interim in January

["Pascal Thubert (pthubert)" <[e-mail]>]

I’m with Toerless here

I think the IETF benefits a lot from architecture documents. We are publishing the DetNet one and last calling the 6TiSCH one at this very moment while going through the pains of missing one at LPWAN. Note that both will be published as std track.

The value of publishing those is many fold:

- provides a std track reference for the WG std documents allowing them to concentrate on their protocol as opposed to spending efforts on the bigger picture.

- provides an entry point to the WG context for new comets and external bodies. E.g., IEC needs to refer DetNet in general before digging in specific methods to be inherited from RFC blah

- position the RFCs from this WG vs other WGs and possibly SDOs such as IEEE. In this efforts some major bugs, overlap or gaps can be isolated and solved.

Note the this discussion does not concern problem statement and requirements drafts. For those there can be other ways. In RFC 8505 I just inserted the rewards draft text in appendix.

All the best,

Pascal

> Le 28 nov. 2018 à 22:55, Toerless Eckert <[e-mail]> a écrit :
> 
>> On Wed, Nov 28, 2018 at 01:49:48PM -0800, Alvaro Retana wrote:
>> Toerless:
>> 
>> I am not a fan of publishing stand-alone framework/requirements/use cases.
> 
> I hope my explanation made it clear that this should not be the goal.
> If you think that how i outlined it makes sense, let me know, or how
> you think it should be changed. Overall i just think there is limited
> interest to work on things not getting published as RFCs.
> 
>> But as I said before, without knowing the specific contents of the
>> documents it is not easy to provide a one-size-fits-all answer.
> 
> I think what we need should be similar to what we have in some of the
> explanations in Pascals document and the IETF103 slides i did.
> 
>> I???m asking early so we don???t end up in the situation you mention below and
>> we are in sync.  There are many ways to go about documenting the support
>> material???not all of them end up as RFCs???but also we don???t need to end up in
>> not publishing something that is needed/important/valuable.
> 
> See above. I would like not do do throwaway work, and you let me know
> if you think if drafts not becoming RFC are throwaway. If you don't
> think they are, then please tell me who still knows
> draft-ietf-idmr-pim-arch
> 
>> Let???s just keep that in mind going forward???
> 
> Sure
> 
> Cheers
>    Toerless
>> 
>> Thanks!
>> 
>> Alvaro.
>> 
>> On November 28, 2018 at 4:39:30 PM, Toerless Eckert ([e-mail]) wrote:
>> 
>> sorry i this is a rant, but your email reads a bit
>> like pushing one of my buttons where i am somewhat sensitive.
>> 
>> In anima i had to live through the ADs asking just to have specs
>> to implement, only that later on in WG and IESG review more
>> and more questiosn where asked for the sepcs to become more
>> explanational by reviewers because they didn't understand thre
>> functionality just from the specification part and so we ended
>> up with humunguous spec drafts because we where asked not to
>> publish arch documents.
>> 
>> I don't think we need to sequentialize explaining the framework
>> and working on the specification of its components. Ideally,
>> we can start with just enough of an outline of a framework so
>> that we can agree on the resulting component specifications and
>> start those quickly.Wwe continue to add explanations to the component
>> framework doc while we are working on the specs, therefore allowing
>> to keep the specs crisp but also have a vehicle to deliver better
>> explanations.
>> 
>> To also give my classic reference: I would have never understood
>> RFC2362 and its revisions of the followind decades if there wouldn't
>> have been draft-ietf-idmr-pim-arch, and i think its a big failure of
>> the IETF to not have published that as an RFC. But then again, i
>> was back then not in the role of the three author/implementers of
>> the PIM-SM spec, but in the role of an operator of PIM-SM.
>> 
>> Cheers
>> Toerless
>> 
>>> On Wed, Nov 28, 2018 at 12:00:10PM -0800, Alvaro Retana wrote:
>>> Just a high-level comment/question???. Off topic...
>>> 
>>> I???m hoping that "to set the stage for the set of required followup
>>> documents specifying the solution??? means that the informational
>> document(s)
>>> will most likely serve their purpose as inspiration for the solution
>>> only???and not be published as RFCs. Is that the intent? Or is the intent
>>> to publish that as requirements, framework, or whatever-else RFCs???and
>>> *later* work on solutions?
>>> 
>>> I realize that without knowing the specific content of those document it
>>> may be hard to provide a definite answer???so I???m just looking for
>> intent at
>>> this point.
>>> 
>>> Thanks!
>>> 
>>> Alvaro.
>>> 
>>> 
>>> On November 28, 2018 at 11:25:19 AM, Toerless Eckert ([e-mail])
>> wrote:
>>> 
>>> a) Lets first determine what the next step is in the documents for
>>> roll-bier that we want to achieve by IETF104.
>>> 
>>> Ines was suggesting that we should consider a high-level overview
>>> draft, for example reformatting into draft form what we had worked
>>> out in slides and the etherpad in the design team. Primarily goal
>>> would be to set the stage for the set of required followup documents
>>> specifying the solution.
>>> 
>>> I could take a stab at that, but maybe good parts of this should come
>>> fro pascals document, e.g.: splitting up the informational parts from
>>> the normative parts and extending on the informational ones .. ?
>>> 
>>> And then fesible next steps for the drafts specifying the solution.
>>> Right now the primary documents existing are the one from pascal
>>> and carsten, so i would like their input for how they could see
>>> those documents evolve until 104.
>>> 
>>> Please chime in if this is the right goal, and if so, what it should
>>> entail.
>> 
>>> _______________________________________________
>>> Roll-bier-dt mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/roll-bier-dt
>> 
>> 
>> -- 
>> ---
>> [e-mail]
> 
> -- 
> ---
> [e-mail]