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 necessary for the success of the specifications. implies the need to be clarify the charter in two ways. The charter needs to reaffirm that the IETF has change control over the specifications at this point, so that there is no question over who gets to decide whether an incompatible change is necessary. I think that this is motherhood and apple pie, and would have no objection to inclusion of a reasonable statement along these lines. But it might take a while to agree what's reasonable and since Dave's right that this would be a kind of impactless change to text that did take some time and effort already, I'd rather not have a prolonged discussion on the topic. Meanwhile, as a point of fact, the DKIM specification has already changed in one on-the-wire incompatible way (canonicalisation), as a result of a bug. I also expect another wrt. hashing since sha-1 is probably not the right thing to use anymore. So, there is an existence proof that the current set of authors are willing to change the specification in response to review. (The suggestion that all charters have some implicit boilerplate that'd include such IETF change control phrasing does sound like a reasonable thing to discuss sometime.) The charter also needs to indicate that the working group will consider the relationship of this work to other, existing IETF technologies. That does not imply that it needs to adopt them, but explaining why it chose to use, for example, this signature mechanism rather than one of the existing ones would help the IETF understand whether this mechanism is a better point solution, implies a problem with the existing mechanisms which should be fixed in the existing solutions, or should be considered as the basis of a more wholesale replacement. Just checking. You're referring to the why not s/mime question here, right? I think answering that question is reasonable (and has a good answer). The putative DKIM WG is not however the place to expect an answer to why don't we all use s/mime as I'm sure you agree. Its quite possible that answer to the first question might help answering the second one, but I wouldn't want to raise too many expectations. (BTW I fully agree with what Barry said on this too.) Doing so in its first milestone document seems like a reasonable way to accomplish this, but doing so in the standards-track specifications also seems reasonable. Well, we included an overview deliverable which is intended to capture all that kind of stuff. Its the last deliverable but of course that doesn't mean that that particular piece of text won't exist earlier. If you're thinking that the IESG might want to see/discuss the why not s/mime answer during IETF last call on the protocol spec, I guess that's reasonable. Requiring that that answer be part of the last-call document or the threats document doesn't seem like the best way to handle this though. Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 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 High Bit-Rate DSL - 2nd generation HDSL and Single-Pair High-Speed Digital Subscriber Line SHDSL Lines Author: yy Status: Experimental Really experimental, it seems :-) I thought it was a strange spam but the Received: headers indicate rather a bug in the RFC editor information system :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 success of the specifications. 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 suggesting that the WG shouldn't consider compatibility, merely that it shouldn't be effectively prohibited by charter from making incompatible improvements. I don't read that as prohibiting incompatible changes, since canonicalisation and hashing are two such changes. Incompatible improvements that are not bug-fixes are discouraged though, and I can see how that raises concerns. I can also see how apparently encouraging incompatible improvements that are not bug-fixes raises concerns. 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 start this WG with a higher bar than one where neither of those things are true. Its obviously tough to write text saying the above that makes everone happy since there are so many subjective aspects involved. Clearly though (as pointed out) a new rough consensus has to be established in the WG, and subsequently during IETF last call and I do expect that process to involve questioning the design decisions which were made prior to the WG getting started. Whether such questioning results in changes (compatible or otherwise), is something we can't know at this stage. I'd also note again that compatible with what's deployed doesn't (once you've changed canonicalisation, which has happened already) mean the same as on-the-wire compatible, so the current text is actually less constraining than might seem to be the case at first reading. Lastly, the text does say that the working group will not be unreasonable in attempting to maintain compatibility, so as the Marx brothers said, there is a sanity clause after all:-) Basically, I think the current text is ok, even if it looks a bit scary. Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 is perfectly reasonable to not trust that newcomers will understand IETF policy; heck, many folks who have been active for years don't. 1. You said you disagreed, but then provided an argument for not trusting participants (people who do not understand the IETF rules.) ... Dave, 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... unless the feature to be changed is definitively proven to not work. I believe that, in situations that are superficially similar, my colleague Dave Crocker has argued that the IETF should not take on the work at all because there is no value added other than endorsement. But perhaps my memory is bad or this situation is subtly different. It seems to me that you and your colleagues have asked for a charter constraint that asserts wide deployment and, on that basis, appears to constrain the choices and changes the IETF can make. I am sympathetic to the desire for that constraint but I think we all need to accept that it is an unusual request. Because it is unusual, it also seems to me that (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 solving whatever problem the proposed work is intended to solve. Normally, that would be a ridiculously onerous requirement to place on a charter proposal for a WG. But, because this effort has requested --and written into the draft charter-- some unusual restrictions on the IETF on the basis of the deployment level, the situation, IMO, changes: if you want or need the restrictions, then you should be willing to accept the added scrutiny and text. While I am convinced that a great deal of effort, collaboration, and compromise have gone into the current proposals, I have yet to see evidence of significant and successful deployment. (ii) this WG proposal and several of your recent comments request that IETF give up most design control --including the ability to determine whether the need for a change is significant enough to be considered -- before (from an IETF process standpoint) the effort has started. I completely agree with you about the difference between broken and maybe could be made better and the importance of understanding where to draw the line. But the intent of this charter appears to be to vest the decision about what changes are appropriate (or not) entirely in the self-designated leadership of the WG, placing constraints on the usual processes of review and interactions. It is reasonable, IMO, for the IETF to respond by including in the charter things that would be obvious were the WG more normal and conventional, and even to impose some extra conditions that would be unusual for a more conventional WG setup, simply to stress that those elements of WG operation and review had not changed. (iii) you are obligated to be quite explicit about the value added by IETF involvement given those constraints, much more explicit that would be expected of a normal WG that had not requested the constraints. There is certainly a case to be made that the push-back you are getting would be unreasonable were this a conventional WG charter proposal. But, because of the request for constraints on permitted changes, it is not a conventional WG charter proposal and suggestions about additional review, additional constraints, and specific additional language all seem to me to be appropriate as a result. 2. You cannot seriously think that adding the language Ted suggests -- [...] -- will make any difference to the working group process. Viewed in the light of the above, some language along the lines I think Ted and others have suggest might actually be quite valuable in delineating how far the WG (or its leadership) is expected or permitted to go in application of the requested restricted changes principle. Such language could be useful in documenting an agreement, setting expectations, and preventing future misunderstandings. Should it be the community's expectation that having such agreements, and having them documented, would not make any difference to the working group
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, that this message signing mechanism would be better over all, or none of the above. I believe the discussion Ted suggests IS in scope for the working group we're proposing to charter, and I don't believe that the charter text in question affects that. It will be up to the WG chairs to judge rough consensus on the discussion, or to decide, should it happen, when the discussion has become fruitless and wasteful of the WG's time, especially considering the short schedule that's proposed. If Russ should choose me as a co-chair of the DKIM WG, be assured that we WILL have this discussion. Be also assured that I won't let it turn into a rathole and impede progress. I believe that is the balance that has to exist in any WG, and that the ADs place a good deal of trust in the WG chairs to both allow discussions that ought to happen, and control discussions so they stay within the scope of the WG and do not get out of hand. I don't think that anything we say in the charter changes this; it is meant to provide a guide for resolving the ratholes and distractions. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 the specifications. 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 suggesting that the WG shouldn't consider compatibility, merely that it shouldn't be effectively prohibited by charter from making incompatible improvements. I hear you, Eric, and, yes, we've all discussed this at length before. There are people with opinions at both extremes on this (from we must leave that paragraph unchanged to we must remove that paragraph completely). For my part, as the current editor of the charter, I'm happy with a change in the text if we can get consensus on some text that will make both sides at least somewhat happy (or perhaps I should say somewhat less unhappy). We weren't able to do that on the ietf-dkim list before the BOF. Let's try to spend a little time doing that now (keeping in mind the realities of the IETF process, and that the charter can not bypass that process, nor is it trying to). We have more eyes and more fingers now, and perhaps someone new can craft text that will work. Experience in this area (anti-spam-related things) shows us that we DO need strong guidelines to stay on track, and I believe that weakening the wording too much does not provide us with those guidelines. As I said in in my other post, just sent, it's really the job of the WG chairs to deal with this. Still, strong guidelines make it easier for the chairs to do their jobs efficiently, and for the ADs to handle escalations effectively. Can someone propose an alternative to the first-quoted paragraph above, from the proposed charter, that keeps the sense that the specifications we're agreeing to use as a starting point be strong conflict-resolution guides, and that they be used to steer the discussion... without making it seem, incorrectly, that the WG is not willing to accept changes that make sense to make? Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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: i-d-announce@ietf.org Asunto: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IETF Meeting Venue Selection Criteria Author(s) : J. Palet Filename : draft-palet-ietf-meeting-venue-selection-criteria-03.txt Pages : 19 Date : 2005-12-20 This document provides the IAD with technical and logistic criteria for selecting venues for IETF meetings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-venue-selection -criteria-03.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-palet-ietf-meeting-venue-selection-criteria-03.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-palet-ietf-meeting-venue-selection-criteria-03.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: [EMAIL PROTECTED] ___ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce -- Fin del mensaje reenviado ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 machines on the order of couple dozen. There is larger deployment of DK on the order of several hundred active mail servers doing signing (including some large ones like outgoing webmail servers @yahoo google; DKIM is different and they all have to change anyway), but it does not even closely comes to something that can be said to be wide deployment or existing protocol. What is there however is a lot of hype and marketing created by Yahoo and associated organizations about DK DKIM being a solution to SPAM (which as we know is not really true). I do not think it's that good when marketing is being used to justify going against IETF normal procedures and instead of working out system on public MASS WG as originally planned, to go around IETF and create proposal in private and then present to IETF for a stamp of approval. 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 alternatives that are superior, but by bypassing MASS and presenting DKIM in current form with constraints on discussion, all that mess is avoided. No matter if we end up with good system or not, I believe in the end IETF and internet in general lost on how it all happened because IETF showed that it can be fairly easily manipulated and for Internet there is no guarantee that what comes out as standard is technically best approach to solve the problem and that such approach is really vendor-neutral in how it was conceived. But perhaps that marketing wins over technically best is how it really works in the real life of corporate business (i.e. think about why Microsoft products are used) and that is not as bad as I think that IETF is being put inline with such vendor-dominated business world. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 objectives and the group clearly documents the reasons for making them. This text still keeps the bar high for unnecessary changes, was already vetted through an existing charter, and helped us through a similar impasse when xmpp was chartered. Tony Hansen [EMAIL PROTECTED] Barry Leiba wrote: 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 the specifications. Can someone propose an alternative to the first-quoted paragraph above, from the proposed charter, that keeps the sense that the specifications we're agreeing to use as a starting point be strong conflict-resolution guides, and that they be used to steer the discussion... without making it seem, incorrectly, that the WG is not willing to accept changes that make sense to make? Barry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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... 1. fine-tuning that really does not change anything is a mis-representation of what I have described. 2. I did not propose anything. I noted that the transfer of existing technology into the IETF has an inherent issue with deciding whether to protect existing work and how much to protect it, and I noted that this is a long way from the first time the IETF has chosen to protect quite a bit. 3. What work do you want to have done by the working group that is prohibited by the the charter language in question? I believe that, in situations that are superficially similar, my colleague Dave Crocker has argued that the IETF should not take on the work at all because there is no value added other than endorsement. But perhaps my memory is bad or this situation is subtly different. or perhaps not so subtly. Does superficially similar mean not really similar? In any event, I'm sure you can substantiate your claim, here. It would be a shame for such an assertion not to be amenable to deeper evaluation. It seems to me that you and your colleagues have asked for a charter constraint that asserts wide deployment and, on that I believe the language that has been used does not match the language you are using. (i) you are obligated to demonstrate that sufficient production-level deployment actually exists to justify John, if you do not care about 2 years of prior technical, development and deployment prior work, then please simply say so. If you do not care about 5 months of open-participation discussion and revision to the charter that reached rough consensus on the draft charter text *twice*, then please simply say so. Welcome to the modern IETF. Infinite time to raise abstract principles, absent any specific technical concerns. No time to focus on concrete work. An excellent productivity disincentive for the community. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 alternatives that are superior, but by bypassing MASS and presenting DKIM in current form with constraints on discussion, all that mess is avoided. My usual immediate response to anything that contains the phrase allowed to be presented is where's the draft. MASS had its BOF and its mailing list, so I'm assuming that whoever participated in that discussion discovered the fact that they could publish an internet-draft for ANYTHING without prior approval, as long as it was done in their own name and not in the IETF's. So in this case, the drafts might actually be out there. If so - what's the draft names? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 damaging to internet. Other aspects of proposal also had alternatives that are superior, but by bypassing MASS and presenting DKIM in current form with constraints on discussion, all that mess is avoided. My usual immediate response to anything that contains the phrase allowed to be presented is where's the draft. Yes, the drafts and proposals were published as part of MASS. I have links to most of that at: http://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htm Yes, the DKIM group clearly purposely bypassed discussions as part of MASS (i.e. ietf open forum) in order to do it in private and leave only one authorization method (i.e. public keys in dns; it so happens that public keys in dns is also core of the Yahoo's patent and other authorization method do not have such IPR constraints). And yes in case you don't know BoF chairs and AD did deny request to present alternatives to DKIM when it was still called MASS BoF. MASS had its BOF and its mailing list, so I'm assuming that whoever participated in that discussion discovered the fact that they could publish an internet-draft for ANYTHING without prior approval, as long as it was done in their own name and not in the IETF's. So in this case, the drafts might actually be out there. If so - what's the draft names? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 and Single-Pair High-Speed Digital Subscriber * Line SHDSL Lines * Author: yy * Status: Experimental * * Really experimental, it seems :-) * * I thought it was a strange spam but the Received: headers indicate * rather a bug in the RFC editor information system :-) * The RFC Editor deeply apologizes for letting this wildcard loose in the Internet. Our programmer is debugging code to generate RFC announcement messages automagically from our database, and apparently she slipped up. Of course, none of US would have ever made such a mistake, right? ;-) Think of it as a Happy Holidays greeting card from the staff of the RFC Editor. Bob Braden ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 required to meet the group's technical objectives and the group clearly documents the reasons for making them. This text still keeps the bar high for unnecessary changes, was already vetted through an existing charter, and helped us through a similar impasse when xmpp was chartered. Tony Hansen [EMAIL PROTECTED] I agree with Tony on the benefits of re-using this language, and it certainly works for me. I'd also like to thank Stephen Farrell for pointing out the overview document as a logical place to answer the relationship to other IETF technologies questions. The current language for that work item says: An informational RFC providing an overview of DKIM and how it can fit into overall messaging systems, implementation and migration considerations, and outlining potential DKIM applications and future extensions. I suggest adding how it relates to other IETF message signature technologies. Given that this document already discusses other potential DKIM applications and future extensions, Stephen is right that the discussion fits here better than either place I earlier suggested. regards, Ted Hardie Barry Leiba wrote: 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 the specifications. Can someone propose an alternative to the first-quoted paragraph above, from the proposed charter, that keeps the sense that the specifications we're agreeing to use as a starting point be strong conflict-resolution guides, and that they be used to steer the discussion... without making it seem, incorrectly, that the WG is not willing to accept changes that make sense to make? Barry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 suggesting that the WG shouldn't consider compatibility, merely that it shouldn't be effectively prohibited by charter from making incompatible improvements. I hear you, Eric, and, yes, we've all discussed this at length before. There are people with opinions at both extremes on this (from we must leave that paragraph unchanged to we must remove that paragraph completely). For my part, as the current editor of the charter, I'm happy with a change in the text if we can get consensus on some text that will make both sides at least somewhat happy (or perhaps I should say somewhat less unhappy). Consensus on the charter would of course be a good thing, but it's not a necessary condition. The job of the charter is to appropriately direct and focus the group's work, not to make everyone happy. Also, the WG may draft a charter, but the charter isn't something that has to be settled on my the WG. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 start this WG with a higher bar than one where neither of those things are true. I strongly disagree. Implementation of a draft specification is useful to establish a proof-of-concept and perhaps (especially if there are multiple independent implementations), to unconver potential ambiguities in the draft specification. Implementation is not however a good indicator of protocol soundness. This might have been sufficient in ARPAnet days, but on the scale of today's Internet it is necessary to perform extensive analysis and review - neither of which have been done for DKIM. So no, it's not appropriate to raise the bar for changes on the basis of existing DKIM implementation. At most, the charter should specify that new DKIM signatures be distinguishable from signatures made according to the old DKIM specification. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 creating a standard. The goal of a standard-setting working group is to understand and describe what will work well for the Internet as a whole and to vett that design via wide review, not to rubber-stamp what has been designed by a small group of people and deployed under relatively limited circumstances. -I'm suggesting the WG tell the IETF what, if anything, is wrong with the bits the IETF had already done. Earth to Ted: THAT'S NOT THE JOB OF THIS WORKING GROUP. Dave, you are not the one who decides what this working group does. that's IESG's job. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 shred of support for your position. You seem to think that you alone dictate the conditions under which a working group should be chartered. You are mistaken, and IMHO your efforts are hindering progress of the the DKIM effort. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 success of the specifications. implies the need to be clarify the charter in two ways. The charter needs to reaffirm that the IETF has change control over the specifications at this point, so that there is no question over who gets to decide whether an incompatible change is necessary. The charter also needs to indicate that the working group will consider the relationship of this work to other, existing IETF technologies. I'll go further than that. The text you quoted from the proposed charter is inappropriate, and needs to be removed entirely. DKIM as currently envisioned has serious flaws that not only limit its flexibility but which will do harm to domains that do not fit its Procrustean model for policy advertisement. The flaws are fixable, and with the fixes DKIM could be quite useful for discouraging forgeries. But the flaws aren't fixable without making incompatible changes. The only when necessary for success clause raises the bar for changes too high. At best it is confusing because different people define success in different ways. There are unfortunately some DKIM proponents who want IETF to rubber stamp this protocol, despite its widely acknowledged flaws. If this clause is allowed to stand they will try to use it as a stick to prevent changes that would make DKIM much more widely applicable. The DKIM working group should have complete latitude to change any feature of the current DKIM protocol. The DKIM protocol is neither widely deployed enough nor useful enough in its current form to dictate features of an IETF standard protocol. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 specification to dictate the standard protocol. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 consensus? there isn't a DKIM WG yet, so rough consensus of the mailing list is irrelevant. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them. This text still keeps the bar high for unnecessary changes, was already vetted through an existing charter, and helped us through a similar impasse when xmpp was chartered. Tony Hansen [EMAIL PROTECTED] I agree with Tony on the benefits of re-using this language, and it certainly works for me. Me too FWIW. Stephen. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 technical objectives and the group clearly documents the reasons for making them. I agree with Tony on the benefits of re-using this language, and it certainly works for me. Then it sounds like we have some text that we can compromise on. Jim Fenton has already said that this text covers his concerns about as well as what we had, Stephen Farrell has accepted it, and now I'm weighing in. 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. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 taken place. We carefully develop charter language through two, complete, multi-month rounds of open collaboration, including significant focus on exactly the language in question, both times. Some folks come in at the late stage of the second open process and seek to change this text, but they fail to develop support. So they re-assert their concerns again during the IETF charter last call, and now the chairs quickly concede the change, even before getting support from the rest of the group. It's not that the proposed language is bad, it is that this sequence bodes rather poorly for dealing with further demands from folks who fail to gain support. And it does not help that two of those doing the (re-)demanding are area directors and another an IAB member, raising the fear that the current concession is strictly to appease the authority those folks have. All this with no specific technical concerns driving the demand. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 agree with Tony on the benefits of re-using this language, and it certainly works for me. It does not work for me. It is biased in the wrong direction. It is entirely inappropriate to encourage the WG to produce output that is compatible with a specification that is known to have significant flaws. Consider also the following: a) we already know that incompatible changes are necessary, thus verifying software will need to be upgraded b) as DKIM is specifically NOT intended to provide assurances of message authenticity for more than a few days, compatibility with existing signatures is of little consequence anyway 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. I suggest the IESG replace the paragraph with the following: While it is understood that the WG will use the current DKIM specifications as a starting point, the WG is neither expected nor constrained to specify a standard which is compatible with those specifications. The WG should feel free to make whatever changes are necessary to produce a specification that is robust with respect to the requirements and flexible enough to support a diverse set of usage scenarios. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 * High Bit-Rate DSL - 2nd generation * HDSL and Single-Pair High-Speed Digital Subscriber * Line SHDSL Lines * Author: yy * Status: Experimental Think of it as a Happy Holidays greeting card from the staff of the RFC Editor. So... this would explain why the author field consists of y's men ? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/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 suggested was just that: a suggestion. You may feel free to spend more time arguing about that paragraph if you like. My opinion (and that's all it is) is that that's not useful. I understand the principle you're fighting for, Dave. And I think it will come up again, which is why you're fighting it. I think it will be better to fight it later, if necessary. Barry -- Barry Leiba, Pervasive Computing Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 http://permalink.gmane.org/gmane.ietf.dkim/1568 is no strong objection, or is it ? Bye, Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
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 chartered or will in the future. Nearly every group has some people with a fairly strong idea of at least one way to solve the problem. Without this, it is usually not clear the work is even possible. Now some groups, XMPP for example, perhaps TLS long ago, have substantial deployment with difficult backwards compatibility questions - theses situation might require the charter to provide more than normal limitations to the scope of the solutions that are possible. I'm failing to see that dkim has existing deployments or difficult backwards compatibility problem that would cause the need for some special text in the charter more than you average WG. (They do have difficult backward compatibility problems with existing email systems and I like the text that limits the scope on that.) My current understanding is that the deployments are small enough that changes are still easy and that non backwards compatible changes are already expected. I fail to see the analogy to XMPP but perhaps there is a good reason for something more like XMPP. I'd sure want whoever approved this charter to be able to give me a clear reason why they though this WG would produce better work by having this constraint. It's going to set a precedent for things to come. Practically speaking, I'm not sure it will make much difference to the work that the WG produces. If the individuals that will form the WG feel that the WG has consensus that they will not make changes beyond a a certain boundary, they don't need the charter to set that boundary. The strong arguments that this needs to be in the charter makes me wonder if the individuals that will form the WG will agree to very limited changes or not. If they will, it's barely worth arguing for here. Related to how much the charter pre-supposes the solution, the sentence that Public keys needed to validate the signatures will be stored in the responsible identity's DNS hierarchy. seems like a pretty heavy constraint on the possible solutions and one that some proposals disagreed with. I'm not arguing against the current dkim drafts, I am arguing that the future of doing internet drafts should not be a process where we come to agreement in a dark and smokey room with a small group of people then set up WG where effectively only syntax level changes can be made. If we like these drafts as is, let's skip the WG and just take them forward as AD sponsored individual drafts and call it done, if we think we need a WG, allow it to have change control to select a reasonable solution to the problem. On 12/21/05 4:07 PM, Keith Moore moore@cs.utk.edu wrote: I suggest the IESG replace the paragraph with the following: While it is understood that the WG will use the current DKIM specifications as a starting point, the WG is neither expected nor constrained to specify a standard which is compatible with those specifications. The WG should feel free to make whatever changes are necessary to produce a specification that is robust with respect to the requirements and flexible enough to support a diverse set of usage scenarios. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
WG Review: EAP Method Update (emu)
A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by December 28. +++ EAP Method Update (emu) Current Status: Proposed Working Group Chairs: TBD Security Area Director(s): Russ Housley [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] Security Area Advisor: Sam Hartman [EMAIL PROTECTED] Mailing List: TBD Description of Working Group: The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used in the PPP, 802.11, 802.16, VPN, PANA, and in some functions in 3G networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Over 40 different EAP methods exist. Most of this methods are proprietary methods and only a few methods are documented in RFCs. The lack of documented, open specifications is a deployment and interoperability problem. In addition, none of the EAP methods in the standards track implement features such as key derivation that are required for many modern applications. This poses a problem for, among other things, the selection of a mandatory to implement EAP method in new network access technologies. For example, no standards track methods meet new requirements such as those posed in RFC 4017, which documents IEEE 802.11 requirements for EAP methods. This group is chartered to work on the following types of mechanisms to meet RFC 3748 and RFC 4017 requirements: - An update to RFC 2716 to bring EAP-TLS into standards track, clarify specification, interoperability, and implementation issues gathered over the years, and update the document to meet the requirements of RFC 3748, RFC 4017, and EAP keying framework documents. Backwards compatibility with RFC 2716 is a requirement. - Enhanced functionality to enable a TLS-based EAP method to support authentication methods beyond certificates, channel bindings and other optional functions required in RFC 4017. So as to enable RFC 2716bis to focus solely on clarifications to the existing protocol, this effort will be handled in a separate document. Depending on an analysis of the behavior of existing implementations, it is possible that this effort may be able to use the existing EAP-TLS type code, or it may need to be handled via assignment of a new EAP Type Code. - A mechanism based on strong shared secrets that meets RFC 3748 and RFC 4017 requirements. This mechanism should strive to be simple and compact for implementation in resource constrained environments. - A mechanism meeting RFC 3748 and RFC 4017 requirements that makes use of existing password databases such as AAA databases. The implementation should strive to be usable in resource constrained environments. In order to facilitate the development of the shared secret and password based methods design teams will be formed. The design teams should take into consideration existing methods including mechanisms based on EAP-TLS such as TLS-PSK. Feb 2006 Form design team to work on strong shared secret mechanism Mar 2006 Submit 2716bis I-D Jun 2006 Submit first draft of enhanced EAP-TLS I-D Jul 2006 Form password based mechanism design team Jul 2006 Submit first draft of shared secret mechanism I-D Aug 2006 Submit 2716bis draft to IESG for Proposed Standard Nov 2006 Submit 2716bis draft to IESG for draft standard Dec 2006 Submit first draft password based method I-D Jan 2007 Submit Strong Shared Secret Mechanism to IESG Jan 2007 Submit enhanced EAP-TLS to IESG Aug 2007 Submit password Based Mechanism to IESG ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Review: Recharter of Pseudo Wire Emulation Edge to Edge (pwe3)
A modified charter has been submitted for the Pseudo Wire Emulation Edge to Edge (pwe3) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by December 28th. +++ Pseudo Wire Emulation Edge to Edge (pwe3) = Current Status: Active Working Group Chair(s): Stewart Bryant [EMAIL PROTECTED] Danny McPherson [EMAIL PROTECTED] Internet Area Director(s): Mark Townsley [EMAIL PROTECTED] Margaret Wasserman [EMAIL PROTECTED] Internet Area Advisor: Mark Townsley [EMAIL PROTECTED] Secretary(ies): Matthew Bocci [EMAIL PROTECTED] Mailing Lists: General Discussion: pwe3@ietf.org To Subscribe: [EMAIL PROTECTED] In Body: subscribe your_email_address Archive: http://www.ietf.org/mail-archive/web/pwe3/index.html Description of Working Group: Network transport service providers and their users are seeking to rationalize their networks by migrating their existing services and platforms onto IP or MPLS enabled IP packet switched networks (PSN). This migration requires communications services that can emulate the essential properties of traditional communications links over a PSN. Pseudowire Emulation Edge to Edge (PWE3) will specify the encapsulation, transport, control, management, interworking and security of services emulated over IETF specified PSNs. A pseudowire emulates a point-to-point link, and provides a single service which is perceived by its user as an unshared link or circuit of the chosen service. It is not intended that an emulated service will be indistinguishable from the service that is being emulated. The emulation need only be sufficient for the satisfactory operation of the service. Emulation necessarily involves a degree of cost-performance trade-off. In some cases it may be necessary to design more than one emulation mechanism in order to resolve these design conflicts. All emulated service definitions must include an applicability statement describing the faithfulness of the emulation. Switching, multiplexing, modification or other operation on the traditional service, unless required as part of the emulation, is out of the scope of the PWE3 WG. PWE3 will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. PWE3 operates edge to edge and will not exert control on the underlying PSN, other than to use any existing QoS or path control mechanism to provide the required connectivity between the two endpoints of the PW. PWE3 will investigate mechanisms necessary to perform clock recovery and other real-time signaling functions. This work will be coordinated with the AVT WG and RTP will be used where appropriate. A PW operating over a shared PSN does not necessarily have the same intrinsic security as a dedicated, purpose built, network. In some cases this is satisfactory, while in other cases it will be necessary to enhance the security of the PW to emulate the intrinsic security of the emulated service. PW specifications MUST include a description of how they are to be operated over a shared PSN with adequate security. Whilst a service provider may traffic engineer their network in such a way that PW traffic will not cause significant congestion, a PW deployed by an end-user may cause congestion of the underlying PSN. Suitable congestion avoidance mechanisms are therefore needed to protect the Internet from the unconstrained deployment of PWs. PWE3 will work closely with the L2VPN WG to ensure a clear demarcation is defined for where PWE3 stops and L2VPN starts. PWE3 will coordinate very closely with any WG that is responsible for protocols which PWE3 intends to extend (e.g., the MPLS WG for LDP), as well as foster interaction with WGs that intend to extend PWE3 protocols. WG Objectives: Specify the following PW types: Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM, SONET/SDH and Fibre Channel. PWE3 will specify a PW type for the special case where the access service payloads at both ends are known to consist entirely of IP packets. PWE3 will not specify mechanisms by which a PW connects two different access services. Specify the control and management functions of chartered PW types, to include PW setup, configuration, maintenance and tear-down. The PWE3 WG will do this in its entirety for MPLS PSNs, and the L2TPEXT WG will develop the L2TP specifics for L2TPv3-based PWs. Specify Operations and Management (OAM) mechanisms for all PW types, suitable for operation over both IP/L2TPv3 and MPLS PSNs, and capable of providing the necessary interworking with the OAM mechanisms of the emulated service. Further enhance PW specifications to enable more transparent emulation when necessary, for example the retention of FCS across a PW. Define a mechanism for MPLS PWs that
WG Action: RECHARTER: Extended Incident Handling (inch)
The charter of the Extended Incident Handling (inch) working group in the Security Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Extended Incident Handling (inch) == Current Status: Active Working Group Chair(s): Roman Danyliw [EMAIL PROTECTED] Security Area Director(s): Russ Housley [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] Security Area Advisor: Sam Hartman [EMAIL PROTECTED] Mailing Lists: General Discussion: inch@nic.surfnet.nl To Subscribe: [EMAIL PROTECTED] In Body: subscribe inch Archive: http://listserv.surfnet.nl/archives/inch.html Description of Working Group: Background Computer security incidents occur across administrative domains often spanning different organizations and national borders. Therefore, the free exchange of incident information and statistics among involved parties and the responsible Computer Security Incident Response Teams (CSIRTs) is crucial for both reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention. Scope The purpose of the Incident Handling (INCH) working group is to define a data format for exchanging security incident information used by a CSIRT. A CSIRT is defined broadly as an entity with a security role or responsibility in a given organization. Often there is a communication and collaborating component. Organizationally, a CSIRT might be a dedicated team in a network operations group, or a single individual with other responsibilities. The primary use case for the INCH work is to standardize the the communication between a CSIRT and: * its constituency (e.g., users, customers) reporting misuse; * parties involved in an incident (e.g., law enforcement, attacking site); or * peer CSIRTs sharing information. In doing such sharing, especially when action is being requested, due attention must be paid to authorization and privacy issues. This format will support the now largely human-intensive dimension of the incident handling process. It will represent the product of various incremental data gathering and analysis operations performed by a CSIRT from the time when the system misuse was initially reported (perhaps by an automated system) till ultimate resolution. Specifically, the working group will address the issues related to representing * the source(s) and target(s) of system misuse, as well as the analysis of their behavior; * the evidence to support any analysis results; * a scheme to document the incident investigation and analysis process; and * constructs to facilitate the exchange of security information across administrative domains (e.g., internationalization, data sensitivity). The WG will investigate the information model needed to support the typical, operational workflow of the incident handling processes found at Internet Service Providers; Managed Security Service Providers; Risk Analysis vendors; and traditional, internal CSIRTs. Constraints The WG will not attempt to - - define an incident or address the implications of sharing incident data across administrative domains; - - define a format for computer security related information for which there is already a standard, but where applicable, provide full compatibility (e.g. IDWG's IDMEF, Mitre's CVE); or - - define a protocol for exchanging the incident information. Output of Working Group 1. A document describing the high-level functional requirements of a data format for collaboration between CSIRTs and parties involved when handling computer security incidents. 2. A specification of the extensible, incident data language that describes the data formats that satisfy the requirements. 3. Guidelines for implementing the WG data format (Output #2 of the WG). 4. A set of sample incident reports and their associate representation in the incident data language. Goals and Milestones: DoneInitial I-D of the incident data language specification DoneInitial I-D for the requirements specification DoneInitial I-D of the implementation guidelines document DoneInitial I-D of the traceback extension specification DoneSubmit initial draft of phishing extension specification I-D Nov 2005Initial I-D of a transport binding specification Dec 2005Submit messaging format specification I-D to the IESG as Proposed Dec 2005Submit incident data language specification I-D to the IESG as Proposed Dec 2005Submit requirements I-D to the IESG as Informational Dec 2005Submit transport binding specification I-D to the IESG as Proposed Dec 2005Submit phishing extension specification I-D to the IESG as Proposed Feb 2006Submit implementation guidelines I-D to the IESG as Informational ___ IETF-Announce mailing list
RFC 4228 on Requirements for an IETF Draft Submission Toolset
A new Request for Comments is now available in online RFC libraries. RFC 4228 Title: Requirements for an IETF Draft Submission Toolset Author(s): A. Rousskov Status: Informational Date: December 2005 Mailbox:[EMAIL PROTECTED] Pages: 31 Characters: 76952 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-tools-draft-submission-09.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4228.txt This document specifies requirements for an IETF toolset to facilitate Internet-Draft submission, validation, and posting. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4228.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4324 on Calendar Access Protocol (CAP)
A new Request for Comments is now available in online RFC libraries. RFC 4324 Title: Calendar Access Protocol (CAP) Author(s): D. Royer, G. Babics, S. Mansour Status: Experimental Date: December 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 131 Characters: 254638 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-royer-calsch-cap-03.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4324.txt The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4324.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4315 on Internet Message Access Protocol (IMAP) - UIDPLUS extension
A new Request for Comments is now available in online RFC libraries. RFC 4315 Title: Internet Message Access Protocol (IMAP) - UIDPLUS extension Author(s): M. Crispin Status: Standards Track Date: December 2005 Mailbox:[EMAIL PROTECTED] Pages: 8 Characters: 16629 Obsoletes: 2359 I-D Tag:draft-crispin-imap-rfc2359bis-04.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4315.txt The UIDPLUS extension of the Internet Message Access Protocol (IMAP) provides a set of features intended to reduce the amount of time and resources used by some client operations. The features in UIDPLUS are primarily intended for disconnected-use clients. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4315.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4298 on RTP Payload Format for BroadVoice Speech Codecs
A new Request for Comments is now available in online RFC libraries. RFC 4298 Title: RTP Payload Format for BroadVoice Speech Codecs Author(s): J.-H. Chen, W. Lee, J. Thyssen Status: Standards Track Date: December 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 14 Characters: 30099 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-avt-rtp-bv-04.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4298.txt This document describes the RTP payload format for the BroadVoice(R) narrowband and wideband speech codecs. The narrowband codec, called BroadVoice16, or BV16, has been selected by CableLabs as a mandatory codec in PacketCable 1.5 and has a CableLabs specification. The document also provides specifications for the use of BroadVoice with MIME and the Session Description Protocol (SDP). This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4298.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4230 on RSVP Security Properties
A new Request for Comments is now available in online RFC libraries. RFC 4230 Title: RSVP Security Properties Author(s): H. Tschofenig, R. Graveman Status: Informational Date: December 2005 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 48 Characters: 121030 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-nsis-rsvp-sec-properties-06.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4230.txt This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities. This document is a product of the Next Steps in Signaling Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4230.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: Network Configuration (netconf)
The charter of the Network Configuration (netconf) working group in the Operations and Management Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Network Configuration (netconf) Current Status: Active Working Group Chair(s): Simon Leinen [EMAIL PROTECTED] Andy Bierman [EMAIL PROTECTED] Operations and Management Area Director(s): Bert Wijnen [EMAIL PROTECTED] David Kessens [EMAIL PROTECTED] Operations and Management Area Advisor: Bert Wijnen [EMAIL PROTECTED] Technical Advisor(s): Wesley Hardaker [EMAIL PROTECTED] Mailing Lists: General Discussion: netconf@ops.ietf.org To Subscribe: [EMAIL PROTECTED] In Body: in msg body: subscribe Archive: https://ops.ietf.org/lists/netconf Description of Working Group: Wes Hardaker is Technical Advisor for Security Matters Configuration of networks of devices has become a critical requirement for operators in today's highly interoperable networks. Operators from large to small have developed their own mechanims or used vendor specific mechanisms to transfer configuration data to and from a device, and for examining device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The Netconf Working Group is chartered to produce a protocol suitable for network configuration, with the following characteristics: - Provides retrieval mechanisms which can differentiate between configuration data and non-configuration data - Is extensible enough that vendors will provide access to all configuration data on the device using a single protocol - Has a programmatic interface (avoids screen scraping and formatting-related changes between releases) - Uses a textual data representation, that can be easily manipulated using non-specialized text manipulation tools. - Supports integration with existing user authentication methods - Supports integration with existing configuration database systems - Supports network wide configuration transactions (with features such as locking and rollback capability) - Is as transport-independent as possible - Provides support for asynchronous notifications The Netconf protocol will use XML for data encoding purposes, because XML is a widely deployed standard which is supported by a large number of applications. XML also supports hierarchical data structures. The Netconf protocol should be independent of the data definition language and data models used to describe configuration and state data. However, the authorization model used in the protocol is dependent on the data model. Although these issues must be fully addressed to develop standard data models, only a small part of this work will be initially addressed. This group will specify requirements for standard data models in order to fully support the Netconf protocol, such as: - identification of principals, such as user names or distinguished names - mechanism to distinguish configuration from non-configuration data - XML namespace conventions - XML usage guidelines It should be possible to transport the Netconf protocol using several different protocols. The group will select at least one suitable transport mechanism, and define a mapping for the selected protocol(s). The initial work will be restricted to the following items: - Netconf Protocol Specification, which defines the operational model, protocol operations, transaction model, data model requirements, security requirements, and transport layer requirements. - Netconf over Transport-TBD Specification, which defines how the Netconf protocol is used with the transport protocol selected by the group, and how it meets the security and transport layer requirements of the Netconf Protocol Specification.. There will be a document of this type for each selected transport protocol. The working group will take the XMLCONF Configuration Protocol draft-enns-xmlconf-spec-00.txt as a starting point. Goals and Milestones: DoneWorking Group formed DoneSubmit initial Netconf Protocol draft DoneSubmit initial Netconf over (transport-TBD) draft DoneBegin Working Group Last Call for the Netconf Protocol draft DoneBegin Working Group Last Call for the Netconf over (transport-TBD) draft DoneSubmit final version of the Netconf Protocol draft to the IESG DoneSubmit final version of the Netconf over SOAP draft to the IESG DoneSubmit final version of the Netconf over BEEP draft to the IESG DoneSubmit final version of the Netconf over SSH draft to the IESG Dec 2005Update charter Jan 2006Submit first version of NETCONF Notifications document Sep 2006Begin WGLC of NETCONF Notifications document
UPDATED: WG Action: RECHARTER: Extended Incident Handling (inch)
The charter of the Extended Incident Handling (inch) working group in the Security Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. +++ Extended Incident Handling (inch) == Current Status: Active Working Group Chair(s): Roman Danyliw [EMAIL PROTECTED] Security Area Director(s): Russ Housley [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] Security Area Advisor: Sam Hartman [EMAIL PROTECTED] Mailing Lists: General Discussion: inch@nic.surfnet.nl To Subscribe: [EMAIL PROTECTED] In Body: subscribe inch Archive: http://listserv.surfnet.nl/archives/inch.html Description of Working Group: Background == Computer security incidents occur across administrative domains often spanning different organizations and national borders. Therefore, the exchange of incident information and statistics among involved parties and associated Computer Security Incident Response Teams (CSIRTs) is crucial for both reactionary analysis of current intruder activity and proactive identification of trends that can lead to incident prevention. Scope = The purpose of the Incident Handling (INCH) working group is to define a data format for exchanging security incident information used by a CSIRT. A CSIRT is defined broadly as an entity (either a team or individual) with a security role or responsibility for a given constituency (e.g., organization, network). The use case for the INCH WG output is to standardize the information model and messaging format currently used in communication between a CSIRT and the: * constituency (e.g., users, customers) from which it receives reports of misuse; * other parties involved in an incident (e.g., technical contact at an attacking site, other CSIRTs); and * analysis centers performing trending across broad data-sets. These INCH developed formats will replace the now largely human- intensive communication processes common in incident handling. The working group will address the issues related to representing and transporting: * the source(s) and target(s) of system misuse, as well as the analysis of their behavior; * the evidence to support this analysis; * status of an incident investigation and analysis process; and * meta-information relevant to sharing sensitive information across administrative domains (e.g., internationalization, authorization, privacy). Constraints === The WG will not attempt to define - - an incident taxonomy; - - an archive format for incident information; - - a format for workflow process internal to a CSIRT; or - - a format for computer security related information for which there is already a working standard. Output of Working Group === 1. A set of high-level requirements for a data format to represent information commonly exchanged by CSIRTs. 2. A specification of an extensible, incident data description language that describes a format that satisfies these requirements (Output #1). 3. A set of sample incident reports and their associate representation in the incident data language. 4. A message format specification and associated transport binding to carry the encoded description of an incident (Output #2). 5. Guidelines for implementing the data format (Output #2) and associated communications (Output #4) Goals and Milestones: DoneInitial I-D of the incident data language specification DoneInitial I-D for the requirements specification DoneInitial I-D of the implementation guidelines document DoneInitial I-D of the traceback extension specification DoneSubmit initial draft of phishing extension specification I-D Nov 2005Initial I-D of a transport binding specification Dec 2005Submit messaging format specification I-D to the IESG as Proposed Dec 2005Submit incident data language specification I-D to the IESG as Proposed Dec 2005Submit requirements I-D to the IESG as Informational Dec 2005Submit transport binding specification I-D to the IESG as Proposed Dec 2005Submit phishing extension specification I-D to the IESG as Proposed Feb 2006Submit implementation guidelines I-D to the IESG as Informational ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
UPDATED: WG Action: RECHARTER: Mobility for IPv4 (mip4)
The Mobility for IPv4 (mip4) working group in the Internet Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. +++ Mobility for IPv4 (mip4) == Current Status: Active Working Group Chair(s): Peter McCann [EMAIL PROTECTED] Henrik Levkowetz [EMAIL PROTECTED] Internet Area Director(s): Mark Townsley [EMAIL PROTECTED] Margaret Wasserman [EMAIL PROTECTED] Internet Area Advisor: Margaret Wasserman [EMAIL PROTECTED] Mailing Lists: General Discussion: mip4@ietf.org To Subscribe: [EMAIL PROTECTED] In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/mip4/index.html Description of Working Group: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its permanent home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings.Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when MIPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a proposed standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience 2. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are: - completion of the MIB for the revised base Mobile IP specification (2006bis) - regional registration draft. 3. The MIP4 WG will also complete the work on MIPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for MIPv4 operation in the presence of IPsec VPNs. 4. Additionally, a proposal has been made for how MOBIKE could work together with MIPv4. This proposal does not describe any new protocol, but formulates a best current practice for deploying MOBIKE together with MIPv4. The working group will adopt and complete this document. 5. Some issues have been raised with respect to RFC3519. These will be identified and addressed as appropriate, through errata, revision of RFC 3519, and/or supplemental documents as needed. 6. It has been proposed that the FMIP protocol, which has been standardised for MIPv6 in the MIPSHOP working group, should also be published as an experimental protocol for MIPv4. A draft for this exists. The working group will take up and carry this work forward to publication 7. An extension to carry generic strings in the Registration Reply message has been proposed. The purpose is to supply supplemental human-readable information intended to the MN user. The working group will complete the specification and applicability statement of such an extension. 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been proposed for MIPv4. The working group will first produce a requirements specification, describing how the work differs from the requirements in RFC 2977 and the functionality provided by RFC 4004 (the MIPv4 Diameter App). The reason why this first step is required is that RFC 3127 pretty clearly shows that full 2977 functionality can't be provided by even a considerably extended RADIUS, so we need to match the requirements to what can be done within RADIUS. Provided the requirements work finds approval with ADs and radext, the workgroup will complete the specification of MIPv4 RADIUS attributes, solicit feedback from the Radius Extensions WG, adjust, and submit this for publication. 9. MIPv4 Extension for Configuration Options. Several drafts have proposed extensions to help improve configuration of MIPv4 clients. The latest proposal is for a general configuration option extension which could carry information such as e.g., DNS address and DHCP server address. The working group will take on and complete one proposal for a configuration option extension. Goals and Milestones: DoneAAA Keys for MIPv4 to
Last Call: 'Repeated Authentication in IKEv2' to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Repeated Authentication in IKEv2 ' draft-nir-ikev2-auth-lt-04.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-18. The file can be obtained via http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-04.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94 and GOST R 34.10-2001 algorithms with the Cryptographic Message Syntax (CMS)' to Proposed Standard
The IESG has received a request from the S/MIME Mail Security WG to consider the following document: - 'Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94 and GOST R 34.10-2001 algorithms with the Cryptographic Message Syntax (CMS) ' draft-ietf-smime-gost-06.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-gost-06.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
