Hi, Michael, On Thu, Oct 25, 2018 at 2:54 PM Michael H. Behringer < michael.h.behrin...@gmail.com> wrote:
> On 25/10/2018 05:21, Spencer Dawkins at IETF wrote: > > Hi, Brian, > > On Wed, Oct 24, 2018 at 10:16 PM Brian E Carpenter < > brian.e.carpen...@gmail.com> wrote: > >> Hi Spencer, >> On 2018-10-25 15:54, Spencer Dawkins wrote: >> ... >> >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > I'm confused here ... >> > >> > This document describes a first, simple, implementable phase of an >> > Autonomic Networking solution. It is expected that the experience >> > from this phase will be used in defining updated and extended >> > specifications over time. Some topics are considered architecturally >> > in this document, but are not yet reflected in the implementation >> > specifications. They are marked with an (*). >> > >> > This is true now, but when this document is approved, will it be >> published >> > immediately (in which case, this is "truth decay", because it becomes >> less true >> > in the unchanging RFC every time a topic is reflected in implementation >> > specifications), or will it be held until all the (*)s are stable? >> >> The intention is to publish it now; the (*) items are FFS (for further >> study) >> in ITU or ISO speak. Should we make the last sentence explicit?: >> >> They are marked with an (*) and are intended for further study. >> > > Thanks for the quick reply. > > I think that would be an improvement, but if it was clear that there's a > reason to include them in a document being published now, that might be > useful to include. > > If it's possible that some of these items might be significantly > re-thought after further study, or even dropped, that seems unhelpful to a > reader in five years. > > > Thanks for the thoughts, Spencer. I sort of see that we might end up with > a situation where one of those (*) topics completely disappears in 5 years, > in which case it might indeed look odd. > > However, the RFCs come with a publication date. I think it'll then be > clear that 5 years ago, we were thinking in a different direction, but that > over time, the views changed. > > Personally, I find it very interesting to read in older documents why > certain things were done or not done, considered or not considered, even if > things change later on. > > So, I would trust the future reader to understand that this is context at > the time of publishing the RFC, and might have changed since. And I think > we could well live with that. My suggestion: Leave. > I'm sorry, I probably confused people. I wasn't questioning whether to keep or remove the information. My point was that in five years, some of them might be in implementation applications, but this RFC will still say that they aren't. If this included Brian's suggested "They are marked with an (*) and are intended for further study.", that would be more accurate, and would explain why they're being included in this document, even though the contents are somewhat speculative. And my comment is even more incredibly non-blocking now that Brian made that suggestion. I'm sure you folk will do the right thing. Spencer > Michael > > > Spencer > > >> Brian >> >> >
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
