playing in such a sandbox -- as the Montevideo
Statement attempts to do -- requires robust effort both to be accurate
in what is said, but also to protect against misinterpretation.
Montevideo Statement seems to have accomplished neither.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
both parts are
phrased in a manner that mostly misses any of the interesting issues
about ICANN, and tends to focus the reader on misperceptions and
irrelevancies.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
x27;enhancing'.
d/
[*] Small observation about the current fashion of moving things to web
pages rather than RFCs: We completely lose version tracking, and being
able to review the history of the document. While one might add a
mechanism to remedy this, note that we don't do that now.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
e, they need to apply it to all
of us, the IETF community.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
d on actual IETF community views.
We need to find some sort of language that gives constructive guidance
and constraint about public representations of the IETF, by our
'leaders'. Not very long ago, there was a concern raised by Pete
Resnick, when an IETF working group chair made statements at an ITU
gathering and represented himself as an IETF wg chair. We might want to
review whatever guidance came out of that.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
s for. And eventual revision to the RFC. Unless someone
thinks that this core construct for the IETF is going to be subject to
constant and fundamental modification???
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
all, at least not in typical
practice in the IETF. It probably /should/ be, and the draft does a
pretty good job of explaining how it /can/ be, but there is nothing in
the "design" of the IETF's consensus process that has a history of
mitigating against the problem the draft discusses here, and the problem
isn't mentioned in formal IETF documents.
presence of an objection, the chair can use their technical judgement
to decide that the objection has been answered by the group and that
rough consensus overrides the objection. Now, the case described
here is probably the hardest call for the chair to make (how many of
us are willing to make the call that the vast majority of people in
the room are simply stonewalling, not trying to come to consensus?),
and if appealed it would be incredibly difficult for the appeals body
to sort out. Indeed, it is likely that if a working group got this
dysfunctional, it would put the whole concept of coming to rough
consensus at risk. But still, the correct outcome in this case is to
look at the very weak signal against the huge background noise in
order to find the rough consensus.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 10/2/2013 11:46 AM, John C Klensin wrote:
I assume we will need to agree to disagree about this, but...
--On Wednesday, October 02, 2013 10:44 -0700 Dave Crocker
wrote:
If a spec is Historic, it is redundant to say not recommended.
As in, duh...
"Duh" notwithstanding, we move
oing to be better at finding and
understanding an applicability statement.
ADSP is only worthy of a small effort, to correct its status, to reflect
its current role in Internet Mail. Namely, its universal non-use within
email filtering.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
centralized.
+1
Except that essentially all services other than email have gained
popularity in centralized form, including IM. So there appear to be
some important and difficult operational and usability barriers,
standing in the way of more truly distributed applications.
d/
--
Dave Crocker
'sensitive' functions, we might want to press for industry
effort to ensure that the implementations -- especially the widely
re-used open systems versions -- haven't introduced essentially systemic
exposures.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
he "fresh start" idea fundamentally wrong is
with efforts to define IPv6-based email as having different semantics
from IPv4, rather than as the transparent extension it needs to be.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
7;s technologies, the requirement is
possibly feasible to satisfy -- if we ignore the continuing human
factors barriers to large scale email authentication. However given the
resources at the time the operational service was developed, I think it
wasn't.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
ssible.
Yeah, the pragmatics of truly independent, distributed processing
environments, with limited resources and fundamental human factors
barriers really are quite shocking.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 9/6/2013 4:19 PM, Scott Brim wrote:
On Sep 6, 2013 3:34 PM, "Dave Crocker" mailto:d...@dcrocker.net>> wrote:
> To what end? Their poor uptake clearly demonstrates some basic
usability deficiencies. That doesn't get fixed by promotional efforts.
Or rather, as w
On 9/6/2013 11:42 AM, Dean Willis wrote:
On Sep 6, 2013, at 9:55 AM, Dave Crocker wrote:
In other words, the IETF needs to assume that we don't know what
will work for end users and we need to therefore focus more on
processing by end /systems/ rather than end /users/.
But we are als
On 9/6/2013 8:34 AM, Stephane Bortzmeyer wrote:
On Fri, Sep 06, 2013 at 08:20:17AM -0700,
Dave Crocker wrote
a message of 21 lines which said:
We currently do not have a concise catalog the basic 'privacy'
threats and their typical mitigations, appropriate for concern with
IETF
-hop, what with proxies, etc...)
We need privacy templates for protocol design.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
need to avoid the 'then a miracle happens' faith that end system
designers will magically figure out the best user interface design for
security, since they have failed at that for the last 25 years; they'll
eventually succeed but they haven't, so far.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
;principle", by placing too much into the infrastructure.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
there something about PGP that creates different exposures than
S/MIME, in terms of those algorithms? (Key management has obvious
differences, of course.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
em in the same way, we might not
understand what behaviors to attempt or to avoid, since that often
requires some understanding of the differences between cultures and people.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
s comments being made,
rather than merely seeking to refute them.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
al.
Also for the broader topic, you also might want to reevaluate much of
what your note does say, in light of the realities of Individual
Submission (on the IETF track) which essentially never conforms to the
criteria and concerns you seem to be asserting.
d/
--
Dave Crocker
B
TF technical work is to have any relation to the operational
Internet, it needs to treat solid, real-world deployment as having
higher priority than theoretical technical perfection.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
are
/essential/ to IETF quality assurance and I have as little patience for
the sneering you describe as anyone else.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
ds on document creators that result from LCs' current
lack of limits on critics.
LC should not be treated as a right of passage, to test the patience of
folks who have developed a document.
It should be exactly what RFC 2418 says it should be.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
at the
suspicions can be allayed. We already had solid indications that
neither were achievable.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 8/21/2013 11:58 AM, Pete Resnick wrote:
AD hat squarely on my head.
On 8/21/13 1:29 PM, Dave Crocker wrote:
Oh. Now I understand.
You are trying to impose new requirements on the original work, many
years after the IETF approved it.
Thanks. Very helpful.
That's not an approp
charter development and clearly of continuing interest
to the effort, namely:
A proposal for Caller Identity in a DNS-based Entrusted Registry
(CIDER)
draft-kaplan-stir-cider-00
An Identity Key-based and Effective Signature for Origin-Unknown
Types
draft-kaplan-stir-ikes-out-00
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 8/21/2013 11:13 AM, Patrik Fältström wrote:
But we are not there. A proper migration strategy to SPF has not been published.
Oh. Now I understand.
You are trying to impose new requirements on the original work, many
years after the IETF approved it.
Thanks. Very helpful.
d/
--
Dave
d analytic legitimacy.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 8/20/2013 9:08 AM, Andrew Sullivan wrote:
On Tue, Aug 20, 2013 at 08:54:02AM -0700, Dave Crocker wrote:
In other words, the specific technical limitations being noted are
unfortunate but (so far) not serious.
You should explain that to my employer's support department.
In any ca
ade-offs.
In other words, the specific technical limitations being noted are
unfortunate but (so far) not serious.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Being able to separate
administration of the underscore-based attribute information is a
feature, not a bug.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
as long as I'm asking for more explanation, given the number of
years of use the construct has had and for the number of different
applications, where has the problem (whatever you mean specifically)
been seen?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
h might be aesthetically
displeasing, but it works just fine.
The second is that, unfortunately, deploying a new RR that gains
widespread, end-to-end support remains problematic, assurances to the
contrary notwithstanding.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
group missed or
explain how it assessed reality incorrectly or otherwise made a
problematic engineering choice.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
that some technologies have multiple components needed before they
are worth adopting, and an initial, incomplete set might be published
before a sufficient set is available.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
n
somewhere, so that we would've had that information when we did the
research for RFC6686.
Well, they were written down 15 years ago, but they haven't gained
traction yet, though I remain hopeful.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
should not be taken as a sufficient waiting
period.
I do not recall anyone (else) showing support for that view, but
certainly not any substantial constituency.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
- we debate incessantly just
about the f2f day-pass, and that's nothing compared to this. For
example: if things break during the meeting session, do we re-imburse
them? Do we pro-rate the re-imbursement based on how many of their
meetings had technical issues with audio or video?
...
It&
kes sense for a specification to document its tradeoffs; it often
does not make sense to choose only one such specification for use in all
scenarios.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
itten criteria that
determine assignment of our standards labels and our process really is
quite ad hoc and therefore unreliable.
I hope you are wrong.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
h I think it's actually destructive,
since it provides fuel to the view that the IETF is a questionable venue
for standards work.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
;t noted anyone challenging it on basic technical
grounds.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
ow of speech, versus not.
So let's be careful about whether slides ahead of time need to be a
requirement, rather than being considered only a nice-to-have.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 8/6/2013 12:15 PM, Ted Lemon wrote:
On Aug 6, 2013, at 11:27 AM, Dave Crocker wrote:
An entirely different approach would be to have all speakers make a
'reservation' into a single meetecho (or whatever) online queue, and then get
called in order, whether local or remote and i
stem, with the entry task distributed.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
rn.
It's not appropriate to throw out results that were validly obtained but
yield unpleasant results, and then repeat the same query. (In fact a
repetition of a survey on the same sample population is a rank violation
of reasonable experimental methodology.)
d/
--
Dave Croc
On 7/31/2013 7:22 AM, Scott Brim wrote:
> http://tools.ietf.org/wg/intarea/trac/wiki/MeetingTimePrioritization
I might argue that that specific list is overly fussy and possibly
Procrustean, but the gist of it definitely looks like the right kind of
thinking, to focus wg face-time on re
ipants who
insist on treating consideration of Full standard as an excuse to
discuss first principles, but it's not within scope.
Over time, as more specifications are processed to Full, the community
will learn to be a bit more efficient about it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
much.
Basically, if a wg is being diligent and candid in summarizing its
problems (as well as progress) the rest of us have an obligation to be
helpful.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
ote:
> The following will be discussed in the DMARC BoF:
>
>"a mechanism for protecting the portion of the
> RFC5322.From field"
>
> My guess is that it might be educational. :-)
I'm involved with the DMARC effort. I'm almost positive it won't be...
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
rticipants we can manage.
Some organizational empathy that is applied to event logistics will go a
long way here.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
installed-base behavior that has, I believe, has no historical precedent.
It is, in fact, possible that Marshall Rose was wrong and that for some
things, there is no possible thrust sufficient to make pigs fly, or at
least not without killing an extraordinary number of other pigs.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
users from
treating dotless names one way to another should be seen as an
impossible task.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 7/13/2013 7:25 AM, Livingood, Jason wrote:
There must be something similar to Godwin's Law whereby any IETF
discussion can devolve into a debate over NAT. ;-)
It's not devolution, it's translation into our private context.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
he example of localhost was cited.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
gs afterwards...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
hers are assured equal
opportunity to participate and influence.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
stablished principles.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
nnot produce
viable committees if we require each member of a committee to be
affiliated with a different company?
In other words, are we really incapable of requiring extensive corporate
diversity?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
rienced with the workings of IETF process, we will continue to risk
a Nomcom composed of people having literally no such knowledge.
The risk is actually a certainty, over time, given how statistical
sampling works, over time.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
provide a guarantee. Still, it
looks like a useful filter.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
e capabilities, but partly because it was always a cool group to
interact with.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
s afraid of doing it.
My reading of the appeal was that it succeeded, in that the agreement
with Sun was signed shortly after that and the IETF took over the NFS
specification.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 6/27/2013 4:24 PM, Brian E Carpenter wrote:
Evi used to be an IETF regular. There is rather ominous news - she is
lost at sea between New Zealand and Australia:
http://en.wikipedia.org/wiki/Evi_Nemeth
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
that is not certain to be
represented amongst IETF protocol engineers who choose to comment, it
seems wise to ask for help from a professional.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mcom does requires the group to have had
significant face-time.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
that have demonstrated no utility for IETF specifications.
Hell, we still debate the differences of just /those/ 3 words...
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
your implication that there is /any/ meaningful distinction made by
native English speakers when reading an RFC...
For the times I've seen the different words used normatively in RFC, I
have not discerned any semantic difference.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
A/S intent is completely clear.
A fine suggestion, with which I agree.
For normative vocabulary, synonyms are sinful.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
river.
individual self-assessment tends to be a very unreliable mechanism upon
which to base efforts at social change.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 6/19/2013 8:08 AM, Peter Saint-Andre wrote:
On 6/19/13 8:32 AM, Dave Crocker wrote:
On 6/19/2013 5:35 AM, Dave Cridland wrote:
Phillip Hallam-Baker wrote:
There is a real problem with accountability and transparency in the IETF
constitution which was designed by a bunch of old boys to
he sees no structural problem.
PSA's been an AD, yes, but:
Forgive me, but you just responded to a rather unpleasant ad hominem.
We should not sustain such threads.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
has been started and pursued in isolation of any other
efforts and it has been the subject of direct IETF discussion. So I
was/am asking about it's follow-up effort.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
open mailing list
https://www.ietf.org/mailman/listinfo/diversity
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
ing in the region, it would
be helpful to see some response to the concerns raised about this as a
recruiting tool.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
text' means demonstrating an understanding of what is being
commented on and fully explaining what our comment means.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
care
about the document, this shows that they do.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
't it?!* ]
oh boy. we need to put that on a t-shirt. it's just perfect. and
universal.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
We also sometimes have drafts that have had little working group
activity.
...
Perhaps having a shepherd-style write up included in the last call
announcement? (Or available via a URL there).
Perhaps something like that, yeah.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
pposed to happen, but it's become more common in the current IETF.
Again, there's no perfect protection against that, but seeing public
activity during IETF LC that demonstrates enough community interest to
do the minimal work of offering a capsule commentary on the draft will help.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
he basis the support, not just the fact of it.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
least once more to the IETF community during Last Call of the draft
that became RFC 6376. Your opinion wasn't agreed with: you were "in
the rough". You're now bringing it up a fourth time (at least), and
you still appear to be in the rough. The decision was to allow the
ve
On 6/4/2013 1:08 PM, Douglas Otis wrote:
Dear Dave,
On Jun 4, 2013, at 11:44 AM, Dave Crocker wrote:
I happen to be sitting in a M3AAWG meeting as I write this note
and it happens that I just came out of a session in which someone
tried to assert the use of DKIM (or SPF) as a 'requir
ead
recipients about who authored a message.
The draft continues to make broad, onerous claims like this, but
provides no documentation to indicate that the DKIM signing
specification is flawed in the function it is performing: attaching a
validated domain name to a message.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
to the IESG
without continued WG discussion;
3. The document proceeds as an Independent Submission to the RFC Editor;
4. The document is abandoned.
mumble. yeah.
but i hope we don't spend too much energy on this topic, given how rare
it is.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
On 5/31/2013 8:12 PM, Scott Brim wrote:
We'll have multiple airships, one for each set of related meeting rooms.
is dirigible a new term of endearment for an AD?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
tting around the bar, imparting
sage advice for how something can be reasonably done, within the formal
bounds of IETF rules and culture.
It's only 'force' is whatever credibility the individual reader choose
to assign to the text, as is true for any "Informational&q
s no force other than
representing some collective wisdom.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
.
d/
ps. The real consideration was whether to try to folk this draft into
Working Group Guidelines and Procedures. I think that idea actually has
some reasonable logic to it; but it doesn't have enough benefit to be
worth the effort of opening up WGG&P a third time, for now.
d/
seen by reasonable
people who are being reasonable, rather than make policy decisions on
the hypothetical of a stray distortion.
There's a lot of nuance here,
There is no nuance at all in this document.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
ck or BCP and that it says quite
explicitly that it isn't normative?
Just the mere fact that it's a "separate" document will somehow impart
and implication of official normativeness?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
ive in the IETF. I don't mean that such meetings aren't useful,
but that I believe they are secondary to the work that is done over the
rest of the time.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Task Force
http://www.ietf.org/tao.html
If the content needs to be improved, let's do it!
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
ation. The easy part is specifying audio/video
streams support. More challenging is to get the personal and personnel
support figured out.
And should it have some means of assisting discussions outside of the
bof/wg/plenary sessions?
What else?
d/
--
Dave Crocker
Brandenburg InternetWo
nges.'
According to the Telegraph, 'The new regulations required anyone wanting
to change Argentine pesos into another currency to submit an online
request for permission to AFIP, the Argentine equivalent of HM Revenue &
Customs. ..."
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
US$
==
OriginBUE Frankfurt TokyoAtlanta
- - ----
SFO 1400 1200 1100 350
Amsterdam1600 150800 1100
Taipei 2100 900400 1500
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
1 - 100 of 1810 matches
Mail list logo
