might preference would be just to pick one, and
provide a stick for hitting those who do it the other way.
I think that IESG is already using that stick :)
AB
On 1/9/13, Dean Willis dean.wil...@softarmor.com wrote:
On Jan 8, 2013, at 12:57 PM, Abdussalam Baryun abdussalambar...@gmail.com
John Day wrote:
For any formal proofing system worth its dime, this can be 100% ruled out,
since the proofing system will emit a 100% bugfree implementation of the
spec in the programming language of your choice as a result/byproduct of the
formal proofing process.
C'mon. You don't really
John Day wrote:
It would be interesting to see you apply that.
This is what I have been talking about. The human mind's ability to
believe that the whole world sees everything the same way they do.
It really is quite amazing.
These so-called gaps often arise because they were unstated
Maybe the survey to be done is a review of all the RFC, STD and see
which ones
- had a great abstract and introduction,
- had the better writing styles
- had the least endorsement resistance
- progress faster than most,
- had the most implementators,
- with least support/questions need to be
On 1/7/2013 6:01 PM, John Day wrote:
All standards groups that I am aware of have had the same view. This is
not uncommon.
Although, I would point out that the TCP specification nor do most
protocols specifications of this type follow this rule. State
transitions are not visible on the wire.
Hi John,
thank you for your reply (i.e. learned alot), so I understand that a
RFC standard track may have more than one implementation but same
behavior enough not to make an error. Regarding following 2119, I
understand most text follow it only when there are normative actions.
Regarding
On 5 January 2013 19:14, Marc Petit-Huguenin petit...@acm.org wrote:
[snip]
Another way to look at it would be to run the following experiment:
1. Someone design a new protocol, something simple but not obvious, and write
in a formal language and keep it secret.
Which raises the obvious
The reasons have been discussed or at least alluded to previously in
this thread. The short answer is we have been there and done that:
30 years ago.
All those tools were developed and used successfully in the 80s. I
know of cases where doing the formal specification alongside the
design
Another problem is maintenance. Protocols change. Having to maintain a
formal specification is commonly at least an order of magnitude more
effort than maintaining a prose description. So it doesn't happen and
they very rapidly get out of synch in any living protocol. As an
example, the IEEE
Hear. Hear. Ditto! Absolutely. etc.
At 10:12 AM -0500 1/8/13, Donald Eastlake wrote:
Another problem is maintenance. Protocols change. Having to maintain a
formal specification is commonly at least an order of magnitude more
effort than maintaining a prose description. So it doesn't happen
but the question of
error in process is; does the RFC lack communication requirement with
the community?
Sorry if not clear. I mean that as some participant are requesting a
scientific approach to struggling with 2119 (i.e. thread-subject),
does that mean in some RFCs the use or not use (i.e.
Why not participant follow one approach to use 2119 in IDs and done,
and if not/another, then please specify in the language section.
AB
On Jan 7, 2013, at 4:53 AM, Stewart Bryant stbry...@cisco.com wrote:
Speaking as both a reviewer and an author, I would like
to ground this thread to some form of reality.
Can anyone point to specific cases where absence or over
use of an RFC2119 key word caused an interoperability
On Jan 8, 2013, at 12:57 PM, Abdussalam Baryun abdussalambar...@gmail.com
wrote:
but the question of
error in process is; does the RFC lack communication requirement with
the community?
Sorry if not clear. I mean that as some participant are requesting a
scientific approach to
John Day jeanj...@comcast.net wrote:
The reasons have been discussed or at least alluded to previously in this
thread. The short answer is we have been there and done that: 30 years ago.
All those tools were developed and used successfully in the 80s.
I know of cases where doing the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/08/2013 05:41 AM, Dick Franks wrote:
On 5 January 2013 19:14, Marc Petit-Huguenin petit...@acm.org wrote:
[snip]
Another way to look at it would be to run the following experiment:
1. Someone design a new protocol, something simple
At 1:36 AM +0100 1/9/13, Martin Rex wrote:
John Day jeanj...@comcast.net wrote:
The reasons have been discussed or at least alluded to previously in this
thread. The short answer is we have been there and done that: 30
years ago.
All those tools were developed and used successfully in
On 9 January 2013 01:19, John Day jeanj...@comcast.net wrote:
[snip]
One person's gap is another person's bug. What may be obvious to one as
something that must occur may not be so to the other. Then there is that
fine line between what part of the specification is required for the
It would be interesting to see you apply that.
This is what I have been talking about. The human mind's ability to
believe that the whole world sees everything the same way they do.
It really is quite amazing.
These so-called gaps often arise because they were unstated
assumptions or
This is what I have been talking about. The human mind's ability to believe
that the whole world sees everything the same way they do. It really is quite
amazing.
These so-called gaps often arise because they were unstated assumptions or
things that the author believed were patently obvious
Speaking as both a reviewer and an author, I would like
to ground this thread to some form of reality.
Can anyone point to specific cases where absence or over
use of an RFC2119 key word caused an interoperability failure,
or excessive development time?
- Stewart
As you are guessing that is unlikely, however, the more pertinent
question is whether it has prevented some innovative approach to
implementations. This would be the more interesting question.
We tend to think of these as state machines and describe them
accordingly. There are other
Indeed an interesting additional question.
My view is that you MUST NOT use RFC2119 language, unless you MUST use
it, for exactly that reason. What is important is on the wire (a term
that from experience is very difficult to define) inter-operation, and
implementers need to be free to
On 07/01/2013 12:42, Stewart Bryant wrote:
Indeed an interesting additional question.
My view is that you MUST NOT use RFC2119 language, unless you MUST use
it, for exactly that reason. What is important is on the wire (a term
that from experience is very difficult to define)
Let me get this straight, Brian. It would seem you are pointing out
that the IETF does not have a clear idea of what it is doing? ;-) I
could believe that.
No, your example is not an example of what I suggested at all.
Yours is an example of not specifying the conditions that a
congestion
On Jan 6, 2013, at 11:50 PM, John Day jeanj...@comcast.net wrote:
However, in the IETF there is also a requirement that there be two
independent but communicating implementations for an RFC to standards-track.
Correct?
Alas, no.
--John
On 07/01/2013 12:42, Stewart Bryant wrote:
Indeed an interesting additional question.
My view is that you MUST NOT use RFC2119 language, unless you MUST use
it, for exactly that reason. What is important is on the wire (a term
that from experience is very difficult to define)
Alas, indeed. ;-)
At 3:50 PM + 1/7/13, John Scudder wrote:
On Jan 6, 2013, at 11:50 PM, John Day jeanj...@comcast.net wrote:
However, in the IETF there is also a requirement that there be two
independent but communicating implementations for an RFC to
standards-track. Correct?
Alas,
Stewart Bryant stbry...@cisco.com writes:
Indeed an interesting additional question.
My view is that you MUST NOT use RFC2119 language, unless you MUST use
it, for exactly that reason. What is important is on the wire (a term
that from experience is very difficult to define)
All standards groups that I am aware of have had the same view. This
is not uncommon.
Although, I would point out that the TCP specification nor do most
protocols specifications of this type follow this rule. State
transitions are not visible on the wire. The rules for sliding
window are
Hi Marc Petit-Huguenin ,
I read the responses so far, and what can be said today is that there is 2
philosophies, with supporters in both camps. The goal of the IETF is to make
the Internet work better, and I do believe that RFC 2119 is one of the
fundamental tool to reach this goal, but having
Strictly speaking, the language of 2119 should be followed wherever
necessary in order for the text to be normative and make it mandatory
that a conforming implementation meets some requirement. Otherwise,
someone could build an implementation and claim it was correct and
possibly cause legal
32 matches
Mail list logo
