, it is certainly true that IETF working group
sessions often are not as productive as we would like, but really, we don't
need help from the hotel to make sure that's the outcome...
d/
--
Dave Crocker
Brandenburg InternetWorking
ides, it's always good to state things positively.
In other words:
It has always been with problems.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
belongs in the IETF, not the publication operator.
The RFC Editor needs a control point within the IETF that asserts that the
submitted document is the right version.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing lis
Tim Chown wrote:
I'd just like to compliment whoever implemented the new web based
IETF draft submission tool. Very simple to use and rather slick :)
+10
Easy to use, and astonishingly quick release for public access to each new
document.
Definite home run.
d/
--
Dave Cr
___ to them." Every
secretary immediately said Reply -- and frankly were a bit irritated, since
they thought the answer (pun?) was so obvious -- so that was the command name
I used.
Took about 30 minutes, mostly because I had to walk around to get to the
secretaries.
d/
--
Dave C
exclusive.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
hrase "critical path" goes hits a relatively new user interface
design paradigm, called "activity based design" where the user *sequence* is
considered in terms of common goals for users.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_
through all
the pain of documenting interoperability without first being sure that a
normative reference issue isn't going to render their work meaningless.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
wish.
But, then, they operate under serious time and resource constraints. Input
from the public would help counter this.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
worthwhile goal, even if for some it's just
an intermediate goal.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
also at the youtube site. under the Subscribe button is a 'more info' link.
d/
[EMAIL PROTECTED] wrote:
And so you can sing along...
The words can be found at the usual place:
http://www.secret-wg.org/Secret-Archive/
--
Dave Crocker
Brandenburg InternetWorking
Harald Tveit Alvestrand wrote:
Can't believe nobody else posted first
OMG. Can't believe how stellar the words and the performance were.
Net Ops has moved into needing awards for "Oscar-worthy" efforts.
Thank you SO much for posting that.
d/
--
Dave C
all kinds of a priori
processes kick in for employees of patent-conscious companies,
...
+1
Otherwise you get into battles over theory and ideology without any of
the information you need to make a decision.
+1
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Marshall Eubanks wrote:
For this thread, perhaps you meant "you have been warmed."
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
s that
increase the cost.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
ot change the situation with IPv6, but it could have an effect on
other, future work.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Thomas Narten wrote:
Dave Crocker <[EMAIL PROTECTED]> writes:
4. The v6 stack would need to have a v4 mode, for use by v4
applications -- applications that use v4 addresses.
Um, sounds an awful lot like dual-stack to me. Hosts (that understand
It's not.
No more than
incremental changes would permit incremental benefit of
the larger address space in IP, routing, applications, etc.
Has the added 15 years brought more functionality than this approach would
have permitted? Is deployment easier?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
chanisms.
John Levine and others have been making this point on the thread, but it does
not seem to be registering.
Having mail receivers at ietf.org take note of email authentication is a Good
Thing. Assuming that this is going to "solve" any particular email problem
Post-posting additional thoughts:
Dave Crocker wrote:
2. Rather, the label says something about community consensus. If a
later disclosure alters that consensus, then of course the community
should re-label the thing, to take it off standards track.
Although this should be check with an
at the label is needed for a spec to
be useful.
2. Rather, the label says something about community consensus. If a later
disclosure alters that consensus, then of course the community should re-label
the thing, to take it off standards track.
d/
--
reason it might be worthy of discussion
is the possible legal impact. I could imagine that Historic would be a more
clear bit of input to the legal process...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Iet
a policy do to mitigate against this kind of threat
to the process?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Stephane Bortzmeyer wrote:
Check your "solution" againt FUSSP
(http://www.rhyolite.com/anti-spam/you-might-be.html) first.
Indeed. Let's also not forget:
<http://craphound.com/spamsolutions.txt>
d/
--
Dave Crocker
Brandenburg Inter
versus interior.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
en the adoption hurdles IPv6 has been showing, then efforts to both make it
easy and publicize/document that it's easy could be helpful.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://w
nd including DNS, and parallel operations of
such things as routing, Neighbor Discovery protocols, IPv6 Stateless Address
Autoconfiguration, ICMP. (Maybe more?)
* Dual, simultaneous admin and ops activities, for IPv4 and IPv6. That's
a big deal.
d/
--
e had been chosen.) The current IPv6 suite probably does not.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
or "a Jabber scribe" but I have never heard one ask for
"an XMPP scribe" (or to be even more precise -- since XMPP-based
Then let's in fact rename the protocol.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
o try to alter the name of the base standard.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
that cited numerous issues with it. (And no, I was not the only one
expressing concerns.)
It appears that the current draft has not responded to -- nevermind resolved
-- any of those concerns. Is the there any intent to work through those issues?
d/
--
Dave Crocker
Brandenburg
e last hop before receipt by
the boundary MTA?
There are a few more roles we mush together under the term sender, but I
suspect you mean one of the above. Confusion in the term usually seems to be
between author and originating operator, but often includes the outbound MTA
operator.
d/
Tony Finch wrote:
I don't understand how it can be easier to do anti-spam checks in an
IM2000 design than in current email.
It is always easier to create the perfect solution on paper, and then compare
it to the imperfections of established practice.
Paper beats rock.
d/
--
when we wind up
inventing interpretations at will.
And the 'we' means a whole lot more than you or me or this particular topic.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
hat change.
Once they've got that, we'll probably be able to figure out how to engineer it.
Until the consensus is developed, these sorts of threads are repetitious
theoretical exercises, of no pragmatic benefit.
d/
--
Dave Crocker
Brandenburg Intern
combined in one unified protocol.
You mean SIP?
Probably not:
<http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=87>
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.or
ast have a good
understanding of why and try to make it as minimal as possible.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
.
Well, this thread is entirely too timely for me to pass up the opportunity of
citing:
"Is It Time to Replace SMTP?"
tiny: <http://tinyurl.com/35m64e>
full:
<http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_10-2/102_smtp.html>
In the current issue
ently suspicious even if the
correspondent is well-known and trusted?
Sure.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
y point
of view, the techniques better have very high leverage on spam
and criminal enterprises in order to justify that. Otherwise,
Right. Or perhaps consider alternate techniques that do not impose this
limitation?
d/
--
Dave Crocker
Branden
Anything that constraint what can go
wrong will limit the ability to make the technology robust and usable.
It is the focus on pragmatic steps that make the technology usable that I
believe Clark was referring to, by saying "running code".
d/
--
Dave Crocker
Brandenburg I
e-wild *service*. Anything that constraint what can go
wrong will limit the ability to make the technology robust and usable.
It is the focus on pragmatic steps that make the technology usable that I
believe Clark was referring to, by saying "running code".
d/
--
Dave Crocker
Br
this was merely due to a difference in scaling, with IPv4 DHCP
usage being large-scale and IPv6 being small?
I suppose the more constructive way to ask this is: Does anyone know why one
worked better than the other?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
the
rest of the technical and operations details as stable as possible. (Yeah,
some change is required, over time, and any change carries some risk.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
et code was
deployed and used in a running service, with increasing scale. So the
distinction between prototype and production is probably of fundamental
importance. (I think that Dave Clark really meant "running service" when he
said "running code".)
d/
--
Dave Crocker
ther words, it seems less like the problem is adding the ability to
specify sub-types under application, than to stop relying only on top-level.
For example message/rfc822 vs. message/x400.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Services based on Email
<http://www.apps.ietf.org/rfc/rfc3297.html>?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
[EMAIL PROTECTED] wrote:
As a Chicagoan I can assure you that any forecast beyond the next 12
hours is useless.
Just like a typical Chicagoan.
Ridiculously optimistic about the weather.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
nnections, but the mail-level view is that,
again, the interaction is direct.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
emonstrates why the discussion should be about layer n and
n-1, rather than n and n+1... Focus on the consumer-side of the architecture,
when defining the service requirements that need to be abstracted, and then
provided by the subordinate layer.
d/
--
Dave Crocker
Brandenburg
the lines of criticizing or recommending
particular protocol features.
It seems that we lack a vocabulary for discussing service needs, without
diving into protocol details. Yet upper-layer independence of lower-layer
details requires exactly that vocabulary.
d/
--
Dave Crocker
t the issue.
The issue is operational risk.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
The IETF network is not, and never has been, for experimentation,
showing off new technology, or making political statements. Please keep
it that way.
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Jun-ichiro itojun Hagino wrote:
maybe we can have the default "IETF61" SSID be pro-IPv6, and SSID
"legacy" be IPv4-only :-P
Ahh, well. That moves the change from being coercive to being cool.
Good marketing approach.
d/
--
Dave Crocker
Branden
ime to cut over to pure ipv6 be when production use
of ipv4 becomes minimal?
No?
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
s deem appropriate.
No, because an open relay is the responsibility of its operators, not the
responsibility of every access provider on the net. You need to
distinguish direct attacks from indirect attacks.
NS. A, oc, c...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
__
cases. Corner cases are expensive... and rare.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
and pointers--
if there is any appreciable risk that it will be deployed and seen in
the wild.
Mostly, I think we (the community) tend to confuse the coordination role of
registration with the approval role of standardization.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
ble idea.
Our pretending that a protocol extension will simply go away because we
don't like it --or because we can't agree that we do like it-- does not
make the Internet work better.
+1.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
__
Tony Finch wrote:
On Tue, 12 Jun 2007, Dave Crocker wrote:
Nothing prevents the document from being submitted directly to the RFC Editor,
for publication as a non-IETF document.
... except that TLS extensions require IETF consensus ...
mumble... grrr... yeah... mumble...
waffle: I
submission. Indeed, being able to obtain
a willing sponsor is considered part of the IETF vetting process.
Nothing prevents the document from being submitted directly to the RFC Editor,
for publication as a non-IETF document.
d/
--
Dave Crocker
Brandenburg InternetWorking
d mail by virtue
of having been configured properly and not having been compromised, then it
sounds to me as if the mail is very much authentic (and authenticated.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing lis
ntication is not a particular technique, it is an assurance. Whatever
achieves that assurance -- to a sufficient degree and with sufficiently low
cost -- is fine.
Side note: on Unix, will cron be forced to authenticate to send emails
at 2 am? :-)
Yes. See above.
d/
--
Dave Crocker
I do not think that that is a danger here.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
em reports, changing the specification looks
like exactly the wrong decision.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Tony Finch wrote:
On Tue, 15 May 2007, Dave Crocker wrote:
So that is a total of at most 2 documented cases in 10-30 years.
And keep in mind that the issue is not that the rule "does not work" but that
it is very rarely mis-used.
Did you miss my post linking to a description of LW
much of our
technology would be deprecated...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
change will not create new
and different problems, such as for other uses of ABNF?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
given the limited time to forage for food elsewhere.
But what is the reason for presuming that the IETF has an obligation to
feed us meals? Why breakfast, but no other meal? Why any?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
__
+1
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
at.
With the IETF Tools Team, such things are easier to pursue, these days, if
folks think it a useful idea.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
library to enable us to find other attendees more
easily:
+1
The Tools team has shown a pretty remarkable record. Adding this to the list
of things the team considers -- and probably adding some volunteers to work on
this -- would be great!
d/
--
Dave Crocker
Brandenburg InternetWorking
Ole Jacobsen wrote:
And, no, it's not my native language either, but somehow I survive as
an editor of it :)
Even better is that the *rest of us* survive your being an editor of it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
regime?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
side a security perimeter and think they are safe to buy the
liquids they could not take through the perimeter.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
uying Champagne, when he was about
to fly to France...
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
e part of
the signaling mechanism, I think. But it's current role is carefully kept
separate from that.
(Multi-addressing designs that use domain names might therefore be viewed as
making the DNS be part of a signaling mechanism, which of course explains why
so many IETF infrastruct
e U.S. Just different.
Yes, it can be a challenge to find credible ways to distinguish between the
two, but it's clear that the otherwise review of published reports is not
sufficient.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_
roblems they
tend not to solve any problems at all.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
.
Who wants to use this spec, now, and why?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
uot;the
latest version" rather than a specific version are entirely warranted...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
at
the correct citation should be the latest version.
Indeed, using the BCP or STD number is really a way of providing an automated
mechanism for resolving the citation "The latest version of ...".
That is even useful for technical specs, but only sometimes.
d/
--
Dave Crock
Brian E Carpenter wrote:
I think you are deeply misunderstanding how PROTO shepherding is
supposed to work.
That's a pretty basic disconnect.
Perhaps you can summarize how it is supposed to work?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
sting list. I should also comment that pre-wg venues
typically do not have clear rules and archiving status. While it is worth
exploring development of guidance for proto-wg lists, I hope that is treated as
something entirely different from whether an I-D states where discussion about
it should occ
line.
The table of mappings constitutes an on-going administrative challenge. Also as
noted, not all I-Ds are tied to working groups.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1
If the IETF is to be truly inclusive, it needs to limit the amount of expertise
required for simple interactions by the rest of the community. Giving them the
name of the mail list seems like a pretty small bit of overhead.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbi
ion.
WG formation is much like negotiating a contract. It should be done among the
principals, not just their representatives.
One of the very big benefits of this will be the creation of a very clear and
public record of community interest and perspective.
d/
--
Dave Crocker
B
one
side of an issue as justifying a choice by IETF management, when the
counter-side is just a valid -- and often more of a concern. I thought IETF
decision-making was about seeking balance?
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
this might
happen).
Markus,
Thank you. This is extremely helpful.
I suggest that the document have something like your above text added to the
Introduction.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
;OPES systems" and which don't. Equally I
seem to be entirely missing what insight or guidance is intended here.
As for trace information, are all Received headers "OPES" information? If so,
why? If not, why?
And so on...
Help?
d/
--
Dav
on WG meetings during IETF Weeks...
Can Dave point out any examples?
No, he can't.
But he did realize that his making the suggestion obligated him to produce at
least one...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_
It merely
requires the decision by a working group -- or for that matter, any wg
participant -- to create it and make it available. Given the popularity of
non-IETF support web pages for working groups, it would of course be trivial to
add the latest DS to t
cipants.
For work of any extended interest, being able to see a summary of on-going work
that looks relevant to them has to be useful for deciding whether to participate
but particularly useful for folks who cannot participate directly but are likely
to be affected by the final output.
d
. It needs to have more to do with satisfying real-world need than with
bureaucracy or abstract idealism about the purity of architecture.
Bureaucracy and idealism can be quite helpful, but only *in the service of*
satisfying real-world need.
We used to be pretty good at that.
d/
--
Dave Crocker
? What improvements resulted?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
ielding
multiple solutions, and letting the market choose among them. So the above
criterion would seem to impose a universal requirement for unanimity that was
most definitely not part of the IETF model, for example, 10-15 years ago.
d/
--
Dav
nts are left to the WG.
You read my words correctly.
Thanks for the helpful re-phrasing/clarification.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
ory, that has been a requirement in some special cases, but
not others. The default view has been to let the market decide among choices.
Requirement for a single choice has been asserted only when there is a strong
argument that having multiple choices will cause damage.
d/
--
Dave Cr
tion
mechanism.
But the most important issue is probably getting the document reviewed,
approved, and applied, no matter what publication mechanism is.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
Ietf mailing list
Ietf@ietf.o
1001 - 1100 of 1810 matches
Mail list logo
