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
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
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,
I am a researcher of Master's degree , working on LEACH routing
protocol for wireless sensor networks and i need to know for which
standard does LEACH , its family ,or even Layer 3 belong to.
A Google search suggests that LEACH has not been standardized. LEACH
appears to have been invented by
On Sun, Jan 6, 2013 at 8:15 PM, Robert Sayre say...@gmail.com wrote:
On Sun, Jan 6, 2013 at 4:01 PM, Robert Sayre say...@gmail.com wrote:
On Sun, Jan 6, 2013 at 3:35 PM, Paul C. Bryan pbr...@anode.ca wrote:
Common concurrent editing algorithms should, in my opinion, use
techniques
to
On Sat, 2013-01-05 at 16:19 -0800, Robert Sayre wrote:
[snip]
1) The ambiguity around arrays makes the patch format unsuitable for
common concurrent editing algorithms.
Common concurrent editing algorithms should, in my opinion, use
techniques to ensure the state of the resource (relative
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
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 beyond
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.)
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,
myself;
-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 problem.
Hello Nabil,
Greg is almost right.
RDI == Remote Defect Indication
This is the abbreviation used in IEEE 802.1ag, Y.1731, G.707, G.8121
and rfc6428.
Regards, Huub.
can we avoid different interpretation of the same abbreviation (RDI):
RDI Remote Defect Indication for Continuity Check
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)
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 to RFC
Maybe part of the job of a working group should be to both/either produce or
approve a reference implementation and/or a test for interoperability? I
always thought a spec should include an acceptance test. Contracts often
do.
If a company submits code that becomes reference code for
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
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 written
Oh, if you were considering a visit to one of the nearby theme parks,
check out their latest hi-tech innovation:
http://www.nytimes.com/2013/01/07/business/media/at-disney-parks-a-bracelet-meant-to-build-loyalty-and-sales.html
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
--On Tuesday, January 08, 2013 02:56 + John Levine
jo...@taugh.com wrote:
Oh, if you were considering a visit to one of the nearby theme
parks, check out their latest hi-tech innovation:
http://www.nytimes.com/2013/01/07/business/media/at-disney-par
I apologize for being absent for this thread until now. Vacation and
medical matters interfered with me keeping current.
First, with my participant hat on:
I've been occasionally comparing this work to conventional UNIX patch to
try to maintain a point of reference as these works developed. As
If I may, I would follow this up with a suggestion that a separate I-D that
provides a more complete treatment of fully-concurrent patch operations
would be helpful. JSON-Patch is largely designed around atomic and
sequential modification operations and is not, necessarily a great match
for the
On Mon, Jan 7, 2013 at 8:40 PM, Murray S. Kucherawy superu...@gmail.com wrote:
we have the test operations, so people
generating patch documents should use them to ensure proper context before
applying any of the operations that alter the target.
I don't see how can the test operation be used
On Mon, Jan 7, 2013 at 8:40 PM, Murray S. Kucherawy superu...@gmail.com wrote:
Then, with my co-chair hat on:
it is not my view after reviewing this
thread that there's rough consensus to reopen the question.
I agree with this assessment.
- Rob
The IESG has received a request from the Locator/ID Separation Protocol
WG (lisp) to consider the following document:
- 'LISP MIB'
draft-ietf-lisp-mib-08.txt as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send
The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'A Security Threat Analysis for Routing over Low Power and Lossy
Networks'
draft-ietf-roll-security-threats-00.txt as Informational RFC
The IESG plans to make a
The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'Link Management Protocol Behavior Negotiation and Configuration
Modifications'
draft-ietf-ccamp-lmp-behavior-negotiation-09.txt as Proposed Standard
The IESG plans
The IESG has approved the following document:
- 'Session Description Protocol (SDP) Media Capabilities Negotiation'
(draft-ietf-mmusic-sdp-media-capabilities-17.txt) as Proposed Standard
This document is the product of the Multiparty Multimedia Session Control
Working Group.
The IESG contact
The RTCWEB and MMUSIC working groups would like to announce an upcoming
joint interim meeting.
The meeting will be held in the Boston, Massachusetts area on February
5-7th, 2013, in conjunction with meetings of the W3C WEBRTC working
group. Full details, including meeting site, nearby hotels, and
This is a reminder of an ongoing IETF-wide Call for Comment on
'Principles for Unicode Code Point Inclusion in Labels in the DNS'.
The document is being considered for publication as an Informational
RFC within the IAB stream, and is available for inspection here:
The IESG has approved the following document:
- 'Representing IPv6 Zone Identifiers in Address Literals and Uniform
Resource Identifiers'
(draft-ietf-6man-uri-zoneid-06.txt) as Proposed Standard
This document is the product of the IPv6 Maintenance Working Group.
The IESG contact persons are
86th IETF Meeting
Orlando, FL, USA
March 10-15, 2013
Host: Comcast and NBCUniversal
Meeting venue: Caribe Royale http://www.cariberoyale.com
Register online at: http://www.ietf.org/meetings/86/
1. Registration
2. Social Event
3. Visas Letters of Invitation
4. Accommodations
5. Companion
A new Request for Comments is now available in online RFC libraries.
RFC 6819
Title: OAuth 2.0 Threat Model and
Security Considerations
Author: T. Lodderstedt, Ed.,
M. McGloin,
P. Hunt
A new Request for Comments is now available in online RFC libraries.
RFC 6828
Title: Content Splicing for RTP Sessions
Author: J. Xia
Status: Informational
Stream: IETF
Date: January 2013
Mailbox:
A new Request for Comments is now available in online RFC libraries.
RFC 6829
Title: Label Switched Path (LSP) Ping for
Pseudowire Forwarding Equivalence Classes (FECs)
Advertised over IPv6
Author: M. Chen, P.
41 matches
Mail list logo
