Re: WG Review: Domain Keys Identified Mail (dkim)

We have had three proposal for some text on changes to prior work, the current proposed charter, the text from the XMPP charter, and the text Keith provided below. The question that I think IESG should be asking themselves is how is this similar and/or different from other groups the have charter

Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

Barry, I understand the principle you're fighting for, Dave. And I think it will come up again, which is why you're fighting it. ack. I think it will be better to fight it later, if necessary. It always seems that way, at the time. d/ -- Dave Crocker Brandenburg InternetWorking +

Re: WG Review: Domain Keys Identified Mail (dkim)

Tony Hansen wrote: > I would be happy with the text that was used in the xmpp > charter +1 And is no strong objection, or is it ? Bye, Frank ___ Ietf mailing list Ietf@

Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

Dave Crocker wrote: and now the chairs quickly concede the change, even before getting support from the rest of the group. 'scuse me; it seemed to me that Tony Hansen and Jim Fenton counted as some of the rest of the group. It also seems to me that no one has made me the boss, so what I sugges

Re: RFCyyyy on Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation HDSL and Single-Pair High-Speed Digital Subscri

On Wed, 2005-12-21 at 09:51 -0800, Bob Braden wrote: > *> > A new Request for Comments is now available in online RFC libraries. > *> ... > *> > BCP NNN > *> > RFC > *> > > *> > Title: Definitions of Managed Objects for > *> > Hig

Re: WG Review: Domain Keys Identified Mail (dkim)

Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. I agre

Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim)

Fellow DKIMers, Barry Leiba wrote: > I suggest that the IESG replace that paragraph in the proposed DKIM > charter with the paragraph above, and that we move on from this topic > to any others that need to be dealt with. Well, I guess no one else is concerned about the sequence that has just t

Re: WG Review: Domain Keys Identified Mail (dkim)

Ted Hardie wrote: I would be happy with the text that was used in the xmpp charter: Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's

Re: WG Review: Domain Keys Identified Mail (dkim)

Ted Hardie wrote: At 9:07 AM -0500 12/21/05, Tony Hansen wrote: I would be happy with the text that was used in the xmpp charter: Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines t

Re: WG Review: Domain Keys Identified Mail (dkim)

> It's a significant precedent that IETF charters have included language > of this sort when there has been a deployed base at the time the WG is > chartered. But can someone explain what's different in this wording > that warrants departing from the version on which there seems to be > rough cons

Re: WG Review: Domain Keys Identified Mail (dkim)

> Personally, I think each on-the-face-of-it-reasonable suggested > improvement has to be considered, but the more time passes and > the more the specifications are mature, the higher the bar is > raised. Since these specs. have been around a while and have > been implemented it seems reasonable to

Re: WG Review: Domain Keys Identified Mail (dkim)

> It's also a principle of good engineering that you don't make unnecessary > changes to deployed code. I think that's an overgeneralization. There's neither a wide enough deployment of DKIM, nor sufficient evidence of DKIM's suitability for the diverse user community, for the current DKIM spec

Re: WG Review: Domain Keys Identified Mail (dkim)

> > >Since experimentation resulted in significant Internet deployment of these > > >specifications, the DKIM working group will make every reasonable attempt > > >to > > >keep changes compatible with what is deployed, making incompatible changes > > >only > > >when they are necessary for the suc

Re: WG Review: Domain Keys Identified Mail (dkim)

> >> the specification" is way too high for that. > > Too high for what? Instead of arguing principles Eric, needs to > indicate what specific technical work that is excluded by this language > is actually essential to the goals of DKIM. Dave, You keep making statements like that without a sh

Re: WG Review: Domain Keys Identified Mail (dkim)

> > As I argued on the DKIM working group list, I think this text is a bad > > idea. Part of IETF having change control of a specification is having > > the ability to make changes, and the bar of "necessary to the success of > > the specification" is way too high for that. Note that I'm not > > su

Re: WG Review: Domain Keys Identified Mail (dkim)

> 1. As interesting as such a discussion might be, it has no effect on the > technical work. The choices made were the choices made. The goal is to > make as few new ones as we can, not to spent time reviewing past > choices. That is almost never an appropriate goal for an IETF working group crea

Re: WG Review: Domain Keys Identified Mail (dkim)

At 9:07 AM -0500 12/21/05, Tony Hansen wrote: >I would be happy with the text that was used in the xmpp charter: > > Although not encouraged, non-backwards-compatible changes to the > basis specifications will be acceptable if the working group > determines that the changes are re

Re: RFCyyyy on Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation HDSL and Single-Pair High-Speed Digital Subscri

*> > A new Request for Comments is now available in online RFC libraries. *> ... *> > BCP NNN *> > RFC *> > *> > Title: Definitions of Managed Objects for *> > High Bit-Rate DSL - 2nd generation *> > HDSL a

Re: WG Review: Domain Keys Identified Mail (dkim)

On Wed, 21 Dec 2005, Harald Tveit Alvestrand wrote: --On onsdag, desember 21, 2005 05:36:08 -0800 "william(at)elan.net" <[EMAIL PROTECTED]> wrote: I also think that if allowed to be presented alternatives to putting public keys in DNS, those would technically be found superior and less damag

Re: WG Review: Domain Keys Identified Mail (dkim)

--On onsdag, desember 21, 2005 05:36:08 -0800 "william(at)elan.net" <[EMAIL PROTECTED]> wrote: I also think that if allowed to be presented alternatives to putting public keys in DNS, those would technically be found superior and less damaging to internet. Other aspects of proposal also had

Re: WG Review: Domain Keys Identified Mail (dkim)

John, As I am sure you will recall, I've been very concerned since you first proposed this about the notion of a WG that starts on the assumption that almost all of the work is done and proven in the field and that the IETF's role is limited to fine-tuning that really does not change anything...

Re: WG Review: Domain Keys Identified Mail (dkim)

I would be happy with the text that was used in the xmpp charter: Although not encouraged, non-backwards-compatible changes to the basis specifications will be acceptable if the working group determines that the changes are required to meet the group's technical obj

Re: WG Review: Domain Keys Identified Mail (dkim)

On Wed, 21 Dec 2005, John C Klensin wrote: (i) you are obligated to demonstrate that sufficient production-level deployment actually exists to justify such a request and that it has been successful in There is no wide deployment of DKIM. What is there are several test

FW: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-03.txt

FYI New inputs welcome ! Regards, Jordi -- Mensaje reenviado De: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Responder a: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Fecha: Tue, 20 Dec 2005 15:50:02 -0500 Para: Asunto: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-03.txt A New Int

Re: WG Review: Domain Keys Identified Mail (dkim)

Eric Rescorla wrote: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the success of t

Re: WG Review: Domain Keys Identified Mail (dkim)

> the IETF has done work on message signing before, and some of those earlier efforts (like CMS in detached signature mode) look enough like pieces of DKIM that there is question of whether DKIM not using them indicates that they do not work, that this message signing is a better point solution,

Re: WG Review: Domain Keys Identified Mail (dkim)

--On Tuesday, 20 December, 2005 18:50 -0800 Dave Crocker <[EMAIL PROTECTED]> wrote: >>> Having this point in this charter mostly serves as a >>> statement of mistrust, rather than providing any useful >>> education or constraint. >> >>... > > Adding such a statement is all about education. It

Re: WG Review: Domain Keys Identified Mail (dkim)

Hi Eric, Eric Rescorla wrote: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are necessary for the s

Re: RFCyyyy on Definitions of Managed Objects for High Bit-Rate DSL - 2nd generation HDSL and Single-Pair High-Speed Digital Subscri

On Tue, Dec 20, 2005 at 05:09:18PM -0800, rfc-editor@rfc-editor.org wrote a message of 182 lines which said: > A new Request for Comments is now available in online RFC libraries. ... > BCP NNN > RFC > > Title: Definitions of Managed Objects for >

Re: WG Review: Domain Keys Identified Mail (dkim)

Ted, Ted Hardie wrote: I believe the text here: Since experimentation resulted in significant Internet deployment of these specifications, the DKIM working group will make every reasonable attempt to keep changes compatible with what is deployed, making incompatible changes only when they are