In many countries service providers are required to track which user behind a
NAT mapped to what IP/port the used. NAT != privacy.
--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF
LEMONADE for mobile email! See http://www.standardstrack.com/ietf/lemonade/
On Jun
I kept my maiden name, too. Another Western option, hyphenation, was not for
us. Who wants to be a Spear-Burger? Unless you want a Pepsi and chips with
that. See http://en.wikipedia.org/wiki/Olympia_Cafe
On Jul 10, 2013, at 9:00 PM, Ida ida_le...@yahoo.com wrote:
Sent from my iPad
On
Riiight. That is why one never has to attend an IETF meeting in person to serve
on NOMCOM, one does not need travel support from one's employer to be on the
IESG, and why people who never come to IETF meetings are the rule and not the
exception with respect to getting documents adopted and
Works for me.
--
Sent from my mobile device. Thanks be to lemonade!
http://www.standardstrack.com/ietf/lemonade/
-Original message-
From: Alexey Melnikov alexey.melni...@isode.com
To: Burger Eric ebur...@cs.georgetown.edu
Cc: Robert Sparks rjspa...@nostrum.com, ietf@ietf.org
Sent:
...@isdg.net wrote:
On 3/20/2013 3:18 PM, Eric Burger wrote:
How much is the concentration of corporate participation in
the IETF a result of market forces, like consolidation and
bankruptcy, as opposed to nefarious forces, like a company
hiring all of the I* leadership? We have mechanisms
Going a bit over-the-top: is there an interaction between sex and sexual
orientation? Can one count as the other?
On Mar 20, 2013, at 8:10 AM, Riccardo Bernardini framefri...@gmail.com wrote:
On Wed, Mar 20, 2013 at 11:53 AM, Margaret Wasserman m...@lilacglade.org
wrote:
Hi Stewart,
How much is the concentration of corporate participation in the IETF a result
of market forces, like consolidation and bankruptcy, as opposed to nefarious
forces, like a company hiring all of the I* leadership? We have mechanisms to
deal with the latter, but there is not much we can do about
I do but don't care. With my IETF hat on, the whole point of the cut-off is to
enforce a physical barrier to ensure we do not ever hear, I posted this draft
yesterday, let's talk about it in a work group. With my legal services hat on,
with the US joining the rest of the world with
Confirmed? Venue?
On Mar 9, 2013, at 11:35 AM, Peter Saint-Andre stpe...@stpeter.im wrote:
I replied, sorry about the delay. It looks like Thursday lunch would
work well.
On 3/5/13 4:47 AM, Randall Gellens wrote:
Hi all,
I created a Doodle poll to see if we can find a time in Orlando to
the work that working groups produce. This happened in the past
as well.
Ciao
Hannes
On Mar 3, 2013, at 6:14 PM, Dave Crocker wrote:
On 3/3/2013 4:56 AM, Eric Burger wrote:
The 50% time commitment is an IESG-imposed requirement. If that is really
the problem, we have had areas with more
,
On Mar 4, 2013, at 13:18, Eric Burger ebur...@standardstrack.com wrote:
I will say it again - the IETF is organized by us. Therefore, this
situation is created by us. We have the power to fix it. We have to want
to fix it. Saying there is nothing we can do because this is the way
There are two other interpretations of this situation, neither of which I think
is true, but we should consider the possibility. The first is the TSV is too
narrow a field to support an area director and as such should be folded in with
another area. The second is if all of the qualified people
The 50% time commitment is an IESG-imposed requirement. If that is really the
problem, we have had areas with more than two ADs.
On Mar 3, 2013, at 7:50 AM, Eggert, Lars l...@netapp.com wrote:
On Mar 3, 2013, at 13:37, Eric Burger ebur...@standardstrack.com wrote:
There are two other
So what if we just said Security Considerations must include what some people
call privacy considerations? If we cannot agree on a concise definition of
security vs. privacy, what is the typical draft author going to do?
--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank
They've got us beat by 10 years. Hope they didn't register the trademark.
On Feb 16, 2013, at 8:17 PM, Ole Jacobsen o...@cisco.com wrote:
Sorry about the late announcement:
http://www.ietfindia.in/
... looks like it ends today, oh well.
:-)
Ole J. Jacobsen
Editor and Publisher,
Abduussalam -
You probably have seen many responses to your message talking about who goes
into the Acknowledgements section. However, I am not sure your original
question was answered.
In short, it is the document editor that puts the acknowledgments section in.
In most cases it will be
As well, if there is a conflict, it will certainly come out in IESG review or
IETF Last Call.
On Feb 8, 2013, at 11:27 PM, Fred Baker (fred) f...@cisco.com wrote:
Speaking for myself, I would say that an internet draft is relevant to work
in a working group if and only if it is covered by
Absolutely nothing. We're screwed. That's why one has to laugh out loud when we
charter a work group to produce a royalty-free version of foo, because there
are encumbered versions of foo out there. Unless the people with the rights to
foo are participating and have offered their rights as part
Way too simple, straightforward, and easy to understand. Can't we play
lawyer-on-the-list and make it a full page again?
--
Sent from my mobile device. Thanks be to lemonade!
http://www.standardstrack.com/ietf/lemonade/
-Original message-
From: IETF Chair ch...@ietf.org
To: IETF
Sounds reasonable to me.
On Oct 29, 2012, at 9:58 AM, John C Klensin wrote:
--On Monday, October 29, 2012 14:06 +0100 Eliot Lear
l...@cisco.com wrote:
Bob, everyone,
As I've mentioned, I'd prefer an alternative to what the
authors have written. Call this the let's program
Echoing John here, he very succinctly explains why setting out clear lines of
what does or does not constitute abandonment invites abuse.
If someone is acting against the interests of the IETF, we have lots of ways of
dealing with it.
If someone falls off the face of the Earth, and repeated
Keeping I-D's around forever is incredibly important form a historical,
technical, and legal perspective. They people understand how we work, think,
and develop protocols (history). They help people what was tried and did or did
not succeed (technology). And they provide a record of the state
+1. The ITU is not evil. It just is not the right place for Internet standards
development. As John points out, there are potential uses of the ITU-T for good.
On Aug 13, 2012, at 10:50 AM, John C Klensin wrote:
--On Monday, August 13, 2012 11:11 +0200 Alessandro Vesely
ves...@tana.it
PLEASE, PLEASE, PLEASE read what the proposal is. The proposal being put forth
is not that the ITU-T wants to write Internet standards. The proposal being put
forth is that ONLY ITU-T standards will be the *legal* standards accepted by
signatory nations.
At best, this would be a repeat of
We seem to be doing a lot of talking about the draft.
On Jul 30, 2012, at 9:33 AM, Scott O Bradner wrote:
2804 does not say not to talk about such things - or that such documents
should
not be published as RFCs - 2804 says that the IETF will not do standards work
in this area
Scott
Do we have guidelines as to what is an organization affiliation?
On Jun 14, 2012, at 5:26 PM, IETF Chair wrote:
Two things have occurred since the message below as sent to the IETF mail
list. First, we got a lawyer in Europe to do some investigation, and the
inclusion of the email address
What we have now *is* sclerotic. See Russ' email above yours.
Can we PLEASE eat our own dog food? Wikipedia managed not to melt down when
they decided NOT TO BUILD WALLS so there were no gates for the barbarians to
crush.
Let's just turn on a wiki. Wiki's have a lot of technical measures to
NSF has a ton of information on this for the U.S. population. I'm too lazy
right now to dig it up, but it is there.
On May 1, 2012, at 4:40 PM, James M. Polk wrote:
There have been some good numbers floated on recent threads, but at least for
me, they aren't enough to gain a complete (or
I would strongly support what Wes is talking about here. I see two (other)
reasons for keeping blue sheets. The first is it is a recognized method of
showing we have an open standards process. The second is to support those who
are trying to defend themselves in patent suits. Frankly, I
I have to admit to laughing out loud when I saw the IESG's announcement. Why?
What is more important: cycling out Experimental RFC's or promoting Proposed
Standards to Internet Standards?
Do I hear chirping in the audience? If we need to focus spare cycles
anywhere, I would offer progressing
I was about to say we are at a point for an RFC 4633 action. Thanks.
On Mar 29, 2012, at 2:26 PM, JORDI PALET MARTINEZ wrote:
Hi Jim,
This is my last message to you as IETF Sergeant-at-arms.
I've asked the Secretariat avoid your posts going thru the email exploder.
Regards,
Jordi
I am responding to Russ' original message, because it is too hard to pick one
of the 52 responses received so far. A quick count is something like 10
thinking this is a good idea with the remainder thinking this idea ranks
somewhere between really bad and evil.
Apps Area people who have
Shall we also set up a formal committee to hear patent filing accusations, a
jury of nomcom-eligible members to pass judgement on the claim, an appeals
board for the party that feels the jury made the wrong decision, a process
document for the IESG to hear the appeal from the appeals board, a
Actually (s), the IETF *does* get credit for rooms sold. We reconcile the
attendee list with hotel guests. Go for it.
On Jan 3, 2012, at 2:48 PM, Michael StJohns wrote:
The pre-pay is pretty annoying. And the if you cancel too late, we'll take
all your money *really* annoys me. So much
Carpenter wrote:
On 2012-01-04 10:03, John C Klensin wrote:
--On Tuesday, January 03, 2012 15:54 -0500 Eric Burger
ebur...@standardstrack.com wrote:
Actually (s), the IETF *does* get credit for rooms sold.
We reconcile the attendee list with hotel guests. Go for it.
In a way
+1,000,000
The argument that an RFC, retrieved from the web, is more accessible than a web
page or wiki, retrieved from the web, does not reflect reality.
The argument that if the questions do not change much from venue to venue needs
to be an RFC, and not a web page or wiki, does not hold
+1
On Dec 1, 2011, at 1:44 PM, Christian Huitema wrote:
Note that the suit does not complain about the 3GPP and ETSI rules. It
alleges instead that the rules were not enforced, and that the leadership of
these organization failed to prevent the alleged anti-competitive behavior of
some
Hacking text display applications when HTML was designed for it already and
most RFC's natively generate HTML (xml2rfc), do we really have a problem to
solve?
On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote:
On 2011-11-28 18:21, Ted Ts'o wrote:
On Mon, Nov 28, 2011 at 06:12:42PM +0100,
In a different venue it was suggested to me that the group (a university-based
research consortium) NOT have a detailed anti-trust policy. The university's
law firm felt that we would be covered so long as we up front reminded the
participants that they were adults and needed to follow the
Naah. We should update the 72-character ASCII limit to 40-characters. Not
only will that work for all of these mobile devices, it will work on a TRS-80,
too.
On Nov 27, 2011, at 3:20 AM, Yaakov Stein wrote:
Dave
I agree that we are thinking as content creators, and that is the problem.
By the time period Steve talks about I was out of diapers and able to toddle on
my own.
Fast forward a few years and I was exposed to LISP (the real one, not the IETF
one) when I did my thesis at the MIT LCS and fell in love with it. To the
point that I regularly argued with various cretins
Any reason not to use attendees...@ietf.org? I do not regularly participate in
the ietf-food list, but I am interested in the results. For example, I am not
a vegetarian, but I like vegetarian food. Likewise, I am on a budget, so
knowing where to buy good food outside the venue interests me.
in ensuring we get safe food as having a
cook that understands the concept. So, personally I would prefer to have
those sorts of discussions on the ietf-food list as I'm sure most attendees
have no interest
whatsoever in a topic like this.
Mary.
On Tue, Nov 1, 2011 at 8:38 AM, Eric Burger
Any reason not to go the Wiki route and just make sure it doesn't get corrupted?
On Oct 29, 2011, at 8:23 PM, John C Klensin wrote:
--On Saturday, October 29, 2011 14:51 -0400 Russ Housley
hous...@vigilsec.com wrote:
I just think we need a volunteer to take over maintenance of
the
It gets worse. To attend every IETF meeting costs about $10,000 per year. If
we say one has to go to the face-to-face meetings, we limit the IETF to
participants from corporations or entities that will sponsor the individual
(pay to play?), IETF participants that have independent funds, or
and Phoenix have huge conference facilities, are easy to go
to, and can get cheap off-season discount. Most of all, it encourages the
participants who want to do work going there.
Make sense?
Ping
On Sun, Oct 23, 2011 at 7:50 AM, Eric Burger ebur...@standardstrack.com
wrote:
It gets worse
+1
On Oct 21, 2011, at 6:58 PM, Melinda Shore wrote:
On 10/20/2011 12:02 PM, Acee Lindem wrote:
I disagree. If the remote participation service is high quality,
it should require the same registration fee structure as on-site
participation.
It seems to me that any fees (and I've got
Simon - Careful what you promse. I am sure someone will try to use the service
through two satelite hops and then complain about the latency. Unfortunately,
we cannot (yet) get of this speed of light thing :-)
On Oct 21, 2011, at 2:54 PM, Simon Pietro Romano wrote:
Dear sm,
just for the
.
/Elwyn
I think you missed Eric's proposal for a one-step Balding is Common
Practice standard.
Ted
Eric Burger wrote:
You all are just bragging you still have hair :-(
On Sep 21, 2011, at 12:55 AM, Melinda Shore wrote:
On 9/20/11 6:26 PM, Ronald Bonica wrote
You all are just bragging you still have hair :-(
On Sep 21, 2011, at 12:55 AM, Melinda Shore wrote:
On 9/20/11 6:26 PM, Ronald Bonica wrote:
This reminds me that it has been a while since we took the last IETF grey
beard photo. A few more of us have gone grey since then.
Maybe we should
So should we move to a one-step process?
On Sep 9, 2011, at 9:33 PM, Thomas Narten wrote:
Advancing a spec is done for marketing, political, process and other
reasons. E.g., to give a spec more legitimacy. Or to more clear
replace an older one. Nothing wrong with that.
Why? No one has cared about the annual review from 2026. No one has time to
do the bookkeeping and spend the effort to evaluate stuck documents.
If there is an RFC that is harmful, then one can always ask to have it moved to
Historic.
On Sep 4, 2011, at 10:23 AM, todd glassey wrote:
There
Would having professional editors make a difference here?
On Aug 31, 2011, at 2:31 AM, John C Klensin wrote:
--On Tuesday, August 30, 2011 14:51 -0700 Fred Baker
f...@cisco.com wrote:
What's also not fair game is to raise the bar - to expect
the document at DS to meet more stringent
the same approach used for all the protocols we support. Start with the
basics and then add on as necessary.
Eric Burger wrote:
What is the difference in this case between SHOULD or MAY?
On Aug 30, 2011, at 2:49 PM, Adam Roach wrote:
On 8/29/11 9:44 PM, Eric Burger wrote:
Yes, and...
I
the implementation has a good reason, failing to
re-subscribe will result in behavior that the user perceives as broken. I
don't think that's really MAY territory.
/a
On 8/30/11 1:57 PM, Eric Burger wrote:
What is the difference in this case between SHOULD or MAY?
On Aug 30, 2011
This highlights an interesting issue as an RFC goes from PS to IS. I would
offer that most SHOULDs in a document will, if there are real implementations
out there, migrate to MUST or MUST NOT.
On Aug 31, 2011, at 9:57 AM, hector wrote:
I think you are speaking of long term operations where
+1, too.
This goes along with my strong desire to eliminate passive voice, unless the
goal is to have the actor be obfuscated (as an example).
On Aug 30, 2011, at 5:29 AM, Mykyta Yevstifeyev wrote:
2) I strongly believe that authors should be encouraged to enumerate the
potential subjects
On Aug 30, 2011, at 9:24 AM, Marshall Eubanks wrote:
Dear Eric;
I support adding the SHOULD ... UNLESS formalism (although maybe it should be
MUST... UNLESS). It would be useful as there will be times where the UNLESS
can be specified and has been given due consideration at the time of
that followed
the hour-glass and end-to-end principles, and then building your complex
protocols out of them?
On Aug 29, 2011, at 11:11 PM, Keith Moore wrote:
On Aug 29, 2011, at 10:44 PM, Eric Burger wrote:
I would offer that ANY construction of SHOULD without an UNLESS is a MAY
This sentiment mostly makes sense.
If an endpoint expects SHOULD/MAY items implemented as MUSTs on the remote end,
then one should slap the endpoint developer silly. Read the RFC! If it says
SHOULD/MAY, then your implementation MUST be able to handle the feature present
*and* absent.
Note
on the capabilities
of the far end or handle the varying data elements or protocol states that will
or will not happen.
On Aug 30, 2011, at 9:58 AM, Keith Moore wrote:
On Aug 30, 2011, at 9:56 AM, Eric Burger wrote:
Every SHOULD/MAY results in at least one if statement, to test the
presence
I think you have hit the root cause on the head.
I would also offer that by removing the crutch, or raising the bar to using the
crutch, will help alleviate the root cause.
On Aug 30, 2011, at 11:44 AM, Keith Moore wrote:
e.g. For the specific case of optional features that must be
Can you give an example of where a dangling SHOULD makes sense? Most often I
see something like:
SHOULD implement security
meaning
SHOULD implement security, unless you do not feel like it or are in an
authoritarian regime that bans security
On Aug 30, 2011, at 12:11 PM, Keith
for making two proprietary protocols look like a
single, Internet protocol.
On Aug 30, 2011, at 1:50 PM, Keith Moore wrote:
On Aug 30, 2011, at 12:46 PM, Eric Burger wrote:
Can you give an example of where a dangling SHOULD makes sense? Most often
I see something like:
SHOULD implement
We violently agree. However, the most cited reason I get for watering down
security requirements are what I mentioned below.
On Aug 30, 2011, at 2:19 PM, Keith Moore wrote:
On Aug 30, 2011, at 2:02 PM, Eric Burger wrote:
Note the language
MUST implement, SHOULD use is a common
What is the difference in this case between SHOULD or MAY?
On Aug 30, 2011, at 2:49 PM, Adam Roach wrote:
On 8/29/11 9:44 PM, Eric Burger wrote:
Yes, and...
I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X
*are* what people usually mean when they say SHOULD
I would assume in the text of the document. This paragraph is simply an
enumeration of Burger's Axiom:
For every SHOULD, there must be an UNLESS, otherwise the SHOULD is a
MAY.
On Aug 29, 2011, at 5:50 PM, Thomas Narten wrote:
It would help me if you explained the diffs and the
Please make my English language sensibilities and satisfy Burger's Second Law
of standards documents at the same time, forbidding passive voice. Can we have
the following as the boilerplate? Thanks.
Either:
In this document, [RFC] describes the following conformance terms: MUST,
...
an UNLESS is a MAY.
Unless of course one considers us the Protocol Nanny's(tm) - if do not do a
SHOULD, we will send you to bed without your treacle! I.e., there IS NO
DISTINCTION BETWEEN A BARE SHOULD AND A MAY.
On Aug 29, 2011, at 9:47 PM, ned+i...@mauve.mrochek.com wrote:
Hi -
From: Eric Burger
+100
On Aug 26, 2011, at 6:50 AM, Scott Schmit wrote:
On Fri, Aug 26, 2011 at 09:18:41AM +0200, t.petch wrote:
Why does the IETF website consider it necessary to use TLS to access
the mailing list archives, when they all appeared without it, or any
other security, in the first place?
TLS
I disagree with the fundamental premise of this concept, that it is a PROBLEM
that the Internet is not a network. Um, last I looked, the Internet is an
interconnection of networks. Not a network in that sense.
Edge devices can today, in the scenario you portray, pick the best network to
Two thoughts.
On the one hand, Ned is absolutely correct: the thing we want to make
absolutely sure of is the integrity of the object. The way of doing that is
making sure the object itself can prove its integrity. In the messaging world,
we do this with S/MIME. The use of TLS for SMTP or
IAOC members are like all other IETF members. We pay for our hotel rooms. That
means when I have a full-time job that wants me at the IETF, I stay at the
convention hotel. When I don't have a full-time sponsor, like now, I stayed at:
o A charming bed breakfast 500m from the Maastricht
I like Thailand, and Bangkok is a StarAlliance hub. I am assuming the political
troubles are settled now, and probably will be for sure in 2 years.
On Aug 5, 2011, at 3:46 AM, Glen Zorn wrote:
I note that there is an opening on the IETF meeting calendar for an
Asian meeting in 2013. Here is
I think John has the issue nailed. I think it would be easy to try to
eliminate the plenaries and then end up with a full Friday, anyway. I would
offer that it would be very difficult, however, to take a compressed Friday and
later add an afternoon to it. Thus, I am much more in favor of a
I don't think I have seen a proposal like this before. I really like it, as
there are a bunch of post-IETF stuff, some of which starts in the afternoon and
thus conflicts with the IETF. This fixes that problem, enables us to have the
same amount of meeting time, and potentially lets people get
On Jul 31, 2011, at 11:55 AM, RJ Atkinson wrote:
On 31st July 2011, Brian Carpenter wrote, in part:
[snip]
It might cause a change, simply because the effort of making the single
move PS-IS will get you to the end state, whereas previously you had
to make two efforts, PS-DS-STD. But only
And the real question is, are we moving forward? I think that we are not moving
as far as we originally wanted. However, I offer we are moving a baby step
forward, and as such is worthwhile doing.
On Jul 28, 2011, at 9:19 AM, Robert Sparks wrote:
Scott -
Didn't RFC 5657 address your point
The patent would have expired by now?
On Jul 28, 2011, at 10:47 AM, Samir Srivastava wrote:
Hi, Thx for your comments. Private walled garden creates lots of
interoperabilty issues. In the long term with deployments in the
field, even after the expiry of patents we end up for a workable
+$1.00
Have we ever had a BOF that looked under-attended? Not me: always standing room
only!
Big rooms = good BOF.
On Jul 28, 2011, at 4:37 PM, Peter Saint-Andre wrote:
On 7/28/11 4:06 PM, Murray S. Kucherawy wrote:
When we ask for a BoF room, we need to give an indication of estimated
Just for the record: we want big rooms!
On Jul 28, 2011, at 10:01 PM, Scott Brim wrote:
And do you really only want people in the room who already know the
issues and have decided to be for or against it? If you already have
so many of them, you don't need a BOF at all, just take a hum and
Interestingly, when I look at the references from IEEE Xplore when I access
Xplore from Georgetown, instead of the built-in Xplore reference, I get a GU
search option, which does pop up the IETF copy of the RFC.
In any event, I happen to know a few people at IEEE. They are looking in to
it, it
time = money
On May 10, 2011, at 5:22 PM, Masataka Ohta wrote:
Bob Braden wrote:
I wonder how many other IEEE standards contain similar
RFC-for-pay references..
It's common (much more than 50% for academic ones, IMHO) that
sold articles are freely available on-line.
For example, a
Agreeing with John here re: it's just a bug.
IEEE Xplore regularly does deals (read: free) to add publishers to the
digital library. It is part of the network effect from their perspective: if
you are more likely to get a hit using their service, you are more likely to
use the service.
We
And the Proxy - Browser interaction is 100% out of IETF scope. For that
matter, the IETF should be pointing out how dangerous and evil such a proposal
is, as it means the end of consumer choice and a competitive marketplace for
clients.
On Mar 30, 2011, at 9:14 AM, Hannes Tschofenig wrote:
I think this encapsulates what Dave is trying to get across:
Yes, it is MUCH easier for a server developer to stuff in a little more
JavaScript.
Now, you have a 100% proprietary system, with no hope or desire for
interoperability, that gets deployed much faster than someone taking their
Would we not be better off just asking (mandating?) at least one open source
implementation? That effort would produce a de facto API.
On Mar 29, 2011, at 11:17 AM, Sam Hartman wrote:
Dave == Dave CROCKER d...@dcrocker.net writes:
Dave On 3/29/2011 10:13 AM, Sam Hartman wrote:
At
Got it in 1.
On Mar 29, 2011, at 1:40 PM, Dave CROCKER wrote:
On 3/29/2011 1:31 PM, Hannes Tschofenig wrote:
Correct.
The interoperability need shifts away from the client-to-server side (for
example, to the server-to-server side;
No, that's wrong and I believe it is not what Eric
Agreed.
On Mar 24, 2011, at 12:13 PM, Bob Hinden wrote:
On Mar 24, 2011, at 5:01 PM, Dave CROCKER wrote:
On 3/24/2011 4:49 PM, Mykyta Yevstifeyev wrote:
Another proposal as for your document. So, it fails to mention what are
the procedures for reclassification of Standards Track RFCs
Speaking personally, with none of my official hats on, I would offer the IETF
is *only* an SDO.
There are no sponsoring organizations, because the IETF is a collection of
individuals. No sponsor needed. For that matter, some individuals consider
some sponsors toxic, so sometimes having a
[Soapbox warning]
I love it! Finally a use for Informational RFC's that I get: Let's turn
Wikipedia pages into RFC's!
[NOT]
On Dec 14, 2010, at 10:42 AM, Marshall Eubanks wrote:
On Dec 14, 2010, at 7:40 AM, Noel Chiappa wrote:
From: Simon Josefsson si...@josefsson.org
Wikipedia has ..
+1
On Nov 13, 2010, at 7:01 AM, John C Klensin wrote:
Russ,
I'd like to make a suggestion that I hope you will find helpful.
We've now got your/the IESG's two-step proposal, Dave's
alternative, discussions about going directly to single step, an
orthogonal proposal about STD numbers (or
And for the most part, we have had decent success with self certification in
SIP and VPIM, as two examples.
On Nov 12, 2010, at 12:25 AM, Spencer Dawkins wrote:
I think it would be sufficient to say something like: The following
implementations represent a significant Internet deployment and
As far as I know, anyone with an email and a credit card can come to an IETF
meeting.
Anyone without an email and an ability to pay the registration fee cannot come
physically to an IETF meeting, but can still participate over the Internet.
It is an incredible stretch to say checking badges at
I would offer we do the venture capital lightning round thing.
Schedule a *single* 2.5 hour slot for *all* BOFs. Each BOF proposer gets 5
minutes to make their pitch and 10 minutes of discussion. I would bet that 15
minutes of FOCUSED attention would give the IAB and IESG enough input as to
+1
On Oct 26, 2010, at 3:04 PM, Fred Baker wrote:
On Oct 26, 2010, at 10:19 AM, Phillip Hallam-Baker wrote:
Action
We should adopt Russ's proposal: Axe the DRAFT status and automatically
promote all DRAFT status documents to STANDARD status. This can be done
formally by changing
Look at RAI: I would be grateful if some proposals had running code that ran
once.
On Oct 27, 2010, at 7:16 PM, Peter Saint-Andre wrote:
As I understand it, running code means that the technology has been
deployed across the full breadth of the Internet, in services large and
small, by
Actually, my heartache with Russ' proposal is the automatic If it's Draft,
it's now Standard.
I would be quite happy with Proposed and Internet Standard, with NO
grandfathering.
On Oct 26, 2010, at 5:57 PM, Ofer Inbar wrote:
On Oct 26, 2010, at 2:39 PM, Dave CROCKER wrote:
I'm a fan of
The known problem is it takes well over four years to get anything published.
I am experiencing in one never-ending saga the logical conclusion of the logic:
since Proposed Standard is the new Draft Standard, and since the IESG has to
make sure any proposal is beyond bullet-proof, the industry
Ever since Proposed Standard became Draft Standard for all practical purposes,
might as well make it official.
On Oct 25, 2010, at 8:35 PM, Brian E Carpenter wrote:
On 2010-10-26 13:22, Barry Leiba wrote:
I'd like to hear from the community about pushing forward with this
proposal or
1 - 100 of 164 matches
Mail list logo
