From nobody Sun Jan 14 05:39:29 2018 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF03F12D7F0; Sun, 14 Jan 2018 05:39:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151593716677.3177.4922288517898944951@ietfa.amsl.com> Date: Sun, 14 Jan 2018 05:39:26 -0800 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-stunbis-14.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 13:39:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized WG of the IETF. Title : Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Jonathan Rosenberg Dan Wing Rohan Mahy Philip Matthews Filename : draft-ietf-tram-stunbis-14.txt Pages : 67 Date : 2018-01-14 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-stunbis-14 https://datatracker.ietf.org/doc/html/draft-ietf-tram-stunbis-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 19 03:40:53 2018 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F33ED1252BA; Fri, 19 Jan 2018 03:40:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151636204794.26783.2603172957637195564@ietfa.amsl.com> Date: Fri, 19 Jan 2018 03:40:47 -0800 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-stunbis-15.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 11:40:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized WG of the IETF. Title : Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Jonathan Rosenberg Dan Wing Rohan Mahy Philip Matthews Filename : draft-ietf-tram-stunbis-15.txt Pages : 67 Date : 2018-01-19 Abstract: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-stunbis-15 https://datatracker.ietf.org/doc/html/draft-ietf-tram-stunbis-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stunbis-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 19 23:12:42 2018 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B861250B8 for ; Fri, 19 Jan 2018 23:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrVV6mcsSz6C for ; Fri, 19 Jan 2018 23:12:37 -0800 (PST) Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61EC51241FC for ; Fri, 19 Jan 2018 23:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-rbbn-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iJ+FT/gNqxrUJcwzN8SZX11k6vwpscGS+cL2lVRb75U=; b=cltoeJwDuv7yOPQ8WWT+rbXbI10TMEogklucSCjEmxojTu4JEd02lDwUf2mSjZD2HyQOjVjSbTIR7YkMET327z1CFTVf7XcaqDCCkdYJPjQs604tMeptBt7G1TOnax5tUedjtn3tU1suBVVb0TiNM1kHVIqPNo/t9EtdU0juVv0= Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0023.outbound.protection.outlook.com [216.32.180.23]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-223-mkNq1pxTP92ySGQ91atfkA-1; Sat, 20 Jan 2018 02:12:33 -0500 Received: from BN6PR03MB3153.namprd03.prod.outlook.com (10.174.94.34) by BN6PR03MB3153.namprd03.prod.outlook.com (10.174.94.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Sat, 20 Jan 2018 07:12:31 +0000 Received: from BN6PR03MB3153.namprd03.prod.outlook.com ([10.174.94.34]) by BN6PR03MB3153.namprd03.prod.outlook.com ([10.174.94.34]) with mapi id 15.20.0428.014; Sat, 20 Jan 2018 07:12:31 +0000 From: "Asveren, Tolga" To: "tram@ietf.org" Thread-Topic: PROTO write up for draft-ietf-tram-stunbis-15 Thread-Index: AdORHkx9+Q2l9uRXSgCJM31s7Bw4IwAn5ukg Date: Sat, 20 Jan 2018 07:12:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR03MB3153; 7:w2pZCTrL51KHAV8pZzj/8dBA8jntSCMWI5rI9Wcc6J+VChx6frlszZ8UOxtVe9moCMrdH9f8watmt2y3s4hMC6n+zM7fFO2IwY1ki/5UZ//Gv6kw6Fe8I1I2v/1etmxycwHdZasA7tQrG01vCOpyjDCJSN6rR/s4Ehb4X5eCKNoQd+HIQoPaGnYMhnYSw6vszGtBpSa0beaC+x0NQ6sW1C9EMYa8IUgcXHYVxCJ2zjRvJ51ynPdQ5AvvZfxHetMk; 20:0FqSVEbMpdkZq+vNPFlpjR1pb9RM8SpIM3n35lhFRX9cyClx/wrhinlj9/gSMI8JpXi1vEdzGOMvHNRIo6DQlUFHwSUH8acT+SEvznP4GtyT21dcmLx0LXRO7+QuxUhK4B7AG4mukzDZRAIzUGKUodmI9oXYsBZYU0jD+7pvb9c= x-ms-office365-filtering-correlation-id: 008c62e9-f90c-4f81-f1f6-08d55fd52c31 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:BN6PR03MB3153; x-ms-traffictypediagnostic: BN6PR03MB3153: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231023)(2400081)(944501161)(6041288)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:BN6PR03MB3153; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR03MB3153; x-forefront-prvs: 0558D3C5AC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(39380400002)(396003)(366004)(346002)(39860400002)(189003)(199004)(3846002)(33656002)(59450400001)(5640700003)(966005)(97736004)(3660700001)(74316002)(305945005)(6916009)(77096007)(6436002)(2501003)(478600001)(106356001)(551544002)(102836004)(2900100001)(6506007)(53936002)(26005)(2351001)(6306002)(6116002)(7736002)(55016002)(7696005)(9686003)(3280700002)(76176011)(25786009)(1730700003)(81156014)(8936002)(8676002)(2906002)(14454004)(2950100002)(68736007)(5660300001)(105586002)(66066001)(316002)(99286004)(230783001)(81166006)(86362001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR03MB3153; H:BN6PR03MB3153.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-microsoft-antispam-message-info: CBtb/kccO3joJzyQAdF0vO1e3d4gs4xM51WHFAJ5GlUBw2KhM1mpKH8xDs5BRfkv/Jt+UGH7zd9GFmG1PIm6Sg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: rbbn.com X-MS-Exchange-CrossTenant-Network-Message-Id: 008c62e9-f90c-4f81-f1f6-08d55fd52c31 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2018 07:12:31.6624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB3153 X-MC-Unique: mkNq1pxTP92ySGQ91atfkA-1 Content-Type: multipart/alternative; boundary="_000_BN6PR03MB3153192657F046288E2D669AA5EE0BN6PR03MB3153namp_" Archived-At: Subject: [tram] PROTO write up for draft-ietf-tram-stunbis-15 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jan 2018 07:12:41 -0000 --_000_BN6PR03MB3153192657F046288E2D669AA5EE0BN6PR03MB3153namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable PROTO write up for draft-ietf-tram-stunbis-15: (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard, as indicated on the front page of the draft. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. In keeping with its tool nature, this specification defines an extensible packet format, defines operation over several transport protocols, and provides for two forms of authentication. This document obsoletes the original STUN specification RFC 5389. Working Group Summary: The working group had a strong consensus around this draft. Document Quality: The document quality is satisfactory. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Tolga Asveren is the document shepherd. Spencer Dawkins and Mirja Kuhlewind are the responsible Area director (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed version 12 of the draft, provided comm= ents. They have been discussed and satisfactorily addressed by version 13 o= f the draft. There also have been other reviews and all comments re address= ed by version 14 of the draft and version 15 contains changes for nits. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. There have been sufficient discussions in the past and during WGLC ti= meframe. There is also at least one implementation of the procedures define= d in this draft. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. The draft has sections pertaining to security, DNS and those are sufficie= ntly reviewed. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. All draft authors also acknowledged that they are not aware of any IP= R associated with the changes introduced by this document. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Strong consensus. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no remaining issues with nits, which are not intentional. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No additional reviews are needed. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. Yes, and it is intentional. The text using the reference for RFC3489 is for the explicit purpose of exp= laining the compatibility issues with that precise version of the protocol.= That is the reason why RFC3489 instead of RFC5389, which obsoletes it, is = used. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Yes, it will obsolete RFC5389. It defines procedures in addition to the o= nes defined in RFC5389. RFC5389 is the listed on the title page and abstrac= t as to be obsoleted. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The IANA Considerations section registers new STUN Methods, updates and d= efines new STUN attributes, updates STUN error codes and updates the refere= nce for STUN UDP/TCP port numbers. It also defines new STUN Security Featur= es Registry/values, Password Algorithm Registry/values. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. New STUN Security Features and Password Algorithm Registries are defined.= IANA experts specializing in security aspects would be suitable for review= ing these. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document has a C snipped to determine STUN Message Types. The C code ha= s been tried and it functions as intended. --_000_BN6PR03MB3153192657F046288E2D669AA5EE0BN6PR03MB3153namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
 
 
PROTO write up for  draft-ietf-tram-stunbis-15:
 
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the
title page header?
 
Proposed Standard, as indicated on the front page of the draft.
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent=
examples can be found in the "Action" announcements for appr= oved
documents. The approval announcement contains the following sections:<= /div>
 
Technical Summary:
 
   Session Traversal Utilities for NAT (STUN) is a protocol = that serves
   as a tool for other protocols in dealing with Network Add= ress
   Translator (NAT) traversal.  It can be used by an en= dpoint to
   determine the IP address and port allocated to it by a NA= T.  It can
   also be used to check connectivity between two endpoints,= and as a
   keep-alive protocol to maintain NAT bindings.  STUN = works with many
   existing NATs, and does not require any special behavior = from them.
 
   STUN is not a NAT traversal solution by itself.  Rat= her, it is a tool
   to be used in the context of a NAT traversal solution.
 
   In keeping with its tool nature, this specification defin= es an
   extensible packet format, defines operation over several = transport
   protocols, and provides for two forms of authentication. =
  This document obsoletes the original STUN specification RFC 538= 9.
 
Working Group Summary:
 
  The working group had a strong consensus around this draft.
 
Document Quality:
 
  The document quality is satisfactory.
 
 
Personnel:
 
Who is the Document Shepherd? Who is the Responsible Area Director?
 
  Tolga Asveren is the document shepherd.
  Spencer Dawkins and Mirja Kuhlewind are the responsible Area di= rector
 
(3) Briefly describe the review of this document that was performed by=
the Document Shepherd. If this version of the document is not ready
for publication, please explain why the document is being forwarded to=
the IESG.
 
  The document shepherd has reviewed version 12 of the draft, pro= vided comments. They have been discussed and satisfactorily addressed by ve= rsion 13 of the draft. There also have been other reviews and all comments = re addressed by version 14 of the draft and version 15 contains changes for nits.
 
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
 
  No. There have been sufficient discussions in the past and duri= ng WGLC timeframe. There is also at least one implementation of the procedu= res defined in this draft.
 
(5) Do portions of the document need review from a particular or from<= /div>
broader perspective, e.g., security, operational complexity, AAA, DNS,=
DHCP, XML, or internationalization? If so, describe the review that
took place.
 
  The draft has sections pertaining to security, DNS and those ar= e sufficiently reviewed.
 
(6) Describe any specific concerns or issues that the Document
Shepherd has with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or she is<= /div>
uncomfortable with certain parts of the document, or has concerns
whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.
 
  No concerns.
 
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP
78 and BCP 79 have already been filed. If not, explain why?
 
  Yes.
 
(8) Has an IPR disclosure been filed that references this document? If=
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
 
  No. All draft authors also acknowledged that they are not aware= of any IPR associated with the changes introduced by this document.
 
(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?<= /div>
 
  Strong consensus.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate<= /div>
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
 
  No.
 
(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the<= /div>
Internet-Drafts Checklist). Boilerplate checks are not enough; this
check needs to be thorough.
 
  There are no remaining issues with nits, which are not intentio= nal.
 
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
 
  No additional reviews are needed.
 
(13) Have all references within this document been identified as
either normative or informative?
 
  Yes.
 
(14) Are there normative references to documents that are not ready
for advancement or are otherwise in an unclear state? If such
normative references exist, what is the plan for their completion?
 
  No.
 
(15) Are there downward normative references references (see RFC
3967)? If so, list these downward references to support the Area
Director in the Last Call procedure.
 
  Yes, and it is intentional.
The text using the reference for RFC3489 is for the explicit purpose o= f explaining the compatibility issues with that precise version of the prot= ocol. That is the reason why RFC3489 instead of RFC5389, which obsoletes it= , is used.
 
 
 
(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed<= /div>
in the abstract, and discussed in the introduction? If the RFCs are
not listed in the Abstract and Introduction, explain why, and point to=
the part of the document where the relationship of this document to
the other RFCs is discussed. If this information is not in the
document, explain why the WG considers it unnecessary.
 
  Yes, it will obsolete RFC5389. It defines procedures in additio= n to the ones defined in RFC5389. RFC5389 is the listed on the title page a= nd abstract as to be obsoleted.
 
(17) Describe the Document Shepherd's review of the IANA
considerations section, especially with regard to its consistency with=
the body of the document. Confirm that all protocol extensions that
the document makes are associated with the appropriate reservations in=
IANA registries. Confirm that any referenced IANA registries have been=
clearly identified. Confirm that newly created IANA registries include=
a detailed specification of the initial contents for the registry,
that allocations procedures for future registrations are defined, and<= /div>
a reasonable name for the new registry has been suggested (see RFC
5226).
 
  The IANA Considerations section registers new STUN Methods, upd= ates and defines new STUN attributes, updates STUN error codes and updates = the reference for STUN UDP/TCP port numbers. It also defines new STUN Secur= ity Features Registry/values, Password Algorithm Registry/values.
 
(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.
 
  New STUN Security Features and Password Algorithm Registries ar= e defined. IANA experts specializing in security aspects would be suitable = for reviewing these.
 
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
 
The document has a C snipped to determine STUN Message Types. The C co= de has been tried and it functions as intended.
 
--_000_BN6PR03MB3153192657F046288E2D669AA5EE0BN6PR03MB3153namp_-- From nobody Mon Jan 29 06:05:38 2018 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B6312D7F1; Mon, 29 Jan 2018 06:05:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: sperreault@jive.com, tram-chairs@ietf.org, tram@ietf.org, spencerdawkins.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151723473611.3101.12048044668588171997.idtracker@ietfa.amsl.com> Date: Mon, 29 Jan 2018 06:05:36 -0800 Archived-At: Subject: [tram] tram - Not having a session at IETF 101 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2018 14:05:36 -0000 Simon Perreault, a chair of the tram working group, indicated that the tram working group does not plan to hold a session at IETF 101. This message was generated and sent by the IETF Meeting Session Request Tool.