[e2e] Are we doing sliding window in the Internet?

[Ted Faber]

On Thu, Jan 04, 2007 at 08:57:45AM -0800, Joe Touch wrote:
> 
> 
> Ted Faber wrote:
> > On Wed, Jan 03, 2007 at 03:51:07PM -0800, Joe Touch wrote:
> ...
> >> Conditional compliance should come with a statement of the conditions.
> >> Absent that, it's just buggy.
> > 
> > Now who's not reading 1122?  The terms are defined there and there's
> > no indication of a "signing statement" requirement for conditionally
> > compliant implementations.  It's just a phrase that means "did all the
> > MUSTs and omitted one or more of the SHOULDs."  It's precise, unlike the
> > "buggy" word we can't agree on.
> 
> See below...
> 
> > You may disagree with omitting delayed ACKs, but the RFCs allow it.
> 
> RFC1122 also states:
> 
>          *    "SHOULD"
> 
>               This word or the adjective "RECOMMENDED" means that there
>               may exist valid reasons in particular circumstances to
>               ignore this item, but the full implications should be
>               understood and the case carefully weighed before choosing
>               a different course.
> 
> I.e., if you negate a SHOULD you ought to demonstrate you understand the
> implications and have weighed the case. That's clearly stated in
> RFC1122. 

If we're going to be picky (and why stop now?) no *demonstration* is
required.  It says that implementors *should* to think seriously about
their choice when they violate a SHOULD, not that they have to explain
their thinking to you (or me, or anyone else).

I understand that there's no objective way to make sure that thinking
has been done, but there's no requirement to present it either.  To whom
would you require such a presentation, anyway?

And, of course, there's a "should" in the definition of SHOULD.
Regardless of whether any thinking at all has happened, one can ignore a
SHOULD and be within the letter of the RFC "law."

FWIW, I don't think SHOULDs should be thrown aside lightly, either.  But
they're spots where the IETF consensus admits that designers and
implementors can make a different decision without catastrophic
interoperability problems.

For my money "bug" is much more derisive than even "wrong design"
because it implies (to me) a level of obliviousness that doesn't seem
present here.  Bugs are accidents; this seems like a conscious choice.
I understand it's a choice you disagree with, but IMHO it's a choice
that violates no RFC.

I think you're much better off debating the content of the design
decision than wether it violates some unenforcable boundary.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20070104/7942ae30/attachment.bin