Subject: [nfsv4] nfsv4 enters the world of "bis"

From: David Noveck <[email-masked]>
Date: Sat, 19 Feb 2011 10:51:47 -0500

*From time to time of late, I have had people in the working group ask me
questions of the form, "What is all this bis crap?".  Instead of  saying
"The area directors are making us", I'd like to offer a more positive answer
to the question and discuss how this will affect what we do and how we would
best adjust.*
*
                                                 *

*This seeemed like a good subject for disussion at the interim meeting but I
was unable to be physically present.  I hoped for a call-in, but apparently
our hosts had a "security issue"*

*Paranoia strikes deep.  Into your heart it may creep   --BUFFALO
Springfield, For what it's worth*

To be fair to our hosts, I'm sure other hosts would have the same issues.  A
far a*s "the man" * goes,  we live at a time when an amusing anecdote about
executive cars in the parking lot and what they must cost might be construed
as a violation of *The Securities Act of 1933.*

*Leaving aside the call-in question, let me give my answer to the
bis-questtion.*

I* think many of us have worked on development projects where the threshhold
for your work to be OK is for it to have achieved generla acceptance in the
community, compiile OK, boot, and seem to do somthing useful.  Not having
bug lists to deal with feels good, but **those who  run into bugs and can't
get them fixed are in tough shape.
                              *
*
                                               *
*We are now transferring from the no-bugs state where we only had to
traverse the IETF gauntlet.  Now we are dciding that iit is a bug-to-b-fixed
if --                  *
*
                                                   *

   - *  It doees't nswer an implmeentor's question clearly.*
   - *The text is misleading*

*So we have taken on fixing such bugs.*
*
                             *
*I'm sure everybody has experiences which indicates possible problems;  For
example:*
*
                             *

   - * y**ou Have  to propropgate fixes from verison to version and it
   isnon-tivial to do so
                                       *
   - *Bug fixes sometimes interact o create neww bugs
         *
   - * There is work in managing this process.
                         *
   - * You need to oganize fix-sets as patch releases  and have to manag
   tht, sometimtes mltiple levels to address different piorities for stability
                                                                       *

*
                                                  *
*Sure there are problems, butthey are not suffiient to justiy telling the
spec users o get  lost when they have issues.  My experience with
Internationalization has shown how far we can be between stuff tht can go
through the approval gauntlet and what is needed by users.  in fact, the
gauntlet forced us to poduce someething not useful.  Sigh!*

*The working group owes a  great debt of gratitude to Tom Haynes for getting
us really going in this direction. He volunteered and did most of the work.
Others just nagged him about getting it done quicker :-(
                           *
*
                                               *
*
*
*One final note:
                                           *
*
                                                    *
*
                                                   *

   - *if v2 is bis
                                    *
   - *and if v3 is tris
                                  *
   - *v7 is heptakis,
                                   *
   - *v9 enneakis
                                  *
   - *v20 ia eiosakis
                                   *
   - *v27 is heptaeicosakis
                                *
   - *v81 is henoctacontakis
                             *
   - *v1001 is henkilliakis
                                  *

*Thanks to the International Union of pure and applied chemistry for the
numeric affixes.*
*
*
*Not volunterring here but my experience with pNFS has shown me that while
it is fundamentlly sound, we may someday wind up trying to do
RFC5661henkilliakis. The big issue is whether we continue the orginal
pattern of codiying N server implementations for client use.  That was a
resonabl srk-compomise (as opposed to continually arguing which of those n
was the one, but many implementers may want more)*

*
*
*
*