From adrian@olddog.co.uk Tue May 7 10:08:45 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CDD21F93DC; Tue, 7 May 2013 10:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TY6zBs4I7YKJ; Tue, 7 May 2013 10:08:40 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7552F21F93B7; Tue, 7 May 2013 10:08:40 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r47H8d5H018460; Tue, 7 May 2013 18:08:39 +0100 Received: from 950129200 (no-reverse-dns.mlnet.ie [31.216.236.149] (may be forged)) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r47H8bOT018445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 May 2013 18:08:37 +0100 From: "Adrian Farrel" To: Date: Tue, 7 May 2013 18:08:34 +0100 Message-ID: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5LRX560irUVDlgRIKUWSY/7OcnkA== Content-Language: en-gb X-Mailman-Approved-At: Wed, 08 May 2013 11:10:09 -0700 Subject: [PWE3] Retiring ACH TLVs X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:08:45 -0000 Hi, ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it = is about explaining why no-one actually wants to use them (i.e., when = each new ACH Type is defined and has a "No TLVs" written for it, we get = asked "why not?"). It seems to us that ACH TLVs are an idea that has been rejected. = Initially we thought they might be used (especially for identifiers), = but there seems to be good opinion that handling generic TLVs would be a = pain. Since I was heavily responsible for insisting that ACH TLVs were = included in RFC 5586, it seems reasonable that I do the work to fix it. The I-D below retires ACH TLVs and handles the necessary registry = changes. Note, of course, that structured data are still possible within = individual ACHs if the protocol spec for an individual ACH decides to = have them. We're directing this work to the MPLS working group because that is = where 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for = information.=20 Thanks for any comments. As humble WG contributors we would be enthusiastic to see early WG = adoption and last call :-) Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 07 May 2013 17:33 > To: Adrian Farrel; Stewart Bryant > Subject: New Version Notification for = draft-farbryantrel-mpls-retire-ach-tlv- > 00.txt >=20 >=20 > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Filename: draft-farbryantrel-mpls-retire-ach-tlv > Revision: 00 > Title: Retiring TLVs from the Associated Channel Header of the MPLS > Generic Associated Channel > Creation date: 2013-05-07 > Group: Individual Submission > Number of pages: 4 > URL: = http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > ach-tlv-00.txt > Status: = http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv > Htmlized: = http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 >=20 >=20 > Abstract: > The MPLS Generic Associated Channel (G-ACh) is a generalization of > the applicability of the Pseudowire (PW) Associated Channel Header > (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) > constructs that can be carried in messages on the G-ACh by placing > them in the ACH. >=20 > No Associated Channel Type yet defined uses a TLV. Furthermore, it > is believed that handling TLVs in hardware introduces significant > problems to the fast-path, and since G-ACh messages are intended to > be processed substantially in hardware, the use of TLVs in > undesirable. >=20 > This document updates RFC 5586 by retiring ACH TLVs and removing = the > associated registry. >=20 >=20 >=20 >=20 > The IETF Secretariat From amalis@gmail.com Wed May 8 11:14:17 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77721F937A for ; Wed, 8 May 2013 11:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6R2nL6sBxeJ for ; Wed, 8 May 2013 11:14:16 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9064B21F9377 for ; Wed, 8 May 2013 11:14:16 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c13so3792553ieb.38 for ; Wed, 08 May 2013 11:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=bVZg7EMN0sT0OZ2PGv2U/MSGs+/RhFAWypm3VIY8Zug=; b=PuWOihewFADXABduS/mm0DxcD3rUJ6pqXPCncDjpwO9IH71VjogbILHMNb5FsyFNeP ubaix4rrjg0MndLkr9KOMeanS0cguoIHO9Z/sMMbyhGPcpFHSCle6noTJy6uNgYoO2eQ dKuB1I8cbpuWYQEEIT95F2xFSJ0R1saQY8Glbg+Z6ZvkGdPGLfXQmU3W0/XBFXgDnxt/ K07TrpLyAaNkdRN1ExsSbxsPiU1qStvBDjSPXlN0nYgXJHiNiUCAUMFcrBe3XGXa3q6c Bn2GIvNSFiEJnds+9RDoqGH2GVfs0/M1Vny48j+aRTq1+Xm1ozQrmK4MB6B54DLZF+X1 yaiA== X-Received: by 10.43.169.202 with SMTP id nn10mr2494063icc.4.1368036856154; Wed, 08 May 2013 11:14:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.179.79 with HTTP; Wed, 8 May 2013 11:13:55 -0700 (PDT) In-Reply-To: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> References: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> From: "Andrew G. Malis" Date: Wed, 8 May 2013 20:13:55 +0200 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2efe8d9cf7204dc38e676 Subject: Re: [PWE3] Retiring ACH TLVs X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 18:14:17 -0000 --001a11c2efe8d9cf7204dc38e676 Content-Type: text/plain; charset=ISO-8859-1 PWE3ers, Comments on this draft should be directed to the mpls email list only. Replying directly to Adrian's email (and not typing in the pwe3 list as well) should accomplish that goal. Thanks, Andy On Tue, May 7, 2013 at 7:08 PM, Adrian Farrel wrote: > Hi, > > ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is > about explaining why no-one actually wants to use them (i.e., when each new > ACH Type is defined and has a "No TLVs" written for it, we get asked "why > not?"). > > It seems to us that ACH TLVs are an idea that has been rejected. Initially > we thought they might be used (especially for identifiers), but there seems > to be good opinion that handling generic TLVs would be a pain. > > Since I was heavily responsible for insisting that ACH TLVs were included > in RFC 5586, it seems reasonable that I do the work to fix it. > > The I-D below retires ACH TLVs and handles the necessary registry changes. > > Note, of course, that structured data are still possible within individual > ACHs if the protocol spec for an individual ACH decides to have them. > > We're directing this work to the MPLS working group because that is where > 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. > > Thanks for any comments. > > As humble WG contributors we would be enthusiastic to see early WG > adoption and last call :-) > > Thanks, > Adrian > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: 07 May 2013 17:33 > > To: Adrian Farrel; Stewart Bryant > > Subject: New Version Notification for > draft-farbryantrel-mpls-retire-ach-tlv- > > 00.txt > > > > > > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Filename: draft-farbryantrel-mpls-retire-ach-tlv > > Revision: 00 > > Title: Retiring TLVs from the Associated Channel Header > of the MPLS > > Generic Associated Channel > > Creation date: 2013-05-07 > > Group: Individual Submission > > Number of pages: 4 > > URL: > http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > > ach-tlv-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv > > Htmlized: > http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 > > > > > > Abstract: > > The MPLS Generic Associated Channel (G-ACh) is a generalization of > > the applicability of the Pseudowire (PW) Associated Channel Header > > (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) > > constructs that can be carried in messages on the G-ACh by placing > > them in the ACH. > > > > No Associated Channel Type yet defined uses a TLV. Furthermore, it > > is believed that handling TLVs in hardware introduces significant > > problems to the fast-path, and since G-ACh messages are intended to > > be processed substantially in hardware, the use of TLVs in > > undesirable. > > > > This document updates RFC 5586 by retiring ACH TLVs and removing the > > associated registry. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > --001a11c2efe8d9cf7204dc38e676 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
PWE3ers,

Comments on this draft should be directed = to the mpls email list only. Replying directly to Adrian's email (and n= ot typing in the pwe3 list as well) should accomplish that goal.

Tha= nks,
Andy


On Tue, May 7, 2013 at 7:08 PM, Adrian Farrel <adrian@olddog.co.uk&= gt; wrote:
Hi,

ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is a= bout explaining why no-one actually wants to use them (i.e., when each new = ACH Type is defined and has a "No TLVs" written for it, we get as= ked "why not?").

It seems to us that ACH TLVs are an idea that has been rejected. Initially = we thought they might be used (especially for identifiers), but there seems= to be good opinion that handling generic TLVs would be a pain.

Since I was heavily responsible for insisting that ACH TLVs were included i= n RFC 5586, it seems reasonable that I do the work to fix it.

The I-D below retires ACH TLVs and handles the necessary registry changes.<= br>
Note, of course, that structured data are still possible within individual = ACHs if the protocol spec for an individual ACH decides to have them.

We're directing this work to the MPLS working group because that is whe= re 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information= .

Thanks for any comments.

As humble WG contributors we would be enthusiastic to see early WG adoption= and last call :-)

Thanks,
Adrian

> -----Original Message-----
> From: internet-drafts@ietf= .org [mailto:internet-draft= s@ietf.org]
> Sent: 07 May 2013 17:33
> To: Adrian Farrel; Stewart Bryant
> Subject: New Version Notification for draft-farbryantrel-mpls-retire-a= ch-tlv-
> 00.txt
>
>
> A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
>
> Filename: =A0 =A0 =A0draft-farbryantrel-mpls-retire-ach-tlv
> Revision: =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Retiring TLVs from the Associat= ed Channel Header of the MPLS
> Generic Associated Channel
> Creation date: =A0 =A0 =A0 =A0 2013-05-07
> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 4
> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.or= g/internet-drafts/draft-farbryantrel-mpls-retire-
> ach-tlv-00.txt
> Status: =A0 =A0 =A0 =A0 =A0http://datatracke= r.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-farbryantrel-mpls-retire-ach-tlv-00
>
>
> Abstract:
> =A0 =A0The MPLS Generic Associated Channel (G-ACh) is a generalization= of
> =A0 =A0the applicability of the Pseudowire (PW) Associated Channel Hea= der
> =A0 =A0(ACH). =A0RFC 5586 defines the concept of Type-Length-Variable = (TLV)
> =A0 =A0constructs that can be carried in messages on the G-ACh by plac= ing
> =A0 =A0them in the ACH.
>
> =A0 =A0No Associated Channel Type yet defined uses a TLV. =A0Furthermo= re, it
> =A0 =A0is believed that handling TLVs in hardware introduces significa= nt
> =A0 =A0problems to the fast-path, and since G-ACh messages are intende= d to
> =A0 =A0be processed substantially in hardware, the use of TLVs in
> =A0 =A0undesirable.
>
> =A0 =A0This document updates RFC 5586 by retiring ACH TLVs and removin= g the
> =A0 =A0associated registry.
>
>
>
>
> The IETF Secretariat

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/pwe3

--001a11c2efe8d9cf7204dc38e676-- From nobo@cisco.com Fri May 10 15:06:31 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7812D21F909A; Fri, 10 May 2013 15:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXYb2cwBx6Gr; Fri, 10 May 2013 15:06:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BBD8521F8FF1; Fri, 10 May 2013 15:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1800; q=dns/txt; s=iport; t=1368223586; x=1369433186; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kZmq7trb6vqPwOKuUIXPa9nv4Q4n618d1eXhEjA1jWc=; b=e3gHnH/7kR03lWGZhMx0zAO6R3CpB5goTeVhvvsbdemRBSeaSIFzsSQj viwPpGvgYkhfOV8HcDI3nP1FulY9WYT8HaRRc3X20ywr2nMz4o0nZv1OQ 59Ihq1v64r5zhJgGbRLWYL1J6byssQBhxwRQWB0UI503PBHu3cqbprhoU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALBujVGtJXG8/2dsb2JhbABSgmYhN8AgfBZ0gh8BAQEDAQEBATc0CwUHBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCId+BgELvTcEjVsLgRExBwaCbmEDqGGDD4FyNQ X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="208981369" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 10 May 2013 22:06:25 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4AM6P00006170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 22:06:25 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 10 May 2013 17:06:24 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , Sam Aldrin Thread-Topic: [mpls] Commenst on draft-akiya-bfd-intervals-03 Thread-Index: Ac3Rh3XM5+9UcfrcQ2S8rX469rwQOQAAVMZQAAy8rAAAAN+FAAAAiuEAAAAzaYAfAr3RgAABGsbw Date: Fri, 10 May 2013 22:06:23 +0000 Message-ID: References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> In-Reply-To: <20130510172441.GB12732@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Santiago Alvarez \(saalvare\)" , "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" , "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [PWE3] [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:06:31 -0000 Hello Jeff, Sam, Santiago, > As a suggestion, there may be two actual documents in such a case: > - An informational document covering the intervals. > - A short document, potentially on the standards track, covering the > procedure by which timers can negotiate to such an interval. This may = be > worth standardizing. (This is covered by Appendix B.) Thanks for comments & make sense. Marc and I will take this offline (potent= ially pull in some folks) and further discuss next steps. Regards, Nobo > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Jeffrey Haas > Sent: Friday, May 10, 2013 1:25 PM > To: Sam Aldrin > Cc: Santiago Alvarez (saalvare); rtg-bfd@ietf.org; pwe3@ietf.org; > mpls@ietf.org > Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 >=20 > On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote: > > I echo what Santiago had said in his email. Good to have an information= al > document and do not support the idea of standardizing the intervals. >=20 > Speaking as chair, while I'm not in favor of have a standardized set of > intervals (the fights such a document would create would be epic), I am > highly supportive of such a document having informational status. >=20 > As a suggestion, there may be two actual documents in such a case: > - An informational document covering the intervals. > - A short document, potentially on the standards track, covering the > procedure by which timers can negotiate to such an interval. This may = be > worth standardizing. (This is covered by Appendix B.) >=20 > -- Jeff > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From jhaas@slice.pfrc.org Fri May 10 10:24:47 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556B221F8E6E; Fri, 10 May 2013 10:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5i21cFT1Qb6; Fri, 10 May 2013 10:24:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B8B2621F8E62; Fri, 10 May 2013 10:24:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2D96CC27A; Fri, 10 May 2013 13:24:41 -0400 (EDT) Date: Fri, 10 May 2013 13:24:41 -0400 From: Jeffrey Haas To: Sam Aldrin Message-ID: <20130510172441.GB12732@pfrc> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sat, 11 May 2013 08:04:14 -0700 Cc: "Santiago Alvarez \(saalvare\)" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [PWE3] [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 17:24:47 -0000 On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote: > I echo what Santiago had said in his email. Good to have an informational document and do not support the idea of standardizing the intervals. Speaking as chair, while I'm not in favor of have a standardized set of intervals (the fights such a document would create would be epic), I am highly supportive of such a document having informational status. As a suggestion, there may be two actual documents in such a case: - An informational document covering the intervals. - A short document, potentially on the standards track, covering the procedure by which timers can negotiate to such an interval. This may be worth standardizing. (This is covered by Appendix B.) -- Jeff From agmalis@gmail.com Thu May 23 12:49:10 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD0721F96E0 for ; Thu, 23 May 2013 12:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRQlUZ+Bf2o7 for ; Thu, 23 May 2013 12:48:57 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 49E6C21F96CD for ; Thu, 23 May 2013 12:12:56 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k13so44445wgh.0 for ; Thu, 23 May 2013 12:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=jUBk+6q0fVgjqm8cQjf3ZQPPO8P9xSX4/4NMMuYi0nM=; b=v2rtBnGEVNpo1hV58ARyZy0BbenRsY30GtDGcP7D5DEP/Bw8P2gFYAfEMxY7p9c8M+ dX44E/OtWvOpQjboQkz9+GuC2tMdIv5g2N5cn8G+sMc4q0anfKm72tyDULI0+9QjrrZ+ yzDVMqfSwublvN0d+Wd4BFgG1Cm2jLhFxg3SHWOsLmcdorAO1A/qfX33gbgJgeBfseBt bEnbkMHyxQHjFpUkPPPPKiQpnNmGd93AZLScmLrMhIgxDoOy7cjea/tjH1J97gVkKL/I LOE/lXHMGa/ykNVBYt2bpo5LphgDT6GB22j87ZCyugqfk/KiZcwD2vXpb3YuN1tSHzsk /RAg== X-Received: by 10.180.107.104 with SMTP id hb8mr41506354wib.26.1369336295994; Thu, 23 May 2013 12:11:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.83.5 with HTTP; Thu, 23 May 2013 12:11:14 -0700 (PDT) In-Reply-To: <20130523155412.29158.24895.idtracker@ietfa.amsl.com> References: <20130523155412.29158.24895.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Thu, 23 May 2013 15:11:14 -0400 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f234ce5803de204dd6773f4 Subject: [PWE3] Fwd: IETF Meeting in South America X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 19:49:10 -0000 --e89a8f234ce5803de204dd6773f4 Content-Type: text/plain; charset=ISO-8859-1 PWE3ers, Just FYI in case you haven't seen this on the main IETF lists. See the email for instructions on how to comment on the proposed meeting location. Cheers, Andy ---------- Forwarded message ---------- From: The IAOC Date: Thu, May 23, 2013 at 11:54 AM Subject: IETF Meeting in South America To: IETF Announcement List Cc: ietf@ietf.org As you may know the IAOC has been investigating the feasibility of having an IETF meeting in South America. There was a site visit to South America last February. We have found two venues that we believe will support a successful IETF meeting and we would like to get feedback from the community. The venues are in Buenos Aires. They meet our requirements for the meeting space, networking, nearby restaurants and bars, hotel room rates in the mid $200 dollar range, nearby alternate hotels at a broad range of prices, nice area in the city, safe, direct international flights, and accessible visas. The IAOC thinks we could have a successful IETF meeting in Buenos Aires and that attendees would like the venues. There has been a consistent level of IETF participation from South and Central America, and it has been growing since IETF82. The data on this is posted at http://iaoc.ietf.org/documents/IETF-Regional-Attendance-00.pdf. The current meeting regional rotation (announced at IETF79) allows for an occasional IETF meeting outside of our main regions (Europe, North America, Asia/Pacific). IETF standards are made more valuable the more relevant they are and the more uptake they get. IETF standards are also made more robust when all perspectives are represented during their development. Encouraging growing participation will help strengthen the Internet, further encourage participation from those areas that will see the most growth in the coming years, and will help advance the IETF in political and international circles which is becoming more of an imperative. We have asked the IESG for their feedback and they are supportive of a meeting in South America if there is community support and active participants attend. Things to consider are that it will be a long trip for the majority of IETFers and the air fares are more expensive (about 10% to 20% higher than average), though restaurants are less expensive. This would be a case where most IETFers would bear more travel pain and expense. The IAOC would like to understand if the IETF community thinks that the IETF should have a meeting in the next few years in Buenos Aires. The IAOC would also like to get feedback on how we can ensure the meeting is as successful as possible and on ways to grow participation in the region. We have set up a survey at https://www.surveymonkey.com/s/NWYLQCD where you can indicate your likelihood of attending, and we encourage you to send your general feedback to the IETF list . Thanks, Bob Hinden IAOC Chair --e89a8f234ce5803de204dd6773f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
PWE3ers,

Just FYI in case you haven't seen this= on the main IETF lists. See the email for instructions on how to comment o= n the proposed meeting location.

Cheers,
Andy

---------- Forwarded message ----------
From: The IAOC <bob.hinden@gmail.com>
Date: Thu, May 23, 2013 at 11:54= AM
Subject: IETF Meeting in South America
To: IETF Announcement List <ietf-announce@ietf.org>
C= c: ietf@ietf.org


As you may= know the IAOC has been investigating the feasibility of having an IETF
meeting in South America. =A0There was a site visit to South America last F= ebruary.
We have found two venues that we believe will support a successful IETF mee= ting
and we would like to get feedback from the community.

The venues are in Buenos Aires. =A0They meet our requirements for the meeti= ng
space, networking, nearby restaurants and bars, hotel room rates in the mid= $200
dollar range, nearby alternate hotels at a broad range of prices, nice area= in the
city, safe, direct international flights, and accessible visas. =A0The IAOC= thinks we
could have a successful IETF meeting in Buenos Aires and that attendees wou= ld
like the venues.

There has been a consistent level of IETF participation from South and Cent= ral
America, and it has been growing since IETF82. =A0The data on this is poste= d at

=A0 =A0http://iaoc.ietf.org/documents/IETF-Regional-Atten= dance-00.pdf.

The current meeting regional rotation (announced at IETF79) allows for an occasional IETF meeting outside of our main regions (Europe, North America,=
Asia/Pacific).

IETF standards are made more valuable the more relevant they are and the mo= re
uptake they get. =A0IETF standards are also made more robust when all persp= ectives
are represented during their development. =A0Encouraging growing participat= ion
will help strengthen the Internet, further encourage participation from tho= se areas
that will see the most growth in the coming years, and will help advance th= e IETF
in political and international circles which is becoming more of an imperat= ive.

We have asked the IESG for their feedback and they are supportive of a meet= ing in
South America if there is community support and active participants attend.=

Things to consider are that it will be a long trip for the majority of IETF= ers and the
air fares are more expensive (about 10% to 20% higher than average), though=
restaurants are less expensive. =A0This would be a case where most IETFers = would
bear more travel pain and expense.

The IAOC would like to understand if the IETF community thinks that the IET= F
should have a meeting in the next few years in Buenos Aires. =A0The IAOC wo= uld
also like to get feedback on how we can ensure the meeting is as successful= as
possible and on ways to grow participation in the region.

We have set up a survey at =A0https://www.surveymonkey.com/s/NWYLQCD =A0where=
you can indicate your likelihood of attending, and we encourage you to send= your
general feedback to the IETF list <ietf= @ietf.org>.

Thanks,
Bob Hinden
IAOC Chair

--e89a8f234ce5803de204dd6773f4-- From agmalis@gmail.com Wed May 29 06:31:04 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754A521F8B60 for ; Wed, 29 May 2013 06:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeG7t871QzCD for ; Wed, 29 May 2013 06:31:03 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 39DF021F8B5F for ; Wed, 29 May 2013 06:31:03 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hn14so3501699wib.1 for ; Wed, 29 May 2013 06:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Vm0lhIb9tFhmyrY+1pDi86OfU2EMJh0I/a5caQhrYYA=; b=BtBEP1BH0dAMy4YXSHf0qbC0wtfyJJSRuiPUgsuo92lRjyCO+kZ1r4P/NXBvq0ABam VhNAxvQ75wmImr63BMiExqyohxOn+N0oTX8Gam4WSb4zuDXYew2VR0UaeMuR1kI0UYQc v6YZyi88oLEH2hDF+CXa56N5ANS7uragrSsxf2aThmR49Z45Q8k5FCrC7wKZpedwF3cA WD8co8Nq2iVw1lXnlovFmeJ+T0+CktI2BNLDRGYKjXLmqKaGldy4cQ64QcahgzjCqHnn NVseE+/cerJ5Fe+icGwQdYSHyfF53XIN/qaTGffF6z0JVJljehRTCFwcTGCOTaRqjBqt MLsw== X-Received: by 10.180.183.206 with SMTP id eo14mr15674939wic.36.1369834262182; Wed, 29 May 2013 06:31:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.83.5 with HTTP; Wed, 29 May 2013 06:30:42 -0700 (PDT) In-Reply-To: <51A5D286.8050203@pi.nu> References: <51A5D286.8050203@pi.nu> From: "Andrew G. Malis" Date: Wed, 29 May 2013 22:30:42 +0900 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2297c9946c804dddb64a7 Subject: [PWE3] Fwd: The Label Distribution Protocol (LDP) Parameters in the IANA registries X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:31:04 -0000 --001a11c2297c9946c804dddb64a7 Content-Type: text/plain; charset=ISO-8859-1 This is also of interest to the PWE3 WG. Cheers, Andy ---------- Forwarded message ---------- From: Loa Andersson Date: Wed, May 29, 2013 at 7:03 PM Subject: The Label Distribution Protocol (LDP) Parameters in the IANA registries To: "mpls@ietf.org" Cc: "mpls-chairs@tools.ietf.org" , "Andrew G. Malis" Working Group, we have done a few (mostly cosmetic) changes in the "Label Distribution Protocol (LDP) Parameters" namespace. You now (as before) find the name space on the IANA Protocol Registries web page: http://www.iana.org/protocols Look for ""Label Distribution Protocol (LDP) Parameters" First, we have changed the name on the IANA page and the name on the page that have the LDP parameter assignments so the have the same name. This should make it easier to write clear and precise IANA sections in our drafts Second - in the "TLV Type Name Space" we have updated the table; the left most column is now "Value" instead of "Range". Third, we have made the "Unassigned" TLV values explicit. Fourth, we have also updated the mail address for Andy, so it is to his current mailbox. /Loa MPLS wg chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --001a11c2297c9946c804dddb64a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is also of interest to the PWE3 WG.

Cheers,Andy

---------- Forwarded message -= ---------
From: Loa Andersson <loa@pi.nu>
Date: Wed, May 29, 2013 at 7:03 PM
Subject: The Label Distribution Proto= col (LDP) Parameters in the IANA registries
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "mpls-chairs@tools.i= etf.org" <mpls-ch= airs@tools.ietf.org>, "Andrew G. Malis" <agmalis@gmail.com>


Working Group,

we have done a few (mostly cosmetic) changes in the "Label Distributio= n Protocol (LDP) Parameters" namespace.

You now (as before) find the name space on the IANA Protocol Registries
web page: http:= //www.iana.org/protocols

Look for ""Label Distribution Protocol (LDP) Parameters"

First, we have changed the name on the IANA page and the name
on the page that have the LDP parameter assignments so the
have the same name. This should make it easier to write clear
and precise IANA sections in our drafts

Second - in the "TLV Type Name Space" we have updated the table; = the
left most column is now "Value" instead of "Range".

Third, we have made the "Unassigned" TLV values explicit.

Fourth, we have also updated the mail address for Andy, so it is to his
current mailbox.

/Loa

MPLS wg chair

--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64

--001a11c2297c9946c804dddb64a7-- From agmalis@gmail.com Fri May 31 19:31:47 2013 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070E721F8A03 for ; Fri, 31 May 2013 19:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRX-Ed8DIP6s for ; Fri, 31 May 2013 19:31:46 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B981221F8956 for ; Fri, 31 May 2013 19:31:45 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so237497wes.12 for ; Fri, 31 May 2013 19:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=ymqMwQohF3bK4nDkh7U10C9pYD+1J1PD7kxBG59GNa4=; b=dvg4NaoQJvds2cWtGy66f38Gyie0NjSfrhAV9K4VJqEz8kvrEC3WuLS12bP4OzPwCk +8lOwCGX+KN2ZaJXXQPYhL07sVDE9AumZR+Tgth1iM5t32uZJ/e6Ggpjdy1qbhqbARMr rsw5KUjCEv+PWvV4jebudJyRQd1dAIkGNOFp6MgoK59xI05cKL8sd476qcVhA18nT5T2 +mNXYFOLnIs2ETlFP29S3ZUdW2MSwDzWPgEhFj83exStRnUX5LGMaq3nSYKMxKw4lJrc /3WfkTcDTGJ8b/XHUDC3Q5qzpmaHt5hNI3k8IfBi2wEchaP0kqdsgL6JbCRQrvBiPX3i KUVw== X-Received: by 10.180.212.74 with SMTP id ni10mr5417624wic.41.1370053900519; Fri, 31 May 2013 19:31:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.83.5 with HTTP; Fri, 31 May 2013 19:31:20 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Sat, 1 Jun 2013 11:31:20 +0900 Message-ID: To: "pwe3@ietf.org" Content-Type: multipart/alternative; boundary=001a11c363ba104efe04de0e8806 Subject: [PWE3] Fwd: Nomcom 2013-14 Volunteering - 2nd Call X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 02:31:47 -0000 --001a11c363ba104efe04de0e8806 Content-Type: text/plain; charset=ISO-8859-1 Please consider volunteering for nomcom. Cheers, Andy ---------- Forwarded message ---------- From: Mankin, Allison Date: Thu, May 30, 2013 at 6:04 AM Subject: Nomcom 2013-14 Volunteering - 2nd Call To: "ietf-announce@ietf.org" Cc: "" Hi, everyone, Remember that I'm challenging the IETF to come up with 200 volunteers for the upcoming nomcom. You can volunteer just by hitting Reply to this email. What are you waiting for?? The more volunteers we get, the better chance we have of choosing a random yet representative cross section of the IETF population. Respond to the 200-volunteer challenge and hit Reply right now. (Well, much as I want you to do this, please look below at the posts being filled and be sure you are willing to forgo trying for any of them this year). The official information: The IETF nominating committee (nomcom) process for 2013-14 is under way. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The details of the selection and operation of the nomcom can be found in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, reply to this email and volunteer. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. Being a nomcom member will require some time commitment - there will be interviews with candidates at meetings, regularly scheduled conference calls to ensure progress, collection and review of requirements from the commitment, review of candidate questionnaires and of community feedback. A more detailed timetable for the nomcom tasks will appear soon. Please respond to this email before 11:59 pm EDT (UTC -4 hours) June 16, 2013. In the body include: 1. your Given Name as you enter it when you register for the IETF 2. your Family Name as you enter it when you register for the IETF 3. your current primary affilation (the information you enter into the Company field) 4. any/all email addresses you've used to register for IETF meetings 5. which email address you prefer 6. your phone number (for our use in confirming you if selected). You should expect an email response from me within 3 business days stating whether or not you are qualified (and added to the list). If you don't receive this response, please re-send your email adding the tag "RESEND" to the subject line. Participating in the IETF nomcom is a meaningful and fun way to contribute to the IETF. Please help us meet the 200-volunteer challenge by hitting Reply to this message today. Allison Allison Mankin Nomcom Chair 2013-2014 --001a11c363ba104efe04de0e8806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please consider volunteering for nomcom.

Cheers,
Andy

---------- For= warded message ----------
From: Mankin, Al= lison <amankin@verisign.com>
Date: Thu, May 30, 2013 at 6:04 AM
Subject: Nomcom 2013-14 Volunteering = - 2nd Call
To: "ietf-announce@ietf.org" <ietf-announce@ietf.org>
Cc: "<ietf@ietf.= org>" <ie= tf@ietf.org>


Hi, everyone,

Remember that I'm challenging the IETF to come up with 200 volunteers f= or
the upcoming nomcom. =A0You can volunteer just by hitting Reply to this ema= il.

What are you waiting for?? =A0The more volunteers we get, the better chance= we
have of choosing a random yet representative cross section of the IETF
population. =A0Respond to the 200-volunteer challenge and hit Reply right n= ow.
(Well, much as I want you to do this, please look below at the posts being<= br> filled and be sure you are willing to forgo trying for any of them this yea= r).

The official information:
The IETF nominating committee (nomcom) process for 2013-14 is under way. Th= e
IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB,
and the IESG. Ten voting members for the nomcom are selected in a verifiabl= y
random way from a pool of volunteers.

The details of the selection and operation of the nomcom can be found
in RFCs 3777, 5078, 5633, 5680, and 6859. =A0Four of those RFCs =A0(3777, 5= 633,
5680 and 6859) =A0comprise BCP 10. We will also reference RFC 3797.

Volunteers must have attended 3 of the past 5 IETF meetings. =A0As specifie= d in
RFC 3777, that means three out of the five past meetings up to the time thi= s
email announcement goes out to start the solicitation of volunteers. The fi= ve
meetings out of which you must have attended three are IETF 82, 83, 84, 85,= 86.

If you qualify, reply to this email and volunteer.

The list of people and posts whose terms end with the March 2014 IETF
meeting, and thus the positions for which this nomcom is responsible, are IAOC:
Chris Griffiths

IAB:
Bernard Aboba
Marc Blanchet
Ross Callon
Eliot Lear
Hannes Tschofenig

IESG:
Barry Leiba (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant (Routing)
Sean Turner (Security)
Martin Stiemerling (Transport)

The primary activity for this nomcom will begin in July 2013 and should be<= br> completed in January 2014. =A0Being a nomcom member will require some time<= br> commitment - there will be interviews with candidates at meetings, regularl= y
scheduled conference calls to ensure progress, collection and review of
requirements from the commitment, review of candidate questionnaires and of community feedback. =A0A more detailed timetable for the nomcom tasks will appear soon.

Please respond to this email before 11:59 pm EDT (UTC -4 hours)
June 16, 2013. =A0In the body include:
=A01. your Given Name as you enter it when you register for the IETF
=A02. your Family Name as you enter it when you register for the IETF
=A03. your current primary affilation (the information you enter into the C= ompany field)
=A04. any/all email addresses you've used to register for IETF meetings=
=A05. which email address you prefer
=A06. your phone number (for our use in confirming you if selected).

You should expect an email response from me within 3 business days stating<= br> whether or not you are qualified (and added to the list). =A0If you don'= ;t receive this
response, please re-send your email adding the tag "RESEND" to th= e subject line.

Participating in the IETF nomcom is a meaningful and fun way to contribute = to the IETF.
Please help us meet the 200-volunteer challenge by hitting Reply to this me= ssage today.

Allison

Allison Mankin
Nomcom Chair 2013-2014
=A0

--001a11c363ba104efe04de0e8806--