> I wasn't sure if I-Ds should set up normative references. Based on the
> comments I'm guessing that I should
> have. I can make a pass to fix all that.
Yes, sure they should. Things that have to be understood in order to
understand the I-D are normative. Things that just give additional
> By all means, let's make this a cesspool of irrelevant junk. Especially for
> junk that clearly has no clue about the
> history of DKIM.
Mike, that's out of line; please stop that sort of characterization.
Barry
___
Ietf-dkim mailing list
> A point I was trying to make in earlier posts is that this topic does
> not seem to me to warrant anything close to that much effort on
> producing background text.
>
> Especially when we so far seem to be lacking cohesive effort to
> formulate serious technical and operational 'solutions' and
As someone who has, as an AD, questioned the publication of such
background documents, even in working groups I chartered, I can give a
related opinion about this one:
I do think the background is important to publish separately for this
work, however easy the problem is to describe. I think
> Anyway, discussing whether spf+dkim verification can mitigate DKIM replay
> belongs to the ietf-dkim list. (In case, it could also be expressed outside
> DMARC, for example by an additional DKIM tag.)
I do agree with this, yes.
Barry
___
Ietf-dkim
Ale, you're venue-shopping; please don't do that.
> Discussions about solutions that only cover DKIM replay are now declared to be
> out of scope for DMARC. In fact, messages that would only be blocked by
> auth=dkim+spf are either messages that pass DKIM but fail SPF, or messages
> that
> pass
DomainKeys was already made Historic when RFC 4870 was published in
2007. Look at the RFC status.
Barry
On Mon, Jun 12, 2023 at 1:18 PM Jan Dušátko
wrote:
>
> Murray, Dave
>
> I would like to ask another question about the following.
> - DomainKey (RFC 4870) only allows signatures to be used
I do not object to using this as a starting point (which is how I
think "adoption" should generally be framed).
Barry
On Tue, Apr 4, 2023 at 11:50 AM Laura Atkins wrote:
>
> I want to thank everyone for their patience as I learn IETF processes and
> tools. Tim and I are working on a statement
Do you understand what "disingenuous" means? Do you really think
someone is intentionally acting in bad faith?
Barry
On Tue, Mar 28, 2023 at 1:05 AM Michael Thomas wrote:
>
>
> On 3/27/23 8:46 AM, Scott Kitterman wrote:
> >
> > On March 27, 2023 3:10:40 PM UTC, Laura Atkins
> > wrote:
> >>
>
I don't agree with the premise. I think what was tried and didn't
work should be documented in the result that the working group comes
out with, but not in the problem statement.
Barry
On Sat, Mar 25, 2023 at 8:57 AM Michael Thomas wrote:
>
>
> And yes, that means spam filters and the rest of
I think that changing this to SHOULD is the wrong approach. An
Applicability Statement might well give advice, possibly at the SHOULD
level, that goes beyond this and discusses use cases, but the base
protocol uses MAY for a good reason, and at the protocol level it
should stay that way.
Barry
nd that "x=" is purely advice to the validator. To *really*
expire a signature, one has to stop publishing the key associated with
the selector.
Barry
On Thu, Feb 16, 2023 at 4:38 PM Scott Kitterman wrote:
>
>
>
> On February 16, 2023 9:21:51 PM UTC, Michael Thomas wrote:
&
>> Okay. What's the value for X - T that prevents this problem, but doesn't
>> cause DKIM signatures of "normal" mail to fail?
>
> There's not one "right" value; we're talking about distributions
> of timings for normal mail vs. replay, and yes, there's some
> overlap there. In practice I've
No, replaying a message that happens to have a DKIM signature in it is
not what we're talking about when we refer to "DKIM replay". The
point of a DKIM replay attack is specifically to use a signature that
continues to validate in order to get false credibility.
Barry
On Wed, Jan 11, 2023 at
I agree with Mike and Scott on the point that it’s worth explicitly
allowing the result to be a “can’t do it” publication. Implicit “couldn’t
do it” is fine in most cases, but here we might say something like, “If the
working group decides that none of the proposed approaches will work
acceptably
I have no formal role here, so please just take this as a plea from a
participant:
Let's please stop bickering: it's simply hindering a productive
discussion of a charter, and it's clear that we can have endless
back-and-forth messages in this vein for quite some time if we let
ourselves. Please,
> >> In some systems, sieve scripts and other filtering is done *after* the
> >> MUA drops the message in the delivery mailbox. If that drop removes
> >> the signature, that hampers the sieve/filtering process severely. A
> >> sieve "redirect" becomes impossible, and the filtering would not be
>
> The purpose of a DKIM signature is, as our original statement put it, to make
> sure that a message from your
> bank actually came from your bank, even if it passed through your alumni
> association. Once it arrives to your
> real mailbox, that signature is not needed.
As long as the
30, 2022 at 9:03 AM Mark Alley wrote:
> That's a question I've always had on this topic.
>
> Is 5322.FROM an acceptable long-term workaround for DMARC enforced
> domains? The community in general seems to be split on 5322.FROM munging
> and it's use in practice.
>
> On 11/30
>> Unless I’m misunderstanding you’re saying those with an
>> enforcing DMARC policy can’t successfully send to mailing lists.
>> I’m doing it now so I don’t think DMARC has to stay inert if
>> mailing lists. That’s a bit of a generalization.
>
>_dmarc.marmot-tech.com. 300 IN TXT "v=DMARC1;
I will say that the use case that is broken by removing the signature
is the "re-send" case, where the MUA or some other post-delivery agent
(perhaps a sieve script) re-introduces the message with a different
RCPT TO but the same MAIL FROM and "From:". I don't know how often
this happens
On Mon, Nov 14, 2022 at 11:03 AM Alessandro Vesely wrote:
>
> On Mon 14/Nov/2022 05:50:42 +0100 Roland Turner wrote:
> > I'd point out that all but one of those things is either redundant (vs. say
> > ARC), unacceptably harmful (we use DKIM *in the first place* to facilitate
> > forwarding
Indeed...
The issue here is this:
1. I get a (free) account on free-email.com.
2. I send myself email from my account to my account. Of course,
free-email signs it, because it's sent from me to me: why would it
not?
3. I take that signed message and cart it over somewhere else, sending
it out to
th this behavior, so I'd like to understand how to
> distinguish good from bad in this space.
>
> Scott K
>
> On Wednesday, November 9, 2022 12:43:35 PM EST Barry Leiba wrote:
> > Is this relevant to the charter? Do you doubt the attacks
> > sufficiently that you would
Is this relevant to the charter? Do you doubt the attacks
sufficiently that you would want to object to chartering a working
group to address the issue?
Barry
On Wed, Nov 9, 2022 at 4:54 PM Alessandro Vesely wrote:
>
> On Wed 09/Nov/2022 13:08:15 +0100 Barry Leiba
Trying to eat my own dog food
I've always wondered how eat our own cooking became eat our own dog
food, which makes no sense at all. Ah, well...
- I guess this could be updated to say don't offer an MSA that ever
allows for cleartext submission but UTA will probably get to that.
UTA should
I find the security considerations in this registration rather weak.
What might have sufficed in 2005 seems to me inadequate for 2013. I
would expect a clearer statement of what are or are not considered
threats or attacks and what mitigations there then are for them.
Tom, do you have
This draft's premise is interesting, but the implementation leaves to be
desired. That is, I like the idea of fragment identifiers for CSV, but
row/column/cell-based selection doesn't address my need.
This is an Independent stream document, and the IETF doesn't have
change control of the
Hi. Just to be sure that everyone has the same understanding of
what is being proposed here, the above says to Historic but
the writeup at
http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/
says to Internet Standard. Can one or the other be corrected?
Gakk. I don't
To both Doug and Hector, and others who want to drift in this direction:
As I've said before, the question of moving ADSP to Historic is one
we're taking on its own, and is not connected to anything we do or
don't do with DMARC. Bringing DMARC into the discussion is a
distraction, and, worse,
because all IETF document are examined by IESG
No they're not. See RFC4844.
Lloyd, it *is* true that all documents in the IETF stream are reviewed
and approved by the IESG. I would take IETF documents to refer to
documents in the IETF stream.
(In fact, documents in the IRTF and Independent
Hi. Just to be sure that everyone has the same understanding of
what is being proposed here, the above says to Historic but
the writeup at
http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/
says to Internet Standard. Can one or the other be corrected?
Gakk. I don't
Yeah it is a thin line. But the language was introduced to keep a
current practice possible (as argued by Barry I believe).
Yes, that was my concern.
I see where you are going.
draft Proposed rewrite
While commonly less mature specifications will be published as
Informational or
Based on the discussion so far I've made a few modifications to the draft.
I am trying to consciously keep this document to the minimum that is needed
to achieve 'less is more' and my feeling is that where we are now is close
to the sweetspot of consensus.
Section 4 makes me happy. I think
The only concern I have is that once we do this -- declare that PS is
always more mature than that -- we can't go back. Do we *really* want
to say that we will never again approve a PS spec that's partially
baked? This is painting us into the room where PS is mature and
robust. If we like
That does seem better, but don't all parties have an obligation to attempt
to communicate clearly?
The new text is as follows:
Participants, particularly those with English as a first language, attempt
to accommodate the needs of other participants by communicating clearly.
I mostly agree with this draft, but I have a concern. Let's anchor
that concern off of this bit that Jari said:
Secondly, the other obvious action we could take is to go back to the original
mode of operation, i.e., making PS RFCs truly early and somewhat untested
specifications. I am
On Sun, Sep 1, 2013 at 5:50 AM, Scott Kitterman sc...@kitterman.com wrote:
I think it's particularly incumbent on native English speakers to
avoid highly idiomatic or stylized language - English that is not
taught to non-native speakers. It may be better to say something
along those lines,
In Section 2:
'a. The code points must be from a space designated as Specification
Required (where an RFC will be used as the stable reference),
RFC Required, IETF Review, or Standards Action.'
I suggest not having the comment (where) and leaving it to RFC 5226 to
define
Pete, I like your position, but I believe go read the archive or the
equivalent will continue to be a standard response unless someone is
responsible for giving a more thorough response. Who do you think that
should be?
If you've had the most fleeting look at this:
In this conversation between Pete and Dave, there's one point that's
come up which has come up often enough that I want to call it out
separately for comment:
the only purpose it seems to serve is to bully others into not
participating in the conversation.
You think I could bully Patrik?
* Will CBOR become the default binary JSON encoding?
That would be up to the implementors. If they like it, they will
implement it and use it in other protocols. No one is suggesting at
this point that there be any specific direction about that -- it's
being proposed as one possible tool.
*
A couple of procedural points here:
The issue here is whether this proposal should be an IETF Proposed STANDARD.
...
Usually when the IETF publishes an algorithm it is given INFORMATIONAL or
EXPERIMENTAL status. That is what originally happened with JSON, RFC 4627
has INFORMATIONAL status
it's extremely common for in-room glassware and cups to be
washed by the housekeeper. If I don't see racks of clean glasses and cups
on the housekeeping carts, then I assume those in my room aren't clean, and
I use paper. Less environmentally friendly, sadly.
I just wash the glasses myself
In the case of a WG-forming BOF, it seems to me that a nucleus
of people willing and competent to do the work, and a good set of
arguments why the work needs to be done and how it will make the
Internet better, are more important than any kind of numbers game.
That one sentence covers
Agreed. Great meeting overall, venue worked well, plenty of places
to eat and stay within reasonable distance, and suitable distractions
for those half days when you don't have any sessions.
Hm.
What are these meeting-free half-days of which you speak?
Barry
What did you think of Pete Resnick's draft about hums.
I thought well of it; I still do. When Pete planned to write it, I
offered to co-author it. But he said that once he got started, it all
just flowed out, and he wanted to present it as just his craziness, at
least at first.
It's not about
We are not voting.
We are expressing agreement with a specific assertion.
That is true whether the agreement is expressed via vocalization
or motion of limbs.
Absolutely so.
The chairs can pick however they want to measure agreement.
Many chairs ask for a show of hands. I prefer that
The most valuable part of IETF meeting is and has always been the hall
conversations and side meetings
I think *side meetings* are killing IETF, I call it *hidden meetings*, there
is no input for IETF when we have side meetings. The input to IETF in
through meeting sessions and discussion
I just followed http://www.iana.org/assignments/enterprise-numbers.html
From RFC3315 (DHCPv6)'s reference section. Ten years later, the URL
doesn't work.
I know that things were reworked when we went to XML based storage, but
I thought that the old URLs would at least have a 301 error on
I discovered that dropping the .html gets me the right data at:
http://www.iana.org/assignments/enterprise-numbers
Yes: that's the form that IANA would like you to use. They changed
their registries from HTML to XML, and the URLs changed.
That's true, but cool URIs don't change:
Unfortunately 87...@ietf.org --the announce version of the
list-- is where the really important things, like schedule
changes, show up. And, at least as far as I can tell, there is
no way for a non-registrant to get on that list.
Has anyone tried to subscribe on the listinfo page?:
Has anyone tried to subscribe on the listinfo page?:
https://www.ietf.org/mailman/listinfo/87all
I'm sorry to be difficult about this, but the point I was trying
to make was about access by relatively remote relative
newcomers. For them, at least, the question is not does the
listinfo page
Registration for IETF87 in Berlin has been suspended to consider the impact
of a change in the VAT rules on Registration Fees. We expect registration
to open as soon as this matter has been clarified.
I don't understand what the effect of VAT rules is on money collected
in the U.S. in U.S.
you're not the first person to be confused by that construct. i will change
instances of
MUST ONLY to is allowed only if (or similar) and remove the definition
for MUST
ONLY from Section 1.2.
I think this is an excellent idea. RFC 6919 aside (ahem), it's rarely
a good idea to try to
I believe that it would be wise to discourage
RECOMMENDED and NOT RECOMMENDED as synonyms for SHOULD and
SHOULD NOT unless they are clearly necessary to avoid awkward
sentences and the non-A/S intent is completely clear.
A fine suggestion, with which I agree.
Barry
-- Why does this need to be published as an IETF stream RFC? If I
understand correctly, this documents an existing protocol as implemented by
commercial products. I agree with Martin's comment that there is value in
publishing this sort of thing, but I applaud the Adobe and the author for
Without agreeing with or disagreeing with Pete, I'll point out that Pete
was talking about IETF last call. It's perfectly reasonable for a WG
participant who has been actively involved to say, This one is ready.
Ship it, and Pete isn't saying otherwise. In that case there is context
that helps.
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.
DKIM does not, in its current form, attach a validated
Of course it is incorrect for a DKIM signature to be valid when a message
has multiple From header fields. DKIM requires AT LEAST the From header
field to be the minimal portion of the message signed. Every other part of
the message is optional.
In retrospect, I think that requirement was
Just on the writeup tooling question:
p.s. I've tried reading your shepherd writeup now in three
different browsers. It appears to be formatted for extremely
long (paragraph-length) lines, with no provision for automatic
wrapping to fit the page frame. That means that trying to read
and
Putting arbitrary time limits on will hurry things up but it will not
produce higher quality results.
Ok, so do you agree, that if who holds the work, at least should tell
us HOW long he is holding or what is the time PLAN. Do you think
working without plan is efficient and gives good
I would like to suggest that the IESG Review be done in public on the WG
mailing list.I've been a WG co-chair for just over a year now, and
I'm truly astounded by what happens behind the scenes.
It's not the substance, it's the quantity, and the lack of WG view of
it. I think that this
Mike:
Actually, I don't think this is even a mostly correct statement -
that AD select chairs.
Dave:
It is a long-standing, simple, objective, unvarying management fact of
IETF procedure: ADs hire and fire wg chairs.
Mike:
The AD's do have the final say. No question. But select implies
This dude's ready to ship. Thanks for addressing my earlier comments.
Barry
On Friday, April 12, 2013, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Improving Awareness of Running Code: the Implementation Status
we have just published a new revision of this draft, defining a new,
optional Implementation Status section to be included in Internet Drafts:
http://tools.ietf.org/html/draft-sheffer-running-code-03
It does look mostly ready, though I think the primary addition in -03,
the recommended
Yes, we could do what you suggest, but as you found, it requires a kind of
meta-note to the RFC Editor that starts to get messy and confusing.
I don't know: I don't think the meta-note is a problem. Perhaps you
might pass it by Sandy and see if she thinks it's reasonable and
understandable.
Obviously not part of the basic note-taking effort, but I suggest that
IETF management groups explicitly consider the task of augmenting the notes
with published action items they are taking from the sessions.
Along that line, I'll note the notes from the App Area chairs meeting,
which we've
http://www.ietf.org/proceedings/86/minutes/minutes-86-iesg-opsplenary
Please review and comment.
-
Lorenzo Colitti was wondering what problem we are trying to solve: He
looked at the IESG and they all look the same as the people in the
audience. Is the
Agree with what John, Brian, and others have said. FWIW, at times -
particularly
with documents having some controversy - the ADs are left wondering what the
silent majority is thinking. So in some cases the private messages to the AD
in
question or to the IESG are helpful. And while +1 is
, happy with how you spell my name. But I'll get over it.
Barry LeiBa
SM,
(it is generally appreciated in the IETF to use real first and last name).
Hi, Ulrich.
This is actually a very cultural issue. I'll point out that in U.S.
culture it's common for people named William to go by Bill, or for people
to regularly use nicknames such as Bud or Woody. Do we call
A couple of points here:
In practice, that depends on the judgment the document author; does
the document author feel that you have made a significant
contribution to the document?
I agree that it is responsibility of owners or authors. In IETF the
I-D may be a WG I-D so the group work
Thank you very much for your review and detailed comments/suggestions, and
thanks for your discussion.
I uploaded the new version that addressed all your comments, as well as
Dan's Gen-ART review comments, and acknowledged your help.
Thanks for the reply, Luyuan. I'm happy with all the
The question is what happens when the SQL file itself carries no
charset information, such as when using mysql-dump with the
--skip-set-charset option. According to MYSQL, UTF-8 would be used
in v5.1+ and ASCII in versions prior to that. Perhaps, we should leave
charset as an optional
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'MPLS-TP Security Framework'
draft-ietf-mpls-tp-security-framework-07.txt as Informational RFC
Some Last Call comments in advance of IESG Evaluation:
-- Abstract --
The IESG has received a request from the Protocol to Access WS database
WG (paws) to consider the following document:
- 'Protocol to Access White Space (PAWS) Database: Use Cases and
Requirements'
draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt as Informational
RFC
Some Last Call
The IESG has received a request from the Protocol to Access WS database
WG (paws) to consider the following document:
- 'Protocol to Access White Space (PAWS) Database: Use Cases and
Requirements'
draft-ietf-paws-problem-stmt-usecases-rqmts-12.txt as Informational
RFC
Some Last Call
We are a diverse community. Absent very, very strong consensus that a
problem is serious enough to warrant a change, the community is not likely
to line up automatically behind a proposal. We will always have some people
who prefer no change and some who offer their different, favorite
IETF participants are unwilling or unable to
consider 3933 experiments. My second reaction was: what if draft-farrell-ft
was an IESG statement? Would the same outcome be reached?
When Stephen proposed his draft to the IESG, I counter-proposed an
IESG Statement that would essentially say that
I want to address one point that SM made:
Additionally, the experiment will only require issues raised
during these three stages to be addressed if they meet the
IESG's Discuss criteria.
Does this mean that a document does not have to represent consensus?
This bothered me too: by
This was discussed in the Working Group, but it wasn't felt that the added
complexity was worth it; there's a strong feeling that this spec should be as
simple as possible.
Might I suggest, however, using -1 instead of - to refer to the last item
in an
array, as this provides two benefits:
Anyone have any comments on what I suggested below?
Barry
On Tue, Dec 11, 2012 at 11:25 PM, Barry Leiba barryle...@computer.org wrote:
Personally -- to me, it seems like you're getting hung up on the word add.
...
add means what the format definition says it means, because otherwise
we have
Abstract
JSON Patch defines the media type application/json-patch, a JSON
document structure for expressing a sequence of operations to apply
to a JSON document, suitable for use with the HTTP PATCH method.
...
http://datatracker.ietf.org/doc/draft-ietf-appsawg-json-patch/
I've
add has the semantics of make the value *this*.
Yeh, I guess the problem I have with that is that that's not the
semantics most of us attach to the concept of add a thing to a set.
And it bothers me that add to an object and add to an array have
different semantics.
That difference is
So, do you have a suggestion?
I do, and it's buried in there:
Case 1 just seems wrong. The add in 1a should be an error, and then
life would make sense.
Turning that into a text suggestion, it would be this (which
represents a change to the protocol, so the working group would have
to
Personally -- to me, it seems like you're getting hung up on the word add.
...
add means what the format definition says it means, because otherwise
we have to rationalise all of the different systems people might use it with
to make sense.
OK, I'll buy that. Then let's take a different
i think we're ratholing here. the point i get is that, if there is open
source code that suppliments the drafts sufficiently to lend confidence
in the implementability and implementation, then progress might be
accelerated.
But the point of running code in our nice, catchy slogan, is that
But this doesn't do that for IETF LC at all! Everyone
not involved in the WG gets just the same notice as now.
This is true.
What I hope is different is that drafts taking this optional
approach are higher quality, being based on running code.
This is a stretch, and that *unprovable*
Running code, when it's an organic part of the document development,
is undoubtedly a good thing -- it doesn't make everything right, but,
yes, it does do *some* spec validation and probably does help spec
quality.
Fully agree. And this kind of experiment may encourage that
good thing some
Elwyn says...
However, I don't think that a short last call cycle need necessarily
compromise cross-area review. There has always been the possibility for
authors or wg chairs to request a early gen-art review with a view to
checking out whether something is in good shape cross-area and for
Do you really think it's likely that a chair who's trying to
fast-track a document will likely go out asking for early GenART,
SecDir, AppDir, and OpsDir reviews?
A few do already. But seriously, if the wg chair(s) actually have an
interest in the technology and feel there is a valid reason
[1] http://tools.ietf.org/id/draft-farrell-ft
I have a serious problem with the premise of the proposal.
The short version is that if the process we're talking about is
useful, we should not shortcut it as a reward for anything. And if
it's not useful, we should not be doing it, regardless of
I have a serious problem with the premise of the proposal.
The short version is that if the process we're talking about is
useful, we should not shortcut it as a reward for anything.
I disagree. The process is neither useful nor just a PITA. Its both,
depending on what document and point of
I, and I believe lots of us, do want to encourage running code
more than now. This is one attempt to help with that. Why not
try it and see?
Because as a reward for claiming to have running code, I think it's
a terrible idea. As a way of handling the process for documents where
it makes
There is no formal process that involves adopting anything.
If you mean that we haven't documented a/the formal process, you are
correct. If you mean that the IETF has not moved towards rather formal
steps for explicitly adopting working group drafts, I disagree.
...
Today, there is
On Wed, Nov 28, 2012 at 5:56 PM, Pete Resnick presn...@qti.qualcomm.com wrote:
...
chair needs to (with the help of minutes takers and other participants) post
detailed notes of the discussion to the list and ask for objections. That
serves two functions: (a) It makes a record of work that was
If we actively *don't*
want an IETF-wide procedure here, we can even document that the process
for WG adoption of drafts is WG-specific and could document those specifics
in a WG policies wiki document maintained by the chairs.
I believe that one is the case, though others can weigh in with
we do not have adequate guidance for either WG chairs or participants on
when it is generally appropriate to adopt a draft as a WG document.
...
It seems to me that these variants are dependent on the people in the WG,
the workload of the group, the chairs, past precedent, AD preferences, etc.
On Tue, Nov 27, 2012 at 12:25 PM, Dale R. Worley wor...@ariadne.com wrote:
That attendance showed me that most of the IETF meeting was a
waste of time, that it was e-mail that was the main vehicle for work,
and I think that the IETF web site has it about right when it says
This is all true.
1 - 100 of 262 matches
Mail list logo
