From Martin.Stiemerling@neclab.eu Mon Jun 3 02:09:52 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AC521F94BA for ; Mon, 3 Jun 2013 02:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1, 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 Ht84FAlf+HEM for ; Mon, 3 Jun 2013 02:09:47 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 37F7521F86E9 for ; Mon, 3 Jun 2013 02:09:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 21BB11042DE; Mon, 3 Jun 2013 11:08:29 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YosJBxnHKKIq; Mon, 3 Jun 2013 11:08:29 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 052F01041E1; Mon, 3 Jun 2013 11:08:04 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Jun 2013 11:07:14 +0200 Message-ID: <51AC590E.4060303@neclab.eu> Date: Mon, 3 Jun 2013 10:51:26 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Olafur Gudmundsson References: <171C1602-F6CC-4A29-B5CA-EDB44B247995@ogud.com> <515AA78F.7000202@neclab.eu> <20130521205348.GA14960@gw01.ehlo.wurstkaes.de> In-Reply-To: <20130521205348.GA14960@gw01.ehlo.wurstkaes.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Cc: Sebastian Kiesel , IETF DNS Directorate , Ted Lemon Subject: Re: [dns-dir] Fwd: Re: Review request X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 09:09:52 -0000 Hi Olafur, all, It would be good to get further feedback about Sebastian's email. The draft is intended to become a WG draft but this depends on the outcome of the DNS directorate review, i.e., if this is something that breaks or not. It is also good to get early expert feedback and not just at the end when we go for IETF last call and IESG revoew. Thanks, Martin On 05/21/2013 10:53 PM, Sebastian Kiesel wrote: > Dear Olafur, > > first of all, thanks for the extensive review of the Third-Party ALTO Server > Discovery draft. Martin Stiemerling, who is very busy these days, has > forwarded your comments to me as I am the main author. > > Let's start with your question #6 because it may have an impact > on the other questions: > >> This boat has probably sailed but I will ask it anyway: >> Question #6 Why not place the NAPTR records in the reverse tree? > > There were two reasons why we chose a two-step lookup > IP address --(PTR lookup)--> host name(s) --(U-NAPTR lookup(s))--> ALTO URI(s) > > > First, this draft is a spin-off from draft-ietf-alto-server-discovery. > Because of different deployment scenarios with different requirements, > the original plan was to specify a two-stage discovery procedure with > three options for the first stage: > > 1) Get a domain name by means of > 1a) manual configuration > 1b) DHCP option > 1c) PTR or SOA-mname lookup in in-addr.arpa. / ip6.arpa. > 2) Do a U-NAPTR lookup for the name yielded by step 1 > > Some WG members raised doubts whether 1c) would be feasible at all. > Therefore, it was decided to move 1c) into a seperate draft in order to > allow working on and finalizing the documents at different paces. > > > > Second, we (the draft authors) had some hallway discussions with DNS > operators at IETF meetings about two years ago, and we were told that > putting non-PTR records in the reverse tree has deployment issues, e.g., > with management software that creates the reverse tree automatically > from the forward tree. On the other hand, RFCs 4025, 4255, and 4322 > already do specify non-PTR records in the reverse trees. > > > > Now that the first argument does not apply anymore we don't feel strong > about the second one. We have running proof-of-concept client-side code > and BIND 9 based server-side configuration files for both variants (see > flow charts at the end of this email), but what is the DNS experts' > advise regarding deployment issues? Should we stick with the PTR+NAPTR > variant, or switch to searching the NAPTR in the reverse tree? > > > > For more answers and counter questions, please see inline: > > > On Tue, Apr 02, 2013 at 11:40:31AM +0200, Martin Stiemerling wrote: >> >> >> >> -------- Original Message -------- >> Subject: Re: [dns-dir] Review request >> Date: Fri, 29 Mar 2013 10:13:37 -0400 >> From: Olafur Gudmundsson >> To: Brian Haberman >> CC: IETF DNS Directorate , Ted Lemon >> , Martin Stiemerling >> >> >> I reviewed the document and this is a well written clear document >> with some deficiencies. >> >> The introduction is real good at explaining what the document is attempting. > > thanks. > >> The procedure(s) proposed are based of the implicit assumption that >> provisioning of reverse DNS is >> somehow related to service provision for another protocol, which may >> or may not be the case. > > Our point of view is that for the ALTO application we need a delegation > hierarchy for ALTO servers, which corresponds to the delegation of > IP address ranges to ISPs or other organisations. > > As the DNS reverse tree delegation already follows the address space > delegation (more or less), we think it is natural to use it as a basis > for our discovery problem. We sequentially try two different discovery > approaches: first PTR/NAPTR to allow fine-grained discovery, then > SOA/NAPTR to allow function without having to add many resource records > to the DNS. > >> Question #1: How is dual stack handled in queries? >> in sequence or in parallel ? >> if sequence which one first ? >> >> Question #2 What about hosts with multiple links? > > The short answer is: > > Dual stack and multihoming basically is the same situation: > The third party usually will use 3pdisc only after receiving an > inbound connection from the actual client. It uses the connection's > source address as parameter for 3pdisc and it will not be aware > of the fact that the client has other addresses as well. > > > For a longer discussion, please see Section 3.1.2. of > draft-kist-alto-3pdisc-03, which we have published recently > (you have reviewed the -02 version; the -03 version has several > clarifications and deployment considerations but the algorithm > didn't change). > > >> The procedures expect hope to get back PTR records and the name in >> the PTR record >> is used for further lookups. (good) >> The fundamental question is are all attempts to find PTR exhausted >> before going to next step? >> >> Question #3: what about the case when there are multiple PTR records >> in the answer? > > The algorithm is called with one IP address as parameter, even in the > case of multihoming/dual stack (see above). Finding the PTRs associated > with said IP address is one lookup. Then, we do a NAPTR lookup on every > yielded host name. This is the only loop in the algorithm. If all of > that fails, we do at most two more lookups for the SOA/NAPTR-based > "Plan B". So, if there are N PTR records associated with an IP address, > the procedure causes at most N+3 DNS lookups. > >> If the lookup fails the procedure hopes to find SOA record in the >> negative answer, >> extracts from the SOA record the name of the "Master DNS server" MNAME, >> and uses that name to do further lookups. >> >> Comment #1: Master DNS servers are not always reachable, as they are >> hidden masters or >> traffic protected. > > We are fully aware of that. Indeed, we never try to contact the master > server. We just use its name for further lookups. We decided to use > the SOA-MNAME instead of the NS records for the respective > in-addr.arpa/ip6.arpa. zone, because there is only one SOA but there > could be several NS, which would cause even more iterating over lists. > >> Frequently there is no correlation between the >> zone name and the Mname >> I did a randomly selected reverse lookup on 185.55.55.55 >> 185.in-addr.arpa. 3600 IN SOA pri.authdns.ripe.net. dns.ripe.net. ??. >> >> In this case it is obvious (to a human) the SOA is useless and the >> algorithm should terminate, > > Why do you think this name is obviously useless? According to whois, > 185/8 is managed by RIPE. Maybe they will provide an ALTO server in the > future. Anyway, it is a single NAPTR lookup to find out. > >> what the procedure as specified will do is to cause many queries to >> the RIR name servers for lots of names that have >> no PTR records and no delegations. > > We have no data on the percentage of IP addresses that have PTRs in the > reverse tree. The first optimization target for ALTO is P2P > applications, with the peers mostly in DSL/cable access networks. At > least in the U.S. and Europe most of these IP addresses seem to have PTRs. > > In the worst case the algorithm causes 3+N DNS lookups, with N being the > number of PTR records assigned to an IP address (usually 0 or 1). > > Do you think this procedure will cause a significant burden for the DNS > as a whole? > > >> Question #4: Why MNAME but not the owner name of the SOA ? (explain >> or point to explanation) > > What is "the owner name of the SOA"? > > Do you mean the RNAME field defined in RFC 1035, Sec 3.3.13? If so, > that would be an option as well but we think the MNAME is the more > natural choice as this is a real host name. > >> Question #5: What is the point of the explicit SOA query for reverse >> name and why do editors expect to get a different answer than in the >> PTR question ? > > The explicit SOA query is used only if the answer to the PTR query did > not contain an authority section (and there were no PTRs or they did > not produce ALTO-specific U-NAPTR lookup results). > >> Section #4: >> there is no mention about the expected extra traffic to RIR (and or >> ISP) DNS server when the PTR lookup fails, >> I would like to see some text on how to abort the algorithms early I.e. >> SOA present --- useful SOA ---> do lookup >> +-------- useless SOA ---> algorithm failed >> > > If we are in the "second half" of the algorithm, i.e., the PTR stuff > has failed, we do at most two further lookups: one to get the SOA if > we don't already have it, the second to check whether there are NAPTR > records associated with the SOA's MNAME. There are no loops around it! > >> This boat has probably sailed but I will ask it anyway: >> Question #6 Why not place the NAPTR records in the reverse tree? > > see above. > >> Editing comment: It would be helpful if the text from section 3 >> bullet 1 about what address to look up was included in section 2 >> before the >> diagrams of the algorithms (or at least pointer to address selection). >> >> Olafur >> >> On Mar 28, 2013, at 6:01 PM, Brian Haberman >> wrote: >> >>> Hi all, >>> The ALTO WG is considering the adoption of a draft focused on the discovery of an ALTO server using DNS (but not SRV records). Martin (TSV AD) has requested an early DNS Directorate review. Could I get a volunteer (or two) to review the draft for DNS sanity? >>> >>> https://datatracker.ietf.org/doc/draft-kist-alto-3pdisc/ >>> >>> Regards, >>> Brian >>> _______________________________________________ >>> dns-dir mailing list >>> dns-dir@ietf.org >>> https://www.ietf.org/mailman/listinfo/dns-dir > > ------------------------------------------------------------------------ > Flow chart taken from draft-kist-alto-3pdisc-03 > (equivalent to variant 1 in -02, but more detailed): > > (-------------------------------------) > ( START 3pdisc with parameters ) > ( IP address IP, Service Parameter SP ) > (------------------+------------------) > V > +- T1 -------------+------------------+ > | R:=.in-addr.arpa./.ip6.arpa.| > | X:=lookup(PTR,R) | > +------------------+------------------+ > V > / B1 --------+------------\ > /----< One or more PTR(s) in X >----\ > | yes \-------------------------/ no | > | V > +- T2 --------|-------------+ /----------------->+ > | V | | V > | /-> FOREACH Y:=PTR in X | | /- B3 -------+------------\ > | | +--------+-----------+ | | < AuthSect with SOA RR in X > > | | |lookup(U-NAPTR,Y,SP)| | | \--+---------+------------/ > | | |add results to Z | | | yes | V no > | | +--------+-----------+ | | | +- T3 -+-------------+ > | \-----------+ | | | | X:=lookup(SOA,R) | > +-------------|-------------+ | | +------+-------------+ > V | | V > /- B2 -------+------------\ | | /- B4 +------------\ no > < One or more results in Z >----/ | -\ > \------------+------------/ no | \-----+------------/ | > | \-------->V yes | > | yes +- T4 --------+-------------+ | > | | Y:=extract MNAME from X | | > V | Z:=lookup(U-NAPTR,Y,SP) | | > +<-----------------\ +-------------+-------------+ | > V | V | > +- T5 --------+-------------+ | /- B5 -------+------------\ | > | sort Z acc. to order,pref | \----< One or more results in Z > | > +-------------+-------------+ yes \------------+------------/ | > V no V<--------------/ > (-------------+-------------) (-------------+-------------) > ( END 3pdisc with result Z ) ( 3pdisc FAILED, no result ) > (---------------------------) (---------------------------) > > > > > ------------------------------------------------------------------------ > Alternative solution with NAPTR records in the reverse tree > (see discussion above): > > (---------------------------------------) > ( START 3pdisc with parameters ) > ( IP_address IP, Service_Parameter SP ) > (-------------------+-------------------) > V > +- T1 --------------+-------------------+ > | R:=.in-addr.arpa. / .ip6.arpa.| > +-------------------+-------------------+ > V > +- T2 --------------+-------------------+ > | X:=DNSlookup(R,U-NAPTR,SP) | > +-------------------+-------------------+ > V > / B1 --------------+------------------\ > /---------< One or more U-NAPTR results in X > > | yes \------------------+------------------/ > | V no > | /- B2 -------------+------------------\ > | /----< Authority sect. with SOA record in X > > | | yes \------------------+------------------/ > | | V no > | | +- T3 --------------+-------------------+ > | | | X:=DNSlookup(R,SOA) | > | | +-------------------+-------------------+ > | | V > | | /- B3 -------------+------------------\ > | | < Lookup OK, SOA record present in X >----\ > | | \------------------+------------------/ no | > | | V yes | > | \----------------------->+ | > | V | > | +- T4 --------------+-------------------+ | > | | M:=extract MNAME from SOA record in X | | > | | X:=DNSlookup(M,U-NAPTR,SP) | | > | +-------------------+-------------------+ | > | V | > | /- B4 -------------+------------------\ V > \--->+<---< One or more U-NAPTR results in X >--->+ > | yes \-------------------------------------/ no | > V V > (-------+-------) (-------+-------) > ( END, result X ) ( END, failure ) > (---------------) (---------------) > > ------------------------------------------------------------------------ > > > Thanks again > Sebastian > -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From bclaise@cisco.com Fri Jun 7 05:30:45 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E2921F8B35; Fri, 7 Jun 2013 05:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.465 X-Spam-Level: X-Spam-Status: No, score=-10.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 C113MF8O1Frr; Fri, 7 Jun 2013 05:30:40 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C76E721F843F; Fri, 7 Jun 2013 05:30:39 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r57CUc9Q021721; Fri, 7 Jun 2013 14:30:38 +0200 (CEST) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r57CUNsk000164; Fri, 7 Jun 2013 14:30:33 +0200 (CEST) Message-ID: <51B1D25F.404@cisco.com> Date: Fri, 07 Jun 2013 14:30:23 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , IETF DNS Directorate , "ops-dir@ietf.org" , YANG Doctors References: <20130606220622.29073.70503.idtracker@ietfa.amsl.com> In-Reply-To: <20130606220622.29073.70503.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130606220622.29073.70503.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [dns-dir] PRELIMINARY Agenda and Package for the June 13, 2013 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 12:30:45 -0000 Dear all, Please find below the agenda of the June 13th IESG telechat. Please send your questions, comments and concerns before June 13th COB. Thanks and Regards, Benoit ---------------------------------------------------- AGENDA PACKAGE FOR 2013-06-13 IESG TELECHAT ---------------------------------------------------- INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2013-06-13 IESG Teleconference 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-sipcore-sip-websocket-08 - IETF stream The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) (Proposed Standard) Note: Paul Kyzivat (pkyzivat@alum.mit.edu) is the document shepherd. Token: Richard Barnes Consensus: Unknown o draft-ietf-6man-impatient-nud-06 - IETF stream Neighbor Unreachability Detection is too impatient (Proposed Standard) Note: Ole Troan is the document shepherd. Token: Brian Haberman Consensus: Unknown o draft-ietf-ipfix-protocol-rfc5101bis-07 - IETF stream Specification of the IP Flow Information eXport (IPFIX) Protocol for the Exchange of Flow Information (Proposed Standard) Note: Juergen Quittek (Quittek@neclab.eu) is the document shepherd. Token: Joel Jaeggli Consensus: Unknown o draft-ietf-geopriv-held-measurements-07 - IETF stream Using Device-provided Location-Related Measurements in Location Configuration Protocols (Proposed Standard) Note: The Document Shepherd is Alissa Cooper (acooper@cdt.org). Token: Richard Barnes Consensus: Unknown 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 2.3 Status Changes 2.3.1 New Items NONE 2.3.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-manet-nhdp-sec-threats-04 - IETF stream Security Threats for NHDP (Informational) Note: Joe Macker is the document shepherd Token: Adrian Farrel Consensus: Yes 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items NONE 3.2.2 Returning Items NONE 3.3 Status Changes 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.4 IRTF and Independent Submission Stream Documents 3.4.1 New Items NONE 3.4.2 Returning Items NONE 3.4.3 For Action o conflict-review-steffann-tunnels-00 IETF conflict review for draft-steffann-tunnels draft-steffann-tunnels-04 A Comparison of IPv6 over IPv4 Tunnel Mechanisms (ISE: Informational) Token: Jari Arkko 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Large-Scale Measurement of Broadband Performance (lmap) 4.1.2 Proposed for Approval o SIP-TO-XMPP (stox) 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval o IP Performance Metrics (ippm) From bclaise@cisco.com Fri Jun 21 09:12:03 2013 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E6721F94E1; Fri, 21 Jun 2013 09:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 SVcKOIw7My8L; Fri, 21 Jun 2013 09:11:57 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 82FB421F9E7D; Fri, 21 Jun 2013 09:11:57 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5LGBuek018353; Fri, 21 Jun 2013 18:11:56 +0200 (CEST) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r5LGBdhO010828; Fri, 21 Jun 2013 18:11:50 +0200 (CEST) Message-ID: <51C47B3B.9070701@cisco.com> Date: Fri, 21 Jun 2013 18:11:39 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , "pm-dir@ietf.org" , IETF DNS Directorate References: <20130621155716.11678.21327.idtracker@ietfa.amsl.com> In-Reply-To: <20130621155716.11678.21327.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130621155716.11678.21327.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020001050806060307040401" Subject: [dns-dir] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2013-06-27 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:12:03 -0000 This is a multi-part message in MIME format. --------------020001050806060307040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Please find below the agenda of the June 27th IESG telechat. Please send your questions, comments and concerns before June 26th COB. Thanks and Regards, Benoit. -------- Original Message -------- Subject: [IESG-AGENDA-DIST] Summarized Agenda for the 2013-06-27 IESG Teleconference Date: Fri, 21 Jun 2013 08:57:16 -0700 From: IESG Secretary To: iesg-agenda-dist@ietf.org INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2013-06-27 IESG Teleconference 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-storm-iser-14 - IETF stream iSCSI Extensions for RDMA Specification (Proposed Standard) Note: David Black (david.black@emc.com) is the document shepherd. Token: Martin Stiemerling IANA Review: IANA - Not OK Consensus: Unknown o draft-ietf-geopriv-relative-location-05 - IETF stream Relative Location Representation (Proposed Standard) Note: Alissa Cooper (acooper@cdt.org) is the document shepherd. Token: Richard Barnes IANA Review: IANA - Not OK Consensus: Unknown o draft-ietf-l3vpn-virtual-hub-06 - IETF stream Virtual Hub-and-Spoke in BGP/MPLS VPNs (Proposed Standard) Note: Document Shepherd is Thomas Morin (thomas.morin@orange.com). Token: Stewart Bryant IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-xrblock-rtcp-xr-discard-14 - IETF stream RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard Count metric Reporting (Proposed Standard) Note: Shida Schubert (shida@ntt-at.com) is the Document Shepherd. Token: Gonzalo Camarillo IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-avtcore-avp-codecs-02 - IETF stream Update to Recommended Codecs for the RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) (Proposed Standard) Note: Magnus Westerlund (magnus.westerlund@ericsson.com) is Document Shepherd. Token: Richard Barnes IANA Review: IANA OK - No Actions Needed Consensus: Unknown o draft-ietf-xrblock-rtcp-xr-jb-12 - IETF stream RTP Control Protocol (RTCP) Extended Report (XR) Block for Jitter Buffer Metric Reporting (Proposed Standard) Note: Dan Romascanu (dromasca@avaya.com) is the Document Shepherd. Token: Gonzalo Camarillo IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-mmusic-sdp-miscellaneous-caps-06 - IETF stream Miscellaneous Capabilities Negotiation in the Session Description Protocol (SDP) (Proposed Standard) Note: Flemming Andreasen (fandreas@cisco.com) is the document shepherd. Token: Gonzalo Camarillo IANA Review: IANA OK - Actions Needed Consensus: Unknown o draft-ietf-pkix-est-07 - IETF stream Enrollment over Secure Transport (Proposed Standard) Token: Sean Turner IANA Review: IANA - Not OK Consensus: Unknown Last call expires: 2013-06-24 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 2.3 Status Changes 2.3.1 New Items NONE 2.3.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-ipsecme-ad-vpn-problem-07 - IETF stream Auto Discovery VPN Problem Statement and Requirements (Informational) Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. Token: Sean Turner IANA Review: IANA OK - No Actions Needed Consensus: Unknown o draft-ietf-pce-gmpls-aps-req-08 - IETF stream Requirements for GMPLS applications of PCE (Informational) Note: Julien Meuric is the document shepherd. Token: Adrian Farrel IANA Review: IANA OK - No Actions Needed Consensus: Yes o draft-ietf-nvo3-overlay-problem-statement-03 - IETF stream Problem Statement: Overlays for Network Virtualization (Informational) Note: The document shepherd is Matthew Bocci (matthew.bocci@alcatel-lucent.com). Token: Stewart Bryant IANA Review: IANA OK - No Actions Needed Consensus: Unknown 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-thornburgh-adobe-rtmfp-07 - IETF stream Adobe's Secure Real-Time Media Flow Protocol (Informational) Token: Martin Stiemerling IANA Review: IANA OK - No Actions Needed Consensus: Unknown Last call expires: 2013-06-25 o draft-sparks-genarea-imaparch-07 - IETF stream IMAP Access to IETF Email List Archives (Informational) Token: Jari Arkko IANA Review: IANA OK - No Actions Needed Consensus: No o draft-housley-rfc2050bis-01 - IETF stream The Internet Numbers Registry System (Informational) Token: Jari Arkko IANA Review: IANA OK - No Actions Needed Consensus: Yes 3.2.2 Returning Items NONE 3.3 Status Changes 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.4 IRTF and Independent Submission Stream Documents 3.4.1 New Items NONE 3.4.2 Returning Items NONE 3.4.3 For Action o conflict-review-donley-nat444-impacts-00 IETF conflict review for draft-donley-nat444-impacts draft-donley-nat444-impacts-06 Assessing the Impact of Carrier-Grade NAT on Network Applications (ISE: Informational) Token: Jari Arkko 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Security Automation and Continuous Monitoring (sacm) 4.1.2 Proposed for Approval o Large-Scale Measurement of Broadband Performance (lmap) 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o Managed Incident Lightweight Exchange (mile) 4.2.2 Proposed for Approval NONE --------------020001050806060307040401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Please find below the agenda of the June 27th  IESG telechat.
Please send your questions, comments and concerns before June 26th COB.


Thanks and Regards, Benoit.


-------- Original Message --------
Subject: [IESG-AGENDA-DIST] Summarized Agenda for the 2013-06-27 IESG Teleconference
Date: Fri, 21 Jun 2013 08:57:16 -0700
From: IESG Secretary <iesg-secretary@ietf.org>
To: iesg-agenda-dist@ietf.org 


INTERNET ENGINEERING STEERING GROUP (IESG)
Summarized Agenda for the 2013-06-27 IESG Teleconference



2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items

  o draft-ietf-storm-iser-14  - IETF stream
    iSCSI Extensions for RDMA Specification (Proposed Standard)
    Note: David Black (david.black@emc.com) is the document shepherd.
    Token: Martin Stiemerling
    IANA Review: IANA - Not OK
    Consensus: Unknown

  o draft-ietf-geopriv-relative-location-05  - IETF stream
    Relative Location Representation (Proposed Standard)
    Note: Alissa Cooper (acooper@cdt.org) is the document shepherd.
    Token: Richard Barnes
    IANA Review: IANA - Not OK
    Consensus: Unknown

  o draft-ietf-l3vpn-virtual-hub-06  - IETF stream
    Virtual Hub-and-Spoke in BGP/MPLS VPNs (Proposed Standard)
    Note: Document Shepherd is Thomas Morin (thomas.morin@orange.com).
    Token: Stewart Bryant
    IANA Review: IANA OK - No Actions Needed
    Consensus: Yes

  o draft-ietf-xrblock-rtcp-xr-discard-14  - IETF stream
    RTP Control Protocol (RTCP) Extended Report (XR) Block for Discard
    Count metric Reporting (Proposed Standard)
    Note: Shida Schubert (shida@ntt-at.com) is the Document Shepherd.
    Token: Gonzalo Camarillo
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-avtcore-avp-codecs-02  - IETF stream
    Update to Recommended Codecs for the RTP Profile for Audio and Video
    Conferences with Minimal Control (RTP/AVP) (Proposed Standard)
    Note: Magnus Westerlund (magnus.westerlund@ericsson.com) is Document
    Shepherd. 
    Token: Richard Barnes
    IANA Review: IANA OK - No Actions Needed
    Consensus: Unknown

  o draft-ietf-xrblock-rtcp-xr-jb-12  - IETF stream
    RTP Control Protocol (RTCP) Extended Report (XR) Block for Jitter
    Buffer Metric Reporting (Proposed Standard)
    Note: Dan Romascanu (dromasca@avaya.com) is the Document Shepherd.
    Token: Gonzalo Camarillo
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-mmusic-sdp-miscellaneous-caps-06  - IETF stream
    Miscellaneous Capabilities Negotiation in the Session Description
    Protocol (SDP) (Proposed Standard)
    Note: Flemming Andreasen (fandreas@cisco.com) is the document
    shepherd.
    Token: Gonzalo Camarillo
    IANA Review: IANA OK - Actions Needed
    Consensus: Unknown

  o draft-ietf-pkix-est-07  - IETF stream
    Enrollment over Secure Transport (Proposed Standard)
    Token: Sean Turner
    IANA Review: IANA - Not OK
    Consensus: Unknown
    Last call expires: 2013-06-24

2.1.2 Returning Items

  NONE

2.2 Individual Submissions
2.2.1 New Items

  NONE

2.2.2 Returning Items

  NONE

2.3 Status Changes
2.3.1 New Items

  NONE

2.3.2 Returning Items

  NONE

3. Document Actions
3.1 WG Submissions
3.1.1 New Items

  o draft-ietf-ipsecme-ad-vpn-problem-07  - IETF stream
    Auto Discovery VPN Problem Statement and Requirements
    (Informational)
    Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd.
    Token: Sean Turner
    IANA Review: IANA OK - No Actions Needed
    Consensus: Unknown

  o draft-ietf-pce-gmpls-aps-req-08  - IETF stream
    Requirements for GMPLS applications of PCE (Informational)
    Note: Julien Meuric  is the document shepherd.
    Token: Adrian Farrel
    IANA Review: IANA OK - No Actions Needed
    Consensus: Yes

  o draft-ietf-nvo3-overlay-problem-statement-03  - IETF stream
    Problem Statement: Overlays for Network Virtualization
    (Informational)
    Note: The document shepherd is Matthew Bocci
    (matthew.bocci@alcatel-lucent.com).
    Token: Stewart Bryant
    IANA Review: IANA OK - No Actions Needed
    Consensus: Unknown

3.1.2 Returning Items

  NONE

3.2 Individual Submissions Via AD
3.2.1 New Items

  o draft-thornburgh-adobe-rtmfp-07  - IETF stream
    Adobe's Secure Real-Time Media Flow Protocol (Informational)
    Token: Martin Stiemerling
    IANA Review: IANA OK - No Actions Needed
    Consensus: Unknown
    Last call expires: 2013-06-25

  o draft-sparks-genarea-imaparch-07  - IETF stream
    IMAP Access to IETF Email List Archives (Informational)
    Token: Jari Arkko
    IANA Review: IANA OK - No Actions Needed
    Consensus: No

  o draft-housley-rfc2050bis-01  - IETF stream
    The Internet Numbers Registry System (Informational)
    Token: Jari Arkko
    IANA Review: IANA OK - No Actions Needed
    Consensus: Yes

3.2.2 Returning Items

  NONE

3.3 Status Changes
3.3.1 New Items

  NONE

3.3.2 Returning Items

  NONE

3.4 IRTF and Independent Submission Stream Documents
3.4.1 New Items

  NONE

3.4.2 Returning Items

  NONE

3.4.3 For Action

  o conflict-review-donley-nat444-impacts-00
    IETF conflict review for draft-donley-nat444-impacts
      draft-donley-nat444-impacts-06
      Assessing the Impact of Carrier-Grade NAT on Network Applications
    (ISE: Informational)
    Token: Jari Arkko

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review

  o Security Automation and Continuous Monitoring (sacm)

4.1.2 Proposed for Approval

  o Large-Scale Measurement of Broadband Performance (lmap)

4.2 WG Rechartering
4.2.1 Under Evaluation for IETF Review

  o Managed Incident Lightweight Exchange (mile)

4.2.2 Proposed for Approval

  NONE
--------------020001050806060307040401--