case, we have an even deeper problem than misunderstandings
>> of rough consensus.
>
> Right, I think what Ted is describing is a BCP, not an Informational RFC.
Oh my! I just saw the IESG agenda, and this _is_ proposed for BCP.
I retract anything I said which might criticize Ted and/or Dave Crocker
for being too picky!
--
John Leslie
Group output, it escapes me at the moment. :^(
Thus perhaps Ted and Dave are right to hold this draft to a high
"consensus of the IETF community" standard.
I just wish that were not so...
--
John Leslie
I'm _very_ glad I don't have that obligation!
--
John Leslie
Dave's opinion. (I happen to not share it.)
Consensus process _also_ works better if we respect Dave's
opinion here.
I suggest we all remember that we don't have to change others'
opinions here (were such a thing possible). We have only to bring
them to the point where they agree they can live with the result.
--
John Leslie
to subsidize the tool for that session.
Cisco seems to automatically approve using the fully-automated tool,
while meetecho seems to need 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
r.
... and Janet 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
laxed a previous
"two or more" requirement, but there are folks who don't want to
accept that relaxing.
One can 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
onfusing than helpful: you're never quite sure which
issue number something 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
. The IESG will have to balance WG rough-consensus against
architectural principles; and I see no resolution 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
umor the IESG!"
(Even so, I personally prefer to hear about such changes. ;^)
--
John Leslie
have been scribing.
I really don't know how to change the perception -- but I strongly
recommend referring to the Narrative Minutes. Hopefully that history
will be preserved "forever".
--
John Leslie
Dave Crocker 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,
&
firming body should learn
of any relaxing (least of all changes!) to the "desired expertise"
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 .
(YMMV...)
--
John Leslie
In no sense do I believe it worth holding 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
each other to put
significant concerns in RFC Editor notes instead of continuing to
block documents.)
> If there is a controversy, the time for that involvement dwarfs the
> time needed for the initial review.
I don't believe that's entirely true. Perhaps some IESG 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
ETF week; and I do hope that will be helpful. But I suggest on-list
discussion before then will be even more helpful -- especially if we
can draw in some NomCom chairs to explain which parts of this have been
hardest to satisfy.
--
John Leslie
raised by an
individual responding to the LastCall. When this happens, it is a
Good Thing (TM).
(I think this covers your particular questions; but if you disagree,
feel free to ask for clarification. Just please read the IESG statement
I linked to first.)
--
John Leslie
l be true under this proposed experiment?
] A Proposed Standard should have no known technical omissions with
] respect to the requirements placed upon it. However, the IESG may
] waive this requirement in order to allow a specification to advance
] to the Proposed Standard state when it is cons
out some details).
I remain unconvinced, however, that fast-tracking the cases
that start from running code is a good use of WG efforts. Such
cases seem better suited to Independent Submissions from a
design team (which would _greatly_ speed the process). When
a WG is formed, IMHO, they should be encouraged to look at the
problem from some quite different angles, in search of a way
to "Simplify!".
--
John Leslie
e it would be desirable were it possible. Code
needs to deal with complex cases that, for the most part, don't
need to be standardized in the first place. But code which
doesn't deal with these is useless in the marketplace.
IMHO, we designed a separate "Proposed Standard" step to get
a specification published quickly without delving into the many
questions that arise when writing actual code. There are plenty
of Standards-Development Organizations that start from "code".
We don't need to become one of them.
--
John Leslie
s needed. Too often, the
Document Editor is the author of the pre-adoption draft, and lacks any
drive to make significant changes. (This is not an abuse if the WGC
never calls consensus 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
Stephan Wenger wrote:
>...
>
> Clearer?
Much clearer. Thank you!
> On 11.7.2012 09:57 , "John Leslie" wrote:
>>Stephan Wenger wrote:
>>>...
>>> It is, in most cases, not to the advantage of a rightholder to disclose
>>> a patent unle
act to it).
--
John Leslie
going forward, they can be incorporated
before it's adopted.
For myself, 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
ubject of recall to resign.
In other organizations, I have lived through longish periods of
uncertainty about the exact status of an individual, and I no longer
find it scary.
--
John Leslie
participating" remotely from my
office. Jabber can be an effective interaction tool; I can keep
multiple screens active; I'm not limited 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
ced in AS4_PATH.)
> Hi, Claudio:
>
> Not sure if you are aware of the large scale outage that occurred a few
> years ago from the leak of the confed related segments by one
> implementation. At the time quite a few implementations were resetting
> the sessions when receiving such updates.
>
> While discarding the whole AS4_PATH would be simpler and less disruptive
> (than 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
rification remedies that omission.
I don't really have an opinion on how the IESG should manage
IETF-stream experiments.
Suggestions on how to manage IESG-stream experiments would be helpful
here. I would hope that opinions on how IRTF-stream experiments should
be managed will find a different thread, ideally in a different list.
--
John Leslie
t, but IMHO should stop
at the first weak link.
(Sorry, Alexey...)
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
bind and perl-script registrar interfaces.
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
g (55 pages).
Brief skimming 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
___
Ietf mailing list
I
#x27;t receive 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 certainl
would strongly favor allocation of a /10 from 240/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
" succeed.
Speaking only for myself, I don't read it to impose anything except
on regulated "carriers", and they're opening up themselves to forcing
a particular mechanism and point of connection when negotiation fails.
This, of course, creates an opportunity to educate FCC fol
t.petch wrote:
> From: "John Leslie"
>> t.petch wrote:
>>> From: "John Leslie"
>>>
>>>> But _why_ is that something "holding up a working group"?
>>>
>>> Because they are the one holding the token, usually
t.petch wrote:
> From: "John Leslie"
>>> --On Sunday, October 23, 2011 07:05 -0700 "Murray S. Kucherawy"
>>> wrote:
>>>
>>>> ... I also am very familiar with the fact that getting work done
>>>> on lists can be a rea
Mikael Abrahamsson 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.
>
&g
a timely fashion.
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.
But terms like "real-time" and "perfect" don't help. Can we avoi
Interims.
There is a definite learning-curve working with conferencing
software, but once you've climbed this it works well enough. And
the additional cutoffs, IMHO, accomplish almost as much as the
meetings themselves! ;^)
My advice is to put more effort into formal scheduling of
Int
to update 2026; others 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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ed and we should see whether "rough consensus" emerges later.
(All of which brings us to the actual question: when advancing a
maturity-level, what constitutes sufficient "consensus"? Arguably,
folks will expect a higher maturity level to indicate that the
"standard" is ready to be handed to an implementor, and merely by
following it, sufficient interoperability is ensured. Alas, we
really don't have a process to address that expectation...)
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
confusing it is
for IESG members to figure out what's expected of them when the question
is advancement of maturity level.)
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Keith Moore 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
t 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 our laptop screens.
Meetecho seemed ready to manage that sort of thing. :^)
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
this list.
BTW, while I do intend to be silent if the IESG adopts this I-D
for publication, that does _not_ mean I will be silent when the next
"adjust to current practice" I-D comes up.
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
t believe they should require extensive IESG scrutiny).
(BTW, I wonder to what extent our current repetition of the
argument about the IESG filing too many DISCUSSes is in reaction to
their scrutiny of Informational track documents.)
I don't have time today to research to what extent Informational
track RFCs have actually received "an IETF consensus call per IETF
process". Perhaps somebody else would like to respond on that...
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
pier if re-classification were an IAB decision. Barring that,
perhaps the RFC calling for re-classification could follow some path
which doesn't require boilerplate which claims to represent "IETF
Consensus"
Or, the IESG could just let this document die.
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
David Morris 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
Paul Hoffman 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 blacklist
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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
consensus of the V6OPS WG...
(Disclaimer: I date from when RFCs didn't claim any sort of consensus;
and I'd be happier if we simply avoided such claims on Informational
track RFCs.)
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Paul Hoffman 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 Work
sense. It is arguable that such an action _should_
require IETF-wide consensus; but at the moment there is no procedure
requiring it.
So, Keith, you must first convince us that an action like this
_does_ require IETF-wide consensus.
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Dave Cridland 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 no
ity-levels here:
warning-labels need to happen if we expect to change implementors'
expectations of PS RFCs.)
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ould suggest a serious effort to list mission-creep 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".
Livingood, Jason wrote:
> To: John Leslie ...
>
> 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 on a number
figured
to _not_ return records to queries by default.
This strikes me as a really-strange transition mechanism.
Color me thoroghly confused.
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
their duties would be more appropriate. So I see the relevant
> question as how to make a change, not whether.
I agree. Hopefully most of us can agree.
Charging them to find someone to do the work feels wrong to me.
Moving them to non-voting status feels right.
Enabling them to participate
AD would volunteer to endure this _again_?)
and we have the wrangling which should be contained in a WG arising
during IETF LastCall: few document authors will persist long enough.
I refuse to argue how many levels there should be -- though I'd
be happy to work withi
tion. I wonder to what extent this
results from:
- 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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
;
And, IMHO, the RFC 2026 specifications for Proposed Standard are pretty
good. I'd ask for pretty strong justification for changing either 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&#x
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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
t Standard status.
May I suggest that our problem may be the RFC2026 "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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
d start
voluntarily following 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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
s,
where we'll "vote for anything so we can adjourn". If so, we could
do worse than Russ's proposal.
But "vote for anything" _very_ often leads to bad law. I fully
agree with Scott Bradner that changing the number of levels isn't
something we should do lightly.
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
han Ted Hardie: Ted spends too much effort aiming for consensus
in things which shouldn't matter, while John sets out to document things
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
minimum to set context,
whether you top-post, bottom-post, or respond inline.
(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 _
we impose additional
experience requirements on some NomCom members without implying that
we want their opinions to be considered "better"?
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
r "better consensus".
I wish we could instead discuss how to improve the _process_ of
advancing through the levels. It may be that some prior IESG was
unwilling to let go of a death-grip on blocking advancement for any
perceived imperfection. (I simply don't know...)
I do NOT believe, however, that the current IESG has any such
interest in keeping tight control of advancement.
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ESG and the RFC Editor -- there has been no "problem"
there for several years at least.
Problem Statements are something we ask of Working Groups when
there is ambiguity in their charter. They take a long time to write,
and they almost always turn up parts of "the problem" which the WG
will end up unable to solve.
I urge you to do as Jari asks: talk not just about why your
proposal is good, but about how it addresses the diverging opinions
expressed so far.
If you're not willing to do that, please either file an appeal,
or stop beating this "pining for the fjords" horse.
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
fference may not be as great as you seem to think. Appeal if
you must, but it's really not unusual 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"
wo
ing
to bed here so that RFC publication can stop stumbling over "license"
questions.
> That's why I yell so much 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
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ic versions.
For one simple example, I know of nothing preventing citations of
self-published "guides" as Informative References in RFCs.
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
>> This abbreviated Last Call is focused solely on whether downrefs to
>> these Proposed Standards are appropriate 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.
s this quick
fix can be applied in 30 days. I strongly urge all of us to let
the quick fix go through without holding it hostage to overturning
the consensus of 5378.
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
May I recommend the Narrative Minutes at
http://www.ietf.org/IESG/iesg-narrative.shtml
(What an IETFnn attendee sees is much less than 10% of the job.)
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
nd a working
address. (This need not imply a delay, as I read it.)
> In practice multihomed services (services with multiple redundant
> links to the public Internet) do not use any of the techniques
> described in RFCs as host multihoming, and often use techniques
> that are contrary to the architecture or outright protocol
> violations (e.g. Akamai's use of CNAME chains).
Does Tony have an alternative to suggest?
--
John Leslie
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
John Day 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
;links". These "nodes"
_are_ points of attachment, not computers (whatever those may be).
Routing _must_ deal in topology, not physical proximity.
> Portraying it as anything else is just deluding yourself.
Again, hardly!
We have been puntin
t ssl and the PRKI
] 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
th developing a protocol
> for communicating email sender reputation. The group can consider
> DNSBL as a possible solution but should not be bound by a requirement to
> be compatible with it, or to use DNS at all.
Lisa and Chris have stated that they're open to consider char
its publication. But it seems to me to be a poor
fit to the IRTF, and I'd be much happier to see this sort of work in
an IETF WG. Writing such a document to avoid becoming quickly outdated
strikes me as an impossible task; and the "right" approach would be to
design services that could
; to read? Should the email Subject
indicate this is an explanation, or is it sufficient to bury a
sentence or two in what looks like a rant? (Again, I certainly don't
volunteer to write it.)
> This makes it worth considering how things could be changed to make
> concerns, such as you had, easier and less painful to resolve.
I totally agree!
--
John Leslie <[EMAIL PROTECTED]>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
uating from WGC, you'll
have a leg up on judging what deserves to be recorded in minutes, and
you'll have a better chance of gleaning a name 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
r concerns to an IESG member. For myself, I won't devote a lot of
mental effort to this issue until I see exceptions 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 the
hope nobody expects editors to end-run that! Likewise the boilerplate
"may"s...
We certainly shouldn't be asking the RFC Editor to "fix" over 100
lower-case "may"s.
Should the Area Director send this back to the Working Group?
Speak now (well, before Th
utility of implicit MX records, even those
> built on A RRs, 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]>
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
IONs we already have.)
I'd like to suggest that many 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 proce
OK
> with letting the IESG to choose the tools they use for maintaining
> things on the web, and don't really mind whether 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
ot provided the firewall has pinhole router configuration.
These are all "security" issues, for which we could find end-runs.
The problem I see is that we just don't care. :^(
--
John Leslie <[EMAIL PROTECTED]>
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Tags for Identifying Languages
The use under RFC2530 is a bit vague ("with LWSP wrapping"); likewise
under RFC3501 ("otherwise treat SP as being equivalent to LWSP"). The
use under RFC4646 has caused known problems.
This would seem to justify deprecation, IMHO.
YMMV,
o _do_ state their name mumble
it so thoroughly that I'm not sure even repeated passes 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
t an automated notification that a DISCUSS remains outstanding
some number of days after the telechat could help bring immediacy to
the process...
--
John Leslie <[EMAIL PROTECTED]>
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
ecisions, to date, 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]>
_
:
]
] The IETF as a whole does not have consensus on the technical approach
] or document.
Keith Moore 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
actually
reading every document is downright silly.
We are _decades_ past the time when everybody _could_ read all the
documents proposed for publication -- and even when we could, we
declined to try.
It's high time we gave up any pretense that the "IETF-as-a-whole"
should come to
erate folk in the WG 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 Leslie <[EMAIL PROTECTED]>
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
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
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.
&
1 - 100 of 156 matches
Mail list logo
