--On Friday, September 16, 2011 01:08 -0400 Keith Moore
mo...@network-heretics.com wrote:
...
Part of the problem is the expectation that some single label
should entirely define the status of a specification. There
are several almost-orthogonal variables that the community
cares about
Scott,
On one hand, most of these RFCs do not harm the Internet. However, if we don't
clean house periodically, we are left with the following questions:
1) In the future, does the IETF have the latitude to do things that might break
these old protocols?
2) If not, must the IETF maintain a
My impression is that the IETF quite regularly does new things that break
current, actively used, maintained, and even standards-track protocols. Maybe
we should worry about those before worry about breaking older protocols.
Keith
On Sep 16, 2011, at 9:30 AM, Ronald Bonica wrote:
Scott,
On 2011-09-15 18:46, Mykyta Yevstifeyev wrote:
...
9) I'd like you hereby disallowed further registration of header fields
beginning with MMHS, likewise RFC 5504 Downgraded prefix
(http://tools.ietf.org/html/rfc5504#page-18).
...
No. It's a bad idea in RFC 5504, and it would be a bad idea
I hit send too quickly after answering the first question, neglecting to answer
the latter two.
2. In general, IETF has a difficult time maintaining a cadre of people with
expertise in any particular area. There's very little representation by
applications developers; there's also
Hi Keith,
--On September 16, 2011 10:10:06 AM -0400 Keith Moore
mo...@network-heretics.com wrote:
I think we need a low-overhead and relatively informal mechanism of
reporting errata and requesting clarifications, and maybe that it should
be expanded a bit to serve as an implementation and
- Original Message -
From: Cyrus Daboo cy...@daboo.name
To: Keith Moore mo...@network-heretics.com; Ronald Bonica
rbon...@juniper.net
Cc: Scott O Bradner s...@harvard.edu; IETF Discussion ietf@ietf.org
Sent: Friday, September 16, 2011 4:52 PM
Hi Keith,
--On September 16, 2011 10:10:06
On Sep 16, 2011, at 10:52 AM, Cyrus Daboo wrote:
Again I would like to bring up the idea of every RFC having an associated
wiki page(s). The goal here is to provide a way for implementors to add
comments, annotations, clarifications, corrections etc to augment the RFCs.
Whilst such
On Sep 16, 2011, at 9:39 AM, Keith Moore wrote:
On Sep 16, 2011, at 10:52 AM, Cyrus Daboo wrote:
Again I would like to bring up the idea of every RFC having an associated
wiki page(s). The goal here is to provide a way for implementors to add
comments, annotations, clarifications,
The -19 version of this draft resolves the issues raised by the Gen-ART review
of the -18 version,
although issue [2] on registering the URIs has a couple of nits:
- IANA also found issue [2] and IANA will need to acknowledge that the -19
version of this draft
resolves this registration
Folks,
After reading responses from Scott, John and Keith, I think that I get it. No
matter how low hanging I believe the fruit to be, this isn't going to be cheap
or easy. So, I withdraw the proposal and apologize to Mykyta for having wasted
his time.
On Sep 16, 2011, at 10:24 AM, Ronald Bonica wrote:
After reading responses from Scott, John and Keith, I think that I get it. No
matter how low hanging I believe the fruit to be, this isn't going to be
cheap or easy. So, I withdraw the proposal and apologize to Mykyta for having
wasted his
On Sep 16, 2011, at 1:06 PM, Paul Hoffman wrote:
On Sep 16, 2011, at 9:39 AM, Keith Moore wrote:
On Sep 16, 2011, at 10:52 AM, Cyrus Daboo wrote:
Again I would like to bring up the idea of every RFC having an associated
wiki page(s). The goal here is to provide a way for implementors to
Hi Paul,
I strongly support the idea of wikis interlinked with RFCs. I'd like to offer
two very successful examples, both much more relevant than Wikipedia: the PHP
Manual (see for examplehttp://www.php.net/manual/en/function.date-parse.php),
and the jQuery manual
I don't see these ass Wikis but basically blog style flat display
of user comments, which I often do find useful, especially for the
user (this way) upon user (not always) follow ups.
A Wiki is more where you can change the main content and perhaps even
the context. I don't think that is a
* Cyrus Daboo wrote:
Again I would like to bring up the idea of every RFC having an associated
wiki page(s). The goal here is to provide a way for implementors to add
comments, annotations, clarifications, corrections etc to augment the RFCs.
Whilst such commentary can often be found on IETF
On Sep 16, 2011, at 3:07 PM, hector wrote:
I don't see these ass Wikis but basically blog style flat display of user
comments, which I often do find useful, especially for the user (this way)
upon user (not always) follow ups.
A Wiki is more where you can change the main content and
On Fri 16 Sep 2011 03:22:08 PM EDT, Keith Moore wrote:
On Sep 16, 2011, at 3:07 PM, hector wrote:
I don't see these ass Wikis but basically blog style flat display of user comments, which I
often do find useful, especially for the user (this way) upon user (not always) follow ups.
A Wiki is
On Sep 16, 2011, at 3:26 PM, Andrew Feren wrote:
On Fri 16 Sep 2011 03:22:08 PM EDT, Keith Moore wrote:
On Sep 16, 2011, at 3:07 PM, hector wrote:
I don't see these ass Wikis but basically blog style flat display of
user comments, which I often do find useful, especially for the user (this
Hi Roni,
On Sep 7, 2011, at 4:37 , Roni Even wrote:
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
Thanks!
Please resolve these comments along with any other Last Call comments
My view since we do these user collaboration, group ware online
hosting software for a Living and deal with this evolutionary
ideas that always seem to be better but not always applicable.
Realistically, it has to be single source and as a migration, I think
it should be explored where
+4 and rotfl
Brian
On 2011-09-16 17:17, Hadriel Kaplan wrote:
I thought the counting of votes was finished on this topic but people seem to
keep emailing their support/lack-of, so naturally I will be a good lemming
and do the same.
1) I am in favor of the two-maturity-levels draft and
Keith,
I think we already have the basis for this with the tools already
there when viewing an I-D, RFC via the tools.ietf.org url.
For example, in the last I-D submission I got, the email message did
not have this link (but it should):
The IESG has approved the following document:
- 'TCP sender clarification for Persist Condition.'
(draft-ietf-tcpm-persist-07.txt) as an Informational RFC
This document is the product of the TCP Maintenance and Minor Extensions
Working Group.
The IESG contact persons are Wesley Eddy and David
The IESG has approved the following document:
- 'LISP Internet Groper (LIG)'
(draft-ietf-lisp-lig-06.txt) as an Informational RFC
This document is the product of the Locator/ID Separation Protocol
Working Group.
The IESG contact persons are Jari Arkko and Ralph Droms.
A URL of this Internet
25 matches
Mail list logo
