[Tinyos Core WG] RFC model

[Vlado Handziski]

After looking at the PEP process (no procedure for fixing the PEP after it
is in final state, can only be obsoleted like the RFCs) and thinking about
this a bit more, I agree with Phil's position that we should stick with the
same model with the following additions.

To handle the problem of finding the relationship between the original and
changed TEPs, I propose the following steps:

1. We declare the TEP metadata part not to be protected by the "final" state
2. We introduce a new metadata attributes: obsoletes and extends
3. The new TEP has to reference the obsoleted/extended TEP in the metadata
4. Upon finalization of the new TEP, the old TEP's _metadata_ will be
changed to state: obsoleted by/extended by: new_TEP number

Vlado


On 10/13/06, Kevin Klues <klueska at gmail.com> wrote:
>
> 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
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20061013/8a9e9e49/attachment.htm