[Ietf-dkim] Re: DKIM with body length

sops to enable/disable. But I agree it was not an answer to restoring original verification and can be a loop hole. All the best, Hector Santos ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org

[Ietf-dkim] Re: [Dcrup] [standards] [Editorial Errata Reported] RFC8463 (7930)

a high overhead of two signatures, The ignorant RFC8463 system (the majority) is not ready for this. One SHA256 signature is sufficient, I would not Ed25519 provides smaller keys that are more supportive by DNS Zone Managers. All the best, Hector Santos ___

Re: [Ietf-dkim] Testing a DKIM implementation

would be appreciated. Thanks in advance for any assistance. There are number of verifiers.   One such address is dkim-autoresp...@isdg.net will verify your DKIM signatures and apply DKIM Policies such as ADSP (deprecated), DMARC and report the result. -- Hector Santos, https://santronics.com

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

is the best. Go with your GUTS. Always works in the long term. All the best, Hector Santos > On Feb 5, 2024, at 8:50 PM, Dave Crocker wrote: > Om > On 2/5/2024 2:08 PM, Jim Fenton wrote: >> On 5 Feb 2024, at 14:02, Dave Crocker wrote: >>> On 2/5/2024 1:56 PM, Jim Fenton wrote

Re: [Ietf-dkim] Security indicators, not Headers that should not be automatically oversigned

xpect-less-email-marketing-dd124c19 Google and Yahoo Are Cracking Down on Inbox Spam. Don’t Expect Less Email Marketing. wsj.com All the best, Hector Santos > On Feb 6, 2024, at 1:43 PM, John Levine wrote: > > It appears that Jim Fenton said: >> On 5 Feb 2024, at 14:02

Re: [Ietf-dkim] Question about lone CR / LF

recall an old corporate project SE coding guideline: usage of a GOTO LABEL was allowed if the LABEL is within the reader's page view, i.e. 25 lines (using 25x80 terminal standards). -- Hector Santos, https://santronics.com https://winserver.com

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

> On Feb 3, 2024, at 8:23 AM, Alessandro Vesely wrote: > > On Fri 02/Feb/2024 14:34:22 +0100 Hector Santos wrote: >> Of course, the MUA is another issue. What read order should be expected for >> Oversign headers? Each MUA can be different although I would think

Re: [Ietf-dkim] Question about lone CR / LF

omehow. CRLF ends a line, anything before that is part of the line, and WSP is just a space or a tab.  Past that, garbage in, garbage out. +1.   5322/5321 EOL is CRLF -- Hector Santos, https://santronics.com https://winserver.com ___ Ietf-dki

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

On 2/1/2024 6:38 AM, Alessandro Vesely wrote: On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote: If I add this feature to wcDKIM, it can be introduced as: [X] Enable DKIM Replay Protection That'd be deceptive, as DKIM replay in Dave's sense won't be blocked, while there can be other

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

ed for certain DKIM signing routes. What is most important is what it is suppose to help address - DKIM Replay hacks. All the best, Hector Santos ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DMARC's auth=dkim+spf tag

> On Jul 3, 2023, at 10:06 AM, Barry Leiba wrote: > >> 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. >

Re: [Ietf-dkim] On the current state of DKIM and the replay problem

> On Mar 28, 2023, at 1:36 PM, Michael Thomas wrote: > > Since the chair is threatening to ban me, I decided to write up my view of > things in a longer form. > > https://rip-van-webble.blogspot.com/2023/03/on-dmarc-arc-and-dkim-replays.html > > This has some technical aspects and meta

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

> On Mar 26, 2023, at 1:11 PM, Michael Thomas wrote: > My contention is that documenting what has failed in the problem statement > saves time eventually in the solution space as you can reference it when > somebody brings it up as to why it doesn't work. It would be just a cut and > paste

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

> On Mar 26, 2023, at 6:13 AM, Murray S. Kucherawy wrote: > > On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas > wrote: >> On 3/24/23 6:19 PM, Barry Leiba wrote: >> > I don't agree with the premise. I think what was tried and didn't >> > work should be documented in the

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

+1. ARC is not a solution, but it is a good part of the problem. It’s not hard to see how our fall back to defocusing, the de-emphasis of the DKIM Policy Model in lieu of Reputation Modeling creating this issue. Every issue we have today is nearly 100% because of the lob-sided efforts to

Re: [Ietf-dkim] Welcome to the rechartered working group

model do not have this problem. But, via POLICY if the domain using reputation wishes a verifier to put more restrictions on a received signed domain, i.e. enforce `x=` expiration tag, I am all for it. Thanks Hector Santos CEO/CTO Santronics Software, Inc. > On Mar 7, 2023, at 7:09

Re: [Ietf-dkim] DKIM update - header tag

-1. The v= tag description is accurate. There is no current DKIM design expectation for any other string value. The current spec is `v=DKIM1`. Any software writing `v=DKIM1.0` is technically “broken” and should not be encourage to exist or perpetuate. IOW, software should not process the

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

> On Nov 20, 2022, at 6:01 PM, Murray S. Kucherawy wrote: > > > > On Sun, Nov 20, 2022, 11:08 Dave Crocker > wrote: >> Seriously. DKIM is intended as a transit-time mechanism. When delivery >> occurs, transit is done. So DKIM has done its job and can (safely?)

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

> On Nov 11, 2022, at 11:46 AM, Barry Leiba wrote: > > Indeed... > The issue here is this: > > 1. I get a (free) account on free-email.com. Ok > 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?

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

We need to update DMARC or any other DKIM Policy proposal to seriously consider 3rd party signature Authorization methods. We have wasted so much time avoiding it. Sure, it may not apply to all, but neither does DMARC and the push to embed a "half-baked" DMARC into our mail network has

Re: [Ietf-dkim] Thinking About DKIM and Surveillance

Thanks jon for loading my plate! :) I plan to finish reading the paper later today. Need to recall past discussions and how the paper relates. But with initial reading, it made me recall the proposal I wrote in 2006: https://tools.ietf.org/html/draft-santos-dkim-rcvd-00 related to

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

On 10/24/2018 4:53 PM, Дилян Палаузов wrote: PS: Please describe the handling, of the above message by the MLM, if the original message contained in addition DKIM-Signature: v=1; d=isdg.net; r=y; … ... or something different than r=y, that permits finding faulty DKIM implementations. Our

Re: [Ietf-dkim] [dmarc-ietf] DKIM-Signature: r=y and MLM

On 10/24/2018 5:18 PM, Kurt Andersen wrote: On Mon, Oct 15, 2018 at 7:30 AM Hector Santos What it should do is: 1) It should use a 1st party signature using d=dmarc.ietf.org to match the new author domain dmarc.ietf.org 2) It should has hash bind the X

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

e: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1537415189; bh=TJWGUVdPL8OTY+HJnUzpBRd52OaKfWjFqS68Cby0s/M=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From; b=. X-Original-From: Hector

[Ietf-dkim] Test Msg to ietf-dk...@ietf.org

Ignore -- HLS ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: Terms and Conditions May Apply

Youtube URL. http://www.youtube.com/watch?v=2UWRuIXXzYs On 10/13/2013 3:16 PM, Brian E Carpenter wrote: I know we don't normally do movie plugs on this list, but anyone who's planning to attend the technical plenary in Vancouver could do worse than watch Terms and Conditions May Apply. It

Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard

On 10/2/2013 5:04 PM, Murray S. Kucherawy wrote: On Wed, Oct 2, 2013 at 7:41 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document

Re: Last Call: Change the status of ADSP (RFC 5617) to Historic

On 10/3/2013 11:11 AM, Scott Kitterman wrote: Alessandro Vesely ves...@tana.it wrote: On Wed 02/Oct/2013 16:52:38 +0200 John Levine wrote: The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The

Re: Last Call: Change the status of ADSP (RFC 5617) to Historic

I agree, the problem IMV is the illusion that DMARC will replace it has some domains has already done by switching their strong exclusive mail operations declaration from _ADSP TXT record policy to a _DMARC policy. Like FACEBOOK.COM. The REJECTING/DISCARD concept is still the same and active,

How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead

On 10/3/2013 1:51 PM, Douglas Otis wrote: Dear Hector, Indeed, more should be said about underlying reasons. The reason for abandoning ADSP is for the same reason few providers reject messages not authorized by SPF records ending in -all (FAIL). Mailing-List software existed long before

Re: How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead

to arise? If its supported (which seems to far to be getting a higher mindset), then why can't ADSP be deprecated at that point, with DMARC making ADSP obsolete? -- HLS On 10/3/2013 4:37 PM, Barry Leiba wrote: To both Doug and Hector, and others who want to drift in this direction: As I've said

Re: How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead

On 10/3/2013 6:25 PM, Douglas Otis wrote: On Oct 3, 2013, at 1:37 PM, Barry Leiba barryle...@computer.org wrote: 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

Re: ORCID - unique identifiers for contributors

+1 Thank you for your input. Seems to me to be a conflict of interest issue. I support the basic concept but why not use a IETF registry instead? Solves several of the conflict of interest concerns, including about 3rd party entities disappearing, losing support, etc. -- HLS On 9/17/2013

Re: ORCID - unique identifiers for contributors

On 9/17/2013 1:55 PM, Michael Tuexen wrote: On Sep 17, 2013, at 7:48 PM, Scott Brim scott.b...@gmail.com wrote: On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen michael.tue...@lurchi.franken.de wrote: I was always wondering the authors can't get an @ietf.org address, which is listed in the

Re: ORCID - unique identifiers for contributors

On 9/17/2013 3:24 PM, Melinda Shore wrote: On 9/17/13 11:14 AM, Michael Tuexen wrote: For example http://www.ietf.org/rfc/rfc3237.txt has 7 authors. I know that at least 4 affiliations have changed and at least you can't reach me anymore via the given e-mail address or telephone number. This

Re: ORCID - unique identifiers for contributors

On 9/17/2013 4:52 PM, Yoav Nir wrote: Having an IETF identity is OK if all you ever publish is in the IETF. Some of our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a few publish Academic papers. Using the same identifier for all these places would be useful, and

Re: What real users think [was: Re: pgp signing in van]

On 9/9/2013 4:09 PM, Brian E Carpenter wrote: On 10/09/2013 01:58, Ted Lemon wrote: ... Seriously, this perfectly illustrates the reason why PGP hasn't seen widespread deployment: it doesn't address a use case that anybody understands or cares about, True story: Last Saturday evening I

Re: pgp signing in van

On 9/6/2013 10:35 PM, Melinda Shore wrote: One of the useful things that PKI provides is some agreement, at least, about what we expect from certification authorities and what it means to issue and sign a certificate. That is to say, the semantics are reasonably well sorted-out, which is not

Re: pgp signing in van

On 9/6/2013 11:04 PM, Ted Lemon wrote: On Sep 6, 2013, at 10:35 PM, Melinda Shore melinda.sh...@gmail.com wrote: I actually don't think that pgp is likely to be particularly useful as a serious trust mechanism, mostly because of issues like this. It's not at all clear to me that serious trust

Re: draft-moonesamy-ietf-conduct-3184bis

Along with the other recent drafts for streamlining the RFC process, I get the feeling even this new drafting on conduct is simply going to be a new rubber stamping tool to shut down the process of due diligent engineering discussions, required cross areas reviews, including increasing

Re: Last Call: draft-ietf-repute-query-http-09.txt (A Reputation Query Protocol) to Proposed Standard

John, I don't think it would of been fun designing and testing a text-based hosting protocol manually with your terminal/telecommunication/telnet client New Line Mode (add LF to CR) option disabled or server text responses only issue CR or LF. It would of been very hard or confusing to do

Re: AppsDir review of draft-ietf-repute-model-08

On 8/30/2013 10:46 AM, Tony Hansen wrote: The document describes a model for reputation services, particularly those being produced by the Repute WG. It follows the recommendations of RFc4101 for describing a protocol model, which requires answers to 1) the problem the protocol is trying to

Re: AppsDir review of draft-ietf-repute-model-08

have these general considerations summarized. Thanks On 8/30/2013 3:20 PM, Andrew Sullivan wrote: On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote: For example, DKIM-REPUTE product designers would need to consider SPF reputons product models. Simple text as follows can resolve

Re: AppsDir review of draft-ietf-repute-model-08

On 8/30/2013 4:09 PM, Andrew Sullivan wrote: On Fri, Aug 30, 2013 at 03:39:14PM -0400, Hector Santos wrote: archives of the Repute WG to find or extract these very real and practical integration considerations. The document should have these general considerations summarized. But your

Re: [dnsext] SPF isn't going to change, was Deprecating SPF

Phillip Hallam-Baker wrote: On Fri, Aug 23, 2013 at 3:46 PM, manning bill bmann...@isi.edu wrote: the question is not that nobody checks type 99, the question is is the rate of adoption of type 99 -changing- in relation to type 16? As John pointed out, support for checking

Re: [dnsext] SPF isn't going to change, was Deprecating SPF

Hector Santos wrote: Phillip Hallam-Baker wrote: Putting a statement in an RFC does not mean that the world will automatically advance towards that particular end state. Thats correct. No one is forced to support RFC 4408bis. From my perspective, there are four basic major changes to BIS

SPF PTR Support [was SPF isn't going to change]

Scott Kitterman wrote: Hector Santos hsan...@isdg.net wrote: I should add: 5- Deprecate PTR by removing PTR publishing support We won't advocate this because for our small to mid size market, this is the lowest cost setup for them - using a PTR. For all our domains, we use PTR

Re: SPF PTR Support [was SPF isn't going to change]

Scott Kitterman wrote: PS: I am not trying to change anything about the PTR 4408BIS status. Just pointing out that a change was made that does touch base with operations and thus not supporting (or delaying, forever) this part of 4408BIS is highly possible. You might change what you recommend

Re: [dnsext] full standards, Deprecating SPF

Andras Salamon wrote: On Thu, Aug 22, 2013 at 11:53:29PM -, John Levine wrote: If you think it's important to move it to full standard, why don't you do somthing about it? A quick look suggests that 3597 meets the requirements in sec 2.2 of RFC 6410 I wouldn't think that it'd be hard to

Re: The Last Call social contract (was - Re: Rude responses)

Dave Crocker wrote: On 8/23/2013 11:06 AM, Scott Brim wrote: We don't have to be like the ones we all know who sneer at anyone presuming to get in the way of their code going into production. Since this is such a fundamental point, I'm sending this reply to emphasize: The concern I

Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

Eliot Lear wrote: Patrik, First, I appreciate that you and Dave are bringing data to the table. However, in this case, it is not in dispute that queries are happening. What *is* in dispute is whether there are answers. I must admit I am having a difficult time understanding the logic,

Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

Scott Kitterman wrote: On Wednesday, August 21, 2013 14:44:41 Olafur Gudmundsson wrote: What I want the IESG to add a note to the document is that says something like the following: The retirement of SPF from specification is not to be taken that new RRtypes can not be used by applications, the

Re: [spfbis] SPF TYPE support

On 8/19/2013 7:42 PM, S Moonesamy wrote: At 14:10 19-08-2013, Hector Santos wrote: I'm having a hard time with both sides of the argument, especially the supposed existence of an interop problem which seems to only highlight how to procedurally stump the SPF type advocates with a error

Re: [spfbis] Last Call: draft-ietf-spfbis-4408bis-19.txt (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

On 8/20/2013 1:12 AM, S Moonesamy wrote: There is a message from the Responsible Area Director at http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html which might shine some light about that part of the charter. Both RR Type 16 and RR Type 99 are in use on the Internet. Tony

SPF TYPE support

Hi, I'm having a hard time with both sides of the argument, especially the supposed existence of an interop problem which seems to only highlight how to procedurally stump the SPF type advocates with a error correction standpoint. What is that error by the way? I don't believe there was

Mentoring Electronic Participants [was Invitation to request an IETF mentor]

Overall, I think the IETF has a marketing problem addressing its #1 customer base - electronic participants. I was somewhat hoping to see more done in the mentor area of assisting electronic participants. Of coarse, this sort of electronic mentoring it could include an end goal to get folks

Dotless Domain conflict with user searching and branding [was: IAB Statement on Dotless Domain]

On 7/13/2013 2:20 PM, Yoav Nir wrote: So finding your site is not that difficult for first-timers. But regardless, the people who type in addresses or DNS names in full are rare and far between. Agreed. Just to see again, I tried it on my wife's new computer with Chrome and it showed:

Re: Dotless Domain conflict with user searching and branding [was: IAB Statement on Dotless Domain]

On 7/14/2013 9:53 AM, Yoav Nir wrote: On Jul 14, 2013, at 4:34 PM, Hector Santos hsan...@isdg.net wrote: On 7/13/2013 2:20 PM, Yoav Nir wrote: So finding your site is not that difficult for first-timers. But regardless, the people who type in addresses or DNS names in full are rare

Re: IAB Statement on Dotless Domains

All the discussion details are overwhelming but I do seem to feel there is a marketing and branding problem especially when it comes to searching a domain at the USER DATA ENTRY LEVEL, i.e. slow keyboard input. For example, I own WINSERVER.COM. Try typing WINSERVER in google (for the first

Re: IAB Statement on Dotless Domains

On 7/13/2013 11:27 AM, Noel Chiappa wrote: From: Livingood, Jason jason_living...@cable.comcast.com FWIW, I think for most larger companies with multi-billion dollar revenues streams it is less about the up-front fees to apply operationalize a gTLD than the long term

Re: IETF registration fee?

On 7/10/2013 5:17 PM, Josh Howlett wrote: Day passes have nothing to do with it. I disagree. Day passes encourage the notion that it's normal to parachute into the IETF to attend a single session. I think that the IETF's strength is that we don't totally compartmentalise work items. I am

Re: Regarding call Chinese names

On 7/10/2013 8:04 PM, Hui Deng wrote: Hello all We submitted two drafts to help people here to correctly call chinese people names: http://tools.ietf.org/html/draft-deng-call-chinese-names-00 http://tools.ietf.org/html/draft-zcao-chinese-pronounce-00 Fantastic. Short and sweet!

Part of Improving IETF Electronic Diversity [was: RFC 6234 code]

I believe this is all part of improving the IETF Electronic Diversity picture. Just like we have to deal with greater people personal globalization diversity issues, there is also greater technology and legal diversity issues to deal with. So many tools, so many languages, so many OSes, so

Re: RFC 6234 code

What language, OS? There are plenty of rich hashing/encrypting C/C++ libraries out there. Windows has CAPI, even OPENSSL has these libraries. On 6/27/2013 11:49 AM, Dearlove, Christopher (UK) wrote: RFC 6234 contains, embedded in it, code to implement various functions, including SHA-2.

Re: RFC 6234 code

Ok, other than time, it should be easy to extract, clean up and cross your fingers that it compiles with your favorite C compiler. But I would write to the authors to get the original source. Or google: C source crypto libraries API hashing functions among the first hit:

Re: SHOULD and RECOMMENDED

I want to know more what it translates to as a technical specification for CODING. To me, it means this: o Authorization Lift Time [X] Send Notification Time to send: __4__ mins (default) The problem as I experienced thus far is whether one MUST IMPLEMENT this protocol

Re: SHOULD and RECOMMENDED

Sounds like an never ending loop. 2119 is an RFC too and thus written in RFCish as well. To me, it only matters in terms of implementation - should we waste time and money on implementing a SHOULD/RECOMMENDED feature? Is it required to be coded? Can it be delayed, for version 2.0? Is it

Re: SHOULD and RECOMMENDED

that last that long. On Jun 25, 2013, at 8:13 PM, Hector Santos hsan...@isdg.net wrote: I want to know more what it translates to as a technical specification for CODING. To me, it means this: o Authorization Lift Time [X] Send Notification Time to send: __4__ mins (default

Re: SHOULD and RECOMMENDED

On 6/24/2013 8:39 AM, John C Klensin wrote: --On Monday, June 24, 2013 07:52 -0400 Phillip Hallam-Baker hal...@gmail.com wrote: They are not synonyms Lets go back to 1980: Implementations SHOULD support DES vs RECOMMENDED encryption algorithms: DES, IDEA Actually, that is the point. The

Re: SHOULD and RECOMMENDED

Hi, I think there are far too many debates on RFC2119 semantics and I think it can be reduced by focusing on better technical protocol writing skills. A simple recommendation to always include (if possible) a Minimum Requirements table or section can go a long way in removing ambiguity.

Re: Weekly posting summary for ietf@ietf.org

These are valid points. For a long time, I used a public forum support reporter for our support process which categorized daily and hourly messaging patterns, hottest threads and topics and reply efficiency concepts. Basically to see how many messages were replied to in general and how many

Re: IETF Diversity

the Diversity Design Team. Thank You Sincerely, Hector Santos, CTO Santronics Software, Inc. On 6/19/2013 11:15 AM, Dave Crocker wrote: 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

DKIM promotion to Internet Standard status

(RFC5585) informational publications. Perhaps some update in the future can correct this design and market inconsistency and explicitly provide knowledge of the alternative frameworks available for DKIM. -- Hector Santos, CTO Santronics Software, Inc.

Re: A note about draft-ietf-spfbis-4408bis

On 5/5/2013 11:58 AM, S Moonesamy wrote: Hi Mark, At 15:57 04-05-2013, Mark Andrews wrote: The publisher can choose to interoperate with everyone by publishing both. The client side can choose to interoperate with everyone by looking for both. Both side can choose their level of

Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]

, in their various IETF protocol interest areas. The structure of this questionnaire will be important to be successful and beneficial. Sincerely, Hector Santos On 5/3/2013 10:32 AM, Thomas Narten wrote: Adrian Farrel adr...@olddog.co.uk writes: Well said, Thomas. Two concrete suggestions: 1) have

Balancing the Process (Was: Obsoleting SPF RRTYPE)

apology. Sincerely, Hector Santos On 5/1/2013 9:44 AM, Pete Resnick wrote: On 4/30/13 7:45 PM, Sam Hartman wrote: So my personal opinion is that this is a valid discussion to be having even if we're having it again in IETF LC. Folks, This document is *not* in IETF LC. A particular WG member, who

Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

The problem I have is not so much with the decision to deprecate SPF rrtype, it will remove this particular SPF protocol dual SPF/TXT call overhead in the network, but more so about what it says for future applications. There will no incentive to design DNS applications with specific types,

Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

If anyone wishes to see one aspect of what is wrong with IETF Diversity, then see whats going on in SPF BIS WG where a key IETF cog essentially attempts to shutdown discussions and communications, attacks posters which by my estimate were making progress. Progress is a status quo - DON'T

Re: Meritocracy, diversity, and leaning on the people you know

On 4/19/2013 2:13 PM, Ted Hardie wrote: ... There are other methods that may well be better than the two Suresh and I discussed, but I put these forward as a potentially concrete step that may help those struggling with this to understand that the end result of this need not be quotas.

Re: Sufficient email authentication requirements for IPv6

I don't have the same overall feeling that its less reliable. I believe it is 100% reliable when it comes to the good communications, the serious stuff, the work, business communications. Those get through and more importantly, above all, when there is a problem, good people complain, any

Proposed solution for DPEP (Diversity Problem Entry Point) - IETF April 1 jokes.

This is one of those DPEP (Diversity Problem Entry Point) arising from globalization, April 1 HRC (Humor Recognition Culture) differences, IETF stalization and the growth of I-D submissions. I suggest there is a direct correlation among these factors with the end goal efficacy of the

Re: Comments for Humorous RFCs or uncategorised RFCs or dated April the first

Hi Abdusalam, You should consider all APRIL 1 published I-D as SPAM and the electronic mail follow ups generated in the IETF list as more wasted bandwidth, time and spam. We have too much time in our hands, boredom for many, and even more wasted time if we spend time reading it - so in

Re: Comments for Humorous RFCs or uncategorised RFCs or dated April the first

On 4/6/2013 11:57 AM, Scott Brim wrote: On 04/06/13 11:52, Hector Santos allegedly wrote: Hi Abdusalam, You should consider all APRIL 1 published I-D as SPAM and the electronic mail follow ups generated in the IETF list as more wasted bandwidth, time and spam. We have too much time in our

Re: Sufficient email authentication requirements for IPv6

it should also offer its own membership and provide IETF.ORG email accounts as well. :) -- Hector Santos, CTO/CEO Santronics Software, Inc. http://www.santronics.com - Original Message - From: Ted Lemon ted.le...@nominum.com To: Dean Willis dean.wil...@softarmor.com Cc: ietf@ietf.org

Re: Sufficient email authentication requirements for IPv6

Good points Dave. However, I would suggest that having tighter controls on the transport practice, e.g.; SMTP handshaking compliancy, following and honoring exclusive domain published policies, does help minimize support cost. -- HLS On 3/30/2013 7:46 PM, Dave Crocker wrote: On 3/30/2013

Re: Sufficient email authentication requirements for IPv6

Hi Doug, This sounds urgent. I am not seeing this urgency, but maybe we just have it under control. Another side question Doug, is this an application-level based filtering? Can one be authenticated lets say for SMTP but not WEB? Is the filtering applied across all protocols? Is it the IP

Re: Sufficient email authentication requirements for IPv6

Hi Doug, On 3/28/2013 2:13 PM, Douglas Otis wrote: Dear IETF, In response to various strategies to reject IPv6 email lacking either DKIM or SPF, the non-negotiated approach suggests far greater review is needed. Whats the difference with IPv6 connections? Should it matter? Does it matter?

Re: It's a personal statement (Re: On the tradition of I-D Acknowledgements sections)

+1. My view as well. I will add I think it generally means there will a problem in a WG if an AUTHOR has issues with its WG participants, enough to a point he/she begins to ignore them - despite all the input they provided, included the indirect ones that help mold others to think and chime

Re: On the tradition of I-D Acknowledgements sections

On 3/25/2013 12:17 PM, Scott Brim wrote: On 03/25/13 11:54, John C Klensin john-i...@jck.com allegedly wrote: So perhaps a little more guidance to authors and WGs about acknowledgments would be in order. or a statement that acknowledgments is not a required section and not subject to IETF

Acknowledgements vs new Contributions section.

Interesting proposal. I suggest perhaps a different Contributions section related to IPR considerations, including also good for open source/public domain information. For me, this would be a quick/goto read item after reading a new I-D abstract of interest. Good idea. -- HLS On

Re: Less Corporate Diversity

On 3/20/2013 3:18 PM, Eric Burger wrote: How much is the concentration of corporate participation in the IETF a result of market forces, like consolidation and bankruptcy, as opposed to nefarious forces, like a company hiring all of the I* leadership? We have mechanisms to deal with the

Re: Mentoring

Anything along the lines of mentoring the virtual world of IETF participants? :) Mr. Klensin, if it wasn't for you, I would of probably lost interest in the IETF long ago. You have reached out and assisted in more ways you should be made aware it was very much needed and welcomed. Thank you.

Re: Diversity of IETF Leadership

Speaking as a successful by-product of the american Affirmative Action and Equal Opportunities programs of the 70s and early 80s, I would suggest the IETF needs to work two small baby steps: - Improving its Marketing, - What is its products? - What will attract all/any groups?

Re: Diversity of IETF Leadership

As a minority raised thru the corporate rank, as stated below I think it is offensive too and unfair to historical facts. But overall, I think it is just the wrong choice of words. All it could suggest is that there are more different views and experiences in the synergistic effect of final

Re: Diversity of IETF Leadership

+1 There lies the fine line of conflict of interest that I believe the IETF has done a tremendous job in keeping in control with diverse disciplines and philosophies well considered. The RFC format by definition, its style, the open WGs, is all geared towards diverse audiences. On

Re: Appointment of a Transport Area Director

One item to consider is to lower the work load of the AD, in particular in reviewing docs towards of the end of projects. Issues and dilemmas are piled on. I think one approach to lowering appeals, for example, is to address unresolved delicate WG issues much faster, in particular the

Re: IETF Challenges

should be reviewed. I believe Pete Resnick is touching base with how Rough Consensus is used in his I-D. That is it for now, if not done. Thank you for the opportunity to provide my viewpoints on IETF matters and its future. -- Hector Santos, CTO/CEO Santronics Software, Inc. On 3/2/2013 4

Re: IETF chair's blog

Its not really orthogonal if you are seeking a feature list. Will it be out-sourced, open source or in-house developed? That's the dilemma with most older establishments that do not wish to provide less support for its long time customers but need to also migrate and provide other methods as

Re: [IAB] Call for Comment: 'Privacy Considerations for Internet Protocols'

of the tenets of the document, in my view. Recognized ownership has a very vital effect on what a protocol may|can|should offer or not offer as to not open Pandora's box. -- HLS On 2/24/2013 2:23 PM, Hannes Tschofenig wrote: Hi Hector, On Feb 23, 2013, at 9:51 PM, Hector Santos wrote: Hi

Re: [IAB] Call for Comment: 'Privacy Considerations for Internet Protocols'

Cooper wrote: Hi Hector, Just to clarify, do you mean ownership of personal data? Or something else? Thanks, Alissa On Feb 25, 2013, at 2:55 PM, Hector Santos wrote: Hi, Related to your question, if it wasn't done already, I think there is one item to consider or define - $Owner(s

  1   2   3   >