...
Anyone who agrees with the CfC statement, and doesn't say anything, is
fine, because the CfC doesn't need or want their support. The CfC will
stand or fall based upon the size of the disagree and replied group.
That's pretty much how I've seen IETF consensus work over the years.
As
Sandy == Sandy Wills [EMAIL PROTECTED] writes:
Sandy Gray, Eric wrote:
It is useful sometimes to differentiate those who have no stake
in a particular issue from those who are not paying attention.
Sandy (rest of post snipped)
Sandy Here I must become two-faced.
Sandy
Sandy == Sandy Wills [EMAIL PROTECTED] writes:
Sandy Brian Rosen wrote (about the format issue):
It's probably true that we can push this problem off another
year, but maybe not, and definitely not for very much longer.
Sandy I think that everyone here is aware of that, which
Stewart == Stewart Bryant [EMAIL PROTECTED] writes:
Stewart I am in favour of any practical method that allows us to
Stewart progress towards the best tools for the job.
Stewart My personal end-goal is simple: I want us to be able to
Stewart use modern graphical techniques in
On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
Are you looking for normative figures? If so, can you point to an
example where you think they are necessary? (I'd like to avoid a
discussion of packet diagrams for the moment if that's OK)
Normative figures perhaps. Normative equations
Scott == Scott W Brim sbrim@cisco.com writes:
Scott On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
Are you looking for normative figures? If so, can you point to
an example where you think they are necessary? (I'd like to
avoid a discussion of packet diagrams for the
Sandy == Sandy Wills [EMAIL PROTECTED] writes:
Sandy Gray, Eric wrote:
Sandy, In fact, contrary to what we observe in nature, change
is not the default outcome in most human organizations. That
is because - as a careful analysis of this discussion over the
years will
Mmm. I have some significant accessibility concerns with that if you
expect me to review the documents. I think that's a small (although
probably impossible at the current point) matter of technology.
Sam,
Thank you for raising this basic point. Since the IETF seeks the widest
possible
Dave == Dave Crocker [EMAIL PROTECTED] writes:
Mmm. I have some significant accessibility concerns with that
if you expect me to review the documents. I think that's a
small (although probably impossible at the current point)
matter of technology.
Dave Sam,
Dave
In message [EMAIL PROTECTED], Scott W Brim writes:
On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
Are you looking for normative figures? If so, can you point to an
example where you think they are necessary? (I'd like to avoid a
discussion of packet diagrams for the moment if that's OK)
Sam/Sandy,
See below...
--
Eric
--- [SNIP] ---
-- Sandy Unfortunately, there seems to be a religious dogma
-- Sandy among the long-time IETF participants that they never take
-- Sandy votes. All they do is judge rough or smooth concensus, and
-- Sandy that reduces
I think these are valuable inputs as well. There are people involved;
whether these people are happy, whether they will continue to work,
are important factors. Of course there are religious arguments on the
other side: I want my architectural diagrams; they work well in the
ITU and I want
*
* Normative figures perhaps. Normative equations definitely.
Scott,
How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
of readable equations in ASCII? I my experience, normative protocol
technical specifications rarely need equations much more complex than
these
Hi. With the exception of packet diagrams, I think all the examples
you bring up benefit significantly from clear textual description. I
believe I'd think that even if I could see the diagrams and I believe
I have enough experience with visualization (although not sight) to be
confident in that
--On Monday, 09 January, 2006 18:17 + Stewart Bryant
[EMAIL PROTECTED] wrote:
I think these are valuable inputs as well. There are people
involved; whether these people are happy, whether they will
continue to work, are important factors. Of course there are
religious arguments on the
Bob Braden wrote:
*
* Normative figures perhaps. Normative equations definitely.
Scott,
How about Sections 4.2.3.3 and 4.2.3.4 of RFC 1122 (1889), for examples
of readable equations in ASCII? I my experience, normative protocol
technical specifications rarely need equations much more
On 01/09/2006 14:02 PM, John C Klensin allegedly wrote:
While I agree that diagrams are not simply a religious issue, I
think that there are many cases in which the use of diagrams,
especially complex ones, leaves people with the impression that
they have understood something when, in fact,
Sam Hartman wrote:
Hi. With the exception of packet diagrams, I think all the examples
you bring up benefit significantly from clear textual description.
Sam
I am not saying that clear text is not needed to accompany a diagram.
However a diagram allows a lot less text to be written
Stewart,
There's a joke that goes something like this: there are three
kinds of people in this world - those that are good at Math and those
that are not.
Funny thing is that there are at least three ways in which
people approach mathematical expressions:
1) Some see a nice,
In message [EMAIL PROTECTED], Scott W Brim writes:
On 01/09/2006 10:41 AM, Sam Hartman allegedly wrote:
Are you looking for normative figures? If so, can you point to an
example where you think they are necessary? (I'd like to avoid a
discussion of packet diagrams for the moment if
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| On Behalf Of Stewart Bryant
| Sent: Tuesday, January 10, 2006 6:47 AM
| To: Sam Hartman
| Cc: Harald Tveit Alvestrand; ietf@ietf.org
| Subject: Re: Normative figures
|
| Sam Hartman wrote:
|
| Hi. With the
All:
To
assist the planning of future meetings, we
ask you kindly to spend a minute or two responding
to the on-line survey at https://www.surveymonkey.com/s.asp?u=465231656574
Even if
you did not attend IETF 64 in Vancouver, we would
value your responses.
All responses will be treated
Note that LaTeX is an input format - it will output to many output
formats - even to ASCII. (And, of course, it sits on top of and
drives TeX itself.)
As a physicist, I have used LaTeX a lot. It has a steep learning
curve - much more than with, say, html.
When I did a set of conference
Stewart,
You realize that the text example you gave is meaningless -
without making some (potentially non-obvious) assumptions, right?
-- -Original Message-
-- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
-- On Behalf Of Stewart Bryant
-- Sent: Monday, January 09, 2006
Dassa wrote:
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| On Behalf Of Stewart Bryant
| Sent: Tuesday, January 10, 2006 6:47 AM
| To: Sam Hartman
| Cc: Harald Tveit Alvestrand; ietf@ietf.org
| Subject: Re: Normative figures
|
| Sam Hartman wrote:
|
|
Eric
You are missing the point.
I was picking an example out of thin air, but it is the type of construct
that we use all the time in fast-reroute.
The example was four routers connected together in a square with some
randomly chosen asymetric costs. Such a network is trivial, but FRR
need to
Stewart,
See below...
--
Eric
-- -Original Message-
-- From: Stewart Bryant [mailto:[EMAIL PROTECTED]
-- Sent: Monday, January 09, 2006 6:50 PM
-- To: Gray, Eric
-- Cc: ietf@ietf.org
-- Subject: Re: Normative figures
--
-- Eric
--
-- You are missing the point.
--
Out of
I disagree that the use of diagrams is a religious issue. Diagrams
are a very simple way to put specification and context together
in a compact notation such that it is easy to move from key
point to key point in a non-linear way. They provide visual
hyperlinking.
Stewart,
While I
On Mon, Jan 09, 2006 at 12:57:56PM -0500, Gray, Eric wrote:
Usually, before you can actually seek consensus, you must have an
essentially binary choice. It is hard enough to reach consensus
on simple choices without turning up the process noise by having a
plethora of possible choices.
I
We write specifications so that they are easier to read, validate
and understand, not so that they are easier to write.
Eric
We write specs so that they will be correctly implemented.
Anything that makes a specification easier to correctly understand
surely makes it more likely that it
Yes. And, if we're talking about wanting to make the figures
normative, I assume we are talking about a specification. In
that case, it is far more important that the description MUST
be precise, than it is that it MAY be convenient.
Please can we clarify the existing rules:
For a
Stewart Bryant wrote:
We write specifications so that they are easier to read, validate and
understand, not so that they are easier to write.
Eric
We write specs so that they will be correctly implemented.
Anything that makes a specification easier to correctly understand
surely makes it
IMHO, *way* too many I*E*TF work groups get chartered based on an idea.
We then spend tons of resources on figuring out if the idea will work.
We produce lots of half-baked documents with little basis in working
code. Then folks try implementing what's been spec'ed, find it doesn't
work, but then
The IESG has approved the following document:
- 'Rivest-Shamir-Adleman (RSA) key exchange for the Secure Shell (SSH)
Transport Layer Protocol '
draft-harris-ssh-rsa-kex-06.txt as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working
The IESG has approved the following document:
- 'Enhancements for Authenticated Identity Management in the Session Initiation
Protocol (SIP) '
draft-ietf-sip-identity-06.txt as a Proposed Standard
This document is the product of the Session Initiation Protocol Working Group.
The IESG
The IESG has approved the following document:
- 'Optimistic Duplicate Address Detection for IPv6 '
draft-ietf-ipv6-optimistic-dad-07.txt as a Proposed Standard
This document is the product of the IP Version 6 Working Group Working Group.
The IESG contact persons are Margaret Wasserman and
The IESG has approved the following document:
- 'Low Latency Handoffs in Mobile IPv4 '
draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt as an Experimental RFC
This document is the product of the Mobility for IPv4 Working Group.
The IESG contact persons are Margaret Wasserman and Mark
The IESG has approved the following document:
- 'Mobile IPv4 Dynamic Home Agent Assignment '
draft-ietf-mip4-dynamic-assignment-07.txt as a Proposed Standard
This document is the product of the Mobility for IPv4 Working Group.
The IESG contact persons are Margaret Wasserman and Mark
The IESG has approved the following document:
- 'Fibre-Channel Name Server MIB '
draft-ietf-imss-fc-nsm-mib-05.txt as a Proposed Standard
This document is the product of the Internet and Management Support for Storage
Working Group.
The IESG contact persons are Bert Wijnen and David
The IESG has approved the following document:
- 'Fibre Channel Fabric Address Manager MIB '
draft-ietf-imss-fc-fam-mib-03.txt as a Proposed Standard
This document is the product of the Internet and Management Support for Storage
Working Group.
The IESG contact persons are Bert Wijnen and
The IESG has approved the following document:
- 'The AES-CMAC Algorithm '
draft-songlee-aes-cmac-03.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Russ Housley.
A URL of this Internet-Draft
The IESG has received a request from the Layer Two Tunneling Protocol
Extensions WG to consider the following document:
- 'L2VPN Extensions for L2TP '
draft-ietf-l2tpext-l2vpn-06.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments
A new Request for Comments is now available in online RFC libraries.
RFC 4285
Title: Authentication Protocol for Mobile IPv6
Author(s): A. Patel, K. Leung, M. Khalil, H. Akhtar,
K. Chowdhury
Status: Informational
Date:
A new Request for Comments is now available in online RFC libraries.
RFC 4233
Title: Integrated Services Digital Network (ISDN)
Q.921-User Adaptation Layer
Author(s): K. Morneault, S. Rengasami, M. Kalla,
G. Sidebottom
44 matches
Mail list logo
