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.
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 ask
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 u
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
>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 wrote:
>
> On Jan 8, 2013, at 12:57 PM, Abdussalam Baryun
> wrote:
>
>>> but the question of
>>> error in pro
>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 obviou
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 things
On 9 January 2013 01:19, John Day 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
> specification and what p
At 1:36 AM +0100 1/9/13, Martin Rex wrote:
John Day 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
-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 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 o
>John Day 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 formal specif
On Jan 8, 2013, at 12:57 PM, Abdussalam Baryun
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 struggling with 2119 (i.
On Jan 7, 2013, at 4:53 AM, Stewart Bryant 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 failure,
> or excessi
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
>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.
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 an
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 802.11
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 p
On 5 January 2013 19:14, Marc Petit-Huguenin 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 question: Why
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 implemen
I have spent more than a little time on this problem and have
probably looked at more approaches to specification than most,
probably well over a 100. I would have to agree. Most of the very
formal methods such as VDL or those based on writing predicates in
the equivalent of first-order logic
> But some people feel we need a more formal specification language
> that goes beyond "key point compliance" or "requirements definition",
> and some are using 2119 words in that role and like it.
Having read specs like the Algol 68 report and ANSI X3.53-1976, the
PL/I standard that's largely wri
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 n
On Mon, 7 Jan 2013, ned+i...@mauve.mrochek.com wrote:
> I'll also note that RFC 1123 most certainly does use the term "compliant" in
> regards to capitalized terms it defines, and if nitpicking on this point
> becames an issue I have zero problem replacing references to RFC 2119 with
> references t
Stewart Bryant 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) inter-operation, and
> imp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/07/2013 12:19 PM, Dean Willis wrote:
>
> Well, I've learned some things here, and shall attempt to summarize:
>
> 1) First. the "1" key is really close to the "2" key, and my spell-checker
> doesn't care. Apparently, I'm not alone in this p
On 01/07/13 15:40, Riccardo Bernardini allegedly wrote:
>>
>> There appears to be interest in clarification, but nobody really wants to
>> revise the immortal words of RFC 2119, although there is a proposal to add a
>> few more words, like IF and THEN to the vocabulary (I'm hoping for GOTO,
>> m
>
> There appears to be interest in clarification, but nobody really wants to
> revise the immortal words of RFC 2119, although there is a proposal to add a
> few more words, like IF and THEN to the vocabulary (I'm hoping for GOTO,
> myself; perhaps we can make 2119 a Turing-complete language.)
Well, I've learned some things here, and shall attempt to summarize:
1) First. the "1" key is really close to the "2" key, and my spell-checker
doesn't care. Apparently, I'm not alone in this problem.
2) We're all over the map in our use of 2119 language, and it is creating many
headaches bey
Dean, I am struggling constantly with 2119 as an AD, because if I take
the letter (and the spirit) of 2119 at face value, a lot of people are
doing this wrong. And 2119 is a BCP; it's one of our process documents.
So I'd like this to be cleared up as much as you. I think there is
active harm in th
Alas, indeed. ;-)
At 3:50 PM + 1/7/13, John Scudder wrote:
On Jan 6, 2013, at 11:50 PM, "John Day" 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
On Jan 6, 2013, at 11:50 PM, "John Day" 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
Dean, I am struggling constantly with 2119 as an AD, because if I take
the letter (and the spirit) of 2119 at face value, a lot of people are
doing this wrong. And 2119 is a BCP; it's one of our process documents.
So I'd like this to be cleared up as much as you. I think there is
active harm in
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 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) inter-ope
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 achie
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 approach
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
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
Scott Brim wrote:
It's a communication problem. If you want your audience to understand
exactly what you're saying, and implement along very specific lines, you
need to tell them in a way they understand.
+1
Personally I prefer a quieter approach, but I've been told that
these days one MUS
> +1 to Brian and others saying upper case should be used sparingly, and
> only where it really matters. If even then.
That's the entire point: The terms provide additional information as to
what the authors consider the important points of compliance to be.
> The notion (that some have) that MU
+1; this is what we're doing in HTTPbis.
On 05/01/2013, at 5:15 AM, Peter Saint-Andre wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Wonderful perennial topic. :)
>
> As I always say when this comes up, when writing drafts I've settled
> on using the 2119 keywords only in their
+1 to Brian and others saying upper case should be used sparingly, and
only where it really matters. If even then.
The notion (that some have) that MUST means you have to do something
to be compliant and that a "must" (lower case) is optional is just
nuts.
If the ARP spec were to say, "upon recei
I generally take (what I infer to be) Richard's view on the matter. If not
doing something will break interoperability or security, then make it
normative. (I realize that's a gross oversimplification).
But that still doesn't mean you have to have a MUST for every step an
implementation has to
rplate.
Adrian
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Lou
> Berger
> Sent: 04 January 2013 13:23
> To: Dean Willis
> Cc: ietf@ietf.org
> Subject: Re: I'm struggling with 2219 language again
>
>
Anecdotal data point number N+1...
As an occasional implementor of IETF specs, I have to say it's much easier to
check my conformance if I can just grep for "MUST" and "SHOULD". It's also
easy for developers to get in the bad habit of ONLY doing those things that are
clearly marked in that way
+1.
I think it is important that we have communications tools for
documenting strong minimum protocol requirements and we only have
RFC2119 to make that possible.
Yet, we need to be careful where the lack of RFC2119 upper case
wordings can be used to leverage an argument for relaxation of
e
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wonderful perennial topic. :)
As I always say when this comes up, when writing drafts I've settled
on using the 2119 keywords only in their uppercase form, and otherwise
using "need to", "ought to", "might" (etc.) to avoid all possible
confusion. Sure
It's a communication problem. If you want your audience to understand
exactly what you're saying, and implement along very specific lines, you
need to tell them in a way they understand. Personally I prefer a
quieter approach, but I've been told that these days one MUST use MUST
or implementors j
I believe that Brian's interpretation is exactly right. At least, it
conforms to the Original Intent of the
applicability terms MUST, MAY, and SHOULD as defined in RFC 1122. And I
sympathize with
Dean Willis whose head hurts; as one-time RFC Editor I was often
confronted with wildly
inconsistent
On 1/4/2013 12:15 AM, Dean Willis wrote:
...
> Are we deliberately evolving our language to use RFC 2119 terms as
> the principle verbs of a formal specification language?
...
My view on this has evolved over time. I used to follow the practice of
using 2219 language only for emphasis. Over t
On Fri, Jan 4, 2013 at 8:03 AM, Brian E Carpenter
wrote:
>
> This Gen-ART reviewer believes that words like "must" have well defined
> meanings
> in the English language, so shouting is not needed at every use. There are
> standards track documents that don't use RFC 2119 at all, and I am not onl
On 04/01/2013 05:15, Dean Willis wrote:
...
> Either way, I'd like to see some consensus. Because my head is throbbing and
> I want to know if it MUST hurt, SHOULD hurst, or just hurts. But I MUST
> proceed in accordance with consensus, because to do otherwise would undermine
> the clarity of ou
56 matches
Mail list logo
