Re: DNS Additional Section Processing Globally Wrong
On 4 Jun 2009, at 04:06, Mark Andrews wrote: In message aaab52ef-ad0a-4d3c-9b28-b864f342d...@sabahattin-gucukoglu.com , Sabahattin Gucukoglu writes: The problem is this: the authoritative servers for a domain can easily never be consulted for DNS data if the resource being looked up happens to be available at the parent zone. That is, bigbox.example.net's address and the RR's TTL can never be as specified by the zone master unless he or she has control over the parent zone's delegation to example.net if bigbox.example.net happens to be serving for example.net. (Registries give you address control, of course, but often they fix on large TTLs.) As far as I can tell, every public recursive server I can reach, dnscache and BIND9, and one Microsoft cache and one of whatever OpenDNS uses, all do the wrong thing (TM) and never look up true data from authoritative name servers. They hang on to additional section data from the delegating name server and pass this on as truth, the whole truth, and nothing but the truth to everybody who asks. Except they don't. What you may be seeing is parent servers returning glue as answers and that being accepted. Glue data, additional and non-authoritative by design, intent and specification, aren't what I want caches to keep. The data I spent my lunch hour putting into my zone file is. :-) As a matter of fact, it never occurred to me to wonder at this misbehaviour - it clearly wasn't that much of a big deal when I was running things myself - but the 2008 cache-poison attacks found me surprised that this is how it is. In particular, they only worked because the cache was happy to keep additional data for hosts that were pertinent to the query, but in which it had no business caching. If it had instead chased up the referal, the attacker would at least have had to run a nameserver to answer the Is it really you? query. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
Sam, Thanks for posting your review. It caused me to have a look at the document, because I've been considering writing something of a missive on my own. I have to say that I enjoyed reading this draft up to about Section 3, and then I came to some problems. I'll spell those out in a separate message, but I agree with you on one key point: this document does not does not provide actionable guidance, and actually avoids the use of 2119 language. Clearly that was a design goal. But I think in the end it has led to a good INFORMATIONAL document, or even the beginnings of a good text book, and not necessarily a BCP. Also, I agree with you that interoperability is not the first and primary goal. Clearly, and I hope Dave and others will agree, the primary goal is the ability to roll out new useful functions and services in a way in which they can be managed in a scalable manner, where one has understood the network impact (or total cost, if you will) for that service. And Section 2 provides a really nice illustration of that, with regard to what happened at Berkeley. I have another problem with 3.2: I think the SMI and other registry-based forms of structured data may be overrated in some cases. Sometimes what is being managed is very simple data, through a central service. One has to question who the consumer of the data is prior to determining how one encodes that data, or even what data is truly necessary. Consider the case of an application that is simply calling home to determine if there are patches. How much structured data does that service need? In this context, 3.2 is often irrelevant to the application running on some host, but it may be very relevant to the central system that is doing the updating. What I would suggest is that some additional context is necessary throughout the document to indicate really who we are talking to. Are we limiting our role to router management? What happened to the toaster with an SNMP stack? Would we use SNMP today for that toaster? Who would manage it? Well, let's put it in a more serious context and swap toaster for major appliance like air conditioner or refrigerator or PDU. Ok, and again. Thanks Dave and others for writing the doc. Eliot On 6/3/09 9:22 PM, Sam Hartman wrote: I was assigned this document as a secdir review. I'm not sure I have any comments in that capacity. However, I do have significant comments on the last call of this document. I appreciate the work that has gone into this document. People have worked hard to find examples, cases and even pithy sayings/architectural principles from many areas of the IETF. The document tries to be broad and to look at a lot of options. I think that it would be reasonable to publish this document as the current thinking of the ops WG or ops area. It may even be reasonable to use something like this as guidelines for network/routing/sub-network layer protocols to think about management and operations. However this document is not suitable for publication as a BCP because: * It does not reflect practices across significant areas of the IETF * It does not provide clear, actionable guidelines * It is not sufficiently clear to be understood outside the OM area. My background. I have never formally been involved in the OM area. However, I have studied SNMP as a participant and AD for the ISMS Wg. I have studied syslog as a user, operator, and as the AD who sponsored many of syslog's base documents. I have studied netconf as an AD who reviewed the spec. I've worked as a small enterprise operator. I'm a chair of a WG (LISP) that needs to consider operations and management issues. I believe that I should be able to read and understand this document; I believe that I'm well within its target audience. I got as far as the bottom of page 18 before giving up. Here are details on my concerns based on what part of the document I've read. I'm happy to invest significant time to get other reviewers to evaluate whether I have valid concerns; if I get others to read the document and consider whether I have a point, then I've done what I set out to do. 1) It does not reflect practices across significant areas of the IETF This is a concern that the document does not have broad enough consensus to be a BCP. I believe that significant areas of the IETF do not view management interoperability as a goal--much less a guiding principle of management. I've been involved in discussions in the Kerberos working group where we explicitly discussed this and came to the conclusion that management interoperability was not something anyone in the room was going to work on. We did work on an information model which covers aspects where people believed some degree of management interoperability would be desirable. It does not cover monitoring, faults, or the like--only provisioning of the database. Similarly, I'm quite certain that most web server vendors, ATOM
Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
At 12:22 03-06-2009, Sam Hartman wrote: I appreciate the work that has gone into this document. People have worked hard to find examples, cases and even pithy sayings/architectural principles from many areas of the IETF. The document tries to be broad and to look at a lot of options. I think that it would be reasonable to publish this document as the current thinking of the ops WG or ops area. It may even be reasonable to use something like this as guidelines for network/routing/sub-network layer protocols to think about management and operations. However this document is not suitable for publication as a BCP because: The document is a good piece of work. The considerations discussed in it may help other areas understand the thinking of the ops area as management and operations considerations are often overlooked. Bernard Aboba posted some interesting comments on Section 1 of this draft for the Last Call. I don't think that the document scales well from an IETF perspective as a BCP. As such, I do not support its publication as a BCP. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-enum-enumservices-guide (IANA Registration of Enumservices: Guide, Template and IANA Considerations) to Proposed Standard
Hello, Section 7.1 of draft-ietf-enum-3761bis-04 is about DNS Security. One sentence caught my attention: Because of these threats, a deployed ENUM service SHOULD include mechanisms to ameliorate these threats. My reading of that is that a deployed ENUM service should include mechanisms to make these threats better. :-) I suggest using mitigate (make less severe) instead of ameliorate. Repl sub-field is used throughout the document. There could be a reference to Section 3.2 of RFC 3402 to make that clearer. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP
Sam, Thank you for your review and opinions. I would like to remind you and let many people that are not aware about the history of the document know one fact that may be important. This document is an outcome of the discussions hold at the IESG retreat in May 2006. I was then the 'fresh' AD bringing this issue to the IESG table, we discussed approaches on dealing with management in the IETF and the need for a different approach of looking at management than the 'write a MIB' which was the rule in the IETF WGs until then. I took the action item to 'write a draft' on this issue - which then developped in this piece of work chartered in the OPSAWG. ... This is a concern that the document does not have broad enough consensus to be a BCP. I believe that significant areas of the IETF do not view management interoperability as a goal--much less a guiding principle of management. I've been involved in discussions in the Kerberos working group where we explicitly discussed this and came to the conclusion that management interoperability was not something anyone in the room was going to work on. We did work on an information model which covers aspects where people believed some degree of management interoperability would be desirable. It does not cover monitoring, faults, or the like--only provisioning of the database. Similarly, I'm quite certain that most web server vendors, ATOM implementors, etc do not want management interoperability. I understand that ISP operators very much do want management interoperability. I think that we have a significant conflict here and I think that we cannot approve such a BCP without addressing that conflict. One possible resolution would be to find an subsection of the IETF that actually agrees with these guidelines and scoping the BCP. Similarly, it has been my experience that the desire to standardize information model semantics is not universal across the IETF. I believe that the document recognizes the variance in approaches for the different areas, protocols, and working groups in the IETF and for this reason rightly avoids making a prescription or imposing a fixed solution or format in dealing with operational considerations and manageability aspects of the IETF protocols. I think that it does make however the point that operational deployment and manageability aspects need to be taken into considerations for any new IETF work. The awareness of these issue should exist in any work the IETF engages with, after all we develop technologies and protocols to be deployed and operated in the real life Internet, not abstract mathematical models. It is fine if a WG decides that its protocol needs not interoperable management or no standardized data model, but this should be the result of discussions and decisions, not of mission. Dan ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelinesfor Considering Operations and Management of New Protocols and ProtocolExtensions) to BCP
In the discussion of IETF consensus of this document and its position as a BCP or otherwise, can I throw into the melting pot draft-ietf-pce-manageability-requirements-06.txt This particular I-D was developed within the PCE working group to apply only in that working group. It covers similar topics, but is more focused on ensuring that the protocols that are developed in PCE are manageable. The I-D has rough WG consensus (or did at the time I stopped being chair a few months ago), but is not mandatory to implement within the WG. It is my opinion that those PCE I-Ds that have taken the draft on board have produced better solutions that will be more successfully implemented and deployed. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP
Dan == Romascanu, Dan (Dan) droma...@avaya.com writes: Dan Sam, Thank you for your review and opinions. Dan I would like to remind you and let many people that are not Dan aware about the history of the document know one fact that Dan may be important. This document is an outcome of the Dan discussions hold at the IESG retreat in May 2006. I was then Dan the 'fresh' AD bringing this issue to the IESG table, we Dan discussed approaches on dealing with management in the IETF Dan and the need for a different approach of looking at Dan management than the 'write a MIB' which was the rule in the Dan IETF WGs until then. I took the action item to 'write a Dan draft' on this issue - which then developped in this piece of Dan work chartered in the OPSAWG. I certainly appreciate the work that has gone into this draft. I'm not sure why the origins here are important. If you're saying that it should have special status because the original discussion happened at the IESG level, I disagree. If you're saying that the content has broad consensus because it started at the IESG level, I disagree. If you're saying that it's important work with a long history, I agree. Dan I believe that the document recognizes the variance in Dan approaches for the different areas, protocols, and working Dan groups in the IETF I strongly disagree that it succeeds in this goal. I agree it tries. As an example, section 3.1 says that the primary goal when considering management should be interoperability. That's a broad statement that does not have IETF consensus and is inappropriate for a BCP. Dan and for this reason rightly avoids making Dan a prescription or imposing a fixed solution or format in Dan dealing with operational considerations and manageability Dan aspects of the IETF protocols. I think that it does make Dan however the point that operational deployment and Dan manageability aspects need to be taken into considerations Dan for any new IETF work. The awareness of these issue should Dan exist in any work the IETF engages with, after all we develop Dan technologies and protocols to be deployed and operated in the Dan real life Internet, not abstract mathematical models. It is Dan fine if a WG decides that its protocol needs not Dan interoperable management or no standardized data model, but Dan this should be the result of discussions and decisions, not Dan of mission. It's not at all clear to me from this document that would be fine. That's one of my most serious problems with the document. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP
Hi Sam, A clarification and a clarification question in-line. Dan -Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Thursday, June 04, 2009 2:23 PM To: Romascanu, Dan (Dan) Cc: Sam Hartman; ietf@ietf.org; ops...@ietf.org Subject: Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP Dan == Romascanu, Dan (Dan) droma...@avaya.com writes: Dan Sam, Thank you for your review and opinions. Dan I would like to remind you and let many people that are not Dan aware about the history of the document know one fact that Dan may be important. This document is an outcome of the Dan discussions hold at the IESG retreat in May 2006. I was then Dan the 'fresh' AD bringing this issue to the IESG table, we Dan discussed approaches on dealing with management in the IETF Dan and the need for a different approach of looking at Dan management than the 'write a MIB' which was the rule in the Dan IETF WGs until then. I took the action item to 'write a Dan draft' on this issue - which then developped in this piece of Dan work chartered in the OPSAWG. I certainly appreciate the work that has gone into this draft. I'm not sure why the origins here are important. If you're saying that it should have special status because the original discussion happened at the IESG level, I disagree. If you're saying that the content has broad consensus because it started at the IESG level, I disagree. If you're saying that it's important work with a long history, I agree. None of these - just background information to place this document in context. ... Dan and for this reason rightly avoids making Dan a prescription or imposing a fixed solution or format in Dan dealing with operational considerations and manageability Dan aspects of the IETF protocols. I think that it does make Dan however the point that operational deployment and Dan manageability aspects need to be taken into considerations Dan for any new IETF work. The awareness of these issue should Dan exist in any work the IETF engages with, after all we develop Dan technologies and protocols to be deployed and operated in the Dan real life Internet, not abstract mathematical models. It is Dan fine if a WG decides that its protocol needs not Dan interoperable management or no standardized data model, but Dan this should be the result of discussions and decisions, not Dan of mission. It's not at all clear to me from this document that would be fine. That's one of my most serious problems with the document. Can you clarify? I cannot understand what is clear to you and what is not, and with which statement you do not agree. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-dawkins-nomcom-dont-wait (Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers) to BCP
On Wed, 27 May 2009, The IESG wrote: - 'Nominating Committee Process: Earlier Announcement of Open Positions and Solicitation of Volunteers' draft-dawkins-nomcom-dont-wait-03.txt as a BCP I have two issues with this. 1) This places a new responsibility at the feet of IETF secretariat. That's a new actor (not even a person but a role) in the process. This is not good. Better would be that the process allowed some already responsible party (be it ISOC president, former NomCom chair, IETF chair, IAB chair, or all of the above) the _option_ to allow IETF secretariat to perform this announcement. (More about the option issue below) 2) As proposed, the IETF secretariat's role is exclusive. In the future no one else would have the authority to publish the solicitation. I don't think this is good. The role should be optional, if _responsible_ party(ies) chooses to take that path, or at most inclusive of other parties' authority. More detailed background on 2) below: Abstract says: This document updates RFC 3777, Section 4, Bullet 13 to allow announcement of open positions and solicitation of volunteers to be issued before a Nominating and Recall Committee Chair has been named by the Internet Society President. But the new bullet says: The IETF Secretariat obtains the list of positions to be reviewed and announces it along with a solicitation for names of volunteers from the IETF community willing to serve on the nominating committee. At the NomCom Chair's request, the IETF Secretariat may perform other clerical support tasks, as long as the task being performed does not require NomCom Chair judgement, in the NomCom Chair's opinion, and as long as the community is appropriately notified that this request is being made. This request may come from the Incoming NomCom Chair (if one has been selected for this NomCom cycle) or the Outgoing NomCom Chair (if the search for an Incoming NomCom Chair is still underway). Allow can be read two ways, one of them conflicts with the actual text. Is the intent that the IETF Secretariat has an authority to obtain the list of positions and announce them (but other parties also have this authority), OR that it has the ONLY authority. The narrow reading of the actual text above suggests that in the future no one else could do the announcement. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS Additional Section Processing Globally Wrong
Sabahattin Gucukoglu wrote: Glue data, additional and non-authoritative by design, intent and specification, aren't what I want caches to keep. You had better cache glue As, as long as they are tagged as glue As with a domain name of query. Then, the cached information may be used as glue in additional section but not in answer section. It is not a problem if a glue A in additional section is cached and reused as a glue A in additional section to similar query. As a matter of fact, it never occurred to me to wonder at this misbehaviour The misbehavior was present because most, if not all, implementations cache both glue and authoritative answers but did not distinguish them by appropriate tagging. As I have been warning on the problem for these 15 years, some implementation may hopefully be fixed. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP
[this one more publicly] Dan, Based on the goals you set out below, I would argue that the document is too long. I would recommend sticking with principles and calling out a few examples. I think this is done reasonably well in Section 2, and less so elsewhere. I would also suggest that you scope the document, because what you write below wasn't clear to me on first read. Eliot On 6/4/09 11:16 AM, Romascanu, Dan (Dan) wrote: Sam, Thank you for your review and opinions. I would like to remind you and let many people that are not aware about the history of the document know one fact that may be important. This document is an outcome of the discussions hold at the IESG retreat in May 2006. I was then the 'fresh' AD bringing this issue to the IESG table, we discussed approaches on dealing with management in the IETF and the need for a different approach of looking at management than the 'write a MIB' which was the rule in the IETF WGs until then. I took the action item to 'write a draft' on this issue - which then developped in this piece of work chartered in the OPSAWG. ... This is a concern that the document does not have broad enough consensus to be a BCP. I believe that significant areas of the IETF do not view management interoperability as a goal--much less a guiding principle of management. I've been involved in discussions in the Kerberos working group where we explicitly discussed this and came to the conclusion that management interoperability was not something anyone in the room was going to work on. We did work on an information model which covers aspects where people believed some degree of management interoperability would be desirable. It does not cover monitoring, faults, or the like--only provisioning of the database. Similarly, I'm quite certain that most web server vendors, ATOM implementors, etc do not want management interoperability. I understand that ISP operators very much do want management interoperability. I think that we have a significant conflict here and I think that we cannot approve such a BCP without addressing that conflict. One possible resolution would be to find an subsection of the IETF that actually agrees with these guidelines and scoping the BCP. Similarly, it has been my experience that the desire to standardize information model semantics is not universal across the IETF. I believe that the document recognizes the variance in approaches for the different areas, protocols, and working groups in the IETF and for this reason rightly avoids making a prescription or imposing a fixed solution or format in dealing with operational considerations and manageability aspects of the IETF protocols. I think that it does make however the point that operational deployment and manageability aspects need to be taken into considerations for any new IETF work. The awareness of these issue should exist in any work the IETF engages with, after all we develop technologies and protocols to be deployed and operated in the real life Internet, not abstract mathematical models. It is fine if a WG decides that its protocol needs not interoperable management or no standardized data model, but this should be the result of discussions and decisions, not of mission. Dan ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
On Wed, Jun 03, 2009 at 03:27:42PM +0900, Masataka Ohta wrote: Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. You know, the former operation is much simpler, thus more secure, than the latter. If an attacker can get its bogus data into the referring zone, who cares whether it's NS data or DS data? One of the important things we are trying to add with DNSSEC is some means of assuring ourselves that the referral we got was the one that comes from the actual authority for that referall, rather than some other agent spoofing the response. DNSSEC appears to provide that assurance, and so far you have provded not one jot of evidence that it does not. I fail completely to see how it is easier to put the wrong DS record in the parent than it is to inject bad NS data in there. If you can put illegitimate data in, there are two possibilities: 1. You put it in via some legitimized mechanism (e.g. via SQL injection, you manage to get data that wasn't intended to be in the zone into the zone). This causes that illegitimate data to be treated as legitimate, and probably signed and such. This is a bad attack, of course, but it is available today. This is no different than being able to plant some evil file on the corporate file server inside the VPN: the security is breached not by failure of its mechanisms, but by failure of authentication. DNSSEC doesn't solve this, I agree; that's because the _provisioning_ of data is beyond the scope of the DNS protocol itself. In any case, surely a more effective attack in this case is to get phony NS or A data (or whatever) into the zone than to put phony DS data. The latter will get you at best a DoS, whereas the former allows you to take control of the target zone. 2. You put it in via some illegitimate mechanism (e.g. by intercepting the wire transmission and adding the data to the stream). Unless the keys are somehow compromised, this vulnerability is exactly what DNSSEC aims to stop. I don't see any argument from you that this DNSSEC capability is not effective. If you have such an argument, it'd be nice to hear it before we continue with the efforts at deployment. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-geopriv-lbyr-requirements-07
Thanks for review ... just wanted to respond to one point in this. On Jun 3, 2009, at 4:47 PM, Spencer Dawkins wrote: C5. User Identity Protection: The location URI MUST NOT contain information that identifies the user or device. Examples include phone extensions, badge numbers, first or last names. Spencer (minor): this is probably a good idea, but I'm not sure it's a 2119 MUST (NOT). How would you recognize this on the wire (do you know what MY badge number is :-)? There is the age old discussion about what 2119 means in a requirement document, but I'm trying to ignore that and just go with how well this conveys the intent of the WG to future readers. I agree we could not really black box test this but I think it does get to the essence of what the requirement is. Even last names might be hard to tell they are a last name, I hear rumor that google thinks Tschofenig is a strong password though I note is is a very common word to find in internet drafts :-) Anyways, I can't think of a better way to write this requirement so unless someone has a concrete proposal, I suspect I will just leave as is. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP
Adopting this document as a BCP would be a serious mistake, and I hope it will be strongly opposed. There is absolutely no evidence that following the dictates of this document will improve the quality of the IETF's work, and we certainly know it won't improve the timeliness. There is no evidence that ignoring it will harm the Internet. I don't see that OPSAWG has any business imposing requirements on work done by other WGs in other Areas. There are already an adequate number of obstacles to getting work done. The last thing we need is another required considerations section, or another set of excuses for ADs from one Area to block documents from other Areas. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
So, there is no point to deploy DNSSEC. no ? http://jprs.co.jp/en/topics/081125.html regards Marc -- Les enfants teribbles - research / deployment Marc Manthey Vogelsangerstrasse 97 D - 50823 Köln - Germany Vogelsangerstrasse 97 Geo: 50.945554, 6.920293 PGP/GnuPG: 0x1ac02f3296b12b4d Tel.:0049-221-29891489 Mobil:0049-1577-3329231 web : http://www.let.de Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. PGP.sig Description: Signierter Teil der Nachricht ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
Hi - From: Eliot Lear l...@cisco.com To: Sam Hartman hartmans-i...@mit.edu Cc: ops...@ietf.org; ietf@ietf.org Sent: Wednesday, June 03, 2009 11:15 PM Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP ... Also, I agree with you that interoperability is not the first and primary goal. Clearly, and I hope Dave and others will agree, the primary goal is the ability to roll out new useful functions and services in a way in which they can be managed in a scalable manner, where one has understood the network impact (or total cost, if you will) for that service. And Section 2 provides a really nice illustration of that, with regard to what happened at Berkeley. Unfortunately, I think the IETF has only adopted the first sentence of this paragraph. The hard work (and it is hard work) to build interoperable *management* seems to have largely been abandoned in the IETF. I think the state of the netconf work attests to the shift to just shoveling around vendor-specific blobs, rather than management information. I have another problem with 3.2: I think the SMI and other registry-based forms of structured data may be overrated in some cases. They're not a panacea. The SMI has weaknesses that can make models cumbersome. I haven't seen a data representation or way of representing data semantics that was ideal for all purposes, and I doubt I ever will. Unfortunately, this recognition that nothing is perfect seems to have led the IETF dangerously close to anything goes. One would hope that this document would help WGs avoid the worst excesses. Sometimes what is being managed is very simple data, through a central service. One has to question who the consumer of the data is prior to determining how one encodes that data, or even what data is truly necessary. Consider the case of an application that is simply calling home to determine if there are patches. How much structured data does that service need? If there will ever be more than one patch, if there are dependencies between patches, if there is every the need to revert, if there are hardware or model dependencies It's really easy to over-simplify, and end up needing a whole bundle of band-aids as the system's needs evolve (or are recognized). ... What I would suggest is that some additional context is necessary throughout the document to indicate really who we are talking to. Are we limiting our role to router management? What happened to the toaster with an SNMP stack? Would we use SNMP today for that toaster? Who would manage it? Well, let's put it in a more serious context and swap toaster for major appliance like air conditioner or refrigerator or PDU. The IETF management discussions have increasingly limited themselves to what it takes to manage a few types of network gear. It seems to me that the IETF abandoned any hope of doing system management, or even management of multi-vendor systems, a long time ago. This may be a bug, this may be a feature. The thrust of this document seems to me to be a recognition of this state of affairs, and that consequently, if we're going to let a thousand vendor- or application-specific flowers bloom, a little advice to help avoid some of the mistakes of the past would be helpful. Consequently, I think having this document is a good thing. The advice it gives reflects the current fragmented state of affairs with respect to management information, and would be useful to folks trying to do a good job in this environment. I can support this as an informational document. I could somewhat reluctantly go along with making it BCP - our experience with that catch-all designation makes it clear that Best only means what we could more-or-less agree on and Current can mean we really hope something better will come along, but aren't going to hold our breath. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Call for Participation: homegate List
This is an open call for participation in the new ³homegate² mailing list, which is dedicated to discussing issues relating to broadband home gateway devices. There has been a BoF request submitted relating to this, which you can find at http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/HomeGate%20BoF %20Proposal%20-%20IETF%2075%20-%20v7.pdf. This work is centered on three key themes: (1) work to improve the network experience a home user gets, (2) work to keep home networks secure, and (3) work to bring new functionality to home users. You can find many more details in the PDF document that is referred to above. If this topic is of interest to you, please join our new mailing list at https://www.ietf.org/mailman/listinfo/homegate. One of our first discussions for the mailing list will be to discuss a problem statement, work on a possible draft charter, and more. Regards Jason Livingood ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP
Joel M. Halpern wrote: To put it differently, the OPS area has as much right to propose their requirements as any other area (Transport Congestion, Security, ...) has. And generally, the community has listened to such requests and gone along with them. Yes, we have produced a bit of a problem that our initial standards now have a quality bar comparable with completed work. But we shouldn't suddenly pick on OPS for that. If we are going to address that problem, it ought to be in a coherent fashion that discusses how we deal with all the legitimate requirements, including the fact that stuff has to be operable. I agree, and I also agree with Randy about the lack of standardized NETCONF content. It is a clear indication that the vendors do not want any standardized configuration content. Every time 'content' has come up for charter consideration, the consensus has been to work on something else instead. But the NETCONF/YANG pieces are coming together, and it will allow WGs much more power and flexibility than SNMP/SMIv2 to define management interfaces which fit better with the native CLI than anything the IETF has had before. That is about as far as OPS-NM area can go. If a protocol WG do not want to define a standard configuration interface, then it does not matter how well SNMP or NETCONF supports this sort of work. (One might question whether using the same NM standardization methodology for 20 years and achieving consistently pathetic results means the methodology itself needs to be changed, not just the technology.) This does not mean we have to simply accept what they (OSP) say. But it does mean we should give it a fair review, looking at the details, rather than objecting on principle. Yours, Joel M. Halpern Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP
This does not mean we have to simply accept what they (OPS) say. But it does mean we should give it a fair review, looking at the details, rather than objecting on principle. This is absolute nonsense. Most of the people actually doing work in the various areas do not have the time, interest, or expertise to do a detailed review of an OPS document. However, these are the people who are in the best position to determine whether OAM Considerations would help or hinder the work that they do. If we are going to talk about adding new hoops for folks to jump through, we should first discuss whether any such hoops are necessary. We should not start the discussion by looking at the details of the particular proposed hoops. the OPS area has as much right to propose their requirements as any other area (Transport Congestion, Security, ...) has. And generally, the community has listened to such requests and gone along with them. Generally, the community (i.e., the folks doing the work in the various areas) has never even heard about these proposed requirements until after a BCP appears, at which time they are told that the BCP has community consensus. Perhaps you're familiar with Douglas Adams' The Hitchhiker's Guide to the Galaxy. To paraphrase, but the plan for the destruction of earth was clearly posted in the planning department on alpha centauri, it's not our fault you didn't see it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP
Eric == Eric Rosen ero...@cisco.com writes: Eric If we are going to talk about adding new hoops for folks to Eric jump through, we should first discuss whether any such hoops Eric are necessary. We should not start the discussion by Eric looking at the details of the particular proposed hoops. Agreed. I think that if we don't have agreement with the goals/high-level of this type of proposal, it's completely reasonable to block review of details until that reaches agreement. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP
Eric == Eric Rosen ero...@cisco.com writes: Eric I don't see that OPSAWG has any business imposing Eric requirements on work done by other WGs in other Areas. Obviously I agree with this statement. However I do believe that the ops area can propose and build consensus on requirements that we all agree to follow. I think this document may be a starting point in such a discussion. I think Eric and I probably both agree it should not be the final word. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management(Guidelines for Considering Operations and Management of NewProtocols and Protocol Extensions) to BCP
To put it differently, the OPS area has as much right to propose their requirements as any other area (Transport Congestion, Security, ...) has. And generally, the community has listened to such requests and gone along with them. Yes, we have produced a bit of a problem that our initial standards now have a quality bar comparable with completed work. But we shouldn't suddenly pick on OPS for that. If we are going to address that problem, it ought to be in a coherent fashion that discusses how we deal with all the legitimate requirements, including the fact that stuff has to be operable. This does not mean we have to simply accept what they (OSP) say. But it does mean we should give it a fair review, looking at the details, rather than objecting on principle. Yours, Joel M. Halpern Sam Hartman wrote: Eric == Eric Rosen ero...@cisco.com writes: Eric I don't see that OPSAWG has any business imposing Eric requirements on work done by other WGs in other Areas. Obviously I agree with this statement. However I do believe that the ops area can propose and build consensus on requirements that we all agree to follow. I think this document may be a starting point in such a discussion. I think Eric and I probably both agree it should not be the final word. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-geopriv-http-location-delivery-14 Reviewer: Ben Campbell Review Date: 2009-06-04 IETF LC End Date: 2009-06-09 IESG Telechat date: (if known) Summary: This draft is ready for publication as a proposed standard. I have a few editorial and clarity comments that might could slightly improve the draft, but can safely be ignored. Additionally, I have one comment highlighting a feature that is not necessarily a problem, but is architecturally important enough that I want to make sure the IESG thinks about it. Major issues: None. Minor issues: -- There is one feature of HELD that the ADs should explicitly think about: The HTTP binding forbids LIS reliance on HTTP digest or basic authentication. If I understand correctly, this means effectively that the _only_ method for client authentication is the built in reverse routeability test. I am agnostic as to whether this is sufficient. Nits/editorial comments: -- section 4, paragraph 1: Please expand (and reference) PIDF-LO on first mention. -- Section 6.2, value list: -- In my previous review, I was confused as to the relationship between the geodetic/civic and LoBV/LoBR choices. I think it's worth some clarification in this section that geodetic and civic imply LoBV. -- section 9.3, 5th paragraph: A temporary spoofing of IP address could mean that a device could request a Location Object or Location URI that would result in another Device's location. It might be worth clarifying that (if I understand correctly) that this is more than a spoofing attack, in that the attacker must not only spoof its source address, but must be able to receive packets sent to the spoofed address? -- same paragraph: ... re-use of the Device's IP address could result in another Device receiving the original Device's location rather than its own location. It seems like this problem is pretty unlikely to occur by _accident_ when HELD is used over TCP (the only binding right now), right? And certain not to happen over TLS? Might be worth a mitigating mention. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
Marc Manthey wrote: So, there is no point to deploy DNSSEC. no ? No, no point. http://jprs.co.jp/en/topics/081125.html FYI, JPRS, which is a commercial entity to administrate JP domain, is commercially motivated not to admit it merely an untrustworthy third party. In general, registries welcome DNSSEC, no matter how secure it is, as long as its complicated operation works as an excuse to increase (or not to reduce) registration charge and registries' revenue. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
Andrew Sullivan wrote: Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. If an attacker can get its bogus data into the referring zone, I never said such a thing. I said issue certificates over forged keys of child zones. The attack is possible by those who have access to signature generation mechanisms and the attack is not visible until the false certificates are used later. People introduced DNSSEC believing DNSSEC makes cache poisoning not a problem, are ready to accept false certificates through unprotected cache. Thus, we must, anyway, protect cache. Then, where is the point to introduce DNSSEC only to have another possibility of security holes? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
On Jun 3, 2009, at 8:35 PM, Masataka Ohta wrote: The problem is that the accuracy and integrity of DNSSEC is not cryptographically, but socially secure. DNS over UDP is prone to port/transaction-id guessing, where cryptography could play a protective role. The risk of these values being guessed increases whenever NATs reduce port diversity, or operate in a predictable manner. Protocols such as SPF that embed macros into DNS, allow hundreds of transactions to be chained. The entire chain might result from the local-parts of a single email. These transactions can target otherwise uninvolved victims or evil domains. When an evil domain is the target of SPF transactions, attackers can discover the nature of the resolver. Afterwords, with only one transaction targeting the evil domain, and others targeting their victim, the guesswork for injecting poison is reduced, where even ACLs offer no protection. The growing speed of today's Internet makes this an ever growing concern. While DNSSEC might prevent caches from being poisoned, EDNS0 creates new concerns also aggravated by SPF. Since the 512 byte DNS message size did not accommodate RSA signatures, EDNS0 is required to adjust message limits. EDNS0 allows bad actors to further leverage DNS transactions, such as those that might emanate from cached SPF records to initiate more than 20 TXT record transactions when a recipient evaluates a single email. The TXT records might be policy documents not intended for machine consumption or wildcard SPF records enumerating address authorizations for outbound MTAs. The flexibility sought by SPF has created a sizable list of concerns, where caution was often countered with distain for DNS. It might have been better to have specified limits for EDNS0, such as a minimum message size of 1280 and a maximum at 1424, where transactions that don't comply are refused. UDP allows source spoofing, which could allow bad actors a means to create packet fragmentation by incorrectly setting message. If addition, when fragmentation does occur, DNS transactional-ids offer little protection for packet fragments that may contained unsigned information. DNS will need to be become pedantic about confirming information, perhaps also enforcing the use of checksums and message size. While DNSSEC may not require channel security at some point when a trust anchor can be safely found, DNS over UDP remains a brute. When an SPF process sequence prematurely times out, rather than waiting for exponential back-off, SPF simply begins another sequence, ignoring congestion avoidance. SCTP carrying either DNS or DNSEC packets would ensure DNS remains tame despite much of the abuse. Unlike TCP, SCTP does not commit resources without return of a cookie, but can start data exchanges sooner. SCTP can carry simultaneous DNS messages and can can keep a large number of sparse connections per port active. Perhaps recursive resolvers might be more responsive with SCTP than with UDP. Importantly, the source of abusive DNS behavior can be identified and thereby avoided. This is not true for either TCP or UDP. -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
In message 4a285750.9010...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes: Andrew Sullivan wrote: Though we have to trust the zone administration put correct referral and glue data in a master zone file, unless we use DNSSEC, we don't have to trust the zone administration never issue certificates over forged keys of child zones. If an attacker can get its bogus data into the referring zone, I never said such a thing. I said issue certificates over forged keys of child zones. The attack is possible by those who have access to signature generation mechanisms and the attack is not visible until the false certificates are used later. People introduced DNSSEC believing DNSSEC makes cache poisoning not a problem, are ready to accept false certificates through unprotected cache. Thus, we must, anyway, protect cache. Then, where is the point to introduce DNSSEC only to have another possibility of security holes? We still lock doors and windows despite the possiblity of people breaking in by lifting tiles. Attacks at the registry level are the equivalient of lifting tiles. It happens sometimes. Locking the doors and windows stops most attacks however. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-geopriv-lbyr-requirements-07
On Jun 4, 2009, at 9:24 AM, Cullen Jennings wrote: Thanks for review ... just wanted to respond to one point in this. On Jun 3, 2009, at 4:47 PM, Spencer Dawkins wrote: C5. User Identity Protection: The location URI MUST NOT contain information that identifies the user or device. Examples include phone extensions, badge numbers, first or last names. Spencer (minor): this is probably a good idea, but I'm not sure it's a 2119 MUST (NOT). How would you recognize this on the wire (do you know what MY badge number is :-)? There is the age old discussion about what 2119 means in a requirement document, but I'm trying to ignore that and just go with how well this conveys the intent of the WG to future readers. I agree we could not really black box test this but I think it does get to the essence of what the requirement is. Even last names might be hard to tell they are a last name, I hear rumor that google thinks Tschofenig is a strong password though I note is is a very common word to find in internet drafts :-) Anyways, I can't think of a better way to write this requirement so unless someone has a concrete proposal, I suspect I will just leave as is. Say WHY it MUST NOT. All 2119 language needs explanation; you MUST NOT include identifying information because if you do, that information will be revealed to attackers, who may exercise it in attacks. Such attacks include but are not limited to social engineering, impersonation, stalking, extortion, and pretending to be an Area Director . . . In other words, when you use 2119 language to explain a requirement, explain the rationale for that requirement; in particular explain what happens (or becomes possible) if the requirement is violated. Unsubstantiated dogma is doggerel. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 110 messages in the last 7 days. script run at: Fri Jun 5 00:53:02 EDT 2009 Messages | Bytes| Who +--++--+ 13.64% | 15 | 10.40% |73803 | mo...@necom830.hpcl.titech.ac.jp 7.27% |8 | 6.18% |43869 | ma...@isc.org 5.45% |6 | 5.99% |42530 | john-i...@jck.com 5.45% |6 | 3.75% |26634 | p...@xelerance.com 4.55% |5 | 3.45% |24454 | ves...@tana.it 2.73% |3 | 4.84% |34315 | bapti...@publicroot.org 3.64% |4 | 3.88% |27514 | thierry.mor...@connotech.com 3.64% |4 | 3.66% |25958 | hartmans-i...@mit.edu 3.64% |4 | 3.37% |23944 | jari.ar...@piuha.net 3.64% |4 | 2.67% |18942 | francis.dup...@fdupont.fr 2.73% |3 | 2.54% |18040 | s...@resistor.net 2.73% |3 | 2.52% |17862 | a...@shinkuro.com 1.82% |2 | 3.32% |23553 | l...@cisco.com 1.82% |2 | 2.49% |17636 | pek...@netcore.fi 1.82% |2 | 1.99% |14146 | droma...@avaya.com 1.82% |2 | 1.85% |13124 | j...@joelhalpern.com 1.82% |2 | 1.75% |12439 | ero...@cisco.com 1.82% |2 | 1.64% |11633 | m...@sabahattin-gucukoglu.com 1.82% |2 | 1.62% |11503 | rbar...@bbn.com 0.91% |1 | 2.19% |15535 | m...@macchiato.com 0.91% |1 | 1.88% |13314 | ana...@cisco.com 0.91% |1 | 1.68% |11914 | f...@cisco.com 0.91% |1 | 1.67% |11860 | skar...@verisign.com 0.91% |1 | 1.62% |11481 | spen...@wonderhamster.org 0.91% |1 | 1.59% |11297 | m...@let.de 0.91% |1 | 1.18% | 8404 | pat...@frobbit.se 0.91% |1 | 1.18% | 8391 | doug.mtv...@gmail.com 0.91% |1 | 1.15% | 8190 | randy_pres...@mindspring.com 0.91% |1 | 1.13% | 8007 | nar...@us.ibm.com 0.91% |1 | 1.01% | 7197 | jason_living...@cable.comcast.com 0.91% |1 | 1.00% | 7078 | lcon...@insensate.co.uk 0.91% |1 | 0.98% | 6977 | o...@nlnetlabs.nl 0.91% |1 | 0.98% | 6960 | j...@jck.com 0.91% |1 | 0.93% | 6597 | bmann...@isi.edu 0.91% |1 | 0.90% | 6418 | d3e...@gmail.com 0.91% |1 | 0.87% | 6198 | a...@netconfcentral.com 0.91% |1 | 0.84% | 5988 | b...@estacado.net 0.91% |1 | 0.82% | 5854 | david.kess...@nsn.com 0.91% |1 | 0.82% | 5814 | flu...@cisco.com 0.91% |1 | 0.79% | 5618 | rpellet...@isoc.org 0.91% |1 | 0.77% | 5463 | michael.tue...@lurchi.franken.de 0.91% |1 | 0.76% | 5420 | huit...@windows.microsoft.com 0.91% |1 | 0.74% | 5248 | d...@virtualized.org 0.91% |1 | 0.73% | 5208 | hous...@vigilsec.com 0.91% |1 | 0.70% | 5001 | mstjo...@comcast.net 0.91% |1 | 0.69% | 4922 | d...@cridland.net 0.91% |1 | 0.69% | 4900 | do...@mail-abuse.org 0.91% |1 | 0.64% | 4560 | adr...@olddog.co.uk 0.91% |1 | 0.58% | 4151 | d...@ewellic.org 0.91% |1 | 0.53% | 3795 | iljit...@muada.com +--++--+ 100.00% | 110 |100.00% | 709659 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-pcn-marking-behaviour (Metering and marking behaviour of PCN-nodes) to Proposed Standard
The IESG has received a request from the Congestion and Pre-Congestion Notification WG (pcn) to consider the following document: - 'Metering and marking behaviour of PCN-nodes ' draft-ietf-pcn-marking-behaviour-03.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 substantive comments to the i...@ietf.org mailing lists by 2009-06-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17745rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-tcpm-rfc2581bis (TCP Congestion Control) to Draft Standard
The IESG has received a request from the TCP Maintenance and Minor Extensions WG (tcpm) to consider the following document: - 'TCP Congestion Control ' draft-ietf-tcpm-rfc2581bis-05.txt as a Draft Standard The implementation report supporting the advancement to Draft Standard is at: http://www.ietf.org/mail-archive/web/tcpm/current/msg03133.html The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-18. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rfc2581bis-05.txt Implementation Report can be accessed at http://www.ietf.org/IESG/implementation.html IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14183rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
