[Tinyos Core WG] RFC model

[Kevin Klues]

OK, I see your point now, but there still needs to be a consistent way
of letting the reader know that these informational TEPs exist.  Even
with that, it still seems a bit awkward to me to have to say something
like -- "Please refer to TEP250 to see a clarification of the
statement XXX on line 56 in paragraph 3 of section 5 in TEP 101.   It
just seems easier to have one document where the changes are made.

A compromise might be to do the following. Finalize TEP XXX and have
it never change.  Write an informational TEP XXX-info that is never
finalized, but serves to clarify any statements in TEP 101.  Whenever
a new set of clarifications need to be made, they are simply appended
to this document.  One such informational TEP could exist for each
finalized TEP.

It might also be nice to define some syntax for writing the info TEPs
so that a tool can be used to easily merge all clarifications with the
original TEP so it can be viewed as a standalone document with all of
its clarifications in place.

Kevin

On 10/13/06, Philip Levis <pal at cs.stanford.edu> wrote:
> On Oct 13, 2006, at 10:02 AM, Kevin Klues wrote:
>
> > I think stable does actually sound better than final.  Saying that a
> > TEP is final sounds, well... too final.  I think creating entirely new
> > TEPs for a small clarification change is a bit too much though.  I
> > think it might be confusing if we decided that, say TEP 101 needed
> > some better clarifications once it was finalized/stabilized (and with
> > the way TEP 101 has been going, it probably will) so we need to
> > reissue a new TEP number for the clarified version as TEP 250 since
> > that is the next available TEP number in the rotation.  It seems more
> > reasonable to me to assign it to TEP 101.1 or something of that
> > nature, keeping the primary number consistent, and just appending
> > revisions onto it.
>
> But, again, how do you resolve the issue of clarifications changing
> the tone of the document?
>
> Think about it from the perspective of the *readers* of the document:
> University A ports a new platform "amote" that meets TEP XXX. TEP XXX
> is then changed, such that it now indicates that the "amote" port is
> a bit off, and all applications written against TEP XXX might be a
> bit off too. One purpose of a clarification is to dispel a
> misperception, but if everyone is uniform, how do you resolve the
> change? Meeting TEP XXX becomes meets TEP XXX version A.B.
>
> Note: you don't need to reissue an entirely new TEP (hence my comment
> about Informational). If all you want is a clarification, then you an
> write an Informational TEP. "TEP XXX states that a system SHOULD do
> Y. We describe considerations for this specification based on our
> experience with ZZZ."
>
> Phil
>


-- 
~Kevin