this draft to a high
consensus of the IETF community standard.
I just wish that were not so...
--
John Leslie j...@jlc.net
picky!
--
John Leslie j...@jlc.net
don't have that obligation!
--
John Leslie j...@jlc.net
such a thing possible). We have only to bring
them to the point where they agree they can live with the result.
--
John Leslie j...@jlc.net
to allocate staff for setup.
But of course these checkoffs happen long before the WGC knows of
individuals desiring to participate remotely. :^(
Conceivably what we need is an automated tool to receive offers
to (partially) subsidize the cost of a tool for a particular session.
--
John Leslie j
was merely the one who _did_ so. Others did their best
to guess at the slide numbers.
At least one-third of the sessions I listened to failed to provide
all we are told to expect in the way of jabber support. :^(
OTOH, we _do_ get what we pay for; so I don't mean to complain.
--
John Leslie
accept the idea that this relaxing has failed, yet still
observe liberal in what you accept as trumping it. I truly wish the
folks in the two or more camp would do so!
--
John Leslie j...@jlc.net
belongs under.
The lists I subscribe to have as work items drafts where nothing
happens until IETF-week deadlines (and sometimes not even then!).
It seems _very_ likely that some automated tools to point out the
inactivity would help...
--
John Leslie j...@jlc.net
that won't invite
appeals. :^(
In a properly designed early-review situation, the issue would have
surfaced early; and it's possible it could have been resolved before
too many folks' positions had hardened...
--
John Leslie j...@jlc.net
about such changes. ;^)
--
John Leslie j...@jlc.net
referring to the Narrative Minutes. Hopefully that history
will be preserved forever.
--
John Leslie j...@jlc.net
Dave Crocker d...@dcrocker.net wrote:
...
On 3/13/2013 9:07 PM, John Leslie wrote:
I see several problems with this text:
1) It wanders from the current clear distinction between desired
expertise, determined by the body where the nominee will serve,
and IETF community's consensus
early in the process, and IMHO, should comment on or accept these
changes.
these requirements shall be made public after nominees are
confirmed.
This seems too vague. I'd suggest we consider listing actual
requirements in a formal report posted to ietf-announce.
(YMMV...)
--
John
up this document any longer
to add clear advice -- I believe that would only add years to the delay.
The document deserves to be published, but with Informational status so
folks don't spend their time trying to interpret its advice.
--
John Leslie j...@jlc.net
members can
offer more information here.
There is no easy fix. Well, maybe the WGs could stop wanting to
publish so many documents...
;^)
--
John Leslie j...@jlc.net
hardest to satisfy.
--
John Leslie j...@jlc.net
,
feel free to ask for clarification. Just please read the IESG statement
I linked to first.)
--
John Leslie j...@jlc.net
] to the Proposed Standard state when it is considered to be useful and
] necessary (and timely) even with known technical omissions.
I would feel less nervous about this experiment were it to include
a specific IESG action to waive the no known technical omissions
clause.
--
John Leslie j
of Standards-Development Organizations that start from code.
We don't need to become one of them.
--
John Leslie j...@jlc.net
!.
--
John Leslie j...@jlc.net
to change anything; but the Document Editors I
consider good don't wait for a WGC declaration.)
My point, essentially, is that some push-back is good, but it won't
solve the problem: even WG LastCall is often too late to fix this.
--
John Leslie j...@jlc.net
to it).
--
John Leslie j...@jlc.net
Stephan Wenger st...@stewe.org wrote:
...
Clearer?
Much clearer. Thank you!
On 11.7.2012 09:57 , John Leslie j...@jlc.net wrote:
Stephan Wenger st...@stewe.org wrote:
...
It is, in most cases, not to the advantage of a rightholder to disclose
a patent unless he is undeniably obligated
, I'm willing to let this fester longer if it is indeed
the consensus of the IETF to let it fester. But I find Barry's
proposal entirely reasonable. (And I have to stop here, to be set up
for scribing today's IESG telechat.)
--
John Leslie j...@jlc.net
the exact status of an individual, and I no longer
find it scary.
--
John Leslie j...@jlc.net
to cookies to keep my
energy level up; et cetera.
I suggest active participation in VMEET:
https://www.ietf.org/mailman/listinfo/vmeet
for all the experienced folks who find themselves unable to attend
IETF weeks in person.
--
John Leslie j...@jlc.net
session resetting), it would still lose the vital as-path info
contained in the AS4_PATH which can otherwise be recovered by
repairing the attribute. That is why the approach specified in the
rfc4893bis is adopted, and it has been implemented widely.
-- Enke
--
John Leslie j...@jlc.net
.
(Sorry, Alexey...)
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
shows it to be much what I would expect from CFR
(not worth my time to read carefully), and not attempting to change
actual IETF process, though perhaps I missed something...
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https
traffic to these IPs, but at least
the outgoing ICMP errors wouldn't be blocked.
especially considering people are (re-)using 1918 space for that now.
Anyway, if that did work, it should kill a bunch of these problems.
It certainly seems like an improvement...
--
John Leslie j...@jlc.net
/4.
It's not obvious to me from reading draft-weil why this wouldn't work;
and I believe that allocations from 240/4 are quite appropriate, given
the imminent exaustion of ordinary IPv4 space.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf
and point of connection when negotiation fails.
This, of course, creates an opportunity to educate FCC folks on the
actual technical issues of voice interchange at IP level...
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https
t.petch daedu...@btconnect.com wrote:
From: John Leslie j...@jlc.net
t.petch daedu...@btconnect.com wrote:
From: John Leslie j...@jlc.net
But _why_ is that something holding up a working group?
Because they are the one holding the token, usually the editorship of
the I-D, and everyone else
t.petch daedu...@btconnect.com wrote:
From: John Leslie j...@jlc.net
--On Sunday, October 23, 2011 07:05 -0700 Murray S. Kucherawy
m...@cloudmark.com wrote:
... I also am very familiar with the fact that getting work done
on lists can be a real challenge: People get sidetracked and can
is to put more effort into formal scheduling of
Interim meetings (probably mostly virtual Interims). Currently
these are treated as exceptional events needing AD approval:
while I agree AD-approval probably belongs there, I'd wish we
could treat them as normal events.
--
John Leslie j...@jlc.net
, though
it's quite achievable within one continent. I expect IETF folks could
learn to work with 250 milliseconds.
But terms like real-time and perfect don't help. Can we avoid
them?
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https
Mikael Abrahamsson swm...@swm.pp.se wrote:
On Mon, 24 Oct 2011, John Leslie wrote:
150 milliseconds is a real challenge to accomplish worldwide, though
it's quite achievable within one continent. I expect IETF folks could
learn to work with 250 milliseconds.
Are these numbers RTT or one
want to do it and let the IESG decide
whether to use it as input to deciding about advancing levels.
Many distinctions; no real difference...
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to address that expectation...)
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
members to figure out what's expected of them when the question
is advancement of maturity level.)
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
at airports on Friday,
and could certainly wear a headphone/mike and watch our laptop screens.
Meetecho seemed ready to manage that sort of thing. :^)
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Keith Moore mo...@network-heretics.com wrote:
On Aug 1, 2011, at 9:39 AM, John Leslie wrote:
For one, I suggest we take remote-participation _seriously_ for the
Friday meetings. Many of us are waiting-for-Godot at airports on Friday,
and could certainly wear a headphone/mike and watch
the next
adjust to current practice I-D comes up.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
on that...
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
die.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Hey, folks!
mail.ietf.org[64.170.98.30] got listed on SORBS for spamming.
It's not that hard to get off... Fix it!
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Paul Hoffman paul.hoff...@vpnc.org wrote:
On Jul 1, 2011, at 4:48 AM, John Leslie wrote:
mail.ietf.org[64.170.98.30] got listed on SORBS for spamming.
It's not that hard to get off... Fix it!
It's also not that hard not to use poorly-managed blacklists. Just sayin'
I'm _really_
David Morris d...@xpasc.com wrote:
On Jul 1, 2011, at 4:48 AM, John Leslie wrote:
mail.ietf.org[64.170.98.30] got listed on SORBS for spamming.
It's not that hard to get off... Fix it!
...
And from my own experience, I know it can be impossible to get removed
from SORBS if you
didn't claim any sort of consensus;
and I'd be happier if we simply avoided such claims on Informational
track RFCs.)
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
, Keith, you must first convince us that an action like this
_does_ require IETF-wide consensus.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Paul Hoffman paul.hoff...@vpnc.org wrote:
On Jun 24, 2011, at 5:55 AM, John Leslie wrote:
First, note the Subject line: an IETF Last-Call on a Working Group
document _isn't_ asking for IETF Consensus: it's simply a last-call for
comments on an action proposed by a Working Group.
I'm quite
'
expectations of PS RFCs.)
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Dave Cridland d...@cridland.net wrote:
On Fri May 6 11:44:48 2011, John Leslie wrote:
If we want to change this, we need to start putting
warning-labels in the _individual_ RFCs that don't meet
a ready for widespread deployment criterion.
I do not believe this will work, actually
that has
found its way into requirements for Proposed Standard; and to work
out what sort of warning labels we could use instead.
Otherwise, I see escalating mission-creep, regardless of the number
of maturity levels.
--
John Leslie j...@jlc.net
me as a really-strange transition mechanism.
Color me thoroghly confused.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Livingood, Jason jason_living...@cable.comcast.com wrote:
To: John Leslie j...@jlc.net...
As I read it, this says that certain DNS servers will be configured
to _not_ return records to queries by default.
This strikes me as a really-strange transition mechanism.
Depends
right.
Adding other individuals with voting status seems reasonable, but
not-exactly-right.
Perhaps the most important change would be simply not counting them
for purposes of quorum...
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
levels there should be -- though I'd
be happy to work within the old consensus for three. What needs work
(assuming we aim for more than one) is how to get there from here!
I have some ideas; but the time just doesn't seem ripe to discuss them.
--
John Leslie j...@jlc.net
:
- cycles being expended on cross-area reviews;
- recommending IPsec whether or not it could be deployed for the use;
- the inherent complexity of key infrastructure?
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
the
name or the RFC 2026 definition.
As to what follows Ted's Step Two, I think that needs work; but the
idea of formalizing something which doesn't require another trip through
the IESG sounds promising.
--
John Leslie j...@jlc.net
___
Ietf mailing list
.
So be it -- I won't object to that...
But I _do_ commend Ted's outline of the base issue; and I sincerely
hope that whatever becomes of Russ's proposal, we save some attention
for the things Ted has outlined -- because those things are the ones
we need to actually fix.
--
John Leslie j
time-in-grade
requirements? Perhaps the IESG should be trusted to publish an RFC
as Draft Standard _without_ going through the whole process twice?
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
the number of levels isn't
something we should do lightly.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
it in cases where the actual policy wouldn't
apply. That is IMHO a measurable part of why the path to PS takes so
long. :^(
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
(Myself, I find it much easier to follow in-line comments, so I take
the effort to post that way. I'll be happy to pay attention to private
emails cricicizing me for this, but I _will_not_ participate in a
public flame-war about how dreadful this practice is.)
--
John Leslie j...@jlc.net
about which there's not a whole lot of room for disagreement.
So, to recap, I give Ted Hardie high marks for identifying the
problem, but John Klensin higher marks for proposing a way forward.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf
proposed in the draft IETF leadership document.
Which, of course, is exactly where we are today...
The devil is in the details here. How can we impose additional
experience requirements on some NomCom members without implying that
we want their opinions to be considered better?
--
John
, that the current IESG has any such
interest in keeping tight control of advancement.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
that, please either file an appeal,
or stop beating this pining for the fjords horse.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
on this matter.
Your opinion is noted. You have our permission to say, I told you so!
when/if we're proven wrong.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to change proposed status as
a result of LastCall comments. It might be more helpful to simply post
(polite) LastCall comments of your own about why Proposed Standard
would be more appropriate than Informational.
--
John Leslie j...@jlc.net
___
Ietf mailing
.
For one simple example, I know of nothing preventing citations of
self-published guides as Informative References in RFCs.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
in the context of RFC 3852.
So, I will comment on that: IMHO, any such downrefs are appropriate.
The issue in advancing to Draft Standard is multiple implementations.
We _have_ multiple implementations based on precisely those references.
I cannot imagine more appropriate references.
--
John Leslie
://www.ietf.org/IESG/iesg-narrative.shtml
(What an IETFnn attendee sees is much less than 10% of the job.)
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
the consensus of 5378.
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
of CNAME chains).
Does Tony have an alternative to suggest?
--
John Leslie j...@jlc.net
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
been punting entirely too much to routing for decades.
There are other perfectly valid ways to divide the problem. And IMHO,
any way that makes the realm of routing reside in a stable space
is a _better_ paradigm.
--
John Leslie j...@jlc.net
___
Ietf
John Day jeanj...@comcast.net wrote:
At 11:34 -0500 2008/12/29, John Leslie wrote:
I accept reliability and flow control as the transport layer's
primary function, but denying it access to multiple interfaces cripples
its ability to perform those functions in a mobility environment
] is considered in such a way that it minimises the fact there is no
] such thing as trusted computing.
How much of this is it reasonable to ask the DNS to do?
--
John Leslie [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
to consider chartering
new WG if there seems to be consensus on a charter.
What about it, folks?
--
John Leslie [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
quickly outdated
strikes me as an impossible task; and the right approach would be to
design services that could avoid the many pitfalls we are seeing with
the current usage of DNSBLs.
--
John Leslie [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
to resolve.
I totally agree!
--
John Leslie [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
from the mumbled sylables
before speakers actually get close enough to the mike.)
--
John Leslie [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
to the cutoff
happening a lot more frequently.
(Fine-tuning the length of the blackout period, OTOH, is probably
appropriate without re-opening the question of whether there should
be a cutoff at all. I'd welcome a proposal in that direction from
the IESG.)
--
John Leslie [EMAIL PROTECTED
.
Should the Area Director send this back to the Working Group?
Speak now (well, before Thursday morning) if you think so -- otherwise
the IESG is likely to approve this document which so blatantly ignores
the expressed wishes of this mailing-list.
;^)
--
John Leslie [EMAIL PROTECTED
, to be at an end.
I quite agree. (But I don't think 2821-bis can go there.)
... I'd recommend the BCP path I comments on in an earlier note.
To tell truth, I dislike writing I-Ds. But I'd be willing to
help in the writing of such a document. Any other volunteers?
--
John Leslie [EMAIL PROTECTED
of the RFC2026 diffs that Brian put
in his Internet Draft might be put in IONs, to the extent they merely
document current practice which already reflects IESG consensus.
(Running those through a WG process seems pointless...)
--
John Leslie [EMAIL PROTECTED
they get called
IONs, wikis, or just web pages.
Sounds like we agree a lot more than we disagree...
--
John Leslie [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
). The
use under RFC4646 has caused known problems.
This would seem to justify deprecation, IMHO.
YMMV, of course...
--
John Leslie [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
at the audio
record could decipher it.
My prejudice is that I don't want to spend a lot of time listening
to folks I can't figure out how to contact by email. YMMV. I don't
know what the mythical IETF consensus might be about this...
--
John Leslie [EMAIL PROTECTED
...
--
John Leslie [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
, but not as a list of individual decisions (or open
issues.)
This sounds as if it would be extremely helpful to folks sitting in
on WG meetings during IETF Weeks...
Can Dave point out any examples?
--
John Leslie [EMAIL PROTECTED]
___
Ietf mailing list
Ietf
:
]
] The IETF as a whole does not have consensus on the technical approach
] or document.
Keith Moore moore@cs.utk.edu wrote:
[John Leslie wrote]
It's high time we gave up any pretense that the IETF-as-a-whole
should come to consensus about the technical details of RFCs before
they're published
pretense that the IETF-as-a-whole
should come to consensus about the technical details of RFCs before
they're published.
--
John Leslie [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
to
simply disengage. It's hard to imaagine _any_ case where it will
lead to a better document.
Granted, it may lead to dropping a document which would actually
have caused problems. But wouldn't it have been better for all
involved to actually _state_ what those problems look to be?
--
John
David Kessens [EMAIL PROTECTED] wrote:
On Sat, Oct 21, 2006 at 07:14:41PM -0400, John Leslie wrote:
Ned Freed [EMAIL PROTECTED] wrote:
[David's DICUSS stated:]
It is haphazardous at best to rescind one control mechanism and to
replace it with one that leaves non working group mail management
David Kessens [EMAIL PROTECTED] wrote:
On Sat, Oct 21, 2006 at 07:14:41PM -0400, John Leslie wrote:
If we ever do have ADs interested in restoring the rights, I quite
specifically do _not_ want to repeat the denial-of-service attack on
this list.
What denial-of service attack are you
on ietf@ietf.org
We need experience with such ideas before we can claim to have a
solution for non-WG lists. We should not hold up Brian's proposal in
search of a perfection which may be beyond our reach.
--
John Leslie [EMAIL PROTECTED]
___
Ietf mailing
that the commitment by a broad selection of IETF folks to tackle the issue
is lacking.
I most strongly urge Eliot to move the discussion of this draft to
another mailing-list.
IN the absence of Eliot specifying otherwise, I suggest the NEWTRK list:
http://darkwing.uoregon.edu/~llynch/newtrk.html
--
John
1 - 100 of 150 matches
Mail list logo
