On Tue, 30 Aug 2011, Martin Sustrik wrote:
For an implementor it's often pretty hard to decide whether to
implement functionality marked as SHOULD given that he has zero
context and no idea whether the reason he has for not implementing the
feature is at all in line with RFC authors'
Alan Barrett wrote:
On Tue, 30 Aug 2011, Martin Sustrik wrote:
For an implementor it's often pretty hard to decide whether to
implement functionality marked as SHOULD given that he has zero
context and no idea whether the reason he has for not implementing the
feature is at all in line with
Hi Jari,
At 15:05 02-09-2011, Jari Arkko wrote:
But what I really wanted to say here was a response to your concern
about those proposals to do something else. Let me just state this
clearly. I know I would be VERY happy to sponsor many different
kinds of improvement proposals. In sequence or
Hi,
I believe that almost everything Roy says below is non-controversial; if
we can tune the language to be less offensive it might fit well into the
Introduction (and not require an IESG Note to get into the document).
Best regards, Julian
On 2011-09-01 21:55, Roy T. Fielding wrote:
I
Sam Hartman wrote:
Eric == Eric Burger ebur...@standardstrack.com writes:
Eric This highlights an interesting issue as an RFC goes from PS to
Eric IS. I would offer that most SHOULDs in a document will, if
Eric there are real implementations out there, migrate to MUST or
Eric
--On Wednesday, August 31, 2011 23:10 -0400 Sam Hartman
hartmans-i...@mit.edu wrote:
Eric == Eric Burger ebur...@standardstrack.com writes:
Eric This highlights an interesting issue as an RFC goes
from PS to Eric IS. I would offer that most SHOULDs in a
document will, if Eric
On 2011-09-03 12:54, Julian Reschke wrote:
Hi,
I believe that almost everything Roy says below is non-controversial; if
we can tune the language to be less offensive it might fit well into the
Introduction (and not require an IESG Note to get into the document).
Best regards, Julian
...
Like
On Tue, 30 Aug 2011, Martin Sustrik wrote:
For an implementor it's often pretty hard to decide whether to
implement functionality marked as SHOULD given that he has zero context
and no idea whether the reason he has for not implementing the feature is
at all in line with
Noel Chiappa wrote:
For me, I would say that unless the implementor in question has
experience in designing protocols, and fairly deep understanding
of that particular area, they are not in a position to make a
good judgement on whether or not they can ignore a 'SHOULD'.
True Noel, but the
Keith:
The current IETF Standards Process has become essentially a one-step process.
The goal, as I believe is stated in the document, is gather some benefit from
implementation and deployment experience. We are not getting that today. When
we do get it, the document recycles at the same
Hi -
From: Hector sant9...@gmail.com
Cc: ietf@ietf.org
Sent: Saturday, September 03, 2011 7:52 AM
Subject: Re: 2119bis
...
For protocol v2.0, X2 is a improved version of X1.
SHOULD USE X2 IF POSSIBLE, IF NOT
MUST USE X1
Its the same as saying
MUST USE X2 first or X1 as
I don't know if this is a cultural issue or not, but neither of those
changes is an improvement, nor should they be any less offensive.
Convoluted and inefficient describes the hashing algorithm in the
least offensive way possible -- complex doesn't say anything.
There are a lot of complex
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Alan
Barrett
Sent: Saturday, September 03, 2011 12:20 AM
To: IETF Discussion
Subject: Re: 2119bis
It's really simple. If an interoperability problem arises
from your failure to implement
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John
C Klensin
Sent: Saturday, September 03, 2011 6:00 AM
To: Sam Hartman; Eric Burger
Cc: IETF discussion list
Subject: Re: 2119bis
Note that this loops back to the the discussion about
14 matches
Mail list logo
