Folks,
I am increasingly concerned about efficiency in the IETF, given the loads
everyone is carrying. One source of inefficiency is having someone create
work for others, without having already done enough of their own work.
[...]
A few years ago I proposed
On Wed, Mar 10, 2010 at 03:42:12PM -0800,
Dave CROCKER d...@dcrocker.net wrote
a message of 52 lines which said:
The prudent action is to return it to the appellant, stating that it
cannot be processed until it has been made clear and concise.
I approve and I also believe that, giving the
On 3/11/10 9:24 AM, Stephane Bortzmeyer wrote:
On Wed, Mar 10, 2010 at 03:42:12PM -0800,
Dave CROCKERd...@dcrocker.net wrote
a message of 52 lines which said:
The prudent action is to return it to the appellant, stating that it
cannot be processed until it has been made clear and
On 10.03.2010 20:34, The IESG wrote:
The IESG has received a request from the NETCONF Data Modeling Language
WG (netmod) to consider the following document:
- 'YANG - A data modeling language for NETCONF '
draft-ietf-netmod-yang-11.txt as a Proposed Standard
The IESG plans to make a
Internet Registration Bar BOF (Update)
This is an update to an announcement set March 4.
When: Wednesday, March 24, 2010 at 8pm PDT (-0700)
Where: IETF 77 Conference hotel - Hilton Anaheim
Room: Mezzanine 1, Mezzanine Level, 3rd Floor, a.k.a Conference Room 1
The session is 1/2 hour after the
At 14:43 10-03-10, Russ Housley wrote:
The IESG has received an appeal. It can be found here:
[snip]
The IESG plans address this appeal in the next few weeks, and the IESG
solicits comments on this appeal from the community. Please send
I will not be able to reply to off-list comments
Periodically, there are flame wars on the IETF mailing list that the
IETF should / shouldn't adopt the latest fad is document formats,
postscript, PDF, whatever, since, after all, everyone uses them,
claims they are too complicated and keep changing resulting in
version/font/... problems are
On Thu, Mar 11, 2010 at 10:32:49AM -0500, Donald Eastlake wrote:
version/font/... problems are overblow, etc. As a data point, I would
refer people to
http://www.networkworld.com/news/2010/031010-hackers-love-to-exploit-pdf.html
That appears to be an argument that Adobe's products contain
My my it must be springtime! Time for our annual food fight ritual of ASCII
in RFC's.
Actually I was thinking that the IETF should approach the International
Digital Publishing Forum with the thought that they consider making the
.epub format an IETF standard. .epub is getting considerable
-Original Message-
From: kitten-boun...@ietf.org [mailto:kitten-boun...@ietf.org] On Behalf
Of
Phillip Hallam-Baker
Sent: Wednesday, March 10, 2010 8:05 AM
To: Melinda Shore
Cc: e...@ietf.org; Glen Zorn; kit...@ietf.org; moonshot-
commun...@jiscmail.ac.uk; Sam Hartman;
On Mon, 8 Mar 2010 07:16:55 -0800 The wrote:
TI The IESG plans to make a decision in the next few weeks, and solicits
TI final comments on this action. Please send substantive comments to the
TI ietf@ietf.org mailing lists by 2010-04-02.
I didn't notice that some MIB objects got renamed between
On Wed, 10 Mar 2010 16:52:25 -0500, Robert Story
robert.st...@cobham.com said:
RS I think that the inconsistent use of 'Client' and 'Server' in the
RS object names is confusing. Both snmpTlstmSessionOpens and
RS snmpTlstmSessionOpenErrors are client-side only objects, and
RS
It is important to do so in ways that ensure that the insurance
criteria are not breached.
Returning the document is not covered in the rules. But there seems to
be no reason that the IESG could not ask someone (e.g. Ted Hardie who
has already done so) to write up a concise summary.
On Wed,
Our process may be complicated, but a deviation from due process
that requires 145 pages of description is simply not possible.
We have specific rules in RFC 2026 and RFC 2418 (and various updates)
and it should be possible to describe specific alleged deviations
from those rules in a page or
Meadhbh,
A major use case that's lacking in the standards you mention is support for
security domain separation. In high assurance environments, a crypto device
typically separates two security domains (protected unprotected), performing
cryptographic operations at the boundary. The existing
On 2010-03-11 00:42 Dave CROCKER said:
An appeal needs to state its concerns and requirements clearly and concisely.
That might include masses of reference material, but the appeal statement,
itself, needs to be short and to the point.
When an appeal is lodged that fails these basic
Richard Shockey wrote:
I do get the arguments in favour of ASCII, though I think there are
some pretty serious countervailing arguments (like, for instance, that
we can't spell many contributors' names, to take an easy one). But
the RFC format _is not_ plain ASCII. Just ask anyone whose
Besides your eyes, (only one in some cases), you don't need any extra
junkware to be able to read the RFCs, even better, without eyes you
still can do it since text to speech works very nicely with ASCII.
There could be some compatibility problems with some ancient blueware
still using EBCDIC.
On 03/11/2010 04:43 PM, Henrik Levkowetz wrote:
On 2010-03-11 00:42 Dave CROCKER said:
An appeal needs to state its concerns and requirements clearly and
concisely.
That might include masses of reference material, but the appeal statement,
itself, needs to be short and to the point.
On 11.03.2010 17:54, Jorge Amodio wrote:
Besides your eyes, (only one in some cases), you don't need any extra
junkware to be able to read the RFCs, even better, without eyes you
still can do it since text to speech works very nicely with ASCII.
...
I'd claim that accessibility for properly
To the IESG:
On Wed, Mar 10, 2010 at 05:43:12PM -0500, Russ Housley wrote:
The IESG has received an appeal. It can be found here:
http://www.ietf.org/iesg/appeal/morfin-2010-03-10.pdf
I have read the document, though I cheerfully concede that some of the
text eludes my understanding. I was
On Thu, Mar 11, 2010 at 8:54 AM, Martin Rex m...@sap.com wrote:
The existing plaintext ASCII format is easy and univerval. Any more
fancy document formats come with plenty of problems and infinitesimal
close to zero benefit.
ARRRGGH
... which is the only contribution a
.epub has a number of serious faults of its own, that are starting to be
experienced as people are playing with it in wake of the iPad stuff. It's
basically a dead end repackaging of an old HTML spec, and it has nobody
working on getting it up to date, or working on it at all.
On Thu, Mar 11,
On 11.03.2010 18:25, Tim Bray wrote:
On Thu, Mar 11, 2010 at 8:54 AM, Martin Rexm...@sap.com wrote:
The existing plaintext ASCII format is easy and univerval. Any more
fancy document formats come with plenty of problems and infinitesimal
close to zero benefit.
ARRRGGH
On Thu, Mar 11, 2010 at 11:12 AM, Julian Reschke julian.resc...@gmx.de wrote:
On 11.03.2010 17:54, Jorge Amodio wrote:
Besides your eyes, (only one in some cases), you don't need any extra
junkware to be able to read the RFCs, even better, without eyes you
still can do it since text to speech
On 11.03.2010 19:44, Jorge Amodio wrote:
On Thu, Mar 11, 2010 at 11:12 AM, Julian Reschkejulian.resc...@gmx.de wrote:
On 11.03.2010 17:54, Jorge Amodio wrote:
Besides your eyes, (only one in some cases), you don't need any extra
junkware to be able to read the RFCs, even better, without eyes
On 3/11/2010 9:16 AM, Andrew Sullivan wrote:
As near as I can
tell, that says that it is _not_ an appeal of the document set itself.
Let us consider careful this sentence.
Andrew expended substantial time an energy to read and analyze the appel. For
all that, he is still left having to
Andrew,
Thankyou for spending time on this.
On 2010-03-12 06:16, Andrew Sullivan wrote:
...
It is instead an appeal that the documents were not published with
disclaimers attached.
Interesting. Since we're being legalistic, all IETF documents carry
the standard disclaimer (by reference in
On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter wrote:
That seems to cover most angles. I can't see why the IESG could be
expected to add technical disclaimers to a consensus document. In fact,
doing so would probably be a process violation in itself.
Well, ok, and yes it probably
你好 Jorge,
You wrote:
And ASCII is more eco-friendly :-)
Simplified Chinese is even more eco-friendly ;-)
Cheers, Huub van Helvoort (AKA 海高明)
--
Always remember that you are unique...just like everyone else...
Andrew == Andrew Sullivan a...@shinkuro.com writes:
Andrew On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter wrote:
That seems to cover most angles. I can't see why the IESG could
be expected to add technical disclaimers to a consensus
document. In fact, doing so
I agree with Sam, for cases which would otherwise result in an
endless DISCUSS - although normally I'd expect the argument
to be complex enough that a separate RFC would be needed to
explain the dissent.
Brian
On 2010-03-12 09:58, Sam Hartman wrote:
Andrew == Andrew Sullivan
Tim Bray wrote:
The existing plaintext ASCII format is easy and univerval. ?Any more
fancy document formats come with plenty of problems and infinitesimal
close to zero benefit.
ARRRGGH
Can't you notice fancy tool of you have wrongly translated a
character in univerval.
Only if hand-written. This E-Mail message went from 13 KB to 4 KB, by
simply deleting the Kanji characters.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Huub
van Helvoort
Sent: Thursday, March 11, 2010 3:53 PM
Cc: ietf@ietf.org
Subject: Re:
And ASCII is more eco-friendly :-)
Simplified Chinese is even more eco-friendly ;-)
Some times, encoding your example takes few bytes, HI only two.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Jorge Amodio wrote:
I'd potentially agree if the format we actually use wouldn't have useless
page breaks that leave 25% of the pages unused. At least over here. I'd also
agree if that format would actually be usable on small devices like ebook
readers (where it's essential that you can
As usual, the discussion of ASCII plain text versus beyond-ASCII plain
text has been mixed up with the essentially unrelated discussion of
plain text versus another format.
Martin Rex mrex at sap dot com wrote:
Unicode characters are also a Royal PITA in specs, because they're
Hi,
First, my excuses to Martin for the cheap shot below. But I really
couldn't help myself, as hist posting illustrates the power of one of
the potential alternatives to ASCII (as a presentation format for drafts
and RFCs) so well...
On 2010-03-12 01:11 Martin Rex said the following:
Henrik Levkowetz henrik at levkowetz dot com wrote:
I really think that we should decide to move beyond the current
pure-ASCII presentation format, whether it be a constrained HTML or
PDF-A (which are the primary serious contenders as alternatives to
pure ASCII as presentation format that I
On Thu, Mar 11, 2010 at 10:52 AM, Andrew Sullivan a...@shinkuro.com wrote:
On Thu, Mar 11, 2010 at 10:32:49AM -0500, Donald Eastlake wrote:
version/font/... problems are overblow, etc. As a data point, I would
refer people to
Hi,
(ah, flamewars! My favourite! :-) )
Can't you notice fancy tool of you have wrongly translated a
character in univerval. ?Any of quoted message, even though
the original message by Martin Rex is pure ASCII.
That is, two consequetive space charactersbefore Any is
translated to a
Hi,
As usual, the discussion of ASCII plain text versus beyond-ASCII
plain text has been mixed up with the essentially unrelated
discussion of plain text versus another format.
+1
Stefan
Martin Rex mrex at sap dot com wrote:
Unicode characters are also a Royal PITA in specs, because
I happy to forward this announcement about DNSSEC deployment on the .ARPA
zone on behalf of Joe Abley, Director DNS Operations at ICANN. Please
reply to him with any specific operational questions you might have.
--Olaf
Colleagues,
This is a technical, operational announcement regarding
43 matches
Mail list logo
