From bclaise@cisco.com Fri May 10 08:57:16 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 9C22321F8AA8; Fri, 10 May 2013 08:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 jjvOHUX6FV+d; Fri, 10 May 2013 08:57:10 -0700 (PDT) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5535D21F872E; Fri, 10 May 2013 08:57:10 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4AFv9Uo022722; Fri, 10 May 2013 11:57:09 -0400 (EDT) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4AFv8YS018607; Fri, 10 May 2013 11:57:08 -0400 (EDT) Message-ID: <518CF242.40403@cisco.com> Date: Fri, 10 May 2013 14:12:34 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "aaa-doctors@ietf.org" , "MIB Doctors (E-mail)" , YANG Doctors , "ops-dir@ietf.org" , IETF DNS Directorate References: <20130509231058.24043.26818.idtracker@ietfa.amsl.com> In-Reply-To: <20130509231058.24043.26818.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130509231058.24043.26818.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [dns-dir] Fwd: [IESG-AGENDA-DIST] Summarized Agenda for the 2013-05-16 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, 10 May 2013 15:57:16 -0000 Dear all, Please find below the agenda of the May 16th IESG telechat. Please send your questions, comments and concerns before May 15th COB. Thanks and Regards, Benoit -------- Original Message -------- INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2013-05-16 IESG Teleconference This agenda was generated at 2013-05-09 16:09:41 PDT Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-ipfix-flow-selection-tech-16 - IETF stream Flow Selection Techniques (Proposed Standard) Note: Nevil Brownlee (nevil@auckland.ac.nz) is the Document Shepherd Token: Benoit Claise Consensus: Unknown o draft-ietf-dhc-triggered-reconfigure-06 - IETF stream Reconfigure Triggered by DHCPv6 Relay Agents (Proposed Standard) Note: Bernie Volz is the document shepherd (volz@cisco.com). Token: Ted Lemon Consensus: Unknown o draft-ietf-netmod-rfc6021-bis-02 - IETF stream Common YANG Data Types (Proposed Standard) Note: David Kessens (david.kessens@nsn.com) is the document shepherd. Token: Benoit Claise Consensus: Yes o draft-ietf-trill-fine-labeling-06 - IETF stream TRILL (Transparent Interconnection of Lots of Links): Fine-Grained Labeling (Proposed Standard) Note: Erik Nordmark (nordmark@acm.org) is the Document Shepherd. Token: Ted Lemon Consensus: Unknown 2.1.2 Returning Items o draft-ietf-core-coap-16 - IETF stream Constrained Application Protocol (CoAP) (Proposed Standard) Token: Barry Leiba IANA Review: IANA - Not OK Consensus: Yes Was deferred by Sean Turner on 2013-04-24 o draft-ietf-tcpm-experimental-options-05 - IETF stream Shared Use of Experimental TCP Options (Proposed Standard) Note: Michael Scharf (michael.scharf@alcatel-lucent.com) is the document shepherd. Token: Martin Stiemerling IANA Review: IANA - Review Needed Consensus: Unknown 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-mpls-tp-ring-protection-06 - IETF stream Applicability of MPLS-TP Linear Protection for Ring Topologies (Informational) Note: Loa Andersson (loa@pi.nu) is the document shepherd Token: Adrian Farrel Consensus: Yes o draft-ietf-6renum-gap-analysis-06 - IETF stream IPv6 Site Renumbering Gap Analysis (Informational) Token: Joel Jaeggli Consensus: Unknown o draft-ietf-opsec-ipv6-implications-on-ipv4-nets-04 - IETF stream Security Implications of IPv6 on IPv4 Networks (Informational) Token: Joel Jaeggli IANA Review: IANA - Review Needed 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 o conflict-review-brandenburg-cdni-has-00 IETF conflict review for draft-brandenburg-cdni-has draft-brandenburg-cdni-has-05 Models for adaptive-streaming-aware CDN Interconnection (ISE: Informational) Token: Martin Stiemerling o conflict-review-touch-tcp-ao-nat-00 IETF conflict review for draft-touch-tcp-ao-nat draft-touch-tcp-ao-nat-04 A TCP Authentication Option NAT Extension (ISE: Experimental) Token: Martin Stiemerling 3.4.3 For Action o conflict-review-irtf-samrg-common-api-00 IETF conflict review for draft-irtf-samrg-common-api draft-irtf-samrg-common-api-08 A Common API for Transparent Hybrid Multicast (IRTF: Experimental) Token: Jari Arkko 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o JavaScript Object Notation (json) 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o IP Performance Metrics (ippm) o Path Computation Element (pce) 4.2.2 Proposed for Approval o Forwarding and Control Element Separation (forces) From sebi@gw01.ehlo.wurstkaes.de Tue May 21 13:54:13 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 867A01F0D23 for ; Tue, 21 May 2013 13:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_54=0.6, 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 xKzkFDfPQ7R3 for ; Tue, 21 May 2013 13:54:12 -0700 (PDT) Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) by ietfa.amsl.com (Postfix) with ESMTP id AF3BF1F0D14 for ; Tue, 21 May 2013 13:54:11 -0700 (PDT) Received: from sebi by gw01.ehlo.wurstkaes.de with local (Exim 4.72) (envelope-from ) id 1UetZ6-0004YD-D2; Tue, 21 May 2013 22:53:48 +0200 Date: Tue, 21 May 2013 22:53:48 +0200 From: Sebastian Kiesel To: Olafur Gudmundsson Message-ID: <20130521205348.GA14960@gw01.ehlo.wurstkaes.de> References: <171C1602-F6CC-4A29-B5CA-EDB44B247995@ogud.com> <515AA78F.7000202@neclab.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515AA78F.7000202@neclab.eu> Accept-Languages: en, de Organization: my personal mail account User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Wed, 22 May 2013 13:39:45 -0700 Cc: Ted Lemon , IETF DNS Directorate , Martin Stiemerling 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: Tue, 21 May 2013 20:54:13 -0000 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 From bclaise@cisco.com Fri May 24 06:50:15 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 39C4021F85C3; Fri, 24 May 2013 06:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.416 X-Spam-Level: X-Spam-Status: No, score=-10.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 Q1HrzyWnWxL4; Fri, 24 May 2013 06:50:08 -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 CB3F421F85E0; Fri, 24 May 2013 06:50:04 -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 r4ODo32T020064; Fri, 24 May 2013 15:50:03 +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 r4ODnm3e005616; Fri, 24 May 2013 15:49:58 +0200 (CEST) Message-ID: <519F6FFC.4000300@cisco.com> Date: Fri, 24 May 2013 15:49:48 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.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" , IETF DNS Directorate References: <20130523224257.19202.51818.idtracker@ietfa.amsl.com> In-Reply-To: <20130523224257.19202.51818.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130523224257.19202.51818.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [dns-dir] Fwd: PRELIMINARY Agenda and Package for the May 30, 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, 24 May 2013 13:50:15 -0000 Dear all, Please find below the agenda of the May 30th IESG telechat. Please send your questions, comments and concerns before May 29th COB. Thanks and Regards, Benoit -------- Original Message -------- INTERNET ENGINEERING STEERING GROUP (IESG) Summarized Agenda for the 2013-05-30 IESG Teleconference This agenda was generated at 2013-05-23 15:40:33 PDT Up-to-date web version of this agenda can be found at: http://datatracker.ietf.org/iesg/agenda/ 1. Administrivia 1.1 Roll Call 1.2 Bash the Agenda 1.3 Approval of the Minutes of Past Telechats 1.4 List of Remaining Action Items from Last Telechat OUTSTANDING TASKS Last updated: May 20, 2013 NONE 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-nfsv4-rfc3530bis-26 - IETF stream Network File System (NFS) Version 4 Protocol (Proposed Standard) Note: Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com) Token: Martin Stiemerling Consensus: Unknown o draft-ietf-nfsv4-rfc3530bis-dot-x-17 - IETF stream Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description (Proposed Standard) Note: Document Author/Shepherd:  Spencer Shepler (sshepler@microsoft.com) Token: Martin Stiemerling Consensus: Unknown o draft-ietf-mmusic-sdp-cs-18 - IETF stream Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN) (Proposed Standard) Note: Flemming Andreasen (fandreas@cisco.com) is the document shepherd. Token: Gonzalo Camarillo Consensus: Unknown o draft-ietf-xrblock-rtcp-xr-decodability-11 - IETF stream RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Independent Decodability Statistics Metrics reporting (Proposed Standard) Note: Dan Romascanu (dromasca@avaya.com) is the Document Shepherd. Token: Gonzalo Camarillo Consensus: Unknown o draft-ietf-dhc-dhcpv6-radius-opt-12 - IETF stream RADIUS Option for DHCPv6 Relay Agent (Proposed Standard) Note: Tomek Mrugalski (tomasz.mrugalski@gmail.com) is the document shepherd. Token: Ted Lemon IANA Review: IANA - Review Needed Consensus: Unknown Last call expires: 2013-05-30 o draft-ietf-oauth-revocation-09 - IETF stream OAuth 2.0 Token Revocation (Proposed Standard) Note: Hannes Tschofenig (hannes.tschofenig@gmx.net) is the document shepherd. Token: Stephen Farrell Consensus: Unknown o draft-ietf-ipsecme-dh-checks-04 - IETF stream Additional Diffie-Hellman Tests for IKEv2 (Proposed Standard) Note: Paul Hoffman (paul.hoffman@vpnc.org) is the document shepherd. Token: Sean Turner Consensus: Unknown 2.1.2 Returning Items o draft-ietf-manet-olsrv2-mib-08 - IETF stream Definition of Managed Objects for the Optimized Link State Routing Protocol version 2 (Proposed Standard) Note: Stan Ratliff (sratliff@cisco.com) is the document shepherd. Token: Adrian Farrel IANA Review: Version Changed - Review Needed Consensus: Yes Was deferred by Benoit Claise on 2013-05-09 2.2 Individual Submissions 2.2.1 New Items o draft-saintandre-impp-call-info-03 - IETF stream Instant Messaging and Presence Purpose for the Call-Info Header Field in the Session Initiation Protocol (SIP) (Proposed Standard) Note: The document shepherd is Yana Stamcheva (yana@jitsi.org). Token: Gonzalo Camarillo Consensus: Unknown 2.2.2 Returning Items NONE 2.3 Status Changes 2.3.1 New Items o status-change-dkim-to-internetstandard-03 - IETF stream Change the status of DKIM (RFC 6376) to Internet Standard (None) Token: Barry Leiba 2.3.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-bmwg-imix-genome-04 - IETF stream IMIX Genome: Specification of variable packet sizes for additional testing (Informational) Note: I've reviewed the discussion on this draft through it's revisions back to IETF 80. I don't believe there are any criticisms remaining that would be considered blocking.As noted (minutes 85) SOB states that that this method is not likely to be used to produce representation of the real world, the real world is not consistent. I think that we can be abundantly aware of the limitations and find utility in this representation.Seeing no additional concerns during the WGLC. I'm prepared to call  this document done and ready to advance. Token: Joel Jaeggli Consensus: Yes o draft-ietf-forces-interop-08 - IETF stream Interoperability Report for Forwarding and Control Element Separation (ForCES) (Informational) Note: Joel Halpern (jmh@joelhalpern.com) is the Document Shepherd. Token: Adrian Farrel IANA Review: Version Changed - Review Needed Consensus: Yes o draft-ietf-softwire-public-4over6-09 - IETF stream Public IPv4 over IPv6 Access Network (Informational) Token: Ted Lemon Consensus: Yes Last call expires: 2013-05-24 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-sheffer-running-code-05 - IETF stream Improving Awareness of Running Code: the Implementation Status Section (Experimental) Token: Stephen Farrell Consensus: Unknown 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 o conflict-review-irtf-samrg-common-api-01 IETF conflict review for draft-irtf-samrg-common-api draft-irtf-samrg-common-api-08 A Common API for Transparent Hybrid Multicast (IRTF: Experimental) Token: Brian Haberman 3.4.2 Returning Items o conflict-review-dolmatov-gost34112012-00 IETF conflict review for draft-dolmatov-gost34112012 draft-dolmatov-gost34112012-01 GOST R 34.11-2012: Hash Function (ISE: Informational) Token: Sean Turner 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o SIP-TO-XMPP (stox) 4.1.2 Proposed for Approval o JavaScript Object Notation (json) 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review o IP Performance Metrics (ippm) o Network Configuration (netconf) 4.2.2 Proposed for Approval NONE