Fwd: RAI AD - Gonzalo will not be re-running
FYI. I have been asked to share the email below on this list as well. Gonzalo Original Message Subject: RAI AD - Gonzalo will not be re-running Date: Tue, 01 Oct 2013 10:58:25 +0200 From: Gonzalo Camarillo gonzalo.camari...@ericsson.com To: r...@ietf.org Folks, this email is to inform everyone that I am not going to be seeking a third term as RAI Area Director. This means that the nomcom will need to choose someone else to serve as RAI AD after my current term ends in March. The consensus in the community seems to be that ADs SHOULD NOT serve more than 4 years, and I fully agree with that. Such a limit is good for the IETF and good for the ADs as well for a number of reasons. The main reason I am writing this email is to give potential candidates enough time to secure management support (or, in general, funding) in order to provide the nomcom with enough good candidates. You can find the expertise required for the position in the following link: https://datatracker.ietf.org/nomcom/2013/expertise/ Additionally, RAI ADs have traditionally selected the beverages for the IESG social gatherings, which is also an important skill ;-) Cheers, Gonzalo
Re: [Tools-discuss] independant submissions that update standards track, and datatracker
Hi Michael, I agree that it should appear in related WG's field or area. I see in IETF we have WGs documents list but not areas' documents list, so the individual document may not be found or discovered. I think any document of IETF should be listed in its field area or related charter, but it seems like the culture of IETF focusing on groups work not on the IETF documents. For example, when I first joined MANET WG I thought that RFC3753 is related because it is IETF, but in one discussion one participant did not accept to use that document even though it was related. Fuethermore, some WGs don't comment on related documents to their WG, which I think this should change in future IETF culture (e.g. there was one individual doc that was requested by AD to comment on by the WG but no respond). Therefore, IMHO, the IETF is divided by groups with different point of views/documents and they force their WG Adopted-Work to list documents (not all related to Group-Charters), but it seems that managemnet does not see that there is a division in knowledge or in outputs of the IETF, which a new comer may see it clearly. I recommend to focus/list documents related to Charter, not related to WG adoptions, because all IETF document are examined by IESG. AB On Tue, Oct 1, 2013 at 7:29 PM, Michael Richardson mcr+i...@sandelman.cawrote: This morning I had reason to re-read parts of RFC3777, and anything that updated it. I find the datatracker WG interface to really be useful, and so I visited http://datatracker.ietf.org/wg/nomcom/ first. I guess I could have instead gone to: http://www.rfc-editor.org/info/rfc3777 but frankly, I'm often bad with numbers, especially when they repeat... (3777? 3737? 3733?) While http://datatracker.ietf.org/wg/nomcom/ lists RFC3777, and in that line, it lists the things that update it, it doesn't actually list the other documents. Thinking this was an error, I asked, and Cindy kindly explained: http://datatracker.ietf.org/wg/nomcom/ lists the documents that were published by the NOMCOM Working Group. The NOMCOM Working Group was open from 2002-2004, and only produced one RFC, which is RFC 3777. The RFCs that update 3777 were all produced by individuals (that is, outside of the NOMCOM Working Group), and so aren't listed individually on the NOMCOM Working Group documents page. I wonder about this as a policy. Seeing the titles of those documents would have helped me find what I wanted quickly (RFC5680 it was)... While I think that individual submissions that are not the result of consensus do not belong on a WG page. But, if the document was the result of consensus, but did not occur in a WG because the WG had closed, I think that perhaps it should appear there anyway. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works ___ Tools-discuss mailing list tools-disc...@ietf.org https://www.ietf.org/mailman/listinfo/tools-discuss
RE: [Tools-discuss] independant submissions that update standards track, and datatracker
Irrepressible Yours Irrespectively, John From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun Sent: Wednesday, October 02, 2013 5:19 AM To: Michael Richardson Cc: ietf; tools-disc...@ietf.org Subject: Re: [Tools-discuss] independant submissions that update standards track, and datatracker Hi Michael, I agree that it should appear in related WG's field or area. I see in IETF we have WGs documents list but not areas' documents list, so the individual document may not be found or discovered. I think any document of IETF should be listed in its field area or related charter, but it seems like the culture of IETF focusing on groups work not on the IETF documents. For example, when I first joined MANET WG I thought that RFC3753 is related because it is IETF, but in one discussion one participant did not accept to use that document even though it was related. Fuethermore, some WGs don't comment on related documents to their WG, which I think this should change in future IETF culture (e.g. there was one individual doc that was requested by AD to comment on by the WG but no respond). Therefore, IMHO, the IETF is divided by groups with different point of views/documents and they force their WG Adopted-Work to list documents (not all related to Group-Charters), but it seems that managemnet does not see that there is a division in knowledge or in outputs of the IETF, which a new comer may see it clearly. I recommend to focus/list documents related to Charter, not related to WG adoptions, because all IETF document are examined by IESG. AB On Tue, Oct 1, 2013 at 7:29 PM, Michael Richardson mcr+i...@sandelman.camailto:mcr+i...@sandelman.ca wrote: This morning I had reason to re-read parts of RFC3777, and anything that updated it. I find the datatracker WG interface to really be useful, and so I visited http://datatracker.ietf.org/wg/nomcom/ first. I guess I could have instead gone to: http://www.rfc-editor.org/info/rfc3777 but frankly, I'm often bad with numbers, especially when they repeat... (3777? 3737? 3733?) While http://datatracker.ietf.org/wg/nomcom/ lists RFC3777, and in that line, it lists the things that update it, it doesn't actually list the other documents. Thinking this was an error, I asked, and Cindy kindly explained: http://datatracker.ietf.org/wg/nomcom/ lists the documents that were published by the NOMCOM Working Group. The NOMCOM Working Group was open from 2002-2004, and only produced one RFC, which is RFC 3777. The RFCs that update 3777 were all produced by individuals (that is, outside of the NOMCOM Working Group), and so aren't listed individually on the NOMCOM Working Group documents page. I wonder about this as a policy. Seeing the titles of those documents would have helped me find what I wanted quickly (RFC5680 it was)... While I think that individual submissions that are not the result of consensus do not belong on a WG page. But, if the document was the result of consensus, but did not occur in a WG because the WG had closed, I think that perhaps it should appear there anyway. -- Michael Richardson mcr+i...@sandelman.camailto:mcr%2bi...@sandelman.ca, Sandelman Software Works ___ Tools-discuss mailing list tools-disc...@ietf.orgmailto:tools-disc...@ietf.org https://www.ietf.org/mailman/listinfo/tools-discuss
RE: [Tools-discuss] independant submissions that update standards track, and datatracker
because all IETF document are examined by IESG No they're not. See RFC4844. Lloyd Wood http://sat-net.com/L.Wood/ From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Abdussalam Baryun [abdussalambar...@gmail.com] Sent: 02 October 2013 13:18 To: Michael Richardson Cc: ietf; tools-disc...@ietf.org Subject: Re: [Tools-discuss] independant submissions that update standards track, and datatracker Hi Michael, I agree that it should appear in related WG's field or area. I see in IETF we have WGs documents list but not areas' documents list, so the individual document may not be found or discovered. I think any document of IETF should be listed in its field area or related charter, but it seems like the culture of IETF focusing on groups work not on the IETF documents. For example, when I first joined MANET WG I thought that RFC3753 is related because it is IETF, but in one discussion one participant did not accept to use that document even though it was related. Fuethermore, some WGs don't comment on related documents to their WG, which I think this should change in future IETF culture (e.g. there was one individual doc that was requested by AD to comment on by the WG but no respond). Therefore, IMHO, the IETF is divided by groups with different point of views/documents and they force their WG Adopted-Work to list documents (not all related to Group-Charters), but it seems that managemnet does not see that there is a division in knowledge or in outputs of the IETF, which a new comer may see it clearly. I recommend to focus/list documents related to Charter, not related to WG adoptions, because all IETF document are examined by IESG. AB On Tue, Oct 1, 2013 at 7:29 PM, Michael Richardson mcr+i...@sandelman.camailto:mcr+i...@sandelman.ca wrote: This morning I had reason to re-read parts of RFC3777, and anything that updated it. I find the datatracker WG interface to really be useful, and so I visited http://datatracker.ietf.org/wg/nomcom/ first. I guess I could have instead gone to: http://www.rfc-editor.org/info/rfc3777 but frankly, I'm often bad with numbers, especially when they repeat... (3777? 3737? 3733?) While http://datatracker.ietf.org/wg/nomcom/ lists RFC3777, and in that line, it lists the things that update it, it doesn't actually list the other documents. Thinking this was an error, I asked, and Cindy kindly explained: http://datatracker.ietf.org/wg/nomcom/ lists the documents that were published by the NOMCOM Working Group. The NOMCOM Working Group was open from 2002-2004, and only produced one RFC, which is RFC 3777. The RFCs that update 3777 were all produced by individuals (that is, outside of the NOMCOM Working Group), and so aren't listed individually on the NOMCOM Working Group documents page. I wonder about this as a policy. Seeing the titles of those documents would have helped me find what I wanted quickly (RFC5680 it was)... While I think that individual submissions that are not the result of consensus do not belong on a WG page. But, if the document was the result of consensus, but did not occur in a WG because the WG had closed, I think that perhaps it should appear there anyway. -- Michael Richardson mcr+i...@sandelman.camailto:mcr%2bi...@sandelman.ca, Sandelman Software Works ___ Tools-discuss mailing list tools-disc...@ietf.orgmailto:tools-disc...@ietf.org https://www.ietf.org/mailman/listinfo/tools-discuss
Re: [Tools-discuss] independant submissions that update standards track, and datatracker
1 April RFCs excepted Scott On Oct 2, 2013, at 10:10 AM, Barry Leiba barryle...@computer.org wrote: because all IETF document are examined by IESG No they're not. See RFC4844. Lloyd, it *is* true that all documents in the IETF stream are reviewed and approved by the IESG. I would take IETF documents to refer to documents in the IETF stream. (In fact, documents in the IRTF and Independent streams are also examined by the IESG, but only for conflict review, according to RFC 5742. The only RFCs that the IESG doesn't look at in any formal way are those in the IAB stream.) Barry, Applications AD
Re: [Tools-discuss] independant submissions that update standards track, and datatracker
because all IETF document are examined by IESG No they're not. See RFC4844. Lloyd, it *is* true that all documents in the IETF stream are reviewed and approved by the IESG. I would take IETF documents to refer to documents in the IETF stream. (In fact, documents in the IRTF and Independent streams are also examined by the IESG, but only for conflict review, according to RFC 5742. The only RFCs that the IESG doesn't look at in any formal way are those in the IAB stream.) Barry, Applications AD
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ I'm one of the authors of this RFC and support the change. ADSP was basically an experiment that failed. It has no significant deployment, and the problem it was supposed to solve is now being addressed in other ways. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
David, Steve, I think the modified introduction text suffices to connect the PATHSEC and BGPsec terms, but I don't think that referring to the SIDR WG charter for the PATHSEC goals is reasonable -- an RFC is an archive document, whereas a WG charter is not. The revised intro text now paraphrases the text from the SIDR charter that describes the path security goals. Steve
Re: [Diversity] Attracting people from emerging regions into the IETF
Hi Steve, At 14:18 01-10-2013, Steve Conte wrote: One of the goals of the ISOC Fellowship to the IETF programme is to increase IETF participation in emerging and developing economies, and thus it contributes to increasing diversity within the IETF. ISOC also has and supports other activities surrounding the increase of awareness and participation in the IETF. The fellowship is just one component. I would like to better understand how the implementation and operation of this ISOC-driven programme speaks to the larger challenge question of increasing diversity at IETF. There is a one-page overview of the IETF provided by the Internet Society [1]. According to the document: The IETF seeks broad participation. The work of the IETF takes places online, largely through email lists, reducing barriers to participation and maximizing contributions from around the world. IETF Working Groups (WGs) are organized by topic into several areas (e.g. routing, transport, security, etc.). The document then has a title about mission and principles which I'll quote: The mission of the IETF is make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. I read an article written by the Chair of the IETF. I'll do some selective quoting of that article: The IETF can benefit of untapped potential and bring even more energy to the work. We think of diversity as something that covers international participation, different cultures, gender, age, organisational background, and so on. While I am very proud of the IETF as a very international organisation with participants from 60 countries working on documents, for instance there are many aspects of diversity where we could do much better. Overall participation is concentrated in some areas of the world, with little participation from Africa and South America, for instance. Similarly, while the IETF has some very active female participants and leadership members, the numbers are very small. The diversity team is a design team tasked with understanding the issues we are facing, drawing in experience from other organizations affected by similar issues, identifying obstacles to us having the widest breadth of talented participants and leaders, and making practical recommendations that could help us improve the situation. The Chair of the IETF asked for practical recommendations. It is not for me to make recommendations. I can only make suggestions (see http://www.ietf.org/mail-archive/web/ietf/current/msg82776.html ). If the IETF Area Directors believe that the suggestions are unpractical or useless they are welcome to ignore them. In my humble opinion the challenge of the IETF is to produce high quality, relevant technical documents. The Chair of the IETF mentioned that there is very little participation from Africa and South America. The main point raised during the discussions about the draft is on-going and active participation. The question is what can be done in practice to improve on-going and active participation from, for example, Africa and South America without making it even more difficult for the IETF to produce high quality, relevant technical documents. I would like to see five Working Groups Chairs who are residing in South America within a few years. They will have to earn the role based on merit and not because they are from South America. They will have to work hard. They will have to learn by themselves what John Klensin means when he says: The I in the IETF is not I. Regards, S. Moonesamy 1. http://www.ietf.org/about/about-the-ietf-en.pdf
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
--On Wednesday, October 02, 2013 07:41 -0700 The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to- historic/ Hi. Just to be sure that everyone has the same understanding of what is being proposed here, the above says to Historic but the writeup at http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ says to Internet Standard. Can one or the other be corrected? After reading the description at the link cited above and assuming that Historic is actually intended, I wonder, procedurally, whether a move to Historic without document other than in the tracker is an appropriate substitute for the publication of an Applicability Statement that says not recommended and that explains, at least in the level of detail of the tracker entry, why using ADSP is a bad idea. If there were no implementations and no evidence that anyone cared about this, my inclination would be to just dispose of RFC 5617 as efficiently and with as little effort as possible. But, since the tracker entry says that there are implementations and that misconfiguration has caused harm (strongly implying that there has even been deployment), it seems to me that a clear and affirmative not recommended applicability statement is in order. thanks, john
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
Hi. Just to be sure that everyone has the same understanding of what is being proposed here, the above says to Historic but the writeup at http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ says to Internet Standard. Can one or the other be corrected? Gakk. I don't know how that happened. I'll see if the Secretariat can fix it. I'm sure it's my fault.. Sigh. Barry
RE: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
Hi, The subject lines says the intention is to move to Internet Standard; the text says the intention is to move to Historic. This Last Call should probably be re-published with matching intent. David Harrington ietf...@comcast.net +1-603-828-1401 -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce- boun...@ietf.org] On Behalf Of The IESG Sent: Wednesday, October 02, 2013 10:42 AM To: IETF-Announce Subject: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ 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 ietf@ietf.org mailing lists by 2013-10-30. 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 affected document can be obtained via http://datatracker.ietf.org/doc/rfc5617/ IESG discussion of this request can be tracked via http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to- historic/ballot/
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
On 10/2/2013 9:28 AM, John C Klensin wrote: After reading the description at the link cited above and assuming that Historic is actually intended, I wonder, procedurally, whether a move to Historic without document other than in the tracker is an appropriate substitute for the publication of an Applicability Statement that says not recommended and that explains, at least in the level of detail of the tracker entry, why using ADSP is a bad idea. This suggestion has the dual potential benefits of being inefficient and ineffective. If a spec is Historic, it is redundant to say not recommended. As in, duh... Even better is that an applicability statement is merely another place for the potential implementer to fail to look and understand. Anyone who fails to understand the implications of Historic (or fails to find the correct status) is not going to be better at finding and understanding an applicability statement. ADSP is only worthy of a small effort, to correct its status, to reflect its current role in Internet Mail. Namely, its universal non-use within email filtering. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
RE: [Tools-discuss] independant submissions that update standards track, and datatracker
While I think that individual submissions that are not the result of consensus do not belong on a WG page. Where do they belong? I prefer that they belong under the Area page, but is there an area page, not sure why was that not a good idea. But, if the document was the result of consensus, but did not occur in a WG because the WG had closed, I think that perhaps it should appear there anyway. I agree, but still I think an area page is required, some day in the future may be the Area will expire or be changed by the community, so don't we should think where is the history of these areas. Also our procedural RFCs and BCPs are not related to General Area, I prefer to see them all under an area related, some day this general area may change as well (may be called Procedural Area). I agree that the way documents are related to IETF-fields or IETF-areas is not an easy way for tracking information, also the documents are not much connected but more separated (IETF is divided in WGs which creates division/differences in documents of the same field). As once one AD proposed Cross-Areas in IETF, I want to add proposing Cross-WGs, all are responsible for related issues in IETF (i.e. Areas and Groups). AB
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
I assume we will need to agree to disagree about this, but... --On Wednesday, October 02, 2013 10:44 -0700 Dave Crocker d...@dcrocker.net wrote: If a spec is Historic, it is redundant to say not recommended. As in, duh... Duh notwithstanding, we move documents to Historic for many reasons. RFC 2026 lists historic as one of the reasons a document may be not recommended (Section 3.3(e)) but says only superceded... or is for any other reason considered to be obsolete about Historic (Section 4.2.4). That is entirely consistent with Maturity Levels and Requirement Levels being basically orthogonal to each other, even if Not Recommended and Internet Standard are presumably mutually exclusive. Even better is that an applicability statement is merely another place for the potential implementer to fail to look and understand. Interesting. If a potential implementer or other potential user of this capability fails to look for the status of the document or protocol, then the reclassification to Historic won't be found and this effort is a waste of the community's time. If, by contrast, that potential user checks far enough to determine that the document has been reclassified to Historic, why is it not desirable to point that user to a superceding document that explains the problem and assigns as requirement status of not recommended? The situation would be different if a huge amount of additional work were involved but it seems to me that almost all of the required explanation is already in the write-up and that the amount of effort required to approve an action consisting of a document and a status change is the same as that required to approve the status change only. If creating an I-D from the write-up is considered too burdensome and it would help, I'd be happy to do that rather than continuing to complain. ADSP is only worthy of a small effort, to correct its status, to reflect its current role in Internet Mail. Namely, its universal non-use within email filtering. If the specification had been universally ignored, I'd think that a simple status change without further documentation was completely reasonable. However, the write-up discusses harm caused by incorrect configuration and by inappropriate use, real cases, and effects from posts from users. That strongly suggests that this is a [mis]feature that has been sufficiently deployed to cause problems, not someone that is universally non-used. And that, IMO, calls for a explanation --at least to the extent of the explanation in the write-up-- as to why ADSP was a bad idea, should be retired where it is used, and should not be further deployed. best, john
RE: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06
Sounds good - I look forward to seeing the revised draft. Thanks, --David From: Stephen Kent [mailto:k...@bbn.com] Sent: Wednesday, October 02, 2013 11:04 AM To: Black, David Cc: a...@cs.unc.edu; General Area Review Team (gen-...@ietf.org); stbry...@cisco.com; ietf@ietf.org; s...@ietf.org Subject: Re: Gen-ART review of draft-ietf-sidr-bgpsec-threats-06 David, Steve, I think the modified introduction text suffices to connect the PATHSEC and BGPsec terms, but I don't think that referring to the SIDR WG charter for the PATHSEC goals is reasonable - an RFC is an archive document, whereas a WG charter is not. The revised intro text now paraphrases the text from the SIDR charter that describes the path security goals. Steve
Re: Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
On Wed, Oct 2, 2013 at 7:41 AM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ [...] I support this change, for the reasons articulated in the request and in this thread. I am the lead developer and maintainer of OpenDKIM, an open source implementation of DKIM and related standards, including VBR, ADSP, the recent REPUTE work, and some others. It is widely deployed, including use at a few of the largest operators. An informal survey was done on one of the mailing lists where this package is supported, asking which operators do ADSP queries and which act upon the results. I have so far only received a half dozen answers to this, but the consensus among them is clear: All of the respondents either do not check ADSP, or check it but do nothing with the results. One operator puts disposition of messages based on ADSP results into the hands of its users, but no statistics were offered about how many of these users have ADSP-based filtering enabled. That same operator intends to remove that capability once this status change goes into effect. -MSK
Last Call: draft-ietf-manet-smf-mib-08.txt (Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process) to Proposed Standard
The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Definition of Managed Objects for the Manet Simplified Multicast Framework Relay Set Process' draft-ietf-manet-smf-mib-08.txt as 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 2013-10-16. 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. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB also reports state information, performance metrics, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/ballot/ No IPR declarations have been submitted directly on this I-D.
Document Action: 'Diameter Overload Control Requirements' to Informational RFC (draft-ietf-dime-overload-reqs-13.txt)
The IESG has approved the following document: - 'Diameter Overload Control Requirements' (draft-ietf-dime-overload-reqs-13.txt) as Informational RFC This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs/ Technical Summary The document sets normative requirements for Diameter overload control solutions. The existing Diameter mechanisms for an overload control are not sufficient for a practical solution. The document also goes into lengths explaining why Diameter overload control functionality is needed and describes the limitations of the existing mechanisms in the Diameter Base Protocol. Working Group Summary The working group reached a consensus on the document. The discussion was extensive. Since this document is a requirements document, possible technical solution space issues are left for future documents and discussions. There is an obvious decision point ahead that got quite a bit of attention, which relates to the dissemination of the overload control information: whether an explicit overload application is needed for proper end-to-end signaling semantics or whether everything is piggybacked on top of existing signaling between adjacent peers in hop-by-hop fashion. However, this is for the solution space and the requirements document currently allows both approaches. Document Quality The document has greater industry interest behind, specifically from the cellular industry. Since the document is a requirement document there are no standardised solutions available yet due to the absence of the protocol specification. There is definitive interest from both operators and vendors to have a standard solution for Diameter overload control. The requirements document has been extensively reviewed by the 3GPP CT4 working group, which is the main AAA protocol group in 3GPP. Personnel Jouni Korhonen is the document shepherd. The responsible area director is Benoit Claise. No IANA experts required.
Last Call: Change the status of ADSP (RFC 5617) to Internet Standard
The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ 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 2013-10-30. 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 affected document can be obtained via http://datatracker.ietf.org/doc/rfc5617/ IESG discussion of this request can be tracked via http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ballot/
REVISED Last Call: Change the status of ADSP (RFC 5617) to Historic
The IESG has received a request from an individual participant to make the following status changes: - RFC5617 from Proposed Standard to Historic The supporting document for this request can be found here: http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ 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 2013-10-30. 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 affected document can be obtained via http://datatracker.ietf.org/doc/rfc5617/ IESG discussion of this request can be tracked via http://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/ballot/
Last Call: draft-ietf-6man-oversized-header-chain-08.txt (Implications of Oversized IPv6 Header Chains) to Proposed Standard
The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Implications of Oversized IPv6 Header Chains' draft-ietf-6man-oversized-header-chain-08.txt as 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 2013-10-16. 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. Abstract The IPv6 specification allows IPv6 header chains of an arbitrary size. The specification also allows options which can in turn extend each of the headers. In those scenarios in which the IPv6 header chain or options are unusually long and packets are fragmented, or scenarios in which the fragment size is very small, the first fragment of a packet may fail to include the entire IPv6 header chain. This document discusses the interoperability and security problems of such traffic, and updates RFC 2460 such that the first fragment of a packet is required to contain the entire IPv6 header chain. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-6man-oversized-header-chain/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-mpls-tp-rosetta-stone-12.txt (A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recomm
The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations.' draft-ietf-mpls-tp-rosetta-stone-12.txt as Informational RFC 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 2013-10-16. 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. Abstract MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-rosetta-stone/ballot/ No IPR declarations have been submitted directly on this I-D.
Last Call: draft-ietf-ccamp-gmpls-ospf-g709v3-09.txt (Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks) to Proposed Standard
The IESG has received a request from the Common Control and Measurement Plane WG (ccamp) to consider the following document: - 'Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks' draft-ietf-ccamp-gmpls-ospf-g709v3-09.txt as 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 2013-10-16. 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. Abstract This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support Generalized MPLS (GMPLS) control of Optical Transport Networks (OTN) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC4203. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1835/ http://datatracker.ietf.org/ipr/1621/
RFC 7027 on Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS)
A new Request for Comments is now available in online RFC libraries. RFC 7027 Title: Elliptic Curve Cryptography (ECC) Brainpool Curves for Transport Layer Security (TLS) Author: J. Merkle, M. Lochter Status: Informational Stream: IETF Date: October 2013 Mailbox:johannes.mer...@secunet.com, manfred.loch...@bsi.bund.de Pages: 10 Characters: 16366 Updates:RFC 4492 I-D Tag:draft-merkle-tls-brainpool-04.txt URL:http://www.rfc-editor.org/rfc/rfc7027.txt This document specifies the use of several Elliptic Curve Cryptography (ECC) Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol. INFORMATIONAL: 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-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC
