Re: [mpls] Last Call: draft-ietf-mpls-ldp-upstream (MPLS Upstream Label Assignment for LDP) to Proposed Standard
Hi Eric, Sorry for the delay. Please see below: snipped At this point, I believe the only change that is needed to draft-ietf-mpls- ldp-upstream is to move the reference to RFC 3472 into the Informational References section. This is fine. I will make the change in the next update. That is, I think that recent revisions to the draft have made the normative reference gratuitous, as one does not need to read RFC3472 in order to implement any part of this draft. That is correct. rahul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
** OAuth Tutorial OAuth Security Session **
Hi all, please consider attending the following two meetings! ** OAuth Security Session ** • Date: Monday, 13:00-15:00 • Location: IAB breakout room (Jade 2) • Contact: Hannes Tschofenig hannes.tschofe...@gmx.net The security consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we would like to put some time aside to discuss what security threats, requirements, and countermeasures need to be described. We will use the Monday, November 8, 1300-1500 slot to have a discussion session. As a starting point I suggest to look at the following documents: • http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations • http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy • http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt Note: If you are unfamiliar with OAuth then the OAuth tutorial session might be more suitable for you! ** OAuth Tutorial ** • Date: Wednesday, 19:30 (after the plenary) • Location: IAB breakout room (Jade 2) • Contact: Hannes Tschofenig hannes.tschofe...@gmx.net OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. The OAuth working group, see http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to finalize their main specification, namely OAuth v2: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ Based on the positive response at the last IETF meeting (in Maastricht) we decided to hold another OAuth tutorial, namely on *Wednesday, starting at 19:30 (after the IETF Operations and Administration Plenary) till about 21:00. (Note: I had to switch the day because of the social event!) It is helpful to read through the documents available int he working group but not required. Up-to-date information can be found here: http://www.ietf.org/registration/MeetingWiki/wiki/79bofs Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OAUTH-WG] ** OAuth Tutorial OAuth Security Session **
Hi all, Mark McGloin and me have been working on OAuth 2.0 security considerations for a couple of weeks now. Since we both cannot attend the IETF-79 meetings, we would like to provide the WG with information regarding the current status of our work. I therefore uploaded a _preliminary_ version of our working document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. The focus of this version was on consolidating previous work as well as results of mailing list discussions and start working towards a rigorous threat model. Please give us feedback. regards, Torsten. Am 07.11.2010 03:22, schrieb Hannes Tschofenig: Hi all, please consider attending the following two meetings! ** OAuth Security Session ** • Date: Monday, 13:00-15:00 • Location: IAB breakout room (Jade 2) • Contact: Hannes Tschofenig hannes.tschofe...@gmx.net The security consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we would like to put some time aside to discuss what security threats, requirements, and countermeasures need to be described. We will use the Monday, November 8, 1300-1500 slot to have a discussion session. As a starting point I suggest to look at the following documents: • http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations • http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy • http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt Note: If you are unfamiliar with OAuth then the OAuth tutorial session might be more suitable for you! ** OAuth Tutorial ** • Date: Wednesday, 19:30 (after the plenary) • Location: IAB breakout room (Jade 2) • Contact: Hannes Tschofenig hannes.tschofe...@gmx.net OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. The OAuth working group, see http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to finalize their main specification, namely OAuth v2: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ Based on the positive response at the last IETF meeting (in Maastricht) we decided to hold another OAuth tutorial, namely on *Wednesday, starting at 19:30 (after the IETF Operations and Administration Plenary) till about 21:00. (Note: I had to switch the day because of the social event!) It is helpful to read through the documents available int he working group but not required. Up-to-date information can be found here: http://www.ietf.org/registration/MeetingWiki/wiki/79bofs Ciao Hannes ___ OAuth mailing list oa...@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Tonight's Plenary: RFCs Will No Longer Be Published
The price of freedom is eternal vigilance. -- Thomas Jefferson It is also the price for maintaining quality and culture. -- D. Crocker One of the problems with having things work well is that we get complacent. Once we get through the challenges of gaining approval for a document, today we find that going the the RFC publication is usually efficient and even painless. This has not always been so and it could become 'not so' in the future. Tonight's plenary will not include the above-offered announcement, but it /will/ include a proposal on the RFC Editor office, covering the structure and functions, with a focus on the open position for the RFC Series Editor -- roughly equivalent to the position previously held by Bob Braden and created by Jon Postel. As always, if you ignore the current round of proposal review, you do not get to later complain that the result is wrong. Worse, if you do not participate now, you are probably increasing the likelihood that it will be wrong... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Tonight's Plenary: RFCs Will No Longer Be Published
On Nov 8, 2010, at 9:14 AM, Dave CROCKER wrote: The price of freedom is eternal vigilance. -- Thomas Jefferson It is also the price for maintaining quality and culture. -- D. Crocker One of the problems with having things work well is that we get complacent. Once we get through the challenges of gaining approval for a document, today we find that going the the RFC publication is usually efficient and even painless. This has not always been so and it could become 'not so' in the future. Tonight's plenary will not include the above-offered announcement, but it /will/ include a proposal on the RFC Editor office, covering the structure and functions, with a focus on the open position for the RFC Series Editor -- roughly equivalent to the position previously held by Bob Braden and created by Jon Postel. As always, if you ignore the current round of proposal review, you do not get to later complain that the result is wrong. Worse, if you do not participate now, you are probably increasing the likelihood that it will be wrong... Some additional information: During this evening we have put this discussion at the end of the agenda, after the IAB open microphone session. WRT timing: We have approximately 30 minutes allocated for about 10 mins of introduction and 20 mins of discussions. While I do not want to be strict with respect to the end time I do want to respect that people need food and want to try to close microphone lines at 19:30. Until now I have not seen any questions for the IAB open microphone session. I suspect that the open microphone doesn't need the allocated 30 mins so we may gain some time at the start. Also see http://www.ietf.org/mail-archive/web/ietf-announce/current/msg08097.html http://www.rfc-editor.org/pipermail/rfc-interest/2010-November/001827.html http://www.rfc-editor.org/rse/RSE.html for some background and references. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Proposed WG and BOF Scheduling Experiment
The IESG is seriously considering a WG and BOF scheduling experiment. The goal of the experiment is to provide WG agenda sooner and also provide more time to craft BOF proposals. The proposed experiment includes three parts. First, schedule all BOFs for Monday afternoon. Second, schedule WGs before we know which BOFs will be held. Finally, provide an additional four weeks to deliver BOF proposal to ADs. Please let us know whether you support this experiment. Discussion is welcome on the mail list and the plenary on Wednesday evening. On behalf of the IESG, Russ Housley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
If we put the BOFs on Friday afternoon instead, wouldn't that make the attendance numbers an even stronger gauge of interest? On 11/8/10 10:26 AM, The IESG wrote: The IESG is seriously considering a WG and BOF scheduling experiment. The goal of the experiment is to provide WG agenda sooner and also provide more time to craft BOF proposals. The proposed experiment includes three parts. First, schedule all BOFs for Monday afternoon. Second, schedule WGs before we know which BOFs will be held. Finally, provide an additional four weeks to deliver BOF proposal to ADs. Please let us know whether you support this experiment. Discussion is welcome on the mail list and the plenary on Wednesday evening. On behalf of the IESG, Russ Housley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
On 11/8/2010 10:26 AM, The IESG wrote: The proposed experiment includes three parts. First, schedule all BOFs for Monday afternoon. Second, schedule WGs before we know which BOFs will be held. Finally, provide an additional four weeks to deliver BOF proposal to ADs. Please let us know whether you support this experiment. 1. Can you provide some rational for the details of the experiment? 2. Is one goal to maximize the attendance conflicts among BOFs? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
On 11/08/2010 10:26 GMT+08:00, The IESG wrote: The IESG is seriously considering a WG and BOF scheduling experiment. The goal of the experiment is to provide WG agenda sooner and also provide more time to craft BOF proposals. The proposed experiment includes three parts. First, schedule all BOFs for Monday afternoon. Second, schedule WGs before we know which BOFs will be held. Finally, provide an additional four weeks to deliver BOF proposal to ADs. I am in favor of the goals but concerned about conflicts between BOFs. BOFs explore possible new work items for the IETF, and some decisions made in BOFs can be significant for the direction of IETF work, and hard to undo after the fact. I am more likely to be unhappy about a scheduling conflict between BOFs than between a BOF and a WG that is continuing in its ordinary work, so I like having BOFs spread out through the week. Have you thought about sensitivity of conflicts, and if so what were your thoughts? Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
On 2010-11-08 15:26, The IESG wrote: The IESG is seriously considering a WG and BOF scheduling experiment. The goal of the experiment is to provide WG agenda sooner and also provide more time to craft BOF proposals. The proposed experiment includes three parts. First, schedule all BOFs for Monday afternoon. Hmm. How many non-overlapping time slots? It would be extremely frustrating if there was a lot of overlap between BOFs. Some of us are interested in almost any new topic. My first reaction is to prefer the BOFs spread out. I'm not sure that concentrating them will reduce the problem of clashes. Second, schedule WGs before we know which BOFs will be held. That is a feature of concentrating the BOFs, but I'm not sure that it's particularly valuable. It moves the clashing problem, but doesn't remove it. Finally, provide an additional four weeks to deliver BOF proposal to ADs. Do you mean: make the BOF request cutoff later? If so, that is a feature, but since people are deadline driven, I'm not sure that moving the deadline is a major advantage. Please let us know whether you support this experiment. Discussion is welcome on the mail list and the plenary on Wednesday evening. It depends on my first question: how many BOF-BOF clashes would we get as a result? Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
On 11/8/10 10:57 AM, Brian E Carpenter wrote: On 2010-11-08 15:26, The IESG wrote: First, schedule all BOFs for Monday afternoon. Hmm. How many non-overlapping time slots? It would be extremely frustrating if there was a lot of overlap between BOFs. Some of us are interested in almost any new topic. My first reaction is to prefer the BOFs spread out. I'm not sure that concentrating them will reduce the problem of clashes. Strongly agree! --aaron ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Beijing TSV area office hours
Hi, the TSV area office hours are Tue 15:20-17:00 in Diamond 3. If you plan on stopping by, please send us (tsv-...@tools.ietf.org) a quick email beforehand. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
Maybe for the experiment we should also move the Social to Friday evening: 1) it won't interfere with IP meeting time; 2) less people so better chance of getting a ticket; 3) more folks will stay for Friday meetings; 4) IETF meeting will be over so we can let our hair down - oops that's not a problem now. geoff On Mon, 2010-11-08 at 10:40 +0800, Dave CROCKER wrote: On 11/8/2010 10:26 AM, The IESG wrote: The proposed experiment includes three parts. First, schedule all BOFs for Monday afternoon. Second, schedule WGs before we know which BOFs will be held. Finally, provide an additional four weeks to deliver BOF proposal to ADs. Please let us know whether you support this experiment. 1. Can you provide some rational for the details of the experiment? 2. Is one goal to maximize the attendance conflicts among BOFs? d/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
One of the factors that frequently determines the outcome of a piece of work is how it is broken down into parts. So the scope of WGs in formation can be the most significant factor in determining what they produce. Putting the BOFs at a known time would be very helpful for that reason. Having the BOFs on Monday seems like a useful idea. Having them only on Monday afternoon seems like it is going to cause rather too many conflicts. On Sun, Nov 7, 2010 at 9:42 PM, Scott Brim scott.b...@gmail.com wrote: On 11/08/2010 10:26 GMT+08:00, The IESG wrote: The IESG is seriously considering a WG and BOF scheduling experiment. The goal of the experiment is to provide WG agenda sooner and also provide more time to craft BOF proposals. The proposed experiment includes three parts. First, schedule all BOFs for Monday afternoon. Second, schedule WGs before we know which BOFs will be held. Finally, provide an additional four weeks to deliver BOF proposal to ADs. I am in favor of the goals but concerned about conflicts between BOFs. BOFs explore possible new work items for the IETF, and some decisions made in BOFs can be significant for the direction of IETF work, and hard to undo after the fact. I am more likely to be unhappy about a scheduling conflict between BOFs than between a BOF and a WG that is continuing in its ordinary work, so I like having BOFs spread out through the week. Have you thought about sensitivity of conflicts, and if so what were your thoughts? Scott ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FW: NomCom 2010-2011: Announcing Beijing Office Hours for IETF-79
-Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of NomCom Chair Sent: Monday, November 08, 2010 12:51 PM To: IETF Announcement list Subject: NomCom 2010-2011: Announcing Beijing Office Hours for IETF-79 Nomcom is pleased to announce office hours during the Beijing IETF-79 Meeting: Location: Jade 4 on the 3rd floor, Valley Wing Mon 11/08/10:13:00-15:00 Tue 11/09/10:10:00-11:15 Wed 11/10/10:08:40-10:00 Thur 11/11/09: 08:40-10:00 As you know, Nomcom is in the process of reviewing the nominees for the various open positions as summarized on the Nomcom wiki: https://wiki.tools.ietf.org/group/nomcom/10/ We are actively seeking feedback on the nominees from the community. There are many ways to provide feedback: - Drop by the Nomcom office - Jade 4 room on the 3rd floor, Valley Wing during office hours. - Use the wiki to provide comments as described in the second call for feedback: https://datatracker.ietf.org/ann/nomcom/2592/ - Or if you would like to schedule an appointment to meet with a NomCom member, please let me know or send a request to nomco...@ietf.org. - Alternatively, please find one of the Nomcom members (wearing an orange dot) at the meeting and share your thoughts. Thanks, Thomas Walsh, Chair, Nomcom 2010-2011 Email: nomcom-ch...@ietf.org Email: twa...@juniper.net ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
CORRECTION: Beijing TSV area office hours
On 2010-11-8, at 11:32, Eggert Lars (Nokia-NRC/Espoo) wrote: the TSV area office hours are Tue 15:20-17:00 in Diamond 3. Correction: Diamond *** 2 *** Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: CORRECTION: Beijing TSV area office hours
Are office hours on the wiki? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Transcript during the Technical Plenary
Dear Colleagues We have arranged for transcription for this evenings plenary session. Please consider this a best-effort service as our regular transcriptionist is not able to join she will be transcribing by following the audio feed remotely. We will project the transcripts on screens on the side of the room but can also be followed life through: http://www.streamtext.net/text.aspx?event=ietf --Olaf Kolkman --- The Internet Architecture Board www.iab.org iab-ch...@iab.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
Hmm. How many non-overlapping time slots? It would be extremely frustrating if there was a lot of overlap between BOFs. Some of us are interested in almost any new topic. My first reaction is to prefer the BOFs spread out. I'm not sure that concentrating them will reduce the problem of clashes. Strongly agree! As do I. I attend BoFs across areas, with interest in looking at new work in general. I've often thought we should *never* schedule two BoFs in the same time slot. I'd hate to have guaranteed conflicts, allowing me to attend only one or two BoFs when a dozen were scheduled. Barry ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed WG and BOF Scheduling Experiment
I think having the BOFs early in the week is a good idea but I'd modify the proposal a bit. Background: At this meeting, we have 8 BOFs. There are also 7 or 8 meetings in each of the sessions (9-11:30, 1-3, 3-4). Scheduling all 8 BOFs at the same time will maximize overlap between them but otherwise not affect the schedule. However, the overlap does not make this a good idea. Also, the lengths of the BOFs will vary, so one size fits all is not a good idea. If we schedule 4 BOFs at the time and have NO WG meetings in parallel, reduce overlap for the BOFs BUT at the same time create more conflicts for the rest of the week, as 8 WG sessions have to be put elsewhere in the schedule. This is not a good idea either.4 BOFs with meetings in parallel works better. 4 BOFs with 4 regular meetings at the same time does not have much impact on the rest of the schedule, but there is still a fair chance of overlap. So, I'd take it a step further: Starting Monday morning, 2 of the 7 or 8 meeting slots in each session are reserved for BOFs and the other 4 or 5 for WG meetings. That way, we'll have all the BOFs done by Tuesday lunchtime, giving time to discuss the results during the week, and impact on the rest of the schedule is minimal. Henk -- -- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 -- I confirm today what I denied yesterday.Anonymous Politician. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Proposed WG and BOF Scheduling Experiment
I support the effort, but not the timing. Maybe having an hour reserved at each end of the day for BoFs would be a compromise (just an idea popping right now). -Message d'origine- De : ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] De la part de Henk Uijterwaal Envoyé : lundi 8 novembre 2010 13:24 Cc : wgcha...@ietf.org; ietf@ietf.org Objet : Re: Proposed WG and BOF Scheduling Experiment I think having the BOFs early in the week is a good idea but I'd modify the proposal a bit. Background: At this meeting, we have 8 BOFs. There are also 7 or 8 meetings in each of the sessions (9-11:30, 1-3, 3-4). Scheduling all 8 BOFs at the same time will maximize overlap between them but otherwise not affect the schedule. However, the overlap does not make this a good idea. Also, the lengths of the BOFs will vary, so one size fits all is not a good idea. If we schedule 4 BOFs at the time and have NO WG meetings in parallel, reduce overlap for the BOFs BUT at the same time create more conflicts for the rest of the week, as 8 WG sessions have to be put elsewhere in the schedule. This is not a good idea either.4 BOFs with meetings in parallel works better. 4 BOFs with 4 regular meetings at the same time does not have much impact on the rest of the schedule, but there is still a fair chance of overlap. So, I'd take it a step further: Starting Monday morning, 2 of the 7 or 8 meeting slots in each session are reserved for BOFs and the other 4 or 5 for WG meetings. That way, we'll have all the BOFs done by Tuesday lunchtime, giving time to discuss the results during the week, and impact on the rest of the schedule is minimal. Henk -- --- --- Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The NetherlandsThe NetherlandsMobile: +31.6.55861746 --- --- I confirm today what I denied yesterday.Anonymous Politician. ___ 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
IANA Office Hours at IETF-78 in Beijing
Greetings! IANA will be holding Office Hours at the IETF-79 in Beijing. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. We will have a table near the IETF registration area, staffed during the following hours: Monday – Thursday, 0900 – 1600 Thank you and see you soon! Michelle Cotton Manager, IETF Relations - IANA ICANN ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
NomCom 2010-2011: Announcing Beijing Office Hours for IETF-79
Nomcom is pleased to announce office hours during the Beijing IETF-79 Meeting: Location: Jade 4 on the 3rd floor, Valley Wing Mon 11/08/10:13:00-15:00 Tue 11/09/10:10:00-11:15 Wed 11/10/10:08:40-10:00 Thur 11/11/09: 08:40-10:00 As you know, Nomcom is in the process of reviewing the nominees for the various open positions as summarized on the Nomcom wiki: https://wiki.tools.ietf.org/group/nomcom/10/ We are actively seeking feedback on the nominees from the community. There are many ways to provide feedback: - Drop by the Nomcom office - Jade 4 room on the 3rd floor, Valley Wing during office hours. - Use the wiki to provide comments as described in the second call for feedback: https://datatracker.ietf.org/ann/nomcom/2592/ - Or if you would like to schedule an appointment to meet with a NomCom member, please let me know or send a request to nomco...@ietf.org. - Alternatively, please find one of the Nomcom members (wearing an orange dot) at the meeting and share your thoughts. Thanks, Thomas Walsh, Chair, Nomcom 2010-2011 Email: nomcom-ch...@ietf.org Email: twa...@juniper.net ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6045 on Real-time Inter-network Defense (RID)
A new Request for Comments is now available in online RFC libraries. RFC 6045 Title: Real-time Inter-network Defense (RID) Author: K. Moriarty Status: Informational Stream: IETF Date: November 2010 Mailbox:moriarty_kathl...@emc.com Pages: 75 Characters: 172817 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-moriarty-post-inch-rid-12.txt URL:http://www.rfc-editor.org/rfc/rfc6045.txt Network security incidents, such as system compromises, worms, viruses, phishing incidents, and denial of service, typically result in the loss of service, data, and resources both human and system. Network providers and Computer Security Incident Response Teams need to be equipped and ready to assist in communicating and tracing security incidents with tools and procedures in place before the occurrence of an attack. Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. Policy guidelines for handling incidents are recommended and can be agreed upon by a consortium using the security recommendations and considerations. RID has found use within the international research communities, but has not been widely adopted in other sectors. This publication provides the specification to those communities that have adopted it, and communities currently considering solutions for real-time inter-network defense. The specification may also accelerate development of solutions where different transports or message formats are required by leveraging the data elements and structures specified here. This document is not an Internet Standards Track specification; it is published for informational purposes. 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/rfcsearch.html. 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6046 on Transport of Real-time Inter-network Defense (RID) Messages
A new Request for Comments is now available in online RFC libraries. RFC 6046 Title: Transport of Real-time Inter-network Defense (RID) Messages Author: K. Moriarty, B. Trammell Status: Informational Stream: IETF Date: November 2010 Mailbox:moriarty_kathl...@emc.com, tramm...@tik.ee.ethz.ch Pages: 7 Characters: 14760 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-moriarty-post-inch-rid-transport-03.txt URL:http://www.rfc-editor.org/rfc/rfc6046.txt The Incident Object Description Exchange Format (IODEF) defines a common XML format for document exchange, and Real-time Inter-network Defense (RID) defines extensions to IODEF intended for the cooperative handling of security incidents within consortia of network operators and enterprises. This document specifies a transport protocol for RID based upon the passing of RID messages over HTTP/TLS (Transport Layer Security). This document is not an Internet Standards Track specification; it is published for informational purposes. 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/rfcsearch.html. 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6051 on Rapid Synchronisation of RTP Flows
A new Request for Comments is now available in online RFC libraries. RFC 6051 Title: Rapid Synchronisation of RTP Flows Author: C. Perkins, T. Schierl Status: Standards Track Stream: IETF Date: November 2010 Mailbox:c...@csperkins.org, t...@thomas-schierl.de Pages: 22 Characters: 53503 Updates:RFC3550 I-D Tag:draft-ietf-avt-rapid-rtp-sync-12.txt URL:http://www.rfc-editor.org/rfc/rfc6051.txt This memo outlines how RTP sessions are synchronised, and discusses how rapidly such synchronisation can occur. We show that most RTP sessions can be synchronised immediately, but that the use of video switching multipoint conference units (MCUs) or large source-specific multicast (SSM) groups can greatly increase the synchronisation delay. This increase in delay can be unacceptable to some applications that use layered and/or multi-description codecs. This memo introduces three mechanisms to reduce the synchronisation delay for such sessions. First, it updates the RTP Control Protocol (RTCP) timing rules to reduce the initial synchronisation delay for SSM sessions. Second, a new feedback packet is defined for use with the extended RTP profile for RTCP-based feedback (RTP/AVPF), allowing video switching MCUs to rapidly request resynchronisation. Finally, new RTP header extensions are defined to allow rapid synchronisation of late joiners, and guarantee correct timestamp-based decoding order recovery for layered codecs in the presence of clock skew. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-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/rfcsearch.html. 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6053 on Implementation Report for Forwarding and Control Element Separation (ForCES)
A new Request for Comments is now available in online RFC libraries. RFC 6053 Title: Implementation Report for Forwarding and Control Element Separation (ForCES) Author: E. Haleplidis, K. Ogawa, W. Wang, J. Hadi Salim Status: Informational Stream: IETF Date: November 2010 Mailbox:eha...@ece.upatras.gr, ogawa.kent...@lab.ntt.co.jp, wmw...@mail.zjgsu.edu.cn, h...@mojatatu.com Pages: 34 Characters: 72337 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-forces-implementation-report-02.txt URL:http://www.rfc-editor.org/rfc/rfc6053.txt Forwarding and Control Element Separation (ForCES) defines an architectural framework and associated protocols to standardize information exchange between the control plane and the forwarding plane in a ForCES network element (ForCES NE). RFC 3654 has defined the ForCES requirements, and RFC 3746 has defined the ForCES framework. This document is an implementation report for the ForCES Protocol, Model, and the Stream Control Transmission Protocol-based Transport Mapping Layer (SCTP TML) documents, and includes a report on interoperability testing and the current state of ForCES implementations. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Forwarding and Control Element Separation Working Group of the IETF. 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/rfcsearch.html. 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 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
IAB member resignation
Dear Colleagues, Vijay Gill has informed the IAB that he is unable to carry out the remainder of his term, and has subsequently resigned from the board. Since Vijay's present term was scheduled to conclude in March 2011, the IAB has decided not to request the Nomcom to fill this mid-term vacancy. On behalf of the IAB I want to thank Vijay for his involvement and participation in the IAB. For the IAB, --Olaf Kolkman IAB Chair --- The Internet Architecture Board www.iab.org iab-ch...@iab.org ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
