From nobody Wed Nov 4 11:41:31 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 751ED3A0FEB; Wed, 4 Nov 2020 11:41:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana via Datatracker To: "The IESG" Cc: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alvaro Retana Message-ID: <160451888939.14817.13295583498248182378@ietfa.amsl.com> Date: Wed, 04 Nov 2020 11:41:29 -0800 Archived-At: Subject: [dispatch] Alvaro Retana's No Objection on charter-ietf-sframe-00-02: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 19:41:30 -0000 Alvaro Retana has entered the following ballot position for charter-ietf-sframe-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It's not clear to me what exactly this last piece of text means: Input to the WG Proposals already existing relating to this charter proposal: https://datatracker.ietf.org/doc/html/draft-omara-sframe-00 It is just a pointer to existing work? Is it a statement that the WG should use (or maybe will use) this document as the base for discussion? Given that the document was the source of the discussion that led to this WG, I assume it's the latter. Please be clear. From nobody Wed Nov 4 13:27:26 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE223A1019 for ; Wed, 4 Nov 2020 13:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 On_rr8v4XfZ5 for ; Wed, 4 Nov 2020 13:27:24 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE0D3A1014 for ; Wed, 4 Nov 2020 13:27:23 -0800 (PST) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0A4LRJTg029050 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Nov 2020 15:27:20 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1604525241; bh=9zbikk3BfLoj0osKIR3fWaREHvRCXWSWQwOUaZTl88s=; h=From:Date:Subject:Cc:To; b=SK9i1kqxU+zWp9tn8UW0H1P5pFOVuRJJeRaTxRf776exxBVn7OJkUu5BNrTfQclOv bGly6bJk6aOVR2xrTAHxSO9932RR3aHWHisQybVgRDVp+223+ni5ZDSUY/O/MjxhFj VS+vFrvOSB25SnwiIBBbaZqFkbeDsMzlQn5g1tuQ= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 4 Nov 2020 15:27:13 -0600 To: dispatch@ietf.org Message-Id: <78A9726E-49AB-450F-B455-9987646F4E1D@nostrum.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [dispatch] DRAFT Agenda for IETF109 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 21:27:25 -0000 Hi, The draft agenda for the IETF 109 dispatch meeting is available at the = following link: https://www.ietf.org/proceedings/109/agenda/agenda-109-dispatch-00 It=E2=80=99s also pasted below for your convenience. Please send any = feedback, suggestions, or other agenda bashes to the chairs and dispatch = list as soon as possible. Thanks! Ben. =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 # DISPATCH Virtual Meeting @IETF-108=20 Monday, 16 November 2020 05:00-07:00 UTC = [MeetEcho](https://meetings.conf.meetecho.com/ietf109/?group=3Ddispatch&sh= ort=3D&item=3D1) [Notes](https://codimd.ietf.org/notes-ietf-109-dispatch) [Jabber](xmpp:dispatch@jabber.ietf.org?join) DISPATCH Meeting=20 ---------------- ### Status and Agenda Bash - Chairs and ADs (15 min) ### A Few Words from our ADs - (5 min) ### IANA Registration of Content-Type Header Field Parameter - = Bernie/Alexey (30 min) = [Draft](https://datatracker.ietf.org/doc/draft-melnikov-iana-reg-forwarded= /) ### The 'haptics' Top-level Media Type - Yeshwant (30 min) = [Draft](https://datatracker.ietf.org/doc/draft-muthusamy-dispatch-haptics/= ) ### WebRTC-HTTP ingestion protocol - Sergio (30 min) [Draft](https://datatracker.ietf.org/doc/draft-murillo-whip/) ART AREA Meeting=20 ---------------- ### BoFs and meetings of interest - ADs (10 min) ### AOB From nobody Thu Nov 5 08:03:06 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF263A13D2; Thu, 5 Nov 2020 08:03:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160459217995.25275.15999743679552040874@ietfa.amsl.com> Date: Thu, 05 Nov 2020 08:02:59 -0800 Archived-At: Subject: [dispatch] Benjamin Kaduk's No Objection on charter-ietf-sframe-00-02: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 16:03:00 -0000 Benjamin Kaduk has entered the following ballot position for charter-ietf-sframe-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This working group, however, will not specify the signaling required to configure SFrame encryption. In particular, considerations related to SIP or SDP are out of scope. This is because SFrame is intended to be applied as an additional layer on top of the base levels of protection that these protocols provide. [...] This text reads like it is saying that SIP and SDP provide "base levels of protection", which is not necessarily the case in the context of the protection that SFrame provides. It is anticipated that several use cases of SFrame will involve its use with keys derived from the MLS group key exchange protocol. The working group will define a mechanism for doing SFrame encryption using keys from MLS, including, for example, the derivation of SFrame keys per MLS epoch and per sender. It may be worth adding another sentence here to reiterate that just because MLS is complicated and may need special integration, that does not preclude using SFrame with other sources of key material. From nobody Fri Nov 6 10:29:12 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2BB3A0AA2 for ; Fri, 6 Nov 2020 10:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.279 X-Spam-Level: X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 9IZM2wmWr39c for ; Fri, 6 Nov 2020 10:29:09 -0800 (PST) Received: from forward106j.mail.yandex.net (forward106j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::109]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC3AB3A0AA0 for ; Fri, 6 Nov 2020 10:29:09 -0800 (PST) Received: from mxback18o.mail.yandex.net (mxback18o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::69]) by forward106j.mail.yandex.net (Yandex) with ESMTP id 5B09911A0158; Fri, 6 Nov 2020 21:29:06 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback18o.mail.yandex.net (mxback/Yandex) with ESMTP id JO7LyuN6rQ-T5YeosoE; Fri, 06 Nov 2020 21:29:05 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1604687345; bh=bdkd/cbq+SATQ2GXE/K7jGJz2ur0ah4L5Ok3TXXnddA=; h=Message-Id:Date:Cc:Subject:To:From; b=mL4L63sxI+qLHqTdf3y3s8npJHDVVBFinl47dSWPwJEa7vQc6yRv7WyyxwSDvjSfy 5UsObVziR9zD5jwIITGkr45qV9udpgmpCkrkY4TQ4w3pG7KwZxvUII1kTtgjkKZQ2B J7JEC9m/xZdqK88V5r3KiAn9RHDTqP3Klk7qeX5k= Authentication-Results: mxback18o.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by iva5-4e96f110c519.qloud-c.yandex.net with HTTP; Fri, 06 Nov 2020 21:29:05 +0300 From: Anton Tveretin To: Yeshwant Muthusamy Cc: DISPATCH list MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 06 Nov 2020 23:29:05 +0500 Message-Id: <27451604686255@mail.yandex.ru> Content-Transfer-Encoding: 7bit Content-Type: text/html Archived-At: Subject: Re: [dispatch] draft-muthusamy-dispatch-haptics-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 18:29:11 -0000
I support this. I think I should add it into the next release of 6GTAPI.
I also think that we should make clear that we are adding a new major media type (as in SDP), not a MIME major type. They are separate namespaces [RFC 4566]. Though now all 7 major media types are also MIME major types.
From nobody Fri Nov 6 11:09:00 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A294A3A0B5C; Fri, 6 Nov 2020 11:08:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Cc: sframe-chairs@ietf.org, The IESG , dispatch@ietf.org, sframe@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <160468973464.30968.15143783219177718112@ietfa.amsl.com> Date: Fri, 06 Nov 2020 11:08:54 -0800 Archived-At: Subject: [dispatch] WG Action: Formed Secure Media Frames (sframe) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2020 19:08:55 -0000 A new IETF WG has been formed in the Applications and Real-Time Area. For additional information, please contact the Area Directors or the WG Chairs. Secure Media Frames (sframe) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Bobo Bose-Kolanu Martin Thomson Assigned Area Director: Murray Kucherawy Applications and Real-Time Area Directors: Barry Leiba Murray Kucherawy Mailing list: Address: sframe@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/sframe Archive: https://mailarchive.ietf.org/arch/browse/sframe/ Group page: https://datatracker.ietf.org/group/sframe/ Charter: https://datatracker.ietf.org/doc/charter-ietf-sframe/ Real-time conferencing sessions increasingly require end-to-end protections that prevent intermediary servers from decrypting real-time media. The PERC WG developed a “double encryption” scheme for end-to-end encryption that was deeply tied to SRTP as its underlying transport. This entanglement has prevented widespread deployment. This working group will define the SFrame secure encapsulation to provide authenticated encryption for real-time media content that is independent of the underlying transport. The encapsulation will provide the following information to drive the authenticated encryption for each encryption operation: * Selection among multiple encryption keys in use during a real-time session * An algorithm for forming a unique nonce within the scope of the key based on information in the encapsulation framing The SFrame specification will detail the specific security properties that the encapsulation provides, and discuss their implications under common usage scenarios / threat models. The transport-independence of this encapsulation means that it can be applied at a higher level than individual RTP payloads. For example, it may be desirable to encrypt whole frames that span multiple packets in order to amortize the overhead from framing and authentication tags. It may also be desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1 OBUs) to allow partial frames to be usable. The working group will choose what levels of granularity can be selected in the protocol. An application using SFrame will need to choose several aspects of its operation, for example: * Selecting whether SFrame is to be used for a given media flow * Specifying which encryption algorithm should be used * Provisioning keys and key identifiers to endpoints * Selecting the granularity at which SFrame encryption is applied (if multiple options are available) This working group, however, will not specify the signaling required to arrange SFrame encryption. In particular, considerations related to SIP or SDP are out of scope. This is because SFrame is intended to be applied as an additional layer on top of the base levels of protection that these protocols provide. This working group will, however, define the guidance for how SFrame interacts with RTP (e.g., with regard to packetization, depacketization, and recovery algorithms) to ensure that it can be used in environments such as WebRTC. Other WebRTC changes such as the payload format and metadata format will be addressed by the AVTCORE working group. It is anticipated that several use cases of SFrame will involve its use with keys derived from the MLS group key exchange protocol. The working group will define a mechanism for doing SFrame encryption using keys from MLS, including, for example, the derivation of SFrame keys per MLS epoch and per sender. The availability of this mechanism for using keys from MLS does not preclude the use of other sources of key material. Milestones: Jun 2021 - Submit SFrame specification to IESG (Standards Track) From nobody Tue Nov 10 14:14:28 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B673A10E7 for ; Tue, 10 Nov 2020 14:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 T3NzIq69mE0c for ; Tue, 10 Nov 2020 14:14:26 -0800 (PST) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED353A10E4 for ; Tue, 10 Nov 2020 14:14:25 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 0AAM82nL039405; Tue, 10 Nov 2020 14:14:24 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=htWJAfm3pC6j9Xc6+xZhKfoSAJQdlje4bop7lV7i4+I=; b=d5Ed32nm8E7mIJfBZ+HdfRpOXVktBUH9DgZH5hiYa2Y669MBJIY1Qs5LoGzFWk4WDwSm 46vbU2kS8rcOklQez4zo/t4h7Qw2YUTim2u6Smty/cTFtxmtttNiIEQVkPgcRPna5Eoa HQGFw92Q/pCenvCKkPeoWKKfGeKsT3snBBRxOgJH27WwrGSXj7T6376tPxSJHF1DEEAD 9Akw3a6kXVN6lizLS/EqTwfRG449mEOUjUWWTnkSGlQ8yIg1n4dEM2o5SjGkJu0heGT3 s/+MaGq9gnPxIeVIgxMNZpMOSvMf2qNS9krDsugLWs+85by+3S8cKLB/8SCd0RuY+w4I sw== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 34nuf1q9eh-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Nov 2020 14:14:24 -0800 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QJL00XDMPS0X160@rn-mailsvcp-mta-lapp02.rno.apple.com>; Tue, 10 Nov 2020 14:14:24 -0800 (PST) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QJL00I00PE2ZG00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 10 Nov 2020 14:14:24 -0800 (PST) X-Va-A: X-Va-T-CD: 74e0fe049f0018981425c9e9dd736fce X-Va-E-CD: a9b383ae911cef976db69c5e3373305f X-Va-R-CD: 539371c0d5821f6669e47b0a08541ba8 X-Va-CD: 0 X-Va-ID: d6b47879-5d4d-401e-8775-a0538d28696b X-V-A: X-V-T-CD: 74e0fe049f0018981425c9e9dd736fce X-V-E-CD: a9b383ae911cef976db69c5e3373305f X-V-R-CD: 539371c0d5821f6669e47b0a08541ba8 X-V-CD: 0 X-V-ID: b15496e7-83f9-4f6b-b5db-5e4d190af692 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-10_08:2020-11-10, 2020-11-10 signatures=0 Received: from [17.234.14.108] (unknown [17.234.14.108]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QJL00LBHPR99H00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 10 Nov 2020 14:14:23 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: David Singer In-reply-to: <87tuunavzc.fsf@hobgoblin.ariadne.com> Date: Tue, 10 Nov 2020 14:14:23 -0800 Cc: Yeshwant Muthusamy , Chris Ullrich Content-transfer-encoding: quoted-printable Message-id: References: <87tuunavzc.fsf@hobgoblin.ariadne.com> To: dispatch@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-10_08:2020-11-10, 2020-11-10 signatures=0 Archived-At: Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 22:14:27 -0000 > On 21Oct, 2020, at 18:29 , Dale R. Worley wrote: >=20 > Another is that it seems like few of these media formats are > non-secret. There are registrations of media formats that are > patent-encumbered, but the specifics of those formats can be > documented. What would really encourage support for a haptics data = type > is one or more open standards. I think the standards are under way; but the top-level type reflects the = existence of a distinct media type and is not, as far as I know, likely = to be encumbered. Though we all know what is needed to present (for example) stereo audio = or =E2=80=99normal video=E2=80=99, haptics doesn=E2=80=99t have such a = presentational obvious baseline, so I think general formats may take a = little longer than for the more traditional types. I don=E2=80=99t think = that should stop the top-level registration, as collecting single-vendor = examples will help us see what a general format might look like. I don=E2=80=99t think we should mix up what=E2=80=99s needed for = sub-type registration, with establishment of the top-level type. = Yeshwant can and should cite examples in the industry, but it=E2=80=99s = not for him to register other people=E2=80=99s formats, of course. > On 24Oct, 2020, at 9:28 , John C Klensin wrote: >=20 > If you are not already in close touch with, and participating > in, ISO/IEC JTC1 SC29 (the body responsible for ISO/IEC > 14496-12), make that connection. If you need help, you might > approach Stephan Wenger, who is IETF's liaison to that SC (see > https://www.ietf.org/about/liaisons/ ). If they are > establishing the "real" definition for the top-level type and > they (or their MA) are defining or approving the registrations, > ending up with a separate registration system in the IETF -- one > that might not be precisely synchronized -- would be really bad > news. =20 Indeed, it was conversation there that led me to suggest to Yeshwant = that we should pay attention to the media-type registration. I don=E2=80=99= t think SC29 can or should define the top-level type to suit only = what=E2=80=99s happening at MPEG. The top-level type should be general. > On 24Oct, 2020, at 9:28 , John C Klensin wrote: >=20 > If there is going to be a new > top-level type, your defining document needs to specify exactly > how subtypes will be registered and managed. Thanks, yes: I would assume very similarly to audio and video. > On 26Oct, 2020, at 7:46 , Ned Freed wrote: >=20 > This may be the case, but it's not the only, or most important case = you need to > make when justifying the creation of a top-level type. In particular, = you > need to explain why haptics deserve special recognition rather than = living > under application, as a myriad of other things (word processing = formats, > spreadsheet formats, automative control formats, etc.) do. >=20 > I don't think this is a difficult case to make - it seems to me that = haptics > data represents a fundamentally different sort of data in the same way = that we > differentiate audio, video, etc. But I think section 2 falls short of = making > the case currently. I=E2=80=99ll try to help Yeshwant improve that section. I think that = perceptual types probably deserve a mediatype, as they indicate what = kind of expression capability you need (e.g. a screen to present video, = speakers for audio, and so on). >=20 > On 27Oct, 2020, at 4:33 , Cullen Jennings wrote: >=20 > How do we deal with that this media type is often embedded in a video = stream? Is this really different than game controller inputs and moves = in real time settings?=20 Indeed, when timed media is multiplexed (a/v files) we have to choose; = at the moment, video/mp4 covers video-only and audio/video, and we=E2=80=99= ll need to decide what to do if timed haptics is multiplexed in. But = note that modern streaming delivery (DASH, HLS) is de-multiplexed, so = that would enable correct substream typing. > On 27Oct, 2020, at 4:43 , Martin J. D=C3=BCrst = wrote: >=20 > As an aside, I think delegating the registration of subtypes in a = certain top-level type to some other standards organization (as alluded = to by John Klensin) is a bad idea because it would create confusion and = additional overhead. T I agree, and I don=E2=80=99t think MPEG is set up for it either; nor is = there any pretense that they =E2=80=98own=E2=80=99 the industry haptics = space. There=E2=80=99s just early work there on handling timed haptics = in a harmonious way along with audio and video, and some other early = work on looking for a possible general format. David Singer singer@mac.com Dave Singer Multimedia and Software Standards, Apple singer@apple.com From nobody Wed Nov 11 08:34:58 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203803A0EB8 for ; Wed, 11 Nov 2020 08:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 tBuI_zPqzGw9 for ; Wed, 11 Nov 2020 08:34:56 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3642E3A1038 for ; Wed, 11 Nov 2020 08:34:49 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MoOQu-1jxFjY1viq-00okNr; Wed, 11 Nov 2020 17:34:44 +0100 Date: Wed, 11 Nov 2020 11:34:43 -0500 (EST) From: Timothy Mcsweeney To: dispatch@ietf.org, superuser@gmail.com, barryleiba@computer.org, Ted Hardie Message-ID: <1109305790.11874.1605112483803@email.ionos.com> In-Reply-To: <1425839401.61842.1593845948843@email.ionos.com> References: <1425839401.61842.1593845948843@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:BmuDWMyJ6eFjyK+k8fsOtxevUoLcQRCw4xr4wM9EpbrK7YP0KeV 1DwDz/M8G0uIA+g0ZCzxLV5oy7ZXINW6rKWyTOIiQmypEv11AyJDbAzl3g6bPkgumvq3z9z XSQezHiur42gALTGP1O/DOJVTuE2clFMDWl8so2I6AOXJqwn3p5/fAcFmFYXDEps0s5EKN7 d7GJILVcFAVRi5koyUhRg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Op+2pNCO66g=:R3A0bf9uZ1Pbwm3vbX+Vt5 8t7YZ5gU1YqqMokVGj3V141WmIzsRI/r+GdDjNdcTLCEGFjVquyagTueAPbACdgGEM/bQH40+ fZxOzRk6EU0a1jNoHEBXe5mj5Yr0zDnnu6eNZZ6jpPeUrMzXZsmjAr+tABZl8yHLtzJtiqYzT 8kE4bxKa5aBDV+s5/ZB06WrzvIRrgHfmpPOsAg4vtad9Sb0QeICzUpmRbzKSULaC2HPqRa8p3 Ww1M4+JBROPiOGtTpJEI525n4pr8m1WEeze6piNjgbjNpV79L4s9NHLtpmUo1aWBqPICxasvG BplkxhhOwLCx3MgxC/1izTNjwcn6ZNz84yQmfp5tCAiqDzUnFLZxvHDAen2EWjDUH4JiWAuXe J0K8iUaQ3mW6dsXLH/i+9XCUErnRxvOAoUu+qw7TIk5vyaLO6JyokzXTzf2lj9zRCJn1s0ftk cc+5wpNi+A== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:34:57 -0000 text version: > I'm hoping for a quick dispatch of this, but happy to discuss. What's the hurry Ted? I know you know your stuff but this draft seems somewhat "corrupted" In your introduction you're talking about registering scheme "NAMES" and then state "..there is no way in the current process set out in BCP 35 [RFC7595] to meet the requirement." ?? Section 5 of RFC3405 has nothing to do with that. Maybe it's BCP 35 [RFC7595] that needs the update. But hey, at least we both agree that uri.arpa registrations don't currently require permanent status. > On 07/04/2020 2:59 AM Timothy Mcsweeney wrote: > > > > I'm hoping for a quick dispatch of this, but happy to discuss. > > > What's the hurry Ted? > > I know you know your stuff but this draft seems somewhat "corrupted" > In your introduction you're talking about registering scheme "NAMES" > and then state "..there is no way in the current process set out in BCP 35 [RFC7595] to meet the requirement." ?? > Section 5 of RFC3405 has nothing to do with that. > Maybe it's BCP 35 [RFC7595] that needs the update. But hey, at least we > both agree that uri.arpa registrations don't currently require permanent > status. From nobody Wed Nov 11 08:35:49 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384423A0EB8 for ; Wed, 11 Nov 2020 08:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 dWRr0AoDk52T for ; Wed, 11 Nov 2020 08:35:47 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F003A0E87 for ; Wed, 11 Nov 2020 08:35:46 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MYe2J-1kqzpb3pqd-00Vh5P; Wed, 11 Nov 2020 17:35:44 +0100 Date: Wed, 11 Nov 2020 11:35:44 -0500 (EST) From: Timothy Mcsweeney To: DISPATCH WG , superuser@gmail.com, barryleiba@computer.org Message-ID: <1028723252.11911.1605112544538@email.ionos.com> In-Reply-To: <1007260719.140376.1593854488478@email.ionos.com> References: <1007260719.140376.1593854488478@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:nJuKZVBhN7Y+sTWU8MQp+2/xsspPWv6tbZjW0zUgh6IkzeYEDKa s80h3qPc6vuyDdaTvzK3jmVaQkSTqkLO6SWcwL53nxwDjP1uqB6pma9gIlUWG44rqAWEyjj 8utIYG0QO5HmxbIxfBuNWQG+RJj+18ed/+L46xcrcksNJ3Zi77VUy+eWxHAgz0Vcox9NBQN 745UkguZwZGY5pIIdyaPw== X-UI-Out-Filterresults: notjunk:1;V03:K0:/u9f2vB8YSw=:TDPjA8Okf2c+9MZ4X4rUUq Rs+bA2slImEe7R2dJp/SwnUJxkx03qGpf9l4+8ZCZQ/nI+TgLAQNDbN9Js6Jo02d++0+kC8S4 NMyjUYMvpJhQ7AAeTpGeTlEZi946VD0DQmZc5pFHA+U4gVzx2qzW+3pejsw7Vgl1i5+nB36du aVjSylQile9jBA4ARBhTIVGTp7zXxvsLVWP3p9ljh9ynh90zE98ls2yFXHdL4n3kDVtKW79L2 l86Ea2Zhq/8AjgnQ8yuXRn0IWuC6rPl4PuZyZZRsEAgWu4RjZuAiI1djE3e3b94lbGOH9K9ij oaNIXaMnaeYGT9dbepZttdPUzYVZf6pI5zFi68MHu/rvvbuWi+JYSgsLcotha4TQcLydchJHy 1VqdNQCFFyWonmuUx4vyC8zP0QsODYrlnMAXjueuscacL3jub5NksuifkQq0m1v6yF0ZU1wOt Of9ZlMr48w== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:35:48 -0000 text version: Ted, In your opening email to the 400 highly respectable people on this list you= say: =E2=80=9CAs it happens, there are very few registrations in URI.ARPA, so we= did not catch it and fix it before now.=E2=80=9D How did you "catch it"? Was there a pending registration? Is there still a pending registration? It would really be bad to try to change the rules while=C2=A0something was = pending. I can't speak for the others but some of them might want to know why after = almost 20 years of there being zero problems with RFC3405 it suddenly needs= to get "fixed". > On 07/04/2020 5:21 AM Timothy Mcsweeney wrote: >=20 >=20 > Ted, > In your opening email to the 400 highly respectable people on this list y= ou say: > "As it happens, there are very few registrations in URI.ARPA, so we did n= ot catch it and fix it before now." >=20 > How did you "catch it"? > Was there a pending registration? > Is there still a pending registration? > It would really be bad to try to change the rules while=C2=A0something wa= s pending. >=20 > I can't speak for the others but some of them might want to know why afte= r almost 20 years of there being zero problems with RFC3405 it suddenly nee= ds to get "fixed". From nobody Wed Nov 11 08:37:17 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20F1A3A08AE for ; Wed, 11 Nov 2020 08:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 zpGJFIpK8KjF for ; Wed, 11 Nov 2020 08:37:13 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1F53A0855 for ; Wed, 11 Nov 2020 08:37:13 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lhxsi-1jzzeU0FUo-00n7A1; Wed, 11 Nov 2020 17:37:12 +0100 Date: Wed, 11 Nov 2020 11:37:11 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG Message-ID: <64765374.11952.1605112631721@email.ionos.com> In-Reply-To: <22863747.195824.1594059994823@email.ionos.com> References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:KpOO9uyr16Zz20Tr2gK5OOB6HIZXaC78Zhel6m+oMbIvp4sjx9M pBXDyzy6IsJNh+bvrAtJke6zArMtWThsk41uAh8rGLNLRk4wU150Ev8ad/eU3XD4DiPpPnV tWsXPMrzZOXoHMxt80dOO0zi5C8d7MZLOA+iCAcg+puRKoQeOKFJi7vFjsQ1kwlh90wPztz FT2dhiYYuxPqAfTkjeltQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:JYkLMVNLKwo=:floYVlSMQU4UzMXU/seTS+ /cj74dDgWvboK77Drj0alWsXqvD53QtKcrbFekVYj3uLAgJCwz7uDYF25UmKJICAq/phAVuSe 7r/ZVQHUA+Z89H7tVUfdN3FRVhXkH+GLxU3Aj3ytypxCrid/Rk1TZNzhnP4P4MVa0EW7pYVPt evQsVglXqWDCwVRuc0x3Fjzh1KRK+6WUCprucbTonEorV4isMGxxFky6xQupttom+heBo343B rF3jaQ1fTQFM2rvzXMsHmp0Pym+wN880/6WKKHaING22Z5z8j36gM22T2nSowmkiVoOsBJHRa L/Vzr6mZ9NrUWl2DZVJY5UfcQeXKFrNaAPDP4uS2dGSB8teDaQgz6uymDKXmjTKGsx9hL1nrV iDfJ8h/MWw78/jtKmHJ9j1iq/f+uF/LF2sg9XXXTOOisVYhzBjXN3EVbXYDPfkiMbxqu7XAav SAbH/Pa3vw== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:37:15 -0000 text version: Ted, > >Yes, this came up because of a proposed registration. Since it was yours, >perhaps you would like to provide the link to the group? There is already a mailing list for that. >Once DISPATCH decides where this ought to be discussed, we can discuss tha= t >outcome or the update to BCP 35 to restore the category as alternatives. There should not be a discussion at all.=C2=A0 1. Section 5 of RFC3405 isn't broken. Maybe you were confusing it with Section 5 or RFC4395?=C2=A0 2. Regardless, any discussions should really wait until after upcoming registrations or appeals of those registrations, or appeals of those appeal= s are completed. >The current rules cannot work because they reference a category that no >longer exists. To put this differently, if they don't change, there can be >no more registrations in URI.arpa. The current rules are working just fine.=C2=A0 HTTP, among others, are still in the uri.arpa zone proving that the RFC3405 Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the cur= rent spec and can be=C2=A0seen in totality in IANA's list of URIs. > On 07/06/2020 2:26 PM Timothy Mcsweeney wrote: >=20 >=20 > Ted, > >=20 > >Yes, this came up because of a proposed registration. Since it was yours= ,=20 > >perhaps you would like to provide the link to the group? >=20 > There is already a mailing list for that. >=20 >=20 > >Once DISPATCH decides where this ought to be discussed, we can discuss t= hat=20 > >outcome or the update to BCP 35 to restore the category as alternatives. >=20 >=20 > There should not be a discussion at all.=20 > 1. Section 5 of RFC3405 isn't broken. Maybe you were confusing it with=20 > Section 5 or RFC4395?=20 > 2. Regardless, any discussions should really wait until after upcoming=20 > registrations or appeals of those registrations, or appeals of those appe= als are=20 > completed. >=20 >=20 > >The current rules cannot work because they reference a category that no= =20 > >longer exists. To put this differently, if they don't change, there can = be=20 > >no more registrations in URI.arpa. >=20 >=20 > The current rules are working just fine.=20 > HTTP, among others, are still in the uri.arpa zone proving that the RFC34= 05=20 > Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the c= urrent=20 > spec and can be=C2=A0seen in totality in IANA's list of URIs.=20 >=20 >=20 >=20 >=20 > > On July 6, 2020 at 12:15 PM Ted Hardie wrote:=20 > >=20 > >=20 > > Howdy,=20 > >=20 > >=20 > > On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumber.com> = wrote:=20 > > > Ted, > > > In your opening email to the 400 highly respectable people on this li= st you say: > > > "As it happens, there are very few registrations in URI.ARPA, so we d= id not catch it and fix it before now." > > >=20 > > > How did you "catch it"? > > > Was there a pending registration? > > > Is there still a pending registration? > >=20 > > Yes, this came up because of a proposed registration. Since it was your= s, perhaps you would like to provide the link to the group? > >=20 > > > It would really be bad to try to change the rules while=C2=A0somethin= g was pending. > > >=20 > >=20 > > The current rules cannot work because they reference a category that no= longer exists. To put this differently, if they don't change, there can be= no more registrations in URI.arpa.=20 > >=20 > > Once DISPATCH decides where this ought to be discussed, we can discuss = that outcome or the update to BCP 35 to restore the category as alternative= s. > >=20 > > regards, > >=20 > > Ted Hardie=20 > >=20 > >=20 > > >=20 > > > I can't speak for the others but some of them might want to know why = after almost 20 years of there being zero problems with RFC3405 it suddenly= needs to get "fixed". > > > _______________________________________________=20 > > > dispatch mailing list=20 > > > dispatch@ietf.org=20 > > > https://www.ietf.org/mailman/listinfo/dispatch=20 >=20 > From nobody Wed Nov 11 08:41:36 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23AC3A0FCF for ; Wed, 11 Nov 2020 08:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 CBKrEZPNZS6r for ; Wed, 11 Nov 2020 08:41:33 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DF83A0EEE for ; Wed, 11 Nov 2020 08:41:32 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MTjBW-1kln9X1RWy-00QQcG; Wed, 11 Nov 2020 17:41:31 +0100 Date: Wed, 11 Nov 2020 11:41:30 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG Message-ID: <91676562.12115.1605112890984@email.ionos.com> In-Reply-To: <22863747.195824.1594059994823@email.ionos.com> References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:rqrdGKJWvXT8WTRHK9KB072OSaV4w0QdXtcChoJwUHoPRbtcmf8 PZZMKUHBcSCk29bU88vBEH3wbzCWvm47/V6MZG/GMuoeYqkw1BcUVmmpRa6e54YtURf/OFI sn+P/0VkqIQjx+KyXidbmu9nnMnCtCGCk9OlIrnCfglSaPUmQUXMV8KJ6ldMFxBgYyxf1QK hgKYEP0fpT1Y+9dnxZRLw== X-UI-Out-Filterresults: notjunk:1;V03:K0:zdnUlFnXiX8=:friXfqT013U04oQ+b8mwKB rVToLvBY+g02dKEI3mJqSLmU0SA8QZVIR92Ej1YMua7sCF5U8KZEsrkMyhZcpn93ws5MnxihD f0mABCU5X7wVlId1SrKcEvGy4xcW3WhNvVvGn1fIOSyti+LdIPHZoR1EUoFSRXkyhS6XAqrn8 u4YUj0QUK5x+88Q6tWIzfaEkE8+QAh0ebkmCwTVqVpvh4Qp+jcGKCRk4jw0nQ54l5hBI4UiGs oSqH/9/6fABUdyo5cU9FK4N+FdyBwnsrgfLwyjB1+9iM1A4gqIRKiWAirlOA3mCg2+OUD1f/n KKxsj4ZnLCzB+c+1sksx70pVyae5+6YzIrt3qy5eVS8XjM2DHrAbchbokZajuNyosKRJp/gmG zHOeWup20Q9TKeyUo+Cs6ASLfj2sGFCHtqG2C76qMwKrLLQwaIICvfZZviwqLfalQJnnd0Umu 6QYQBd0o0Q== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:41:35 -0000 text version: Ted,=20 > >Yes, this came up because of a proposed registration. Since it was yours, >perhaps you would like to provide the link to the group? There is already a mailing list for that. >Once DISPATCH decides where this ought to be discussed, we can discuss tha= t >outcome or the update to BCP 35 to restore the category as alternatives. There should not be a discussion at all.=20 1. Section 5 of RFC3405 isn't broken. Maybe you were confusing it with Section 5 or RFC4395?=20 2. Regardless, any discussions should really wait until after upcoming registrations or appeals of those registrations, or appeals of those appeal= s are completed. >The current rules cannot work because they reference a category that no >longer exists. To put this differently, if they don't change, there can be >no more registrations in URI.arpa. The current rules are working just fine.=20 HTTP, among others, are still in the uri.arpa zone proving that the RFC3405 Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the cur= rent spec and can be seen in totality in IANA's list of URIs. > On 07/06/2020 2:26 PM Timothy Mcsweeney wrote: >=20 >=20 > Ted, > >=20 > >Yes, this came up because of a proposed registration. Since it was yours= ,=20 > >perhaps you would like to provide the link to the group? >=20 > There is already a mailing list for that. >=20 >=20 > >Once DISPATCH decides where this ought to be discussed, we can discuss t= hat=20 > >outcome or the update to BCP 35 to restore the category as alternatives. >=20 >=20 > There should not be a discussion at all.=20 > 1. Section 5 of RFC3405 isn't broken. Maybe you were confusing it with=20 > Section 5 or RFC4395?=20 > 2. Regardless, any discussions should really wait until after upcoming=20 > registrations or appeals of those registrations, or appeals of those appe= als are=20 > completed. >=20 >=20 > >The current rules cannot work because they reference a category that no= =20 > >longer exists. To put this differently, if they don't change, there can = be=20 > >no more registrations in URI.arpa. >=20 >=20 > The current rules are working just fine.=20 > HTTP, among others, are still in the uri.arpa zone proving that the RFC34= 05=20 > Section 3.1.1 reference [10] lives on through the obsoleted RFCs to the c= urrent=20 > spec and can be=C2=A0seen in totality in IANA's list of URIs.=20 >=20 >=20 >=20 >=20 > > On July 6, 2020 at 12:15 PM Ted Hardie wrote:=20 > >=20 > >=20 > > Howdy,=20 > >=20 > >=20 > > On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumber.com> = wrote:=20 > > > Ted, > > > In your opening email to the 400 highly respectable people on this li= st you say: > > > "As it happens, there are very few registrations in URI.ARPA, so we d= id not catch it and fix it before now." > > >=20 > > > How did you "catch it"? > > > Was there a pending registration? > > > Is there still a pending registration? > >=20 > > Yes, this came up because of a proposed registration. Since it was your= s, perhaps you would like to provide the link to the group? > >=20 > > > It would really be bad to try to change the rules while=C2=A0somethin= g was pending. > > >=20 > >=20 > > The current rules cannot work because they reference a category that no= longer exists. To put this differently, if they don't change, there can be= no more registrations in URI.arpa.=20 > >=20 > > Once DISPATCH decides where this ought to be discussed, we can discuss = that outcome or the update to BCP 35 to restore the category as alternative= s. > >=20 > > regards, > >=20 > > Ted Hardie=20 > >=20 > >=20 > > >=20 > > > I can't speak for the others but some of them might want to know why = after almost 20 years of there being zero problems with RFC3405 it suddenly= needs to get "fixed". > > > _______________________________________________=20 > > > dispatch mailing list=20 > > > dispatch@ietf.org=20 > > > https://www.ietf.org/mailman/listinfo/dispatch=20 >=20 > From nobody Wed Nov 11 08:42:19 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E593A0FF2 for ; Wed, 11 Nov 2020 08:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 c6nEUpXhguB8 for ; Wed, 11 Nov 2020 08:42:16 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6553A0FF0 for ; Wed, 11 Nov 2020 08:42:15 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1N1xEj-1kAogh14SP-012Izq; Wed, 11 Nov 2020 17:42:14 +0100 Date: Wed, 11 Nov 2020 11:42:13 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG Message-ID: <1141414332.12154.1605112933920@email.ionos.com> In-Reply-To: <1557624035.199224.1594062567206@email.ionos.com> References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> <1557624035.199224.1594062567206@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:v5abOm7WSvPJdiHu+GCENiz1pYprWgEH/zJO8pVhKTr2bUvY1jR zJYEexoS3ws+xAVNcGjdDi2AFtP7B1fSfAAcQS42hsgkGIgRxexvNASHI0FogGj6JpCh9BB StVBcraqhpmqXZzEUmLI14yTFs3eHJUIMFjxJk951AXn5iGLSYvoyKmXiK3SxvWKNAlbxQu 4AQcwBE7C6TBlFTIrct3Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:lhPSBbeChKM=:xf9xYzbYjKZHqSzYMipN7/ MqHanRiEkViAehnmSCY0N1lKCBPV0LsrXOnjqhDbSBd6JRJ0K5yNMjfoHFpZt7mA8qCZYSkGA XsHVu05QuEKahodG/09B2O85uuzRmmC4wWiQVk0FVrniPQlnzUY2gsVNRXn26T3IddINU9doc TcmEO52JSmThq5o69Na7nEiw2Pd0GREIfed/zdZgJUTojA1lmyrO7mYJ5tXKOyuE32sBJF0Vm LCvtd8Bky48xjIy9H9FIQHisYfySkircyxe4UX60h3s+XRCPEOYBgok4vhCc8Dx992YAkaQRD xUKCSsKXxQ7zVmJIrs0FIrsfg7ZIYlstNxIbB1+14OcSVh/0sRp+nielDw1axbtbiFx4QxNJl mU9hV7a1LissK1FzKpTKGDg6RlH+w8BxdX9X6lk+O9W7HOMpxsIHds1geLR9zx4/HF9+L7f7i FNna//CAGg== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:42:18 -0000 text version: Hi, >If I understand you correctly, you are arguing that because URI.arpa was n= ot >depopulated when the IETF tree was dropped, registrations can still be = made >according to the old rules as if there still were an IETF tree. I'm arguing that, as it sits right now, in order to insert a record into ur= i.arpa,=20 you have to have a scheme name registered. =20 > On 07/06/2020 3:09 PM Timothy Mcsweeney wrote: >=20 >=20 > Hi, > >If I understand you correctly, you are arguing that because URI.arpa was= not >depopulated when the IETF tree was dropped, registrations can still b= e made >according to the old rules as if there still were an IETF tree. >=20 >=20 > I'm arguing that, as it sits right now, in order to insert a record into = uri.arpa, > you have to have a scheme name registered. >=20 >=20 >=20 >=20 > > On July 6, 2020 at 2:51 PM Ted Hardie wrote:=20 > >=20 > >=20 > > Howdy,=20 > >=20 > >=20 > > On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < tim@dropnumber.com>= wrote:=20 > > > Ted, > > > >=20 > > > >Yes, this came up because of a proposed registration. Since it was y= ours,=20 > > > >perhaps you would like to provide the link to the group? > > >=20 > > > There is already a mailing list for that. > > >=20 > > >=20 > > > >Once DISPATCH decides where this ought to be discussed, we can discu= ss that=20 > > > >outcome or the update to BCP 35 to restore the category as alternati= ves. > > >=20 > > >=20 > > > There should not be a discussion at all.=20 > > > 1. Section 5 of RFC3405 isn't broken. Maybe you were confusing it wit= h=20 > > > Section 5 or RFC4395?=20 > >=20 > > As I note in the extremely short document: > >=20 > > The document requires that registrations be in the "IETF > > tree" of URI registrations. The use of URI scheme name trees was > > defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395]= . > > Since the use of trees was discontinued, there is no way in the > > current process set out in BCP 35 [RFC7595] to meet the requirement. > >=20 > > If we leave things as they are, no registrations can be made, because t= he category is gone. We can change it to require permanent registrations in= stead (as this document suggests) or you could propose something different = (e.g. updating BCP 35 to recreate the IETF tree for these registrations). > >=20 > > > 2. Regardless, any discussions should really wait until after upcomin= g=20 > > > registrations or appeals of those registrations, or appeals of those = appeals are=20 > > > completed. > > >=20 > > >=20 > > >=20 > > > >The current rules cannot work because they reference a category that= no=20 > > > >longer exists. To put this differently, if they don't change, there = can be=20 > > > >no more registrations in URI.arpa. > > >=20 > > >=20 > > > The current rules are working just fine.=20 > > > HTTP, among others, are still in the uri.arpa zone proving that the R= FC3405=20 > > > Section 3.1.1 reference [10] lives on through the obsoleted RFCs to t= he current=20 > > > spec and can be=C2=A0seen in totality in IANA's list of URIs.=20 > > >=20 > > >=20 > > If I understand you correctly, you are arguing that because URI.arpa wa= s not depopulated when the IETF tree was dropped, registrations can still b= e made according to the old rules as if there still were an IETF tree.=20 > >=20 > > That's not how the IETF process treats obsoleting BCPs; see the IESG st= atement at https://www.ietf.org/about/groups/iesg/statements/designating-rf= cs-historic-2014-07-20/. > >=20 > > This situation has pointed out that there was a bug introduced by RFC 4= 395 that was carried forward into RFC 7595, because they did not address th= e dependency on the removed IETF tree in BCP 65. This document is one way t= o address that bug. If you wish to suggest others, that's fine, but we stil= l need DISPATCH to identify where the discussion should happen.=20 > >=20 > > regards, > >=20 > > Ted=20 > >=20 > > >=20 > > >=20 > > >=20 > > > > On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.com> wrote:= =20 > > > >=20 > > > >=20 > > > > Howdy,=20 > > > >=20 > > > >=20 > > > > On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumber.c= om> wrote:=20 > > > > > Ted, > > > > > In your opening email to the 400 highly respectable people on thi= s list you say: > > > > > "As it happens, there are very few registrations in URI.ARPA, so = we did not catch it and fix it before now." > > > > >=20 > > > > > How did you "catch it"? > > > > > Was there a pending registration? > > > > > Is there still a pending registration? > > > >=20 > > > > Yes, this came up because of a proposed registration. Since it was = yours, perhaps you would like to provide the link to the group? > > > >=20 > > > > > It would really be bad to try to change the rules while=C2=A0some= thing was pending. > > > > >=20 > > > >=20 > > > > The current rules cannot work because they reference a category tha= t no longer exists. To put this differently, if they don't change, there ca= n be no more registrations in URI.arpa.=20 > > > >=20 > > > > Once DISPATCH decides where this ought to be discussed, we can disc= uss that outcome or the update to BCP 35 to restore the category as alterna= tives. > > > >=20 > > > > regards, > > > >=20 > > > > Ted Hardie=20 > > > >=20 > > > >=20 > > > > >=20 > > > > > I can't speak for the others but some of them might want to know = why after almost 20 years of there being zero problems with RFC3405 it sudd= enly needs to get "fixed". > > > > > _______________________________________________=20 > > > > > dispatch mailing list=20 > > > > > dispatch@ietf.org=20 > > > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > > >=20 > > >=20 >=20 > From nobody Wed Nov 11 08:42:58 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071C23A0FF0 for ; Wed, 11 Nov 2020 08:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 P3aAhl0hszQ7 for ; Wed, 11 Nov 2020 08:42:55 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFEC3A0FED for ; Wed, 11 Nov 2020 08:42:55 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MRF0r-1kjKDJ011j-00UXvJ; Wed, 11 Nov 2020 17:42:54 +0100 Date: Wed, 11 Nov 2020 11:42:53 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG Message-ID: <646957862.12190.1605112973676@email.ionos.com> In-Reply-To: <1990424976.229638.1594067242698@email.ionos.com> References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> <1557624035.199224.1594062567206@email.ionos.com> <1990424976.229638.1594067242698@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:e/+M4vkTSVFuh26hvetUAC15yKhHMTDfMHlEVpr7kQO9W0oCbgo rk+agLEnOWw3msSPMd1cpIFuQ+lmkxbubXYCVa+H8A0tviBDhvpxMaZ6hAcomabHubol0Sg XaBVzM9bnookKebmulak1+h7TOUu1/qaKZHf7oHJSuULsdzcStN1xgR5wMb24Wa5Vlnnlh0 ZlGPyU8FwFdWcXMXdBaAg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Bwy6sjUON/8=:T8ekMOFF+XHXnrDlummEds qLSNZKfg4NUn7QYbXVfuGNJWXd0G0myyd44DSsSrDbXbMI6m1nxyIY7iYKsshUxcLgZFeVjLG KnhUyBZ/xbAgSXbkq/u0Ukh3wO+N90EiJmNkkt6TJBsfnNlsU7ZD/Cy2jojILLSoPH4ZCa+tI WhIaXs4Yo0pZnLkviJkzEaTnjTMD/nlBpUKfh9DJFjj9q6gUS/GXSwnE9ymByPwuSm+DB5/CS E2e+ss899b0Wh9MjecQ2kLv9vlOZ+KHb9QVZl8iIPisl3K+k47Naudgk2yzuNMEU/2HGrwjkr 4CLo5qVR1fRZq2fGQxFdmr5S32OsfJYrlP/yRcGL7m6mPkKVm7X2VZwqkIWI/83giXMXMj4G5 lnJxhisCLmwulPrdGP+1Sf/qKR4KjlwobSGapQCj4G+XNcQ4UXMS+yI6NCoJeUOa4Hld8w6Q/ sZn1eoTYzw== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:42:57 -0000 text version: Ted, Do you not want my scheme in the arpa zone? > On 07/06/2020 4:27 PM Timothy Mcsweeney wrote: >=20 >=20 > Ted, > Do you not want my scheme in the arpa zone? >=20 >=20 > > On July 6, 2020 at 4:19 PM Ted Hardie wrote:=20 > >=20 > >=20 > > On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < tim@dropnumber.com>= wrote:=20 > > > Hi, > > > >If I understand you correctly, you are arguing that because URI.arpa= was not >depopulated when the IETF tree was dropped, registrations can sti= ll be made >according to the old rules as if there still were an IETF tree. > > >=20 > > >=20 > > > I'm arguing that, as it sits right now, in order to insert a record i= nto uri.arpa, > > > you have to have a scheme name registered. > > >=20 > >=20 > > RFC 3405 is pretty restrictive in its language: > >=20 > > > 3.1 URI.ARPA Registration > > >=20 > > > 3.1.1 Only Schemes in the IETF Tree Allowed > > >=20 > > > In order to be inserted into the URI.ARPA zone, the subsequent URI > > > scheme MUST be registered under the IETF URI tree. The requiremen= ts > > > for this tree are specified in [10]. > > >=20 > > Given the "Only" and the RFC 2119 "MUST", I don't think a plain reading= of the text supports the view that any URI registration is sufficient. Sec= tion 3.1.2 also reinforces that the registration must be prior and then the= record insertion must pass IESG review; that section does not given the IE= SG the right to waive the requirements: > >=20 > > 3.1.2 Scheme Registration Takes Precedence > >=20 > > The registration of a NAPTR record for a URI scheme MUST NOT precede > > proper registration of that scheme and publication of a stable > > specification in accordance with [10]. The IESG or its designated > > expert will review the request for > >=20 > > 1. correctness and technical soundness > >=20 > > 2. consistency with the published URI specification, and > >=20 > > 3. to ensure that the NAPTR record for a DNS-based URI does not > > delegate resolution of the URI to a party other than the > > holder of the DNS name. This last rule is to insure that a > > given URI's resolution hint doesn't hijack (inadvertently or > > otherwise) network traffic for a given domain. > >=20 > > regards, > >=20 > > Ted Hardie=20 > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > On July 6, 2020 at 2:51 PM Ted Hardie < ted.ietf@gmail.com> wrote:= =20 > > > >=20 > > > >=20 > > > > Howdy,=20 > > > >=20 > > > >=20 > > > > On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < tim@dropnumber.= com> wrote:=20 > > > > > Ted, > > > > > >=20 > > > > > >Yes, this came up because of a proposed registration. Since it w= as yours,=20 > > > > > >perhaps you would like to provide the link to the group? > > > > >=20 > > > > > There is already a mailing list for that. > > > > >=20 > > > > >=20 > > > > > >Once DISPATCH decides where this ought to be discussed, we can d= iscuss that=20 > > > > > >outcome or the update to BCP 35 to restore the category as alter= natives. > > > > >=20 > > > > >=20 > > > > > There should not be a discussion at all.=20 > > > > > 1. Section 5 of RFC3405 isn't broken. Maybe you were confusing it= with=20 > > > > > Section 5 or RFC4395?=20 > > > >=20 > > > > As I note in the extremely short document: > > > >=20 > > > > The document requires that registrations be in the "IETF > > > > tree" of URI registrations. The use of URI scheme name trees wa= s > > > > defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4= 395]. > > > > Since the use of trees was discontinued, there is no way in the > > > > current process set out in BCP 35 [RFC7595] to meet the requirem= ent. > > > >=20 > > > > If we leave things as they are, no registrations can be made, becau= se the category is gone. We can change it to require permanent registration= s instead (as this document suggests) or you could propose something differ= ent (e.g. updating BCP 35 to recreate the IETF tree for these registrations= ). > > > >=20 > > > > > 2. Regardless, any discussions should really wait until after upc= oming=20 > > > > > registrations or appeals of those registrations, or appeals of th= ose appeals are=20 > > > > > completed. > > > > >=20 > > > > >=20 > > > > >=20 > > > > > >The current rules cannot work because they reference a category = that no=20 > > > > > >longer exists. To put this differently, if they don't change, th= ere can be=20 > > > > > >no more registrations in URI.arpa. > > > > >=20 > > > > >=20 > > > > > The current rules are working just fine.=20 > > > > > HTTP, among others, are still in the uri.arpa zone proving that t= he RFC3405=20 > > > > > Section 3.1.1 reference [10] lives on through the obsoleted RFCs = to the current=20 > > > > > spec and can be=C2=A0seen in totality in IANA's list of URIs.=20 > > > > >=20 > > > > >=20 > > > > If I understand you correctly, you are arguing that because URI.arp= a was not depopulated when the IETF tree was dropped, registrations can sti= ll be made according to the old rules as if there still were an IETF tree.= =20 > > > >=20 > > > > That's not how the IETF process treats obsoleting BCPs; see the IES= G statement at https://www.ietf.org/about/groups/iesg/statements/designatin= g-rfcs-historic-2014-07-20/. > > > >=20 > > > > This situation has pointed out that there was a bug introduced by R= FC 4395 that was carried forward into RFC 7595, because they did not addres= s the dependency on the removed IETF tree in BCP 65. This document is one w= ay to address that bug. If you wish to suggest others, that's fine, but we = still need DISPATCH to identify where the discussion should happen.=20 > > > >=20 > > > > regards, > > > >=20 > > > > Ted=20 > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.com> wr= ote:=20 > > > > > >=20 > > > > > >=20 > > > > > > Howdy,=20 > > > > > >=20 > > > > > >=20 > > > > > > On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dropnumb= er.com> wrote:=20 > > > > > > > Ted, > > > > > > > In your opening email to the 400 highly respectable people on= this list you say: > > > > > > > "As it happens, there are very few registrations in URI.ARPA,= so we did not catch it and fix it before now." > > > > > > >=20 > > > > > > > How did you "catch it"? > > > > > > > Was there a pending registration? > > > > > > > Is there still a pending registration? > > > > > >=20 > > > > > > Yes, this came up because of a proposed registration. Since it = was yours, perhaps you would like to provide the link to the group? > > > > > >=20 > > > > > > > It would really be bad to try to change the rules while=C2=A0= something was pending. > > > > > > >=20 > > > > > >=20 > > > > > > The current rules cannot work because they reference a category= that no longer exists. To put this differently, if they don't change, ther= e can be no more registrations in URI.arpa.=20 > > > > > >=20 > > > > > > Once DISPATCH decides where this ought to be discussed, we can = discuss that outcome or the update to BCP 35 to restore the category as alt= ernatives. > > > > > >=20 > > > > > > regards, > > > > > >=20 > > > > > > Ted Hardie=20 > > > > > >=20 > > > > > >=20 > > > > > > >=20 > > > > > > > I can't speak for the others but some of them might want to k= now why after almost 20 years of there being zero problems with RFC3405 it = suddenly needs to get "fixed". > > > > > > > _______________________________________________=20 > > > > > > > dispatch mailing list=20 > > > > > > > dispatch@ietf.org=20 > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > > > > >=20 > > > > >=20 > > >=20 > > >=20 >=20 > From nobody Wed Nov 11 08:44:19 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECB63A0FED for ; Wed, 11 Nov 2020 08:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ryRWyzUc2EOY for ; Wed, 11 Nov 2020 08:44:15 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7B03A0E37 for ; Wed, 11 Nov 2020 08:44:08 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MbODK-1ktS8g2gya-00Ip6I; Wed, 11 Nov 2020 17:44:06 +0100 Date: Wed, 11 Nov 2020 11:44:06 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG Message-ID: <857122167.12250.1605113046276@email.ionos.com> In-Reply-To: <1229438794.80445.1594084111594@email.ionos.com> References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> <1557624035.199224.1594062567206@email.ionos.com> <1990424976.229638.1594067242698@email.ionos.com> <1229438794.80445.1594084111594@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:a3Ee6myvLr/jFNU8sLNT4sP1abK5uQOgm61VVe7VF72Abfynvzn jcUHnoC07GxyC1MFPp0WRxnRYyUEJpLDFBG6s2AyVsoKyfYHpfFgGSNNiFKihPk9vIbtwIM CrkPa9yE1FFZf23YJwQNb80bEfHQLjPx7BCOzKLGgnto7W13Blr/ckbGWzPNLS5dVM8LRvm ZAOrTlAWl2jELce46abGQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:S360Ick1NoY=:EQ1uQxY6bbBhNKjTsylSo7 9gykHoEqAdL5cnIdvNuFJjDcfo1UD1hASypQb+y6I+BIZKHsjNyMu+SXxs7+JGAam4LtGZmMP YsBYcaVsBlOSvTmptpdYGKPhNPtOM2bRpc9FUb2DmcdEderGMa57L/ZRVVS5JENXanSUd/el3 ENn8s7LHHmAHFNumvOzg49NN4a0IQ4H+OV6RCfdVpYgxctbF06TMo2TnxQf6JZN2kCMUzR1jp KU6DklLMHstMahZkzmJze1tF+k/i6YXQO9bqcK6PoCzp8NNaU2QsT6Sdzl3jRQ+2bxNhlh58h rvGipqlKljWnvto89oQQec1/htffbUk1VGGbEZjx4v7rnqOYyfsAnSxHKCwJgMWB5BVurmWZ0 mVm/IT3e6tOtT+gVAes0peREHrq6gSYwOZhb4eV/dT9gj4pfkUFXmL6CX2qbfV39NzYQTYQBv da8eoRw3eg== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:44:17 -0000 text version: I'll take that as a yes. > On 07/06/2020 9:08 PM Timothy Mcsweeney wrote: >=20 >=20 > I'll take that as a yes. >=20 >=20 >=20 > > On July 6, 2020 at 6:13 PM Ted Hardie wrote:=20 > >=20 > >=20 > > Howdy,=20 > >=20 > >=20 > > On Mon, Jul 6, 2020 at 1:27 PM Timothy Mcsweeney < tim@dropnumber.com> = wrote:=20 > > > Ted, > > > Do you not want my scheme in the arpa zone? > > >=20 > >=20 > > I'm just trying to avoid a silly state, where we say do X but don't let= anyone do X. If this is published, then we'll have a clear rule that match= es the current system. But if the consensus turns out to be that the IETF t= ree should return for the sole purpose of registering schemes going into .a= rpa, I would go along with that as well.=20 > >=20 > > I don't support allowing provisionals in the zone because they are firs= t-come-first-served as of RFC 7595 and some of the registrations are very v= endor specific (for example, many of the ms- uri schemes in the provisional= category at https://www.iana.org/assignments/uri-schemes/uri-schemes.xml a= re Microsoft-only). That's not in-line with the purpose of .arpa as an infr= astructure domain.=20 > >=20 > > If you disagree, please write up your proposal. I trust DISPATCH will e= nsure that it gets discussed in the same place as this proposal.=20 > >=20 > > regards, > >=20 > > Ted=20 > >=20 > >=20 > > >=20 > > >=20 > > > > On July 6, 2020 at 4:19 PM Ted Hardie < ted.ietf@gmail.com> wrote:= =20 > > > >=20 > > > >=20 > > > > On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < tim@dropnumber.= com> wrote:=20 > > > > > Hi, > > > > > >If I understand you correctly, you are arguing that because URI.= arpa was not >depopulated when the IETF tree was dropped, registrations can= still be made >according to the old rules as if there still were an IETF t= ree. > > > > >=20 > > > > >=20 > > > > > I'm arguing that, as it sits right now, in order to insert a reco= rd into uri.arpa, > > > > > you have to have a scheme name registered. > > > > >=20 > > > >=20 > > > > RFC 3405 is pretty restrictive in its language: > > > >=20 > > > > > 3.1 URI.ARPA Registration > > > > >=20 > > > > > 3.1.1 Only Schemes in the IETF Tree Allowed > > > > >=20 > > > > > In order to be inserted into the URI.ARPA zone, the subsequent= URI > > > > > scheme MUST be registered under the IETF URI tree. The requir= ements > > > > > for this tree are specified in [10]. > > > > >=20 > > > > Given the "Only" and the RFC 2119 "MUST", I don't think a plain rea= ding of the text supports the view that any URI registration is sufficient.= Section 3.1.2 also reinforces that the registration must be prior and then= the record insertion must pass IESG review; that section does not given th= e IESG the right to waive the requirements: > > > >=20 > > > > 3.1.2 Scheme Registration Takes Precedence > > > >=20 > > > > The registration of a NAPTR record for a URI scheme MUST NOT pre= cede > > > > proper registration of that scheme and publication of a stable > > > > specification in accordance with [10]. The IESG or its designat= ed > > > > expert will review the request for > > > >=20 > > > > 1. correctness and technical soundness > > > >=20 > > > > 2. consistency with the published URI specification, and > > > >=20 > > > > 3. to ensure that the NAPTR record for a DNS-based URI does = not > > > > delegate resolution of the URI to a party other than the > > > > holder of the DNS name. This last rule is to insure that= a > > > > given URI's resolution hint doesn't hijack (inadvertently= or > > > > otherwise) network traffic for a given domain. > > > >=20 > > > > regards, > > > >=20 > > > > Ted Hardie=20 > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > On July 6, 2020 at 2:51 PM Ted Hardie < ted.ietf@gmail.com> wro= te:=20 > > > > > >=20 > > > > > >=20 > > > > > > Howdy,=20 > > > > > >=20 > > > > > >=20 > > > > > > On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < tim@dropnum= ber.com> wrote:=20 > > > > > > > Ted, > > > > > > > >=20 > > > > > > > >Yes, this came up because of a proposed registration. Since = it was yours,=20 > > > > > > > >perhaps you would like to provide the link to the group? > > > > > > >=20 > > > > > > > There is already a mailing list for that. > > > > > > >=20 > > > > > > >=20 > > > > > > > >Once DISPATCH decides where this ought to be discussed, we c= an discuss that=20 > > > > > > > >outcome or the update to BCP 35 to restore the category as a= lternatives. > > > > > > >=20 > > > > > > >=20 > > > > > > > There should not be a discussion at all.=20 > > > > > > > 1. Section 5 of RFC3405 isn't broken. Maybe you were confusin= g it with=20 > > > > > > > Section 5 or RFC4395?=20 > > > > > >=20 > > > > > > As I note in the extremely short document: > > > > > >=20 > > > > > > The document requires that registrations be in the "IETF > > > > > > tree" of URI registrations. The use of URI scheme name tree= s was > > > > > > defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [= RFC4395]. > > > > > > Since the use of trees was discontinued, there is no way in = the > > > > > > current process set out in BCP 35 [RFC7595] to meet the requ= irement. > > > > > >=20 > > > > > > If we leave things as they are, no registrations can be made, b= ecause the category is gone. We can change it to require permanent registra= tions instead (as this document suggests) or you could propose something di= fferent (e.g. updating BCP 35 to recreate the IETF tree for these registrat= ions). > > > > > >=20 > > > > > > > 2. Regardless, any discussions should really wait until after= upcoming=20 > > > > > > > registrations or appeals of those registrations, or appeals o= f those appeals are=20 > > > > > > > completed. > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > >The current rules cannot work because they reference a categ= ory that no=20 > > > > > > > >longer exists. To put this differently, if they don't change= , there can be=20 > > > > > > > >no more registrations in URI.arpa. > > > > > > >=20 > > > > > > >=20 > > > > > > > The current rules are working just fine.=20 > > > > > > > HTTP, among others, are still in the uri.arpa zone proving th= at the RFC3405=20 > > > > > > > Section 3.1.1 reference [10] lives on through the obsoleted R= FCs to the current=20 > > > > > > > spec and can be=C2=A0seen in totality in IANA's list of URIs.= =20 > > > > > > >=20 > > > > > > >=20 > > > > > > If I understand you correctly, you are arguing that because URI= .arpa was not depopulated when the IETF tree was dropped, registrations can= still be made according to the old rules as if there still were an IETF tr= ee.=20 > > > > > >=20 > > > > > > That's not how the IETF process treats obsoleting BCPs; see the= IESG statement at https://www.ietf.org/about/groups/iesg/statements/design= ating-rfcs-historic-2014-07-20/. > > > > > >=20 > > > > > > This situation has pointed out that there was a bug introduced = by RFC 4395 that was carried forward into RFC 7595, because they did not ad= dress the dependency on the removed IETF tree in BCP 65. This document is o= ne way to address that bug. If you wish to suggest others, that's fine, but= we still need DISPATCH to identify where the discussion should happen.=20 > > > > > >=20 > > > > > > regards, > > > > > >=20 > > > > > > Ted=20 > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > > On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.com= > wrote:=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Howdy,=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@drop= number.com> wrote:=20 > > > > > > > > > Ted, > > > > > > > > > In your opening email to the 400 highly respectable peopl= e on this list you say: > > > > > > > > > "As it happens, there are very few registrations in URI.A= RPA, so we did not catch it and fix it before now." > > > > > > > > >=20 > > > > > > > > > How did you "catch it"? > > > > > > > > > Was there a pending registration? > > > > > > > > > Is there still a pending registration? > > > > > > > >=20 > > > > > > > > Yes, this came up because of a proposed registration. Since= it was yours, perhaps you would like to provide the link to the group? > > > > > > > >=20 > > > > > > > > > It would really be bad to try to change the rules while= =C2=A0something was pending. > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > The current rules cannot work because they reference a cate= gory that no longer exists. To put this differently, if they don't change, = there can be no more registrations in URI.arpa.=20 > > > > > > > >=20 > > > > > > > > Once DISPATCH decides where this ought to be discussed, we = can discuss that outcome or the update to BCP 35 to restore the category as= alternatives. > > > > > > > >=20 > > > > > > > > regards, > > > > > > > >=20 > > > > > > > > Ted Hardie=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > I can't speak for the others but some of them might want = to know why after almost 20 years of there being zero problems with RFC3405= it suddenly needs to get "fixed". > > > > > > > > > _______________________________________________=20 > > > > > > > > > dispatch mailing list=20 > > > > > > > > > dispatch@ietf.org=20 > > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > > > > > > >=20 > > > > > > >=20 > > > > >=20 > > > > >=20 > > >=20 > > >=20 >=20 > From nobody Wed Nov 11 08:45:06 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31053A0FED for ; Wed, 11 Nov 2020 08:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 uSPRkwANTQU9 for ; Wed, 11 Nov 2020 08:45:01 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765723A0E37 for ; Wed, 11 Nov 2020 08:45:01 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MEXgF-1kWaer2PrF-00Fk5l for ; Wed, 11 Nov 2020 17:45:00 +0100 Date: Wed, 11 Nov 2020 11:45:00 -0500 (EST) From: Timothy Mcsweeney Cc: DISPATCH WG Message-ID: <1399538086.12284.1605113100291@email.ionos.com> In-Reply-To: <540630596.80446.1594084113227@email.ionos.com> References: <1007260719.140376.1593854488478@email.ionos.com> <22863747.195824.1594059994823@email.ionos.com> <1557624035.199224.1594062567206@email.ionos.com> <1990424976.229638.1594067242698@email.ionos.com> <23997780-BD02-4A2B-90FD-B21CEB6FFF38@nostrum.com> <540630596.80446.1594084113227@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:9VNGhbZMNo4Uy4e635ii3XhNNC+DM2fuiLZY8lBuuqvfBYSABPm 1lU7qBinDMzf8ilXxsFQDdp8JD8VDjTSSEyYekYwAwHtg08KKoNaGW/zsRvYWmqo4a14SRR ottsSMVp1I8NjeupkriDV+duHRyNIMF7gUa+P3b1LWSPdkCcv8xrquExMGkS/CGpVxZ0IpA ZcAYo114TaM8WAGfp3DkQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:Ktd1aCqjpwc=:ru2ny1fTOx01MV8ivoC2Ko GxkK856rtjjze2QlCjxEgSnBzDxxESmPh3jiBW1EDutsvef6U++DubhmXgPqf9HhDaJU510D0 P/+tAIA3BYniZWjCgYhzPiIBGeV6pqqg31s36W7pxBpXp5DmyvRzXdi2JRAl8L/gSG8/zik7+ SqFPZOd+kM6vz/HKTHMEKqP4Lp80xWEdIrkdXfRtS1GejvKWGmsdvZB9ahfEwsSa3oVpv6zRD Mp2sBR7AK1myQ0wYK2aPMMtWPcHuIlmLb/pAx3JIAiwECe+ZMFtLACj8MKtlhz7bzPAKAap0W kprNsxZZ29hCwzKrwZf2wpoNL1XioGzQX15Q/wIkD11R5U8E9TAQ2CPCW6ylOCI5Bjo1BUtyy 78ZGfkj67AfO6nJmsHz9NFbb4cx0r3H/e1ygZ11YmG0q++PcfdiIOHp/uLxJFFzMdiAUtU9zL IdS+5uPlYA== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:45:04 -0000 text version: Everyone, In case I do not get a chance to re-iterate my opinion, I think discussion = on this topic can wait for a while and the timing is suspect. Ted's name i= s on RFC4395 as well as RFC7595 giving him more than 15 years to bring this= up. Tim > On 07/06/2020 9:08 PM Timothy Mcsweeney wrote: >=20 >=20 > Everyone, >=20 > In case I do not get a chance to re-iterate my opinion, I think discussio= n on this topic can wait for a while and the timing is suspect. Ted's name = is on RFC4395 as well as RFC7595 giving him more than 15 years to bring thi= s up. >=20 > Tim >=20 >=20 >=20 > > On July 6, 2020 at 6:25 PM Ben Campbell wrote:=20 > >=20 > >=20 > > (As Co-Chair) > >=20 > > Hi All, > >=20 > > For the moment at least, please focus DISPATCH discussion on determinin= g what the proper venue for discussion is. > >=20 > > Our choices are: > > 1) Recommend AD Sponsored > > 2) Adopt in DISPATCH as an =E2=80=9Cadministrative document=E2=80=9D as= allowed by our charter > > 3) =E2=80=9CDispatch=E2=80=9D to an existing WG, or recommend one be fo= rmed. > > 4) Recommend a BoF. > >=20 > > Thanks! > >=20 > > Ben. > >=20 > >=20 > > > On Jul 6, 2020, at 5:13 PM, Ted Hardie < ted.ietf@gmail.com> wrote: > > >=20 > > >=20 > > > Howdy,=20 > > >=20 > > >=20 > > > On Mon, Jul 6, 2020 at 1:27 PM Timothy Mcsweeney < tim@dropnumber.com= > wrote:=20 > > > > Ted, > > > > Do you not want my scheme in the arpa zone? > > > >=20 > > >=20 > > > I'm just trying to avoid a silly state, where we say do X but don't l= et anyone do X. If this is published, then we'll have a clear rule that mat= ches the current system. But if the consensus turns out to be that the IETF= tree should return for the sole purpose of registering schemes going into = .arpa, I would go along with that as well.=20 > > >=20 > > > I don't support allowing provisionals in the zone because they are fi= rst-come-first-served as of RFC 7595 and some of the registrations are very= vendor specific (for example, many of the ms- uri schemes in the provision= al category at https://www.iana.org/assignments/uri-schemes/uri-schemes.xml= are Microsoft-only). That's not in-line with the purpose of .arpa as an in= frastructure domain.=20 > > >=20 > > > If you disagree, please write up your proposal. I trust DISPATCH will= ensure that it gets discussed in the same place as this proposal.=20 > > >=20 > > > regards, > > >=20 > > > Ted=20 > > >=20 > > >=20 > > > >=20 > > > >=20 > > > > > On July 6, 2020 at 4:19 PM Ted Hardie < ted.ietf@gmail.com> wrote= :=20 > > > > >=20 > > > > >=20 > > > > > On Mon, Jul 6, 2020 at 12:09 PM Timothy Mcsweeney < tim@dropnumbe= r..com> wrote:=20 > > > > > > Hi, > > > > > > >If I understand you correctly, you are arguing that because UR= I..arpa was not >depopulated when the IETF tree was dropped, registrations = can still be made >according to the old rules as if there still were an IET= F tree. > > > > > >=20 > > > > > >=20 > > > > > > I'm arguing that, as it sits right now, in order to insert a re= cord into uri.arpa, > > > > > > you have to have a scheme name registered. > > > > > >=20 > > > > >=20 > > > > > RFC 3405 is pretty restrictive in its language: > > > > >=20 > > > > > > 3.1 URI.ARPA Registration > > > > > >=20 > > > > > > 3.1.1 Only Schemes in the IETF Tree Allowed > > > > > >=20 > > > > > > In order to be inserted into the URI.ARPA zone, the subseque= nt URI > > > > > > scheme MUST be registered under the IETF URI tree. The requ= irements > > > > > > for this tree are specified in [10]. > > > > > >=20 > > > > > Given the "Only" and the RFC 2119 "MUST", I don't think a plain r= eading of the text supports the view that any URI registration is sufficien= t. Section 3.1.2 also reinforces that the registration must be prior and th= en the record insertion must pass IESG review; that section does not given = the IESG the right to waive the requirements: > > > > >=20 > > > > > 3.1.2 Scheme Registration Takes Precedence > > > > >=20 > > > > > The registration of a NAPTR record for a URI scheme MUST NOT p= recede > > > > > proper registration of that scheme and publication of a stable > > > > > specification in accordance with [10]. The IESG or its design= ated > > > > > expert will review the request for > > > > >=20 > > > > > 1. correctness and technical soundness > > > > >=20 > > > > > 2. consistency with the published URI specification, and > > > > >=20 > > > > > 3. to ensure that the NAPTR record for a DNS-based URI doe= s not > > > > > delegate resolution of the URI to a party other than th= e > > > > > holder of the DNS name. This last rule is to insure th= at a > > > > > given URI's resolution hint doesn't hijack (inadvertent= ly or > > > > > otherwise) network traffic for a given domain. > > > > >=20 > > > > > regards, > > > > >=20 > > > > > Ted Hardie=20 > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > > On July 6, 2020 at 2:51 PM Ted Hardie < ted.ietf@gmail.com> w= rote:=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > Howdy,=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > On Mon, Jul 6, 2020 at 11:26 AM Timothy Mcsweeney < tim@dropn= umber.com> wrote:=20 > > > > > > > > Ted, > > > > > > > > >=20 > > > > > > > > >Yes, this came up because of a proposed registration.. Sin= ce it was yours,=20 > > > > > > > > >perhaps you would like to provide the link to the group? > > > > > > > >=20 > > > > > > > > There is already a mailing list for that. > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > >Once DISPATCH decides where this ought to be discussed, we= can discuss that=20 > > > > > > > > >outcome or the update to BCP 35 to restore the category as= alternatives. > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > There should not be a discussion at all.=20 > > > > > > > > 1. Section 5 of RFC3405 isn't broken. Maybe you were confus= ing it with=20 > > > > > > > > Section 5 or RFC4395?=20 > > > > > > >=20 > > > > > > > As I note in the extremely short document: > > > > > > >=20 > > > > > > > The document requires that registrations be in the "IETF > > > > > > > tree" of URI registrations. The use of URI scheme name tr= ees was > > > > > > > defined in RFC 2717 [RFC2717] but discontinued by RFC 4395= [RFC4395]. > > > > > > > Since the use of trees was discontinued, there is no way i= n the > > > > > > > current process set out in BCP 35 [RFC7595] to meet the re= quirement. > > > > > > >=20 > > > > > > > If we leave things as they are, no registrations can be made,= because the category is gone. We can change it to require permanent regist= rations instead (as this document suggests) or you could propose something = different (e.g. updating BCP 35 to recreate the IETF tree for these registr= ations). > > > > > > >=20 > > > > > > > > 2. Regardless, any discussions should really wait until aft= er upcoming=20 > > > > > > > > registrations or appeals of those registrations, or appeals= of those appeals are=20 > > > > > > > > completed. > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > >The current rules cannot work because they reference a cat= egory that no=20 > > > > > > > > >longer exists. To put this differently, if they don't chan= ge, there can be=20 > > > > > > > > >no more registrations in URI.arpa. > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > The current rules are working just fine.=20 > > > > > > > > HTTP, among others, are still in the uri.arpa zone proving = that the RFC3405=20 > > > > > > > > Section 3.1.1 reference [10] lives on through the obsoleted= RFCs to the current=20 > > > > > > > > spec and can be=C2=A0seen in totality in IANA's list of URI= s.=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > If I understand you correctly, you are arguing that because U= RI.arpa was not depopulated when the IETF tree was dropped, registrations c= an still be made according to the old rules as if there still were an IETF = tree.=20 > > > > > > >=20 > > > > > > > That's not how the IETF process treats obsoleting BCPs; see t= he IESG statement at https://www.ietf.org/about/groups/iesg/statements/desi= gnating-rfcs-historic-2014-07-20/. > > > > > > >=20 > > > > > > > This situation has pointed out that there was a bug introduce= d by RFC 4395 that was carried forward into RFC 7595, because they did not = address the dependency on the removed IETF tree in BCP 65. This document is= one way to address that bug. If you wish to suggest others, that's fine, b= ut we still need DISPATCH to identify where the discussion should happen.= =20 > > > > > > >=20 > > > > > > > regards, > > > > > > >=20 > > > > > > > Ted=20 > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > > On July 6, 2020 at 12:15 PM Ted Hardie < ted.ietf@gmail.c= om> wrote:=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Howdy,=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > On Sat, Jul 4, 2020 at 2:28 AM Timothy Mcsweeney < tim@dr= opnumber.com> wrote:=20 > > > > > > > > > > Ted, > > > > > > > > > > In your opening email to the 400 highly respectable peo= ple on this list you say: > > > > > > > > > > "As it happens, there are very few registrations in URI= .ARPA, so we did not catch it and fix it before now." > > > > > > > > > >=20 > > > > > > > > > > How did you "catch it"? > > > > > > > > > > Was there a pending registration? > > > > > > > > > > Is there still a pending registration? > > > > > > > > >=20 > > > > > > > > > Yes, this came up because of a proposed registration. Sin= ce it was yours, perhaps you would like to provide the link to the group? > > > > > > > > >=20 > > > > > > > > > > It would really be bad to try to change the rules while= =C2=A0something was pending. > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > The current rules cannot work because they reference a ca= tegory that no longer exists. To put this differently, if they don't change= , there can be no more registrations in URI.arpa.=20 > > > > > > > > >=20 > > > > > > > > > Once DISPATCH decides where this ought to be discussed, w= e can discuss that outcome or the update to BCP 35 to restore the category = as alternatives. > > > > > > > > >=20 > > > > > > > > > regards, > > > > > > > > >=20 > > > > > > > > > Ted Hardie=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > I can't speak for the others but some of them might wan= t to know why after almost 20 years of there being zero problems with RFC34= 05 it suddenly needs to get "fixed". > > > > > > > > > > _______________________________________________=20 > > > > > > > > > > dispatch mailing list=20 > > > > > > > > > > dispatch@ietf.org=20 > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > >=20 > > > >=20 > > > _______________________________________________=20 > > > dispatch mailing list=20 > > > dispatch@ietf.org=20 > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > >=20 >=20 > From nobody Wed Nov 11 08:46:29 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A25B3A0FF0 for ; Wed, 11 Nov 2020 08:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0ewxiFCKGObl for ; Wed, 11 Nov 2020 08:46:26 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE523A0FED for ; Wed, 11 Nov 2020 08:46:26 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LnPvE-1k5TCB2g06-00hdcD for ; Wed, 11 Nov 2020 17:46:25 +0100 Date: Wed, 11 Nov 2020 11:46:25 -0500 (EST) From: Timothy Mcsweeney To: Dispatch WG Message-ID: <881385272.12327.1605113185341@email.ionos.com> In-Reply-To: <1580898449.190942.1594130597348@email.ionos.com> References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:OKGRupOuvT282FGJRu87edScy17a4OFXzlWNSCFGACyusvrolwk rlqyhTpovx4VphdrtCfNUzOoMgZ5uDCuqirhftpsY0q+KmoFOTP2UoBDtV6bNJdlcoRdvMI TFKH5VvCAn7dhood61oviw+zEDsGIk80lNFJrQ4uaBFGAxs1VdAmaCV6vHdTZK3Scty4BRn FGiTTKp3nbdLjaIyCSMJQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:/+vnFXInZl8=:290NtOBViOtC9by+1khmms V9VoIEnLlvAoQ33RNQFeK8lCFtNGU6z9awN57YF4ppYtzkH5haHYO/7ldNMeeinVnNUGF4Est Xj9/bilsOwwk/1iQ7/PNZnFkpPzkqpZpro3mf3mKEH2Z+VfoXPEzZ6UYs42AIQP4bhql5cgnw A7t7Gc3XUjDLOheAHPKfDHCkJ6HtHQrk/cqvFf31yMe1/S5JFngzw7DDVG/hIcyDaJdzFGVIq xuZJGYwd/QAf3FH6v7m7tca2ACZtl35wwoYL67HL3g3VnjYQWbg+NfsJE1MN3R9TkJnFt1XuP XpGTo8ejnLMLAiV5qhPiuFh23ifiQ1HkpxXItZQNldeZexbdLw59zPynCHptMGjb72ApfLw5D PE6U96vO5uue4YZOy2jNuX4X1sVQk0LweOGw4/hnu1RD2ah58uw37ZvXfGl9qhGrtr4gXWkXE B461s1RtAA== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:46:29 -0000 text version: Hi All, Updating RFC3405 will necessarily require changes to RFC3401 as stated in i= ts=20 introduction. "This document will be updated and or obsoleted when changes are made to the DDDS specifications." We are now changing two RFCs so I don't think this fits as a "simple administrative". But, I may have a work around that is simple and also solves the provisiona= l registration problem as stated by Ted. I could have ready in a day or so= . Tim > On 07/07/2020 10:03 AM Timothy Mcsweeney wrote: >=20 >=20 > Hi All, >=20 > Updating RFC3405 will necessarily require changes to RFC3401 as stated in= its > introduction. "This document will be updated and or obsoleted when change= s > are made to the DDDS specifications." >=20 > We are now changing two RFCs so I don't think this fits as a > "simple administrative". >=20 > But, I may have a work around that is simple and also solves the provisio= nal registration problem as stated by Ted. I could have ready in a day or s= o. >=20 > Tim > > On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama.ac= .jp> wrote: > >=20 > >=20 > > On 23/06/2020 07:51, Ben Campbell wrote: > > > Hi Everyone, > > >=20 > > > The ART ADs have reminded the chairs that our charter allows us to ad= opt =E2=80=9Csimple administrative=E2=80=9D work such as IANA registration = documents. This draft seems to fit squarely in that category. Does anyone s= ee a reason we shouldn=E2=80=99t just adopt it, with the expectation of goi= ng immediately to WGLC? (The last-call timeline is the same either way, eit= her 2 weeks WGLC and 2 weeks IETF LC for a working group draft, or 4 weeks = IETF LC for an AD sponsored draft.) > >=20 > > Triggered by the recent discussion, I had a look at Ted's draft and the > > mail up to today. To me, both AD sponsored and Dispatch WG look > > reasonable, with a slight preference for the former (if asked to expres= s > > such a preference). > >=20 > > With respect to "pending registrations", I do not think these are > > relevant, in particular because the thing in question isn't actually a > > scheme, as discussed on the relevant list. > >=20 > > I have one comment: The abstract currently reads > > "This document removes references to the IETF tree of URI registrations > > for registrations in URI.ARPA.". I found this hard to read, and I guess > > it's because of the "registrations for registrations" piece. Unless one > > is very familiar with the matter at hand, it's easy to think that both > > occurrences of "registration" are referencing the same thing. While I'm > > at it, it would also be good if the abstract mentioned something > > positive. I think a less normative version of (the single sentence that > > is) Section 2 would serve well as the abstract. > >=20 > > Regards, Martin. > >=20 > > > Thanks! > > >=20 > > > Ben (as co-chair) > > >=20 > > > > On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail.com> wrote: > > > >=20 > > > > Howdy, > > > >=20 > > > > This is one the shortest drafts I've ever written: https://datatrac= ker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < https://datatracke= r.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/> .. Basically, RFC 34= 05 used to require that registrations in URI.ARPA be from the "IETF Tree". = That tree was deprecated after the document was published. As it happens, t= here are very few registrations in URI.ARPA, so we did not catch it and fix= it before now. > > > >=20 > > > > This draft updates RFC 3405 to require "permanent" scheme registrat= ions. The salient bit is this: > > > >=20 > > > > All registrations in URI.ARPA MUST be for schemes which are permane= nt > > > > registrations, as they are described in BCP 35. > > > >=20 > > > > I'm hoping for a quick dispatch of this, but happy to discuss. > > > >=20 > > > > regards, > > > >=20 > > > > Ted Hardie > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > >=20 > > -- > > Prof. Dr.sc. Martin J. D=C3=BCrst > > Department of Intelligent Information Technology > > College of Science and Engineering > > Aoyama Gakuin University > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > 252-5258 Japan > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Nov 11 08:47:19 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC303A0FF0 for ; Wed, 11 Nov 2020 08:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XzJaw80sycEc for ; Wed, 11 Nov 2020 08:47:16 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112EC3A0FED for ; Wed, 11 Nov 2020 08:47:15 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1M1qCq-1kahPe1dd2-002GD2; Wed, 11 Nov 2020 17:47:06 +0100 Date: Wed, 11 Nov 2020 11:47:04 -0500 (EST) From: Timothy Mcsweeney To: Ben Campbell Cc: DISPATCH WG Message-ID: <505913151.12353.1605113224999@email.ionos.com> In-Reply-To: <2116535970.9156.1594304410818@email.ionos.com> References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:hjGroRgpC9SV4oceirpFdB1/2WQOSXTEaZOhJT+fTa3VmhrV3nJ fwbxzkJx1zZXj7pAQ4p+SRCX2BuoTXiycWJKXE9NERroQSCmE5DarPuyYlO3QcQQxKeWIn9 plQj2VNf/0Q0cKfyFRq6TiUMqwNrV7knW5TxQFJD0KvWrJuaSKUOl2u9WivnFfrm+oOpBzk /pNT/JDcQp8E2rO5FUUVw== X-UI-Out-Filterresults: notjunk:1;V03:K0:8Hzbn8M0UqA=:mwQ8cfIyflXymF3FMZOguw 3jVP/7Ak+/71YQ6XdQvv/Rd+5PU16J3+piQF4yD86JprgUxP7Cfz74tOPfl47SIL16PAf/w9J U9FYqnhhfFA5RDPJIG88U26nR67841S0kyODSoebQNYzCzsIys7U7cFBFZ2vVMGp7hdJkXJVb dxE2R3ZI5vwFPUgkkhf4IrDPmq2oUImtFl2KOV5rqhGCkz6vmXgcUTxQ0rgAPYfXU6hRyHKb+ IdjGDZzdIGHJwwC+zS9eh5SUhG7Kgw+WO7AYeiYXLtSPi4QQlRnOy1kmcoV5FBFD+pBNNdZdr fxzvReMNC4+V37DJNrnbl/nNW+6tnTG2EYyOyBxAKIDce+PrAzWGTPLVhP2JglSzTLHowM9wn 9pa4zksMZSwvqbrdaWvIQefdyKwJjeFTSaSvAFSYXceLP5/JqNpvnPG3WhjHblgAfaMIrjflU HwM8G/Sd6Q== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:47:18 -0000 text version: Hi Ben,=20 Thanks for the heads up on the deadline, I am a little surprised that you are choosing to discuss this at all with p= ending=20 registrations and I obviously disagree with that. But if there are more th= an 5 people besides Ted that think the current rules for provisionals in th= e zone are too open and need to be further constrained then I will submit a draft that= does just that before the deadline.=20 > On 07/09/2020 10:20 AM Timothy Mcsweeney wrote: >=20 >=20 > Hi Ben, >=20 > Thanks for the heads up on the deadline, >=20 > I am a little surprised that you are choosing to discuss this at all with= pending > registrations and I obviously disagree with that. But if there are more t= han 5 people besides Ted that think the current rules for provisionals in t= he zone are > too open and need to be further constrained=C2=A0then I will submit a dra= ft that does > just that before the deadline. >=20 >=20 > > On July 8, 2020 at 10:36 PM Ben Campbell wrote:=20 > >=20 > > Hi Tim, > >=20 > > Do you plan to submit an internet-draft? If so, please be advised that = the deadline for drafts prior to IETF108 is this coming Monday (7/13). If y= ou submit a draft prior to the deadline, we can consider it along with Ted= =E2=80=99s draft (either on the list or possibly in the IETF108 DISPATCH me= eting). > >=20 > > Thanks, > >=20 > > Ben.=20 > >=20 > >=20 > >=20 > > > On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < tim@dropnumber.com> w= rote: > > >=20 > > >=20 > > > Hi All, > > >=20 > > > Updating RFC3405 will necessarily require changes to RFC3401 as state= d in its > > > introduction. "This document will be updated and or obsoleted when ch= anges > > > are made to the DDDS specifications." > > >=20 > > > We are now changing two RFCs so I don't think this fits as a > > > "simple administrative". > > >=20 > > > But, I may have a work around that is simple and also solves the prov= isional registration problem as stated by Ted. I could have ready in a day = or so. > > >=20 > > > Tim > > > > On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < duerst@it.aoyam= a.ac.jp> wrote: > > > >=20 > > > >=20 > > > > On 23/06/2020 07:51, Ben Campbell wrote: > > > > > Hi Everyone, > > > > >=20 > > > > > The ART ADs have reminded the chairs that our charter allows us t= o adopt =E2=80=9Csimple administrative=E2=80=9D work such as IANA registrat= ion documents. This draft seems to fit squarely in that category. Does anyo= ne see a reason we shouldn=E2=80=99t just adopt it, with the expectation of= going immediately to WGLC? (The last-call timeline is the same either way,= either 2 weeks WGLC and 2 weeks IETF LC for a working group draft, or 4 we= eks IETF LC for an AD sponsored draft.) > > > >=20 > > > > Triggered by the recent discussion, I had a look at Ted's draft and= the > > > > mail up to today. To me, both AD sponsored and Dispatch WG look > > > > reasonable, with a slight preference for the former (if asked to ex= press > > > > such a preference). > > > >=20 > > > > With respect to "pending registrations", I do not think these are > > > > relevant, in particular because the thing in question isn't actuall= y a > > > > scheme, as discussed on the relevant list. > > > >=20 > > > > I have one comment: The abstract currently reads > > > > "This document removes references to the IETF tree of URI registrat= ions > > > > for registrations in URI.ARPA.". I found this hard to read, and I g= uess > > > > it's because of the "registrations for registrations" piece. Unless= one > > > > is very familiar with the matter at hand, it's easy to think that b= oth > > > > occurrences of "registration" are referencing the same thing. While= I'm > > > > at it, it would also be good if the abstract mentioned something > > > > positive. I think a less normative version of (the single sentence = that > > > > is) Section 2 would serve well as the abstract. > > > >=20 > > > > Regards, Martin. > > > >=20 > > > > > Thanks! > > > > >=20 > > > > > Ben (as co-chair) > > > > >=20 > > > > > > On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail.com> wr= ote: > > > > > >=20 > > > > > > Howdy, > > > > > >=20 > > > > > > This is one the shortest drafts I've ever written: https://data= tracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < https://datatr= acker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/ (https://datatra= cker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/)> .. Basically, RF= C 3405 used to require that registrations in URI.ARPA be from the "IETF Tre= e". That tree was deprecated after the document was published. As it happen= s, there are very few registrations in URI.ARPA, so we did not catch it and= fix it before now. > > > > > >=20 > > > > > > This draft updates RFC 3405 to require "permanent" scheme regis= trations. The salient bit is this: > > > > > >=20 > > > > > > All registrations in URI.ARPA MUST be for schemes which are per= manent > > > > > > registrations, as they are described in BCP 35. > > > > > >=20 > > > > > > I'm hoping for a quick dispatch of this, but happy to discuss. > > > > > >=20 > > > > > > regards, > > > > > >=20 > > > > > > Ted Hardie > > > > > > _______________________________________________ > > > > > > dispatch mailing list > > > > > > dispatch@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > dispatch mailing list > > > > > dispatch@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > >=20 > > > >=20 > > > > -- > > > > Prof. Dr.sc. Martin J. D=C3=BCrst > > > > Department of Intelligent Information Technology > > > > College of Science and Engineering > > > > Aoyama Gakuin University > > > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > > > 252-5258 Japan > > > >=20 > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________=20 > > > dispatch mailing list=20 > > > dispatch@ietf.org=20 > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > >=20 >=20 > From nobody Wed Nov 11 08:48:14 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6853A1016 for ; Wed, 11 Nov 2020 08:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 tFTWURCcF-dX for ; Wed, 11 Nov 2020 08:48:09 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF3A3A0FF0 for ; Wed, 11 Nov 2020 08:48:09 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MZjFw-1kroZl1f70-00LYYv; Wed, 11 Nov 2020 17:48:07 +0100 Date: Wed, 11 Nov 2020 11:48:06 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG Message-ID: <1487665401.12407.1605113286766@email.ionos.com> In-Reply-To: <1777741348.21431.1594315737558@email.ionos.com> References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:wfEKXItwphR3YudLvlfrdtmKS+iaNRSDhix0qdF6qN+16UwpbB0 g+VY1iu3EbSGti/Scr7PUfB9T+D1gJaQxgSWYDpzBzj6wZKcbYW9sWVYNPWlJ0+QaWFqbKd ACQ+uIFaregGYbYxvByNzN/JaXWnjkrLjyOUS+VJMshpgZdg7zXMxbVSZCbiElUqG06qfsO TgZKCMEfhjVnVD9RAo+ww== X-UI-Out-Filterresults: notjunk:1;V03:K0:9XkYBoNLM1Y=:k/GsB4xrH2eFl/ZbL7VdMB daq8lDbg3ncnxxMf/nUno3vKTo1b3JJKpkwNL/9UQpO7TKxA024Mq9KD7iAb6MW60pTCBj6OL pMftE14xME924fgdL9dFXsWt0ZHlnOEIe2SsHZPLkfgVwxJ983uMTehA0OjF6flt56K58+/rr 0F2pRUG01Esxs3pNIYn2GdduKf0bZ6xA3TH7JuhMHO+1QtpsKrq9hYawa6vQ7UMk6rHnveIMG EMVunOrF6FLcW+jdjitbAedBLbT6wVdS6DmM/eIqLv9i1OSDjPcvhSZ4g153D+6Pucf4ozHDl 45RPmS3wdPwRMyR+wWTIohjpmRmpICteFks29SdRg0Euyj5yNq7Jsc3cQ8tfBoUsYtcvooCzq ybC+g9E2/8V2/mA2pkQdZn9Y0zue1xm39uV6lBNTRqbbPpaWHxSj6zutEFknpcb7+rNGqN+sG T1GkPSDLxQ== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:48:12 -0000 text version: Ted, Section 2 (Updated Requirements) of your draft says: =E2=80=9CAll registrations in URI.ARPA MUST be for schemes which are perman= ent registrations, as they are described in BCP 35.=E2=80=9D I take that as: We must update this because permanent registrations are not required. Other= wise there is no reason for an update. If you are going to argue both sides, my draft and I will just stay out of = it. Here is your pointer. https://www.ietf.org/id/draft-hardie-dispatch-rfc= 3405-update-01.html#section-2 Tim > On 07/09/2020 1:28 PM Timothy Mcsweeney wrote: >=20 >=20 > Ted, >=20 > Section 2 (Updated Requirements) of your draft says: > "All registrations in URI.ARPA MUST be for schemes which are permanent re= gistrations, as they are described in BCP 35." >=20 > I take that as: > We must update this because permanent registrations are not required. Oth= erwise there is no reason for an update. >=20 > If you are going to argue both sides, my draft and I will just stay out o= f it. Here is your pointer. https://www.ietf.org/id/draft-hardie-dispatch-r= fc3405-update-01.html#section-2 >=20 > Tim >=20 >=20 > > On July 9, 2020 at 11:57 AM Ted Hardie wrote:=20 > >=20 > >=20 > > Howdy,=20 > >=20 > >=20 > > On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < tim@dropnumber.com> = wrote:=20 > > > Hi Ben, > > >=20 > > > Thanks for the heads up on the deadline, > > >=20 > > > I am a little surprised that you are choosing to discuss this at all = with pending > > > registrations and I obviously disagree with that. But if there are mo= re than 5 people besides Ted that think the current rules for provisionals = in the zone > >=20 > > I don't think I've seen anyone but you argue that the current rules per= mit provisionals in the zone; if I have missed others reading the rules tha= t way, I'd appreciate a pointer. > >=20 > > I think, though, that the key thing is to get some clarity on what the = rules should be after the elimination of the IETF tree. Since you obviously= disagree with my proposal, having your alternative spelled in a draft does= seem like the best way forward. Wherever dispatch sends the question would= then have two clear proposals to choose between.=20 > >=20 > > regards, > >=20 > > Ted Hardie=20 > > > are > > > too open and need to be further constrained=C2=A0then I will submit a= draft that does > > > just that before the deadline. > > >=20 > > >=20 > > > > On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com> wrote:= =20 > > > >=20 > > > > Hi Tim, > > > >=20 > > > > Do you plan to submit an internet-draft? If so, please be advised t= hat the deadline for drafts prior to IETF108 is this coming Monday (7/13). = If you submit a draft prior to the deadline, we can consider it along with = Ted=E2=80=99s draft (either on the list or possibly in the IETF108 DISPATCH= meeting). > > > >=20 > > > > Thanks, > > > >=20 > > > > Ben.=20 > > > >=20 > > > >=20 > > > >=20 > > > > > On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < tim@dropnumber.co= m> wrote: > > > > >=20 > > > > >=20 > > > > > Hi All, > > > > >=20 > > > > > Updating RFC3405 will necessarily require changes to RFC3401 as s= tated in its > > > > > introduction. "This document will be updated and or obsoleted whe= n changes > > > > > are made to the DDDS specifications." > > > > >=20 > > > > > We are now changing two RFCs so I don't think this fits as a > > > > > "simple administrative". > > > > >=20 > > > > > But, I may have a work around that is simple and also solves the = provisional registration problem as stated by Ted. I could have ready in a = day or so. > > > > >=20 > > > > > Tim > > > > > > On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < duerst@it.a= oyama.ac.jp> wrote: > > > > > >=20 > > > > > >=20 > > > > > > On 23/06/2020 07:51, Ben Campbell wrote: > > > > > > > Hi Everyone, > > > > > > >=20 > > > > > > > The ART ADs have reminded the chairs that our charter allows = us to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IANA regis= tration documents. This draft seems to fit squarely in that category. Does = anyone see a reason we shouldn=E2=80=99t just adopt it, with the expectatio= n of going immediately to WGLC? (The last-call timeline is the same either = way, either 2 weeks WGLC and 2 weeks IETF LC for a working group draft, or = 4 weeks IETF LC for an AD sponsored draft.) > > > > > >=20 > > > > > > Triggered by the recent discussion, I had a look at Ted's draft= and the > > > > > > mail up to today. To me, both AD sponsored and Dispatch WG look > > > > > > reasonable, with a slight preference for the former (if asked t= o express > > > > > > such a preference). > > > > > >=20 > > > > > > With respect to "pending registrations", I do not think these a= re > > > > > > relevant, in particular because the thing in question isn't act= ually a > > > > > > scheme, as discussed on the relevant list. > > > > > >=20 > > > > > > I have one comment: The abstract currently reads > > > > > > "This document removes references to the IETF tree of URI regis= trations > > > > > > for registrations in URI.ARPA.". I found this hard to read, and= I guess > > > > > > it's because of the "registrations for registrations" piece. Un= less one > > > > > > is very familiar with the matter at hand, it's easy to think th= at both > > > > > > occurrences of "registration" are referencing the same thing. W= hile I'm > > > > > > at it, it would also be good if the abstract mentioned somethin= g > > > > > > positive. I think a less normative version of (the single sente= nce that > > > > > > is) Section 2 would serve well as the abstract. > > > > > >=20 > > > > > > Regards, Martin. > > > > > >=20 > > > > > > > Thanks! > > > > > > >=20 > > > > > > > Ben (as co-chair) > > > > > > >=20 > > > > > > > > On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..co= m> wrote: > > > > > > > >=20 > > > > > > > > Howdy, > > > > > > > >=20 > > > > > > > > This is one the shortest drafts I've ever written: https://= datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < https://da= tatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/ (https://dat= atracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/)> .. Basically= , RFC 3405 used to require that registrations in URI.ARPA be from the "IETF= Tree". That tree was deprecated after the document was published.. As it h= appens, there are very few registrations in URI.ARPA, so we did not catch i= t and fix it before now. > > > > > > > >=20 > > > > > > > > This draft updates RFC 3405 to require "permanent" scheme r= egistrations. The salient bit is this: > > > > > > > >=20 > > > > > > > > All registrations in URI.ARPA MUST be for schemes which are= permanent > > > > > > > > registrations, as they are described in BCP 35. > > > > > > > >=20 > > > > > > > > I'm hoping for a quick dispatch of this, but happy to discu= ss. > > > > > > > >=20 > > > > > > > > regards, > > > > > > > >=20 > > > > > > > > Ted Hardie > > > > > > > > _______________________________________________ > > > > > > > > dispatch mailing list > > > > > > > > dispatch@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > dispatch mailing list > > > > > > > dispatch@ietf.org > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > >=20 > > > > > >=20 > > > > > > -- > > > > > > Prof. Dr.sc. Martin J. D=C3=BCrst > > > > > > Department of Intelligent Information Technology > > > > > > College of Science and Engineering > > > > > > Aoyama Gakuin University > > > > > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > > > > > 252-5258 Japan > > > > > >=20 > > > > > > _______________________________________________ > > > > > > dispatch mailing list > > > > > > dispatch@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________=20 > > > > > dispatch mailing list=20 > > > > > dispatch@ietf.org=20 > > > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > > > >=20 > > >=20 > > >=20 > > > _______________________________________________=20 > > > dispatch mailing list=20 > > > dispatch@ietf.org=20 > > > https://www.ietf.org/mailman/listinfo/dispatch=20 >=20 > From nobody Wed Nov 11 08:51:19 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F413A108A for ; Wed, 11 Nov 2020 08:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 o6BWgyrnTgd5 for ; Wed, 11 Nov 2020 08:51:15 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 488B83A122C for ; Wed, 11 Nov 2020 08:49:37 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MFN9m-1kXP8V3MjE-00ENhI; Wed, 11 Nov 2020 17:49:35 +0100 Date: Wed, 11 Nov 2020 11:49:35 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG Message-ID: <1589261623.12469.1605113375465@email.ionos.com> In-Reply-To: <166222013.29010.1594323818783@email.ionos.com> References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:/c3+thmiAcyylTrjFIv4VnfnLzQAY7kBdjHBRCz4Zb/u+8j0nUh ucsygZ3yKDHTqCIDWFoiK8eyDHZCfelx6bcAREibkr3IVfdkkjANYUhXT8yorc35yTmrZMb cCymscgua3zAsMRP4H/nXGIogVRD3S4/lS+77u0F/KoAY5gQePQxfuLYljlB8cuZr5BR9E9 FIM7hJ2Dv0h/XwVb7918w== X-UI-Out-Filterresults: notjunk:1;V03:K0:mWO/M4Qe8wc=:HZTjQ+1hX2o9mwToz13SDn 1FIc3dtMK5hGk3aaRKNXMKIePLIIPhj/Tcwrbln55LfxF2tVGlsiVwa2b26oyV5pe0j/Xbbod lqgc7mtbLasshHWDWHjm606dk3jyQohNS+mAv5SSuD/gNuUEf5HDEE6dhejzGnL/UDpTgUegd 9wa68lABU40Vn9pJf3Y0Jqnbbe77BHNXBRYZ4tq8sD6DbMsZMJqpCPp0nga1rQB0Qim7JEWCK BVCLTvC8xyfidzFdLj5NyB39jkCRIXkrZB57JdA9i3JhgaHN2vCW5k6JGXxhRlRRHIsGIwdZG UGWmNhQLAHiTHjNayM4tw+zIX1GkQ/ynve1FYWFbu4E46SWY7HoI8OcupUDfaaKuvdmQpY4CE rmPxI2WoZFP9uaBt0WtjP4xgmt6gcR8lsnvNzKHnZUYk/6DLRNVVqi80KE8COJ//Vvyiz1Ya9 PlZN2/uSpg== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:51:18 -0000 text version: You're talking about the [ 10] reference in section 3.1.1 in 3405 and when = I click on the reference it sends me right to BCP35. >The reason for the update is that IETF tree registrations *are* required. That is now, scheme registration is required, including provisionals. See,= no bug. Tim > On 07/09/2020 3:43 PM Timothy Mcsweeney wrote: >=20 >=20 > You're talking about the [ 10 (https://tools.ietf.org/html/rfc3405#ref-10= )] reference in section 3.1.1 in 3405 (https://tools.ietf.org/html/rfc3405#= section-3.1.1) and when I click on the reference it sends me right to BCP35= (https://tools.ietf.org/html/bcp35). >=20 > >The reason for the update is that IETF tree registrations *are* required= . >=20 > That is now, scheme registration is required, including provisionals. See= , no bug. >=20 > Tim >=20 >=20 >=20 >=20 > > On July 9, 2020 at 3:09 PM Ted Hardie wrote:=20 > >=20 > >=20 > > On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < tim@dropnumber.com>= wrote:=20 > > > Ted, > > >=20 > > > Section 2 (Updated Requirements) of your draft says: > > > "All registrations in URI.ARPA MUST be for schemes which are permanen= t registrations, as they are described in BCP 35." > > >=20 > > > I take that as: > > > We must update this because permanent registrations are not required.= Otherwise there is no reason for an update. > >=20 > > The reason for the update is that IETF tree registrations *are* require= d. That effectively closes the registry, without the community having made = the affirmative decision to do so. I want to fix that bug.=20 > >=20 > > I currently think that the closest replacement to the IETF tree would b= e permanent registration and that we should fix this by requiring that. But= I'm happy to see a clear draft espousing some other way of fixing the bug;= if you have an idea about that, please write the draft. > >=20 > > regards, > >=20 > > Ted=20 > >=20 > >=20 > >=20 > >=20 > > >=20 > > > If you are going to argue both sides, my draft and I will just stay o= ut of it. Here is your pointer. https://www.ietf.org/id/draft-hardie-dispat= ch-rfc3405-update-01.html#section-2 > > >=20 > > > Tim > > >=20 > > >=20 > > > > On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com> wrote:= =20 > > > >=20 > > > >=20 > > > > Howdy,=20 > > > >=20 > > > >=20 > > > > On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < tim@dropnumber.c= om> wrote:=20 > > > > > Hi Ben, > > > > >=20 > > > > > Thanks for the heads up on the deadline, > > > > >=20 > > > > > I am a little surprised that you are choosing to discuss this at = all with pending > > > > > registrations and I obviously disagree with that. But if there ar= e more than 5 people besides Ted that think the current rules for provision= als in the zone > > > >=20 > > > > I don't think I've seen anyone but you argue that the current rules= permit provisionals in the zone; if I have missed others reading the rules= that way, I'd appreciate a pointer. > > > >=20 > > > > I think, though, that the key thing is to get some clarity on what = the rules should be after the elimination of the IETF tree. Since you obvio= usly disagree with my proposal, having your alternative spelled in a draft = does seem like the best way forward. Wherever dispatch sends the question w= ould then have two clear proposals to choose between.=20 > > > >=20 > > > > regards, > > > >=20 > > > > Ted Hardie=20 > > > > > are > > > > > too open and need to be further constrained=C2=A0then I will subm= it a draft that does > > > > > just that before the deadline. > > > > >=20 > > > > >=20 > > > > > > On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com> wro= te:=20 > > > > > >=20 > > > > > > Hi Tim, > > > > > >=20 > > > > > > Do you plan to submit an internet-draft? If so, please be advis= ed that the deadline for drafts prior to IETF108 is this coming Monday (7/1= 3). If you submit a draft prior to the deadline, we can consider it along w= ith Ted=E2=80=99s draft (either on the list or possibly in the IETF108 DISP= ATCH meeting). > > > > > >=20 > > > > > > Thanks, > > > > > >=20 > > > > > > Ben.=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > > On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < tim@dropnumbe= r.com> wrote: > > > > > > >=20 > > > > > > >=20 > > > > > > > Hi All, > > > > > > >=20 > > > > > > > Updating RFC3405 will necessarily require changes to RFC3401 = as stated in its > > > > > > > introduction. "This document will be updated and or obsoleted= when changes > > > > > > > are made to the DDDS specifications." > > > > > > >=20 > > > > > > > We are now changing two RFCs so I don't think this fits as a > > > > > > > "simple administrative". > > > > > > >=20 > > > > > > > But, I may have a work around that is simple and also solves = the provisional registration problem as stated by Ted. I could have ready i= n a day or so. > > > > > > >=20 > > > > > > > Tim > > > > > > > > On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < duerst@= it.aoyama.ac.jp> wrote: > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > On 23/06/2020 07:51, Ben Campbell wrote: > > > > > > > > > Hi Everyone, > > > > > > > > >=20 > > > > > > > > > The ART ADs have reminded the chairs that our charter all= ows us to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IANA r= egistration documents. This draft seems to fit squarely in that category. D= oes anyone see a reason we shouldn=E2=80=99t just adopt it, with the expect= ation of going immediately to WGLC? (The last-call timeline is the same eit= her way, either 2 weeks WGLC and 2 weeks IETF LC for a working group draft,= or 4 weeks IETF LC for an AD sponsored draft.) > > > > > > > >=20 > > > > > > > > Triggered by the recent discussion, I had a look at Ted's d= raft and the > > > > > > > > mail up to today. To me, both AD sponsored and Dispatch WG = look > > > > > > > > reasonable, with a slight preference for the former (if ask= ed to express > > > > > > > > such a preference). > > > > > > > >=20 > > > > > > > > With respect to "pending registrations", I do not think the= se are > > > > > > > > relevant, in particular because the thing in question isn't= actually a > > > > > > > > scheme, as discussed on the relevant list. > > > > > > > >=20 > > > > > > > > I have one comment: The abstract currently reads > > > > > > > > "This document removes references to the IETF tree of URI r= egistrations > > > > > > > > for registrations in URI.ARPA.". I found this hard to read,= and I guess > > > > > > > > it's because of the "registrations for registrations" piece= . Unless one > > > > > > > > is very familiar with the matter at hand, it's easy to thin= k that both > > > > > > > > occurrences of "registration" are referencing the same thin= g. While I'm > > > > > > > > at it, it would also be good if the abstract mentioned some= thing > > > > > > > > positive. I think a less normative version of (the single s= entence that > > > > > > > > is) Section 2 would serve well as the abstract. > > > > > > > >=20 > > > > > > > > Regards, Martin. > > > > > > > >=20 > > > > > > > > > Thanks! > > > > > > > > >=20 > > > > > > > > > Ben (as co-chair) > > > > > > > > >=20 > > > > > > > > > > On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail= ..com> wrote: > > > > > > > > > >=20 > > > > > > > > > > Howdy, > > > > > > > > > >=20 > > > > > > > > > > This is one the shortest drafts I've ever written: http= s://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < https:= //datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/ (https:/= /datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/)> .. Basic= ally, RFC 3405 used to require that registrations in URI.ARPA be from the "= IETF Tree". That tree was deprecated after the document was published.. As = it happens, there are very few registrations in URI.ARPA, so we did not cat= ch it and fix it before now. > > > > > > > > > >=20 > > > > > > > > > > This draft updates RFC 3405 to require "permanent" sche= me registrations. The salient bit is this: > > > > > > > > > >=20 > > > > > > > > > > All registrations in URI.ARPA MUST be for schemes which= are permanent > > > > > > > > > > registrations, as they are described in BCP 35. > > > > > > > > > >=20 > > > > > > > > > > I'm hoping for a quick dispatch of this, but happy to d= iscuss. > > > > > > > > > >=20 > > > > > > > > > > regards, > > > > > > > > > >=20 > > > > > > > > > > Ted Hardie > > > > > > > > > > _______________________________________________ > > > > > > > > > > dispatch mailing list > > > > > > > > > > dispatch@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > _______________________________________________ > > > > > > > > > dispatch mailing list > > > > > > > > > dispatch@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > -- > > > > > > > > Prof. Dr.sc. Martin J. D=C3=BCrst > > > > > > > > Department of Intelligent Information Technology > > > > > > > > College of Science and Engineering > > > > > > > > Aoyama Gakuin University > > > > > > > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > > > > > > > 252-5258 Japan > > > > > > > >=20 > > > > > > > > _______________________________________________ > > > > > > > > dispatch mailing list > > > > > > > > dispatch@ietf.org > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > _______________________________________________=20 > > > > > > > dispatch mailing list=20 > > > > > > > dispatch@ietf.org=20 > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > > > _______________________________________________=20 > > > > > dispatch mailing list=20 > > > > > dispatch@ietf.org=20 > > > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > > >=20 > > >=20 >=20 > From nobody Wed Nov 11 08:51:22 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE573A108B for ; Wed, 11 Nov 2020 08:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 6ilMi_b_G7Cq for ; Wed, 11 Nov 2020 08:51:16 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507AD3A0978 for ; Wed, 11 Nov 2020 08:50:20 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LijEJ-1k0oPn3p7d-00cyWb; Wed, 11 Nov 2020 17:50:18 +0100 Date: Wed, 11 Nov 2020 11:50:18 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG Message-ID: <1018810658.12503.1605113418568@email.ionos.com> In-Reply-To: <577450265.31749.1594326660123@email.ionos.com> References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> <577450265.31749.1594326660123@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:dy5mkgFkC0yofLZ3kWJrjKDs/mA7DkgXI07412RJl7SsBsS6Q0s AOT9WsIwNRKWQ5h1i6gohpD38fi9JpeN2C9HR/vxbNrbZz6s6fuKHOEZC9pjXFOokv1pRPg YNh7VkUpPC/SkneFon2DQXDNcXplL0KKy4SWCHqI42KB1/gcEAcBeoHmyKOAqc8z0dGyDmr VJ2PGldcmeNaalf1uVjLA== X-UI-Out-Filterresults: notjunk:1;V03:K0:O1N5L9+uGqI=:M4l9kVa0rXtWKPR3gwZVBV 0e+n5Hgqi3I0VtszUhOjs5Ua97LwS7524vm3ak2p2nclHK+991qTm5dGMT3iUrU726uyL+YnN /vD27fqEvEAz33ajW4HAz35X0oRCgoWbVdtp5th+XxeE25WtWArJR+IY4MLg4QIsxdxKsggVm 9ID4Wq7ddOaJlD1HIbHYyC3E16BiA35uG3WCEzhFnq5wyql3jWqEuzHvG0nnGQyDjYaD7sbj0 /3RuLGV8sCq0i2b/BTz8GIHVmVVVMXcOkgAHHCaN/WpVqG4Eu6ggbr+gdzNUcJKN0Oq9LpvV3 mvYNul+WMKOwrDSKnyrUJtGooY3qQXzTfx818NMsllA/FYhYQeSHpG05tHxdT2Y+0Y7EUmmRH wYnw0o6/YqsMYxKhqZFEvf9BTJSnI+jvNXtkDGu/ZnCD8rgEYZRhxcarIkOtax2juZ90I1R/k XBZtFW10hg== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:51:18 -0000 text version: Yeah I looked at that a month ago already but unfortunately it doesn't matt= er if you change the reference from [10] to [11] it still goes to BCP35. S= till no bug :-) > On 07/09/2020 4:31 PM Timothy Mcsweeney wrote: >=20 >=20 > Yeah I looked at that a month ago already but unfortunately it doesn't ma= tter if you change the reference from [10] to [11] it still goes to BCP35. = Still no bug :-) > > On July 9, 2020 at 3:43 PM Timothy Mcsweeney wrote= :=20 > >=20 > >=20 > > You're talking about the [ 10 (https://tools.ietf.org/html/rfc3405#ref-= 10)] reference in section 3.1.1 in 3405 (https://tools.ietf.org/html/rfc340= 5#section-3.1.1) and when I click on the reference it sends me right to BCP= 35 (https://tools.ietf.org/html/bcp35). > >=20 > > >The reason for the update is that IETF tree registrations *are* requir= ed. > >=20 > > That is now, scheme registration is required, including provisionals. S= ee, no bug. > >=20 > > Tim > >=20 > >=20 > >=20 > >=20 > > > On July 9, 2020 at 3:09 PM Ted Hardie wrote:=20 > > >=20 > > >=20 > > > On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < tim@dropnumber.co= m> wrote:=20 > > > > Ted, > > > >=20 > > > > Section 2 (Updated Requirements) of your draft says: > > > > "All registrations in URI.ARPA MUST be for schemes which are perman= ent registrations, as they are described in BCP 35." > > > >=20 > > > > I take that as: > > > > We must update this because permanent registrations are not require= d. Otherwise there is no reason for an update. > > >=20 > > > The reason for the update is that IETF tree registrations *are* requi= red. That effectively closes the registry, without the community having mad= e the affirmative decision to do so. I want to fix that bug.=20 > > >=20 > > > I currently think that the closest replacement to the IETF tree would= be permanent registration and that we should fix this by requiring that. B= ut I'm happy to see a clear draft espousing some other way of fixing the bu= g; if you have an idea about that, please write the draft. > > >=20 > > > regards, > > >=20 > > > Ted=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > >=20 > > > > If you are going to argue both sides, my draft and I will just stay= out of it. Here is your pointer. https://www.ietf..org/id/draft-hardie-dis= patch-rfc3405-update-01.html#section-2 (https://www.ietf.org/id/draft-hardi= e-dispatch-rfc3405-update-01.html#section-2) > > > >=20 > > > > Tim > > > >=20 > > > >=20 > > > > > On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com> wrot= e:=20 > > > > >=20 > > > > >=20 > > > > > Howdy,=20 > > > > >=20 > > > > >=20 > > > > > On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < tim@dropnumber= .com> wrote:=20 > > > > > > Hi Ben, > > > > > >=20 > > > > > > Thanks for the heads up on the deadline, > > > > > >=20 > > > > > > I am a little surprised that you are choosing to discuss this a= t all with pending > > > > > > registrations and I obviously disagree with that. But if there = are more than 5 people besides Ted that think the current rules for provisi= onals in the zone > > > > >=20 > > > > > I don't think I've seen anyone but you argue that the current rul= es permit provisionals in the zone; if I have missed others reading the rul= es that way, I'd appreciate a pointer. > > > > >=20 > > > > > I think, though, that the key thing is to get some clarity on wha= t the rules should be after the elimination of the IETF tree. Since you obv= iously disagree with my proposal, having your alternative spelled in a draf= t does seem like the best way forward. Wherever dispatch sends the question= would then have two clear proposals to choose between.=20 > > > > >=20 > > > > > regards, > > > > >=20 > > > > > Ted Hardie=20 > > > > > > are > > > > > > too open and need to be further constrained=C2=A0then I will su= bmit a draft that does > > > > > > just that before the deadline. > > > > > >=20 > > > > > >=20 > > > > > > > On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com> w= rote:=20 > > > > > > >=20 > > > > > > > Hi Tim, > > > > > > >=20 > > > > > > > Do you plan to submit an internet-draft? If so, please be adv= ised that the deadline for drafts prior to IETF108 is this coming Monday (7= /13). If you submit a draft prior to the deadline, we can consider it along= with Ted=E2=80=99s draft (either on the list or possibly in the IETF108 DI= SPATCH meeting). > > > > > > >=20 > > > > > > > Thanks, > > > > > > >=20 > > > > > > > Ben.=20 > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > > On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < tim@dropnum= ber.com> wrote: > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > Hi All, > > > > > > > >=20 > > > > > > > > Updating RFC3405 will necessarily require changes to RFC340= 1 as stated in its > > > > > > > > introduction. "This document will be updated and or obsolet= ed when changes > > > > > > > > are made to the DDDS specifications." > > > > > > > >=20 > > > > > > > > We are now changing two RFCs so I don't think this fits as = a > > > > > > > > "simple administrative". > > > > > > > >=20 > > > > > > > > But, I may have a work around that is simple and also solve= s the provisional registration problem as stated by Ted. I could have ready= in a day or so. > > > > > > > >=20 > > > > > > > > Tim > > > > > > > > > On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < duers= t@it.aoyama.ac.jp> wrote: > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > On 23/06/2020 07:51, Ben Campbell wrote: > > > > > > > > > > Hi Everyone, > > > > > > > > > >=20 > > > > > > > > > > The ART ADs have reminded the chairs that our charter a= llows us to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IANA= registration documents. This draft seems to fit squarely in that category.= . Does anyone see a reason we shouldn=E2=80=99t just adopt it, with the exp= ectation of going immediately to WGLC? (The last-call timeline is the same = either way, either 2 weeks WGLC and 2 weeks IETF LC for a working group dra= ft, or 4 weeks IETF LC for an AD sponsored draft.) > > > > > > > > >=20 > > > > > > > > > Triggered by the recent discussion, I had a look at Ted's= draft and the > > > > > > > > > mail up to today. To me, both AD sponsored and Dispatch W= G look > > > > > > > > > reasonable, with a slight preference for the former (if a= sked to express > > > > > > > > > such a preference). > > > > > > > > >=20 > > > > > > > > > With respect to "pending registrations", I do not think t= hese are > > > > > > > > > relevant, in particular because the thing in question isn= 't actually a > > > > > > > > > scheme, as discussed on the relevant list. > > > > > > > > >=20 > > > > > > > > > I have one comment: The abstract currently reads > > > > > > > > > "This document removes references to the IETF tree of URI= registrations > > > > > > > > > for registrations in URI.ARPA.". I found this hard to rea= d, and I guess > > > > > > > > > it's because of the "registrations for registrations" pie= ce. Unless one > > > > > > > > > is very familiar with the matter at hand, it's easy to th= ink that both > > > > > > > > > occurrences of "registration" are referencing the same th= ing. While I'm > > > > > > > > > at it, it would also be good if the abstract mentioned so= mething > > > > > > > > > positive. I think a less normative version of (the single= sentence that > > > > > > > > > is) Section 2 would serve well as the abstract. > > > > > > > > >=20 > > > > > > > > > Regards, Martin. > > > > > > > > >=20 > > > > > > > > > > Thanks! > > > > > > > > > >=20 > > > > > > > > > > Ben (as co-chair) > > > > > > > > > >=20 > > > > > > > > > > > On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gma= il..com> wrote: > > > > > > > > > > >=20 > > > > > > > > > > > Howdy, > > > > > > > > > > >=20 > > > > > > > > > > > This is one the shortest drafts I've ever written: ht= tps://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ (https= ://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/) < https= ://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/> .. Bas= ically, RFC 3405 used to require that registrations in URI.ARPA be from the= "IETF Tree". That tree was deprecated after the document was published... = As it happens, there are very few registrations in URI.ARPA, so we did not = catch it and fix it before now. > > > > > > > > > > >=20 > > > > > > > > > > > This draft updates RFC 3405 to require "permanent" sc= heme registrations. The salient bit is this: > > > > > > > > > > >=20 > > > > > > > > > > > All registrations in URI.ARPA MUST be for schemes whi= ch are permanent > > > > > > > > > > > registrations, as they are described in BCP 35. > > > > > > > > > > >=20 > > > > > > > > > > > I'm hoping for a quick dispatch of this, but happy to= discuss. > > > > > > > > > > >=20 > > > > > > > > > > > regards, > > > > > > > > > > >=20 > > > > > > > > > > > Ted Hardie > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > dispatch mailing list > > > > > > > > > > > dispatch@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > _______________________________________________ > > > > > > > > > > dispatch mailing list > > > > > > > > > > dispatch@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > -- > > > > > > > > > Prof. Dr.sc. Martin J. D=C3=BCrst > > > > > > > > > Department of Intelligent Information Technology > > > > > > > > > College of Science and Engineering > > > > > > > > > Aoyama Gakuin University > > > > > > > > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > > > > > > > > 252-5258 Japan > > > > > > > > >=20 > > > > > > > > > _______________________________________________ > > > > > > > > > dispatch mailing list > > > > > > > > > dispatch@ietf.org > > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > _______________________________________________=20 > > > > > > > > dispatch mailing list=20 > > > > > > > > dispatch@ietf.org=20 > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________=20 > > > > > > dispatch mailing list=20 > > > > > > dispatch@ietf.org=20 > > > > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > > > >=20 > > > >=20 > >=20 > >=20 > > _______________________________________________ dispatch mailing list d= ispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch >=20 > From nobody Wed Nov 11 08:51:51 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB973A13D3 for ; Wed, 11 Nov 2020 08:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 9Siigzm_BK3x for ; Wed, 11 Nov 2020 08:51:46 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BEA3A136C for ; Wed, 11 Nov 2020 08:51:33 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MkqKB-1jsauR2KIJ-00mI7t for ; Wed, 11 Nov 2020 17:51:32 +0100 Date: Wed, 11 Nov 2020 11:51:32 -0500 (EST) From: Timothy Mcsweeney Cc: DISPATCH WG Message-ID: <1428362467.12567.1605113492259@email.ionos.com> In-Reply-To: <630535283.101560.1594647207701@email.ionos.com> References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> <630535283.101560.1594647207701@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:3JCniDJc5obyu1TQzTFxnryITyS53CLXfUraIzp6Uv97tnMV6OB XGBNIKJegFVlNivs+/LdzE/2Y0gh7jkoynCRf3bpHY/pZsyK8WykQyc8mteAHul0JwiSpfe S6IDNAfvN79P51//+W9e37zW3TstfOAKaY7Nt10zMriJMwqA2W/P1jOtjSd1I/xrBKVNJ0v QB4YHqBTRNPu1DRqY3ZQw== X-UI-Out-Filterresults: notjunk:1;V03:K0:ZmZoNAp++RU=:hPGgglbBq+GhwALjOu7PKf QvYBhisJqVoF1eAW/gpC63ZAeU2jsLubUtitQ/Au8tE6XAttZmLuk2EW17JmFjhyojn09hoUq 3wKEf0xbY5Q+w233kDe4XrCeJkUv8j6hPtiRZ9gG1yD5i1+yJU3894f5CM7zBB3PFuM08x52R 9eGdp+5AfIneLa0G8V5hEYIt+iJzsYzNiuIc09KHwf06e4YBpvnL9K7f9fVJiL2YYoAh/YWF7 6dhzDYoXKhP3z6lMKzK0J0DyM1b7tDgiMgsLZgqRNbLrSofwcV5oeVrYwPtOZXXCQDZdXhXJK pzsjF+0woM1fzJeyqouYH1b0SpKW33nZyFfE/5wLd41+inLe4xfaozRRoLPT+rsyQ2dFeSe9o 59qZU+JRXPcMejfy8d9ysB8n9GjrSu9iRVGWxrkUpMnXPWUvA0kHS1tcoCVfWh2edwmI3Jt1h Li12OX6Juw== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:51:50 -0000 text version: Martin,=20 >The current BCP 35 doesn't contain such requirements, and >therefore doesn't make any sense. That's right, BCP doesn't contain such requirements. Whether or not makes sense to you is immaterial. Thank you for helping me state my case. Tim > On 07/13/2020 9:33 AM Timothy Mcsweeney wrote: >=20 >=20 > Martin, >=20 > >The current BCP 35 doesn't contain such requirements, and=20 > >therefore doesn't make any sense. >=20 > That's right, BCP doesn't contain such requirements. > Whether or not makes sense to you is immaterial. > Thank you for helping me state my case. >=20 > Tim >=20 >=20 >=20 >=20 >=20 > > On July 12, 2020 at 7:43 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama.a= c.jp> wrote: > >=20 > >=20 > > On 10/07/2020 04:43, Timothy Mcsweeney wrote: > > > You're talking about the [ 10 < ]" rel=3D"noopener" target=3D"_blank"= data-mce-href=3D"https://tools.ietf.org/html/rfc3405#ref-10>]">https://too= ls.ietf.org/html/rfc3405#ref-10>] (https://tools.ietf.org/html/rfc3405#ref-= 10) > > > reference in section 3.1.1 in 3405 > > > < https://tools.ietf.org/html/rfc3405#section-3.1.1> and when I click= on the > > > reference it sends me right to BCP35 < " rel=3D"noopener" target=3D"_= blank" data-mce-href=3D"https://tools.ietf.org/html/bcp35>">https://tools.i= etf.org/html/bcp35> (https://tools.ietf.org/html/bcp35). > > When I look at > >=20 > > >>>> > > [10] Petke, R. and I. King, "Registration Procedures for URL Scheme > > Names", BCP 35, RFC 2717, January 1999. > > >>>> > > it has two links, one for BCP 35 (which now redirects to something else > > which doesn't actually match the reference data) and one for RFC 2717 > > (which matches the original reference, including author and date of > > publication). > >=20 > > RFC 2717 then says: > >=20 > > >>>> > > 2.2 The IETF Tree > >=20 > > The IETF tree is intended for URL schemes of general interest to the > > Internet community. The tree exists for URL schemes that require a > > substantive review and approval process. It is expected that > > applicability statements for particular applications will be > > published from time to time that recommend implementation of, and > > support for, URL schemes that have proven particularly useful in > > those contexts. > > >>>> > >=20 > > > >The reason for the update is that IETF tree registrations *are* requ= ired. > > Yes, and the closest to that ("URL schemes of general interest to the > > Internet community", "require a substantive review and approval > > process") we currently have is permanent registration, so that's where > > Ted's proposal (which I fully support) comes from. > >=20 > > > That is now, scheme registration is required, including provisionals.= See, no bug. > > No. That there's a link somewhere doesn't mean you can interpret things > > any which way. The reference you follow (in one specific way) comes fro= m > >=20 > > >>>> > > 3.1.1 Only Schemes in the IETF Tree Allowed > >=20 > > In order to be inserted into the URI.ARPA zone, the subsequent URI > > scheme MUST be registered under the IETF URI tree. The requirements > > for this tree are specified in [10]. > > >>>> > >=20 > > This means that the reference is for defining the requirements of the > > IETF URI tree. The current BCP 35 doesn't contain such requirements, an= d > > therefore doesn't make any sense. The old BCP 35 (RFC 2717) is clear, > > but is no longer in force. As a consequence, we have a dangling > > reference (IETF Tree is no longer defined in a valid IETF spec). We > > cannot just say "let's assume this means whatever suits me best" or "by > > chance there's a link (out of two) that leads to a spec that includes > > something that suits me", but we have to recognize that we have a > > problem with the spec (when updating BCP 35, its authors forgot to > > update RFC 3405), and have to fix that. > >=20 > > And the fix that Ted is proposing is the fix that is closest to the > > original intent, and takes into account the reason for the original > > restriction. > >=20 > > Regards, Martin. > >=20 > >=20 > > > Tim > > >=20 > > >=20 > > >=20 > > >=20 > > > > On July 9, 2020 at 3:09 PM Ted Hardie < ted.ietf@gmail.com> wrote: > > >> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < tim@dropnumber.c= om > > >> > wrote: > > >> > > >> __ > > >> Ted, > > >> > > >> Section 2 (Updated Requirements) of your draft says: > > >> "All registrations in URI.ARPA MUST be for schemes which are permane= nt > > >> registrations, as they are described in BCP 35." > > >> > > >> I take that as: > > >> We must update this because permanent registrations are not required= . > > >> Otherwise there is no reason for an update. > > >> > > >> > > >> The reason for the update is that IETF tree registrations *are* requ= ired. > > >> That effectively closes the registry, without the community having m= ade the > > >> affirmative decision to do so. I want to fix that bug. > > >> > > >> I currently think that the closest replacement to the IETF tree woul= d be > > >> permanent registration and that we should fix this by requiring that= . But I'm > > >> happy to see a clear draft espousing some other way of fixing the bu= g; if you > > >> have an idea about that, please write the draft. > > >> > > >> regards, > > >> > > >> Ted > > >> > > >> > > >> > > >> > > >> > > >> If you are going to argue both sides, my draft and I will just stay = out of > > >> it. Here is your pointer. > > >> https://www.ietf..org/id/draft-hardie-dispatch-rfc3405-update-01.htm= l#section-2 > > >> < https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.ht= ml#section-2> > > >> > > >> > > >> Tim > > >> > > >> > > >>> On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com > > >>> > wrote: > > >>> > > >>> Howdy, > > >>> > > >>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < tim@dropnumber.c= om > > >>> > wrote: > > >>> > > >>> __ > > >>> Hi Ben, > > >>> > > >>> Thanks for the heads up on the deadline, > > >>> > > >>> I am a little surprised that you are choosing to discuss this at al= l > > >>> with pending > > >>> registrations and I obviously disagree with that. But if there are > > >>> more than 5 people besides Ted that think the current rules for > > >>> provisionals in the zone > > >>> > > >>> > > >>> I don't think I've seen anyone but you argue that the current rules > > >>> permit provisionals in the zone; if I have missed others reading th= e > > >>> rules that way, I'd appreciate a pointer. > > >>> > > >>> I think, though, that the key thing is to get some clarity on what = the > > >>> rules should be after the elimination of the IETF tree. Since you > > >>> obviously disagree with my proposal, having your alternative spelle= d in a > > >>> draft does seem like the best way forward. Wherever dispatch sends = the > > >>> question would then have two clear proposals to choose between. > > >>> > > >>> regards, > > >>> > > >>> Ted Hardie > > >>> > > >>> are > > >>> too open and need to be further constrained then I will submit a > > >>> draft that does > > >>> just that before the deadline. > > >>> > > >>> > > >>>> On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com > > >>>> > wrote: > > >>>> > > >>>> Hi Tim, > > >>>> > > >>>> Do you plan to submit an internet-draft? If so, please be advised > > >>>> that the deadline for drafts prior to IETF108 is this coming Monda= y > > >>>> (7/13). If you submit a draft prior to the deadline, we can consid= er > > >>>> it along with Ted=E2=80=99s draft (either on the list or possibly = in the > > >>>> IETF108 DISPATCH meeting). > > >>>> > > >>>> Thanks, > > >>>> > > >>>> Ben. > > >>>> > > >>>>> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < tim@dropnumber.co= m > > >>>>> > wrote: > > >>>>> > > >>>>> Hi All, > > >>>>> > > >>>>> Updating RFC3405 will necessarily require changes to RFC3401 as > > >>>>> stated in its > > >>>>> introduction. "This document will be updated and or obsoleted whe= n > > >>>>> changes > > >>>>> are made to the DDDS specifications." > > >>>>> > > >>>>> We are now changing two RFCs so I don't think this fits as a > > >>>>> "simple administrative". > > >>>>> > > >>>>> But, I may have a work around that is simple and also solves the > > >>>>> provisional registration problem as stated by Ted. I could have > > >>>>> ready in a day or so. > > >>>>> > > >>>>> Tim > > >>>>>> On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < > > >>>>>> duerst@it.aoyama.ac.jp > wrote: > > >>>>>> > > >>>>>> > > >>>>>> On 23/06/2020 07:51, Ben Campbell wrote: > > >>>>>>> Hi Everyone, > > >>>>>>> > > >>>>>>> The ART ADs have reminded the chairs that our charter allows us > > >>>>>>> to adopt =E2=80=9Csimple administrative=E2=80=9D work such as I= ANA registration > > >>>>>>> documents. This draft seems to fit squarely in that category.. > > >>>>>>> Does anyone see a reason we shouldn=E2=80=99t just adopt it, wi= th the > > >>>>>>> expectation of going immediately to WGLC? (The last-call timeli= ne > > >>>>>>> is the same either way, either 2 weeks WGLC and 2 weeks IETF LC > > >>>>>>> for a working group draft, or 4 weeks IETF LC for an AD sponsor= ed > > >>>>>>> draft.) > > >>>>>> > > >>>>>> Triggered by the recent discussion, I had a look at Ted's draft > > >>>>>> and the > > >>>>>> mail up to today. To me, both AD sponsored and Dispatch WG look > > >>>>>> reasonable, with a slight preference for the former (if asked to > > >>>>>> express > > >>>>>> such a preference). > > >>>>>> > > >>>>>> With respect to "pending registrations", I do not think these ar= e > > >>>>>> relevant, in particular because the thing in question isn't > > >>>>>> actually a > > >>>>>> scheme, as discussed on the relevant list. > > >>>>>> > > >>>>>> I have one comment: The abstract currently reads > > >>>>>> "This document removes references to the IETF tree of URI > > >>>>>> registrations > > >>>>>> for registrations in URI.ARPA.". I found this hard to read, and = I > > >>>>>> guess > > >>>>>> it's because of the "registrations for registrations" piece. > > >>>>>> Unless one > > >>>>>> is very familiar with the matter at hand, it's easy to think tha= t > > >>>>>> both > > >>>>>> occurrences of "registration" are referencing the same thing. > > >>>>>> While I'm > > >>>>>> at it, it would also be good if the abstract mentioned something > > >>>>>> positive. I think a less normative version of (the single senten= ce > > >>>>>> that > > >>>>>> is) Section 2 would serve well as the abstract. > > >>>>>> > > >>>>>> Regards, Martin. > > >>>>>> > > >>>>>>> Thanks! > > >>>>>>> > > >>>>>>> Ben (as co-chair) > > >>>>>>> > > >>>>>>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com > > >>>>>>>> > wrote: > > >>>>>>>> > > >>>>>>>> Howdy, > > >>>>>>>> > > >>>>>>>> This is one the shortest drafts I've ever written: > > >>>>>>>> https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405= -update/ > > >>>>>>>> < https://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3= 405-update/> > > >>>>>>>> < > > >>>>>>>> https://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc34= 05-update/> > > >>>>>>>> .. Basically, RFC 3405 used to require that registrations in > > >>>>>>>> URI.ARPA be from the "IETF Tree". That tree was deprecated aft= er > > >>>>>>>> the document was published... As it happens, there are very fe= w > > >>>>>>>> registrations in URI.ARPA, so we did not catch it and fix it > > >>>>>>>> before now. > > >>>>>>>> > > >>>>>>>> This draft updates RFC 3405 to require "permanent" scheme > > >>>>>>>> registrations. The salient bit is this: > > >>>>>>>> > > >>>>>>>> All registrations in URI.ARPA MUST be for schemes which are > > >>>>>>>> permanent > > >>>>>>>> registrations, as they are described in BCP 35. > > >>>>>>>> > > >>>>>>>> I'm hoping for a quick dispatch of this, but happy to discuss. > > >>>>>>>> > > >>>>>>>> regards, > > >>>>>>>> > > >>>>>>>> Ted Hardie > > >>>>>>>> _______________________________________________ > > >>>>>>>> dispatch mailing list > > >>>>>>>> dispatch@ietf.org > > >>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> dispatch mailing list > > >>>>>>> dispatch@ietf.org > > >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch > > >>>>>>> > > >>>>>> > > >>>>>> -- > > >>>>>> Prof. Dr.sc. Martin J. D=C3=BCrst > > >>>>>> Department of Intelligent Information Technology > > >>>>>> College of Science and Engineering > > >>>>>> Aoyama Gakuin University > > >>>>>> Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > >>>>>> 252-5258 Japan > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> dispatch mailing list > > >>>>>> dispatch@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/dispatch > > >>>>> _______________________________________________ > > >>>>> dispatch mailing list > > >>>>> dispatch@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/dispatch > > >>>> > > >>> > > >>> _______________________________________________ > > >>> dispatch mailing list > > >>> dispatch@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dispatch > > >>> > > >> > > >=20 > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > > -- > > Prof. Dr.sc. Martin J. D=C3=BCrst > > Department of Intelligent Information Technology > > College of Science and Engineering > > Aoyama Gakuin University > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > 252-5258 Japan From nobody Wed Nov 11 08:56:16 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A3E3A09BB for ; Wed, 11 Nov 2020 08:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 JS2ub6nrrt2I for ; Wed, 11 Nov 2020 08:56:10 -0800 (PST) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99A63A0978 for ; Wed, 11 Nov 2020 08:56:09 -0800 (PST) Received: by mail-lj1-x244.google.com with SMTP id h23so2815057ljg.13 for ; Wed, 11 Nov 2020 08:56:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3AtP4tga/NOW6a5PSix2Qb7PyZ+jDtAYr6QMrgdKov8=; b=eYPzFImktwlKdypyoJIUOq5Sa+zH0CxxXMvMuweRrmzjjZOktpugBADfsAXIDy9B0B W22xUx1eS1443E9VrOTf8o7a6Lqwa5qmvjX16e8gth4nomU0X+MnhPG7EprqSZjCmffI R6qL7vSQgai8D4prmCzEHy52V4NNU24i3+fyXLqTiUOSCvadASUFVQY2Zvj2UvsYFbGA PZn4S4EKZNI5MjB8yz6hxzcj0sEV509ld0oVNEKEYBHzsxzbY2HeBCGvdu2PYkHUAvgN 1/AVs1R0qCZqHOtrGqeH1jQMDZuArrslBkW5OHdNYI7b4letdWWKWq3IT4F+Yqkcljts 1/WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3AtP4tga/NOW6a5PSix2Qb7PyZ+jDtAYr6QMrgdKov8=; b=o03wHLBDS1SmJMxzq8A9Zv3FfomiyIm4enF3fSVtD85mzlnZL31U6YjnPLXwJT2nyT st5Peub2FNT7Z416caZTEr4dAap6+i96uPNzB8/0bSa8MZ1ugttpo8g9YLT5dkYrVzjT 16aZk/Yt808sWb4AZIC7iXnDJJ0abplveqtWhg/Fke3nS3mVUB929PPAYoGuvC7ZseZy luhAC3xWprCPYeAT5g9n/s21MPqijCQWnRzD0/gmHh7OQsRQrkmt5kgmOYdW4DZ5eMvz GimwcDB/h1lsKy4LH0GPskUJa7knD6v6xhnvutxT6kogENSEb4UX+IQmkMUz9rK3BCDy KSMA== X-Gm-Message-State: AOAM531I2Ld1PcDukNqaZerJGd+RATvDBpiZiPoNICTNWjB5a1SHedTs RHH4hroQmdxAuz8y6rWNrvVTz3ftEUyAKnZs5WDIaw== X-Google-Smtp-Source: ABdhPJzOSJaJuyNCfsbIGFrSWbPoIcK5U7LeqkuWRYaHmyFWiPb1Ez3+8PeKAO1BL0I2R5QFhJKG7G0EQFVMS9EJMCo= X-Received: by 2002:a2e:9096:: with SMTP id l22mr7492581ljg.199.1605113767594; Wed, 11 Nov 2020 08:56:07 -0800 (PST) MIME-Version: 1.0 References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> <630535283.101560.1594647207701@email.ionos.com> <1428362467.12567.1605113492259@email.ionos.com> In-Reply-To: <1428362467.12567.1605113492259@email.ionos.com> From: Eric Rescorla Date: Wed, 11 Nov 2020 08:55:31 -0800 Message-ID: To: Timothy Mcsweeney Cc: DISPATCH WG Content-Type: multipart/alternative; boundary="000000000000f1238205b3d7ab1c" Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 16:56:14 -0000 --000000000000f1238205b3d7ab1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Timothy, You have sent quite a few messages to this list on this topic in the past hour. However, this draft has already been approved by the IESG and is in the RFC Editor queue, so further discussion on this topic on dispatch is not really productive. What are you trying to achieve? -Ekr On Wed, Nov 11, 2020 at 8:52 AM Timothy Mcsweeney wrote: > text version: > Martin, > > >The current BCP 35 doesn't contain such requirements, and > >therefore doesn't make any sense. > > That's right, BCP doesn't contain such requirements. > Whether or not makes sense to you is immaterial. > Thank you for helping me state my case. > > Tim > > > > On 07/13/2020 9:33 AM Timothy Mcsweeney wrote: > > > > > > Martin, > > > > >The current BCP 35 doesn't contain such requirements, and > > >therefore doesn't make any sense. > > > > That's right, BCP doesn't contain such requirements. > > Whether or not makes sense to you is immaterial. > > Thank you for helping me state my case. > > > > Tim > > > > > > > > > > > > > On July 12, 2020 at 7:43 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama= .ac.jp> > wrote: > > > > > > > > > On 10/07/2020 04:43, Timothy Mcsweeney wrote: > > > > You're talking about the [ 10 < ]" rel=3D"noopener" target=3D"_blan= k" > data-mce-href=3D"https://tools.ietf.org/html/rfc3405#ref-10>]"> > https://tools.ietf.org/html/rfc3405#ref-10>] ( > https://tools.ietf.org/html/rfc3405#ref-10) > > > > reference in section 3.1.1 in 3405 > > > > < https://tools.ietf.org/html/rfc3405#section-3.1.1> and when I > click on the > > > > reference it sends me right to BCP35 < " rel=3D"noopener" > target=3D"_blank" data-mce-href=3D"https://tools.ietf.org/html/bcp35>"> > https://tools.ietf.org/html/bcp35> (https://tools.ietf.org/html/bcp35). > > > When I look at > > > > > > >>>> > > > [10] Petke, R. and I. King, "Registration Procedures for URL Scheme > > > Names", BCP 35, RFC 2717, January 1999. > > > >>>> > > > it has two links, one for BCP 35 (which now redirects to something el= se > > > which doesn't actually match the reference data) and one for RFC 2717 > > > (which matches the original reference, including author and date of > > > publication). > > > > > > RFC 2717 then says: > > > > > > >>>> > > > 2.2 The IETF Tree > > > > > > The IETF tree is intended for URL schemes of general interest to the > > > Internet community. The tree exists for URL schemes that require a > > > substantive review and approval process. It is expected that > > > applicability statements for particular applications will be > > > published from time to time that recommend implementation of, and > > > support for, URL schemes that have proven particularly useful in > > > those contexts. > > > >>>> > > > > > > > >The reason for the update is that IETF tree registrations *are* > required. > > > Yes, and the closest to that ("URL schemes of general interest to the > > > Internet community", "require a substantive review and approval > > > process") we currently have is permanent registration, so that's wher= e > > > Ted's proposal (which I fully support) comes from. > > > > > > > That is now, scheme registration is required, including > provisionals. See, no bug. > > > No. That there's a link somewhere doesn't mean you can interpret thin= gs > > > any which way. The reference you follow (in one specific way) comes > from > > > > > > >>>> > > > 3.1.1 Only Schemes in the IETF Tree Allowed > > > > > > In order to be inserted into the URI.ARPA zone, the subsequent URI > > > scheme MUST be registered under the IETF URI tree. The requirements > > > for this tree are specified in [10]. > > > >>>> > > > > > > This means that the reference is for defining the requirements of the > > > IETF URI tree. The current BCP 35 doesn't contain such requirements, > and > > > therefore doesn't make any sense. The old BCP 35 (RFC 2717) is clear, > > > but is no longer in force. As a consequence, we have a dangling > > > reference (IETF Tree is no longer defined in a valid IETF spec). We > > > cannot just say "let's assume this means whatever suits me best" or "= by > > > chance there's a link (out of two) that leads to a spec that includes > > > something that suits me", but we have to recognize that we have a > > > problem with the spec (when updating BCP 35, its authors forgot to > > > update RFC 3405), and have to fix that. > > > > > > And the fix that Ted is proposing is the fix that is closest to the > > > original intent, and takes into account the reason for the original > > > restriction. > > > > > > Regards, Martin. > > > > > > > > > > Tim > > > > > > > > > > > > > > > > > > > > > On July 9, 2020 at 3:09 PM Ted Hardie < ted.ietf@gmail.com> wrote= : > > > >> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < > tim@dropnumber.com > > > >> > wrote: > > > >> > > > >> __ > > > >> Ted, > > > >> > > > >> Section 2 (Updated Requirements) of your draft says: > > > >> "All registrations in URI.ARPA MUST be for schemes which are > permanent > > > >> registrations, as they are described in BCP 35." > > > >> > > > >> I take that as: > > > >> We must update this because permanent registrations are not > required. > > > >> Otherwise there is no reason for an update. > > > >> > > > >> > > > >> The reason for the update is that IETF tree registrations *are* > required. > > > >> That effectively closes the registry, without the community having > made the > > > >> affirmative decision to do so. I want to fix that bug. > > > >> > > > >> I currently think that the closest replacement to the IETF tree > would be > > > >> permanent registration and that we should fix this by requiring > that. But I'm > > > >> happy to see a clear draft espousing some other way of fixing the > bug; if you > > > >> have an idea about that, please write the draft. > > > >> > > > >> regards, > > > >> > > > >> Ted > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> If you are going to argue both sides, my draft and I will just sta= y > out of > > > >> it. Here is your pointer. > > > >> https://www.ietf. > .org/id/draft-hardie-dispatch-rfc3405-update-01.html#section-2 > > > >> < > https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#sect= ion-2 > > > > > >> > > > >> > > > >> Tim > > > >> > > > >> > > > >>> On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com > > > >>> > wrote: > > > >>> > > > >>> Howdy, > > > >>> > > > >>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < > tim@dropnumber.com > > > >>> > wrote: > > > >>> > > > >>> __ > > > >>> Hi Ben, > > > >>> > > > >>> Thanks for the heads up on the deadline, > > > >>> > > > >>> I am a little surprised that you are choosing to discuss this at > all > > > >>> with pending > > > >>> registrations and I obviously disagree with that. But if there ar= e > > > >>> more than 5 people besides Ted that think the current rules for > > > >>> provisionals in the zone > > > >>> > > > >>> > > > >>> I don't think I've seen anyone but you argue that the current rul= es > > > >>> permit provisionals in the zone; if I have missed others reading > the > > > >>> rules that way, I'd appreciate a pointer. > > > >>> > > > >>> I think, though, that the key thing is to get some clarity on wha= t > the > > > >>> rules should be after the elimination of the IETF tree. Since you > > > >>> obviously disagree with my proposal, having your alternative > spelled in a > > > >>> draft does seem like the best way forward. Wherever dispatch send= s > the > > > >>> question would then have two clear proposals to choose between. > > > >>> > > > >>> regards, > > > >>> > > > >>> Ted Hardie > > > >>> > > > >>> are > > > >>> too open and need to be further constrained then I will submit a > > > >>> draft that does > > > >>> just that before the deadline. > > > >>> > > > >>> > > > >>>> On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com > > > >>>> > wrote: > > > >>>> > > > >>>> Hi Tim, > > > >>>> > > > >>>> Do you plan to submit an internet-draft? If so, please be advise= d > > > >>>> that the deadline for drafts prior to IETF108 is this coming > Monday > > > >>>> (7/13). If you submit a draft prior to the deadline, we can > consider > > > >>>> it along with Ted=E2=80=99s draft (either on the list or possibl= y in the > > > >>>> IETF108 DISPATCH meeting). > > > >>>> > > > >>>> Thanks, > > > >>>> > > > >>>> Ben. > > > >>>> > > > >>>>> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < > tim@dropnumber.com > > > >>>>> > wrote: > > > >>>>> > > > >>>>> Hi All, > > > >>>>> > > > >>>>> Updating RFC3405 will necessarily require changes to RFC3401 as > > > >>>>> stated in its > > > >>>>> introduction. "This document will be updated and or obsoleted > when > > > >>>>> changes > > > >>>>> are made to the DDDS specifications." > > > >>>>> > > > >>>>> We are now changing two RFCs so I don't think this fits as a > > > >>>>> "simple administrative". > > > >>>>> > > > >>>>> But, I may have a work around that is simple and also solves th= e > > > >>>>> provisional registration problem as stated by Ted. I could have > > > >>>>> ready in a day or so. > > > >>>>> > > > >>>>> Tim > > > >>>>>> On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < > > > >>>>>> duerst@it.aoyama.ac.jp > > wrote: > > > >>>>>> > > > >>>>>> > > > >>>>>> On 23/06/2020 07:51, Ben Campbell wrote: > > > >>>>>>> Hi Everyone, > > > >>>>>>> > > > >>>>>>> The ART ADs have reminded the chairs that our charter allows = us > > > >>>>>>> to adopt =E2=80=9Csimple administrative=E2=80=9D work such as= IANA registration > > > >>>>>>> documents. This draft seems to fit squarely in that category.= . > > > >>>>>>> Does anyone see a reason we shouldn=E2=80=99t just adopt it, = with the > > > >>>>>>> expectation of going immediately to WGLC? (The last-call > timeline > > > >>>>>>> is the same either way, either 2 weeks WGLC and 2 weeks IETF = LC > > > >>>>>>> for a working group draft, or 4 weeks IETF LC for an AD > sponsored > > > >>>>>>> draft.) > > > >>>>>> > > > >>>>>> Triggered by the recent discussion, I had a look at Ted's draf= t > > > >>>>>> and the > > > >>>>>> mail up to today. To me, both AD sponsored and Dispatch WG loo= k > > > >>>>>> reasonable, with a slight preference for the former (if asked = to > > > >>>>>> express > > > >>>>>> such a preference). > > > >>>>>> > > > >>>>>> With respect to "pending registrations", I do not think these > are > > > >>>>>> relevant, in particular because the thing in question isn't > > > >>>>>> actually a > > > >>>>>> scheme, as discussed on the relevant list. > > > >>>>>> > > > >>>>>> I have one comment: The abstract currently reads > > > >>>>>> "This document removes references to the IETF tree of URI > > > >>>>>> registrations > > > >>>>>> for registrations in URI.ARPA.". I found this hard to read, an= d > I > > > >>>>>> guess > > > >>>>>> it's because of the "registrations for registrations" piece. > > > >>>>>> Unless one > > > >>>>>> is very familiar with the matter at hand, it's easy to think > that > > > >>>>>> both > > > >>>>>> occurrences of "registration" are referencing the same thing. > > > >>>>>> While I'm > > > >>>>>> at it, it would also be good if the abstract mentioned somethi= ng > > > >>>>>> positive. I think a less normative version of (the single > sentence > > > >>>>>> that > > > >>>>>> is) Section 2 would serve well as the abstract. > > > >>>>>> > > > >>>>>> Regards, Martin. > > > >>>>>> > > > >>>>>>> Thanks! > > > >>>>>>> > > > >>>>>>> Ben (as co-chair) > > > >>>>>>> > > > >>>>>>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@gmail..com > > > >>>>>>>> > wrote: > > > >>>>>>>> > > > >>>>>>>> Howdy, > > > >>>>>>>> > > > >>>>>>>> This is one the shortest drafts I've ever written: > > > >>>>>>>> > https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ > > > >>>>>>>> < https://datatracker.ietf. > .org/doc/draft-hardie-dispatch-rfc3405-update/> > > > >>>>>>>> < > > > >>>>>>>> https://datatracker.ietf. > ..org/doc/draft-hardie-dispatch-rfc3405-update/> > > > >>>>>>>> .. Basically, RFC 3405 used to require that registrations in > > > >>>>>>>> URI.ARPA be from the "IETF Tree". That tree was deprecated > after > > > >>>>>>>> the document was published... As it happens, there are very > few > > > >>>>>>>> registrations in URI.ARPA, so we did not catch it and fix it > > > >>>>>>>> before now. > > > >>>>>>>> > > > >>>>>>>> This draft updates RFC 3405 to require "permanent" scheme > > > >>>>>>>> registrations. The salient bit is this: > > > >>>>>>>> > > > >>>>>>>> All registrations in URI.ARPA MUST be for schemes which are > > > >>>>>>>> permanent > > > >>>>>>>> registrations, as they are described in BCP 35. > > > >>>>>>>> > > > >>>>>>>> I'm hoping for a quick dispatch of this, but happy to discus= s. > > > >>>>>>>> > > > >>>>>>>> regards, > > > >>>>>>>> > > > >>>>>>>> Ted Hardie > > > >>>>>>>> _______________________________________________ > > > >>>>>>>> dispatch mailing list > > > >>>>>>>> dispatch@ietf.org > > > >>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> _______________________________________________ > > > >>>>>>> dispatch mailing list > > > >>>>>>> dispatch@ietf.org > > > >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch > > > >>>>>>> > > > >>>>>> > > > >>>>>> -- > > > >>>>>> Prof. Dr.sc. Martin J. D=C3=BCrst > > > >>>>>> Department of Intelligent Information Technology > > > >>>>>> College of Science and Engineering > > > >>>>>> Aoyama Gakuin University > > > >>>>>> Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > > >>>>>> 252-5258 Japan > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> dispatch mailing list > > > >>>>>> dispatch@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/dispatch > > > >>>>> _______________________________________________ > > > >>>>> dispatch mailing list > > > >>>>> dispatch@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/dispatch > > > >>>> > > > >>> > > > >>> _______________________________________________ > > > >>> dispatch mailing list > > > >>> dispatch@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/dispatch > > > >>> > > > >> > > > > > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > -- > > > Prof. Dr.sc. Martin J. D=C3=BCrst > > > Department of Intelligent Information Technology > > > College of Science and Engineering > > > Aoyama Gakuin University > > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > > 252-5258 Japan > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000f1238205b3d7ab1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Timothy,

You have sent quite= a few messages to this list on this topic in the past hour. However, this = draft has already been approved by the IESG and is in the RFC Editor queue,= so further discussion on this topic on dispatch is not really productive. = What are you trying to achieve?

-Ekr


On Wed, Nov 11, 2020 at 8:52 AM Timothy Mcsweeney <tim@dropnumber.com> wrote:
text version:
Martin,

>The current BCP 35 doesn't contain such requirements, and
>therefore doesn't make any sense.

That's right, BCP doesn't contain such requirements.
Whether or not makes sense to you is immaterial.
Thank you for helping me state my case.

Tim


> On 07/13/2020 9:33 AM Timothy Mcsweeney <tim@dropnumber.com> wrote:
>
>
> Martin,
>
> >The current BCP 35 doesn't contain such requirements, and
> >therefore doesn't make any sense.
>
> That's right, BCP doesn't contain such requirements.
> Whether or not makes sense to you is immaterial.
> Thank you for helping me state my case.
>
> Tim
>
>
>
>
>
> > On July 12, 2020 at 7:43 AM "Martin J. D=C3=BCrst" <= duerst@it.aoya= ma.ac.jp> wrote:
> >
> >
> > On 10/07/2020 04:43, Timothy Mcsweeney wrote:
> > > You're talking about the [ 10 < ]" rel=3D"n= oopener" target=3D"_blank" data-mce-href=3D"https://tools.ietf.org/html/rfc3405#ref-10>]">https://tools.ietf.org/html/rfc3405#ref-10>] (https://tools.ietf.org/html/rfc3405#ref-10)
> > > reference in section 3.1.1 in 3405
> > > < https://tools.ietf.org/html/rfc= 3405#section-3.1.1> and when I click on the
> > > reference it sends me right to BCP35 < " rel=3D"= ;noopener" target=3D"_blank" data-mce-href=3D"https://tools.ietf.org/html/bcp35>">https://tools.i= etf.org/html/bcp35> (https://tools.ietf.org/html/bcp35).=
> > When I look at
> >
> > >>>>
> > [10] Petke, R. and I. King, "Registration Procedures for URL= Scheme
> > Names", BCP 35, RFC 2717, January 1999.
> > >>>>
> > it has two links, one for BCP 35 (which now redirects to somethin= g else
> > which doesn't actually match the reference data) and one for = RFC 2717
> > (which matches the original reference, including author and date = of
> > publication).
> >
> > RFC 2717 then says:
> >
> > >>>>
> > 2.2 The IETF Tree
> >
> > The IETF tree is intended for URL schemes of general interest to = the
> > Internet community. The tree exists for URL schemes that require = a
> > substantive review and approval process. It is expected that
> > applicability statements for particular applications will be
> > published from time to time that recommend implementation of, and=
> > support for, URL schemes that have proven particularly useful in<= br> > > those contexts.
> > >>>>
> >
> > > >The reason for the update is that IETF tree registration= s *are* required.
> > Yes, and the closest to that ("URL schemes of general intere= st to the
> > Internet community", "require a substantive review and = approval
> > process") we currently have is permanent registration, so th= at's where
> > Ted's proposal (which I fully support) comes from.
> >
> > > That is now, scheme registration is required, including prov= isionals. See, no bug.
> > No. That there's a link somewhere doesn't mean you can in= terpret things
> > any which way. The reference you follow (in one specific way) com= es from
> >
> > >>>>
> > 3.1.1 Only Schemes in the IETF Tree Allowed
> >
> > In order to be inserted into the URI.ARPA zone, the subsequent UR= I
> > scheme MUST be registered under the IETF URI tree. The requiremen= ts
> > for this tree are specified in [10].
> > >>>>
> >
> > This means that the reference is for defining the requirements of= the
> > IETF URI tree. The current BCP 35 doesn't contain such requir= ements, and
> > therefore doesn't make any sense. The old BCP 35 (RFC 2717) i= s clear,
> > but is no longer in force. As a consequence, we have a dangling > > reference (IETF Tree is no longer defined in a valid IETF spec). = We
> > cannot just say "let's assume this means whatever suits = me best" or "by
> > chance there's a link (out of two) that leads to a spec that = includes
> > something that suits me", but we have to recognize that we h= ave a
> > problem with the spec (when updating BCP 35, its authors forgot t= o
> > update RFC 3405), and have to fix that.
> >
> > And the fix that Ted is proposing is the fix that is closest to t= he
> > original intent, and takes into account the reason for the origin= al
> > restriction.
> >
> > Regards, Martin.
> >
> >
> > > Tim
> > >
> > >
> > >
> > >
> > > > On July 9, 2020 at 3:09 PM Ted Hardie < ted.ietf@gmail.com> wrot= e:
> > >> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < <= a href=3D"mailto:tim@dropnumber.com" target=3D"_blank">tim@dropnumber.com
> > >> <mailto: tim@dropnumber.com>> wrote:
> > >>
> > >> __
> > >> Ted,
> > >>
> > >> Section 2 (Updated Requirements) of your draft says:
> > >> "All registrations in URI.ARPA MUST be for schemes = which are permanent
> > >> registrations, as they are described in BCP 35." > > >>
> > >> I take that as:
> > >> We must update this because permanent registrations are = not required.
> > >> Otherwise there is no reason for an update.
> > >>
> > >>
> > >> The reason for the update is that IETF tree registration= s *are* required.
> > >> That effectively closes the registry, without the commun= ity having made the
> > >> affirmative decision to do so. I want to fix that bug. > > >>
> > >> I currently think that the closest replacement to the IE= TF tree would be
> > >> permanent registration and that we should fix this by re= quiring that. But I'm
> > >> happy to see a clear draft espousing some other way of f= ixing the bug; if you
> > >> have an idea about that, please write the draft.
> > >>
> > >> regards,
> > >>
> > >> Ted
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> If you are going to argue both sides, my draft and I wil= l just stay out of
> > >> it. Here is your pointer.
> > >> https://www.ietf..org/id/draft-hardie-dispatch-rfc3405-upda= te-01.html#section-2
> > >> < https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#sect= ion-2>
> > >>
> > >>
> > >> Tim
> > >>
> > >>
> > >>> On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com
> > >>> <mailto: ted.ietf@gmail.com>> wrote:
> > >>>
> > >>> Howdy,
> > >>>
> > >>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney <= ; tim@dropnumber.co= m
> > >>> <mailto: tim@dropnumber.com>> wrote:
> > >>>
> > >>> __
> > >>> Hi Ben,
> > >>>
> > >>> Thanks for the heads up on the deadline,
> > >>>
> > >>> I am a little surprised that you are choosing to dis= cuss this at all
> > >>> with pending
> > >>> registrations and I obviously disagree with that. Bu= t if there are
> > >>> more than 5 people besides Ted that think the curren= t rules for
> > >>> provisionals in the zone
> > >>>
> > >>>
> > >>> I don't think I've seen anyone but you argue= that the current rules
> > >>> permit provisionals in the zone; if I have missed ot= hers reading the
> > >>> rules that way, I'd appreciate a pointer.
> > >>>
> > >>> I think, though, that the key thing is to get some c= larity on what the
> > >>> rules should be after the elimination of the IETF tr= ee. Since you
> > >>> obviously disagree with my proposal, having your alt= ernative spelled in a
> > >>> draft does seem like the best way forward. Wherever = dispatch sends the
> > >>> question would then have two clear proposals to choo= se between.
> > >>>
> > >>> regards,
> > >>>
> > >>> Ted Hardie
> > >>>
> > >>> are
> > >>> too open and need to be further constrained then I w= ill submit a
> > >>> draft that does
> > >>> just that before the deadline.
> > >>>
> > >>>
> > >>>> On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com
> > >>>> <mailto: ben@nostrum.com>> wrote:
> > >>>>
> > >>>> Hi Tim,
> > >>>>
> > >>>> Do you plan to submit an internet-draft? If so, = please be advised
> > >>>> that the deadline for drafts prior to IETF108 is= this coming Monday
> > >>>> (7/13). If you submit a draft prior to the deadl= ine, we can consider
> > >>>> it along with Ted=E2=80=99s draft (either on the= list or possibly in the
> > >>>> IETF108 DISPATCH meeting).
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Ben.
> > >>>>
> > >>>>> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweene= y < tim@dropnumb= er.com
> > >>>>> <mailto: tim@dropnumber.com>> wrote:
> > >>>>>
> > >>>>> Hi All,
> > >>>>>
> > >>>>> Updating RFC3405 will necessarily require ch= anges to RFC3401 as
> > >>>>> stated in its
> > >>>>> introduction. "This document will be up= dated and or obsoleted when
> > >>>>> changes
> > >>>>> are made to the DDDS specifications." > > >>>>>
> > >>>>> We are now changing two RFCs so I don't = think this fits as a
> > >>>>> "simple administrative".
> > >>>>>
> > >>>>> But, I may have a work around that is simple= and also solves the
> > >>>>> provisional registration problem as stated b= y Ted. I could have
> > >>>>> ready in a day or so.
> > >>>>>
> > >>>>> Tim
> > >>>>>> On July 7, 2020 at 3:34 AM "Martin = J. D=C3=BCrst" <
> > >>>>>> duerst@it.aoyama.ac.jp <mailto: duerst@it.aoyama= .ac..jp>> wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>> On 23/06/2020 07:51, Ben Campbell wrote:=
> > >>>>>>> Hi Everyone,
> > >>>>>>>
> > >>>>>>> The ART ADs have reminded the chairs= that our charter allows us
> > >>>>>>> to adopt =E2=80=9Csimple administrat= ive=E2=80=9D work such as IANA registration
> > >>>>>>> documents. This draft seems to fit s= quarely in that category..
> > >>>>>>> Does anyone see a reason we shouldn= =E2=80=99t just adopt it, with the
> > >>>>>>> expectation of going immediately to = WGLC? (The last-call timeline
> > >>>>>>> is the same either way, either 2 wee= ks WGLC and 2 weeks IETF LC
> > >>>>>>> for a working group draft, or 4 week= s IETF LC for an AD sponsored
> > >>>>>>> draft.)
> > >>>>>>
> > >>>>>> Triggered by the recent discussion, I ha= d a look at Ted's draft
> > >>>>>> and the
> > >>>>>> mail up to today. To me, both AD sponsor= ed and Dispatch WG look
> > >>>>>> reasonable, with a slight preference for= the former (if asked to
> > >>>>>> express
> > >>>>>> such a preference).
> > >>>>>>
> > >>>>>> With respect to "pending registrati= ons", I do not think these are
> > >>>>>> relevant, in particular because the thin= g in question isn't
> > >>>>>> actually a
> > >>>>>> scheme, as discussed on the relevant lis= t.
> > >>>>>>
> > >>>>>> I have one comment: The abstract current= ly reads
> > >>>>>> "This document removes references t= o the IETF tree of URI
> > >>>>>> registrations
> > >>>>>> for registrations in URI.ARPA.". I = found this hard to read, and I
> > >>>>>> guess
> > >>>>>> it's because of the "registrati= ons for registrations" piece.
> > >>>>>> Unless one
> > >>>>>> is very familiar with the matter at hand= , it's easy to think that
> > >>>>>> both
> > >>>>>> occurrences of "registration" = are referencing the same thing.
> > >>>>>> While I'm
> > >>>>>> at it, it would also be good if the abst= ract mentioned something
> > >>>>>> positive. I think a less normative versi= on of (the single sentence
> > >>>>>> that
> > >>>>>> is) Section 2 would serve well as the ab= stract.
> > >>>>>>
> > >>>>>> Regards, Martin.
> > >>>>>>
> > >>>>>>> Thanks!
> > >>>>>>>
> > >>>>>>> Ben (as co-chair)
> > >>>>>>>
> > >>>>>>>> On Jun 3, 2020, at 6:13 PM, Ted = Hardie < ted.ietf@gmail..com
> > >>>>>>>> <mailto: ted.ietf@gmail.com>> wrote: > > >>>>>>>>
> > >>>>>>>> Howdy,
> > >>>>>>>>
> > >>>>>>>> This is one the shortest drafts = I've ever written:
> > >>>>>>>> https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405= -update/
> > >>>>>>>> < https://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/>
> > >>>>>>>> <
> > >>>>>>>> https://datatracker.ietf...o= rg/doc/draft-hardie-dispatch-rfc3405-update/>
> > >>>>>>>> .. Basically, RFC 3405 used to r= equire that registrations in
> > >>>>>>>> URI.ARPA be from the "IETF = Tree". That tree was deprecated after
> > >>>>>>>> the document was published... As= it happens, there are very few
> > >>>>>>>> registrations in URI.ARPA, so we= did not catch it and fix it
> > >>>>>>>> before now.
> > >>>>>>>>
> > >>>>>>>> This draft updates RFC 3405 to r= equire "permanent" scheme
> > >>>>>>>> registrations. The salient bit i= s this:
> > >>>>>>>>
> > >>>>>>>> All registrations in URI.ARPA MU= ST be for schemes which are
> > >>>>>>>> permanent
> > >>>>>>>> registrations, as they are descr= ibed in BCP 35.
> > >>>>>>>>
> > >>>>>>>> I'm hoping for a quick dispa= tch of this, but happy to discuss.
> > >>>>>>>>
> > >>>>>>>> regards,
> > >>>>>>>>
> > >>>>>>>> Ted Hardie
> > >>>>>>>> ________________________________= _______________
> > >>>>>>>> dispatch mailing list
> > >>>>>>>> dispatch@ietf.org <mailto: dispatch@ietf.org>
> > >>>>>>>> https://www= .ietf.org/mailman/listinfo/dispatch
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> ____________________________________= ___________
> > >>>>>>> dispatch mailing list
> > >>>>>>> dispatch@ietf.org <mailto: dispatch@ietf.org>
> > >>>>>>> https://www.iet= f.org/mailman/listinfo/dispatch
> > >>>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Prof. Dr.sc. Martin J. D=C3=BCrst
> > >>>>>> Department of Intelligent Information Te= chnology
> > >>>>>> College of Science and Engineering
> > >>>>>> Aoyama Gakuin University
> > >>>>>> Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > >>>>>> 252-5258 Japan
> > >>>>>>
> > >>>>>> ________________________________________= _______
> > >>>>>> dispatch mailing list
> > >>>>>> dispatch@ietf.org <mailto: dispatch@ietf.org>
> > >>>>>> https://www.ietf.or= g/mailman/listinfo/dispatch
> > >>>>> ____________________________________________= ___
> > >>>>> dispatch mailing list
> > >>>>> dispatch@ietf.org <mailto: dispatch@ietf.org>
> > >>>>> https://www.ietf.org/ma= ilman/listinfo/dispatch
> > >>>>
> > >>>
> > >>> _______________________________________________
> > >>> dispatch mailing list
> > >>> dispatch@ietf.org <mailto: dispatch@ietf.org>
> > >>> https://www.ietf.org/mailman/li= stinfo/dispatch
> > >>>
> > >>
> > >
> > > _______________________________________________
> > > dispatch mailing list
> > > dispa= tch@ietf.org
> > > https://www.ietf.org/mailman/listinfo/d= ispatch
> > >
> > --
> > Prof. Dr.sc. Martin J. D=C3=BCrst
> > Department of Intelligent Information Technology
> > College of Science and Engineering
> > Aoyama Gakuin University
> > Fuchinobe 5-1-10, Chuo-ku, Sagamihara
> > 252-5258 Japan

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000f1238205b3d7ab1c-- From nobody Wed Nov 11 09:10:24 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854673A190A for ; Wed, 11 Nov 2020 09:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 kuTDvLA2Uvpf for ; Wed, 11 Nov 2020 09:10:17 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D51323A17DB for ; Wed, 11 Nov 2020 09:08:19 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lmae5-1k4eyn4AUt-00aHx2; Wed, 11 Nov 2020 18:08:11 +0100 Date: Wed, 11 Nov 2020 12:08:10 -0500 (EST) From: Timothy Mcsweeney To: Ben Campbell , DISPATCH WG Message-ID: <620476948.13264.1605114490582@email.ionos.com> In-Reply-To: <1728083860.882593.1596215282277@email.ionos.com> References: <1728083860.882593.1596215282277@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:OpSjNsL8j9s/C1EXb7ve/yRUQN9XnI3vEUHjYUghFDw5RxBQiyl uksDBSs/vZ0rl1yJbcT/g2IwteH6zquD8kJ49LKwns9OdHyp5eS0t2S3nnTGH6219DfIfCl QzZ0hua+eSbNXNkGGYJxF2Hsbv8khymCw1kRhcDO59WJXLeUm7UG/TCjPpDGTMLHi4LaMPB /VFCHeHFahW/nhD81wSVQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:wI7gmgeWhFE=:3g/NKzHWFmz6wL1qk3Vrc5 snEq2Fxo6doyx7Q/v+ZpHn/IA4WsSPVgmS7ewjVBah38RpBU3XZ52EXjbevgKP2x74XcBnLLz KFfQbMkwecYcF6qVXXQlMu5m1yBSImFR20QZOfiADjWLXo2dpoVBc/HO5FwcFuo7PPMVfFPR7 Z1iXOCF7GNY+sFdmtwj2K4jhK0bTCy7EoQYsdnk4QJ+iYtQDqWjFAMtCvD14QjYwA5vZmAumD p3ivDsaRha8PmqF085XHT7fZwAl5OWyhgFEU+YT22LqbE5n9aQjDFde+8zzDfHnq1AXXc00+y 6M3EsX6OPow0New7ZTS24HLnbe7LcX4/VujxFr6lBb1mnnWDEQn1xsrkGuu3SfDGSi7aNK20Q bzE9+4dLGRu3763azLbop9xJMKufCqcmkbo/L8AinKostnBFMPgrkQl7tpoMG40k6PcciUIbs sU3EBHPBPg== Archived-At: Subject: Re: [dispatch] IETF108 DISPATCH Minutes X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:10:23 -0000 > On 07/31/2020 1:08 PM Timothy Mcsweeney wrote: > > > The Youtube video of this Disptach teleconference has a transcription that is really good. I would like to add one thing to the minutes from that transcription starting at roughly the 14:11 minute marker. > > * **Cullen Jennings**: so i was actually going to suggest > that in the in dispatch working group > is administratively was fine but i think > AD sponsored is fine as well > um it gives the AD a little bit more > coverage and given there's likely to be > appeals around this > having a working group consensus around > it might be a slight advantage > that's that's the only thing i would > mention From nobody Wed Nov 11 09:13:33 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FD43A1596 for ; Wed, 11 Nov 2020 09:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 X7QxUUcaJPZk for ; Wed, 11 Nov 2020 09:13:23 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB3A3A1784 for ; Wed, 11 Nov 2020 09:10:00 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1N1g7Y-1kAWsB0NEe-01225D; Wed, 11 Nov 2020 18:09:59 +0100 Date: Wed, 11 Nov 2020 12:09:58 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: DISPATCH WG Message-ID: <756478791.13382.1605114598762@email.ionos.com> In-Reply-To: <814993411.851567.1596660089989@email.ionos.com> References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> <814993411.851567.1596660089989@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:IC2bRMAVWjDpVQsSbZnlZS912ZKJgueQ0muFcvlLTKN3/vxshRJ DCujPZOku/uKYh9aiDhxJa0nAliDXzspLl/tWWIazpW1XJfVPFq2U2d8Ex26ujzaa7g95q4 9cyXC7m/DyNMC6WTbZYfCEAz+Iell7xckWH7e1NNdeVipMNwM0bSX23057iYBeHGqcESQ3M AE85xhNA/gEsZcLLQJx6Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:vq91/LQp8Rg=:d3EQu+siip8W+eBThZdKMm e8ugpGcFnrvg8v6zjJSkXZ28yjf4bHDMZLTVEAkvu9Fj7rmzjkSNtT60KQNiiyD75wumpQXs9 ey6x5IcTrmo7c3JsiirASkylMoM5Io9oi8NJ2RO9+Kzdzz5pLYdJr0YIvN7FRPiSMUZXzmXzI mDPg6qQdWBFCtAYkbqsO0Y6cCB1smypQVwsAUcBSngIf5lZeKpMctFqUA4iZa1ENoQhgQn4qO H3QJT3YJJmSAe2inWGPsIYtPCK6kQuZEQFtXP8Ql7yUVyWhTFMhuKyjYDB/JrYCImx6InsbUF CvJ3tq2/ypkyRtjdtxQ/l4NdrBrqHsKCLteW3+mDgH04pTlFD3mXhQEBaBzlvfQO3aqZsX+EC pUVi2wsmwouwZUKbdrDWTMh2y0WQ9QHIFr9NpqRa9GkoDOD41D/RXZLwOZqWtoAbO9Ljr7xLy HTWoTDbpYg== Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:13:31 -0000 > On 08/05/2020 4:41 PM Timothy Mcsweeney wrote: >=20 >=20 > Hi Ted, >=20 > In the abstract of your most recent draft.....how about using "...from Se= ctions 3 & 6..." instead of "...from the procedures..."? I wouldn't want an= yone to confuse it with the sections that use the word procedures. >=20 > Tim >=20 >=20 >=20 > > On July 9, 2020 at 4:03 PM Ted Hardie wrote:=20 > >=20 > >=20 > > On Thu, Jul 9, 2020 at 12:43 PM Timothy Mcsweeney < tim@dropnumber.com>= wrote:=20 > > > You're talking about the [ 10 (https://tools.ietf.org/html/rfc3405#re= f-10)] reference in section 3.1.1 in 3405 (https://tools.ietf.org/html/rfc3= 405#section-3.1.1) and when I click on the reference it sends me right to B= CP35 (https://tools.ietf.org/html/bcp35). > > >=20 > > > >The reason for the update is that IETF tree registrations *are* requ= ired. > > >=20 > > > That is now, scheme registration is required, including provisionals.= See, no bug. > > >=20 > > > Tim > > >=20 > > >=20 > >=20 > > Quite simply, that's not what the document says. The previous effort to= simply re-interpret it (see https://www.rfc-editor.org/errata/eid2842) was= already rejected.=20 > >=20 > > regards, > >=20 > > Ted=20 > >=20 > >=20 > >=20 > > >=20 > > >=20 > > >=20 > > > > On July 9, 2020 at 3:09 PM Ted Hardie < ted.ietf@gmail.com> wrote:= =20 > > > >=20 > > > >=20 > > > > On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < tim@dropnumber.= com> wrote:=20 > > > > > Ted, > > > > >=20 > > > > > Section 2 (Updated Requirements) of your draft says: > > > > > "All registrations in URI.ARPA MUST be for schemes which are perm= anent registrations, as they are described in BCP 35." > > > > >=20 > > > > > I take that as: > > > > > We must update this because permanent registrations are not requi= red. Otherwise there is no reason for an update. > > > >=20 > > > > The reason for the update is that IETF tree registrations *are* req= uired. That effectively closes the registry, without the community having m= ade the affirmative decision to do so. I want to fix that bug.=20 > > > >=20 > > > > I currently think that the closest replacement to the IETF tree wou= ld be permanent registration and that we should fix this by requiring that.= But I'm happy to see a clear draft espousing some other way of fixing the = bug; if you have an idea about that, please write the draft. > > > >=20 > > > > regards, > > > >=20 > > > > Ted=20 > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > >=20 > > > > > If you are going to argue both sides, my draft and I will just st= ay out of it. Here is your pointer. https://www.ietf.org/id/draft-hardie-di= spatch-rfc3405-update-01.html#section-2 > > > > >=20 > > > > > Tim > > > > >=20 > > > > >=20 > > > > > > On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com> wr= ote:=20 > > > > > >=20 > > > > > >=20 > > > > > > Howdy,=20 > > > > > >=20 > > > > > >=20 > > > > > > On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < tim@dropnumb= er.com> wrote:=20 > > > > > > > Hi Ben, > > > > > > >=20 > > > > > > > Thanks for the heads up on the deadline, > > > > > > >=20 > > > > > > > I am a little surprised that you are choosing to discuss this= at all with pending > > > > > > > registrations and I obviously disagree with that. But if ther= e are more than 5 people besides Ted that think the current rules for provi= sionals in the zone > > > > > >=20 > > > > > > I don't think I've seen anyone but you argue that the current r= ules permit provisionals in the zone; if I have missed others reading the r= ules that way, I'd appreciate a pointer. > > > > > >=20 > > > > > > I think, though, that the key thing is to get some clarity on w= hat the rules should be after the elimination of the IETF tree. Since you o= bviously disagree with my proposal, having your alternative spelled in a dr= aft does seem like the best way forward. Wherever dispatch sends the questi= on would then have two clear proposals to choose between.=20 > > > > > >=20 > > > > > > regards, > > > > > >=20 > > > > > > Ted Hardie=20 > > > > > > > are > > > > > > > too open and need to be further constrained=C2=A0then I will = submit a draft that does > > > > > > > just that before the deadline. > > > > > > >=20 > > > > > > >=20 > > > > > > > > On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com>= wrote:=20 > > > > > > > >=20 > > > > > > > > Hi Tim, > > > > > > > >=20 > > > > > > > > Do you plan to submit an internet-draft? If so, please be a= dvised that the deadline for drafts prior to IETF108 is this coming Monday = (7/13). If you submit a draft prior to the deadline, we can consider it alo= ng with Ted=E2=80=99s draft (either on the list or possibly in the IETF108 = DISPATCH meeting). > > > > > > > >=20 > > > > > > > > Thanks, > > > > > > > >=20 > > > > > > > > Ben.=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > > On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < tim@dropn= umber.com> wrote: > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > Hi All, > > > > > > > > >=20 > > > > > > > > > Updating RFC3405 will necessarily require changes to RFC3= 401 as stated in its > > > > > > > > > introduction. "This document will be updated and or obsol= eted when changes > > > > > > > > > are made to the DDDS specifications." > > > > > > > > >=20 > > > > > > > > > We are now changing two RFCs so I don't think this fits a= s a > > > > > > > > > "simple administrative". > > > > > > > > >=20 > > > > > > > > > But, I may have a work around that is simple and also sol= ves the provisional registration problem as stated by Ted. I could have rea= dy in a day or so. > > > > > > > > >=20 > > > > > > > > > Tim > > > > > > > > > > On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < due= rst@it.aoyama.ac.jp> wrote: > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > On 23/06/2020 07:51, Ben Campbell wrote: > > > > > > > > > > > Hi Everyone, > > > > > > > > > > >=20 > > > > > > > > > > > The ART ADs have reminded the chairs that our charter= allows us to adopt =E2=80=9Csimple administrative=E2=80=9D work such as IA= NA registration documents. This draft seems to fit squarely in that categor= y. Does anyone see a reason we shouldn=E2=80=99t just adopt it, with the ex= pectation of going immediately to WGLC? (The last-call timeline is the same= either way, either 2 weeks WGLC and 2 weeks IETF LC for a working group dr= aft, or 4 weeks IETF LC for an AD sponsored draft.) > > > > > > > > > >=20 > > > > > > > > > > Triggered by the recent discussion, I had a look at Ted= 's draft and the > > > > > > > > > > mail up to today. To me, both AD sponsored and Dispatch= WG look > > > > > > > > > > reasonable, with a slight preference for the former (if= asked to express > > > > > > > > > > such a preference). > > > > > > > > > >=20 > > > > > > > > > > With respect to "pending registrations", I do not think= these are > > > > > > > > > > relevant, in particular because the thing in question i= sn't actually a > > > > > > > > > > scheme, as discussed on the relevant list. > > > > > > > > > >=20 > > > > > > > > > > I have one comment: The abstract currently reads > > > > > > > > > > "This document removes references to the IETF tree of U= RI registrations > > > > > > > > > > for registrations in URI.ARPA.". I found this hard to r= ead, and I guess > > > > > > > > > > it's because of the "registrations for registrations" p= iece. Unless one > > > > > > > > > > is very familiar with the matter at hand, it's easy to = think that both > > > > > > > > > > occurrences of "registration" are referencing the same = thing. While I'm > > > > > > > > > > at it, it would also be good if the abstract mentioned = something > > > > > > > > > > positive. I think a less normative version of (the sing= le sentence that > > > > > > > > > > is) Section 2 would serve well as the abstract. > > > > > > > > > >=20 > > > > > > > > > > Regards, Martin. > > > > > > > > > >=20 > > > > > > > > > > > Thanks! > > > > > > > > > > >=20 > > > > > > > > > > > Ben (as co-chair) > > > > > > > > > > >=20 > > > > > > > > > > > > On Jun 3, 2020, at 6:13 PM, Ted Hardie < ted.ietf@g= mail..com> wrote: > > > > > > > > > > > >=20 > > > > > > > > > > > > Howdy, > > > > > > > > > > > >=20 > > > > > > > > > > > > This is one the shortest drafts I've ever written: = https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ < ht= tps://datatracker.ietf...org/doc/draft-hardie-dispatch-rfc3405-update/ (htt= ps://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc3405-update/)> .. B= asically, RFC 3405 used to require that registrations in URI.ARPA be from t= he "IETF Tree". That tree was deprecated after the document was published..= As it happens, there are very few registrations in URI.ARPA, so we did not= catch it and fix it before now. > > > > > > > > > > > >=20 > > > > > > > > > > > > This draft updates RFC 3405 to require "permanent" = scheme registrations. The salient bit is this: > > > > > > > > > > > >=20 > > > > > > > > > > > > All registrations in URI.ARPA MUST be for schemes w= hich are permanent > > > > > > > > > > > > registrations, as they are described in BCP 35. > > > > > > > > > > > >=20 > > > > > > > > > > > > I'm hoping for a quick dispatch of this, but happy = to discuss. > > > > > > > > > > > >=20 > > > > > > > > > > > > regards, > > > > > > > > > > > >=20 > > > > > > > > > > > > Ted Hardie > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > dispatch mailing list > > > > > > > > > > > > dispatch@ietf.org > > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > dispatch mailing list > > > > > > > > > > > dispatch@ietf.org > > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > > > >=20 > > > > > > > > > >=20 > > > > > > > > > > -- > > > > > > > > > > Prof. Dr.sc. Martin J. D=C3=BCrst > > > > > > > > > > Department of Intelligent Information Technology > > > > > > > > > > College of Science and Engineering > > > > > > > > > > Aoyama Gakuin University > > > > > > > > > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > > > > > > > > > 252-5258 Japan > > > > > > > > > >=20 > > > > > > > > > > _______________________________________________ > > > > > > > > > > dispatch mailing list > > > > > > > > > > dispatch@ietf.org > > > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > > > _______________________________________________=20 > > > > > > > > > dispatch mailing list=20 > > > > > > > > > dispatch@ietf.org=20 > > > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > > > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > _______________________________________________=20 > > > > > > > dispatch mailing list=20 > > > > > > > dispatch@ietf.org=20 > > > > > > > https://www.ietf.org/mailman/listinfo/dispatch=20 > > > > >=20 > > > > >=20 > > >=20 > > >=20 >=20 > From nobody Wed Nov 11 09:15:16 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67503A115D for ; Wed, 11 Nov 2020 09:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 caiMrLut44fb for ; Wed, 11 Nov 2020 09:15:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996213A1CFD for ; Wed, 11 Nov 2020 09:10:59 -0800 (PST) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0ABHAsdO045353 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 11 Nov 2020 11:10:55 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1605114656; bh=WXnt2RSeH7K1ncD9p9mh1FqzXsDYd5fZa8rrMjYJrKs=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=dXICjvKnhoVfT3sM+AhbJzpWCaB0/83hg5Xgdz7Z57ZKm6NMuAnvqYFNiqfLtuh38 FvDkjrVDcUm48KsNPPf5ebvPnHwsxuzHHM+/FqQJW3IT71O9QKJQy4X1LcrbH9uTpn InZb1m1FD9Pw9q0wlosYK1w6t80aBRzN92elO5Co= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4F2DBB38-1562-4B2D-A475-D013D7B7822C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 11 Nov 2020 11:10:48 -0600 In-Reply-To: Cc: Timothy Mcsweeney , DISPATCH WG To: Eric Rescorla References: <85664807-701C-4700-ABB7-D0434F14D6A0@nostrum.com> <1580898449.190942.1594130597348@email.ionos.com> <3A1C3068-717D-4822-A110-9F91272B04CB@nostrum.com> <2116535970.9156.1594304410818@email.ionos.com> <1777741348.21431.1594315737558@email.ionos.com> <166222013.29010.1594323818783@email.ionos.com> <630535283.101560.1594647207701@email.ionos.com> <1428362467.12567.1605113492259@email.ionos.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dispatch] Tiny update to RFC 3405 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:15:15 -0000 --Apple-Mail=_4F2DBB38-1562-4B2D-A475-D013D7B7822C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not sure, but I think something just resent a big dump of = old emails from Timothy. > On Nov 11, 2020, at 10:55 AM, Eric Rescorla wrote: >=20 > Timothy, >=20 > You have sent quite a few messages to this list on this topic in the = past hour. However, this draft has already been approved by the IESG and = is in the RFC Editor queue, so further discussion on this topic on = dispatch is not really productive. What are you trying to achieve? >=20 > -Ekr >=20 >=20 > On Wed, Nov 11, 2020 at 8:52 AM Timothy Mcsweeney > wrote: > text version: > Martin,=20 >=20 > >The current BCP 35 doesn't contain such requirements, and > >therefore doesn't make any sense. >=20 > That's right, BCP doesn't contain such requirements. > Whether or not makes sense to you is immaterial. > Thank you for helping me state my case. >=20 > Tim >=20 >=20 > > On 07/13/2020 9:33 AM Timothy Mcsweeney > wrote: > >=20 > >=20 > > Martin, > >=20 > > >The current BCP 35 doesn't contain such requirements, and=20 > > >therefore doesn't make any sense. > >=20 > > That's right, BCP doesn't contain such requirements. > > Whether or not makes sense to you is immaterial. > > Thank you for helping me state my case. > >=20 > > Tim > >=20 > >=20 > >=20 > >=20 > >=20 > > > On July 12, 2020 at 7:43 AM "Martin J. D=C3=BCrst" < = duerst@it.aoyama.ac.jp > wrote: > > >=20 > > >=20 > > > On 10/07/2020 04:43, Timothy Mcsweeney wrote: > > > > You're talking about the [ 10 < ]" rel=3D"noopener" = target=3D"_blank" = data-mce-href=3D"https://tools.ietf.org/html/rfc3405#ref-10 = >]">https://tools.ietf.org/htm= l/rfc3405#ref-10 >] = (https://tools.ietf.org/html/rfc3405#ref-10 = ) > > > > reference in section 3.1.1 in 3405 > > > > < https://tools.ietf.org/html/rfc3405#section-3.1.1 = > and when I click on = the > > > > reference it sends me right to BCP35 < " rel=3D"noopener" = target=3D"_blank" data-mce-href=3D"https://tools.ietf.org/html/bcp35 = >">https://tools.ietf.org/html/bcp35 = > (https://tools.ietf.org/html/bcp35 = ). > > > When I look at > > >=20 > > > >>>> > > > [10] Petke, R. and I. King, "Registration Procedures for URL = Scheme > > > Names", BCP 35, RFC 2717, January 1999. > > > >>>> > > > it has two links, one for BCP 35 (which now redirects to something = else > > > which doesn't actually match the reference data) and one for RFC = 2717 > > > (which matches the original reference, including author and date = of > > > publication). > > >=20 > > > RFC 2717 then says: > > >=20 > > > >>>> > > > 2.2 The IETF Tree > > >=20 > > > The IETF tree is intended for URL schemes of general interest to = the > > > Internet community. The tree exists for URL schemes that require a > > > substantive review and approval process. It is expected that > > > applicability statements for particular applications will be > > > published from time to time that recommend implementation of, and > > > support for, URL schemes that have proven particularly useful in > > > those contexts. > > > >>>> > > >=20 > > > > >The reason for the update is that IETF tree registrations *are* = required. > > > Yes, and the closest to that ("URL schemes of general interest to = the > > > Internet community", "require a substantive review and approval > > > process") we currently have is permanent registration, so that's = where > > > Ted's proposal (which I fully support) comes from. > > >=20 > > > > That is now, scheme registration is required, including = provisionals. See, no bug. > > > No. That there's a link somewhere doesn't mean you can interpret = things > > > any which way. The reference you follow (in one specific way) = comes from > > >=20 > > > >>>> > > > 3.1.1 Only Schemes in the IETF Tree Allowed > > >=20 > > > In order to be inserted into the URI.ARPA zone, the subsequent URI > > > scheme MUST be registered under the IETF URI tree. The = requirements > > > for this tree are specified in [10]. > > > >>>> > > >=20 > > > This means that the reference is for defining the requirements of = the > > > IETF URI tree. The current BCP 35 doesn't contain such = requirements, and > > > therefore doesn't make any sense. The old BCP 35 (RFC 2717) is = clear, > > > but is no longer in force. As a consequence, we have a dangling > > > reference (IETF Tree is no longer defined in a valid IETF spec). = We > > > cannot just say "let's assume this means whatever suits me best" = or "by > > > chance there's a link (out of two) that leads to a spec that = includes > > > something that suits me", but we have to recognize that we have a > > > problem with the spec (when updating BCP 35, its authors forgot to > > > update RFC 3405), and have to fix that. > > >=20 > > > And the fix that Ted is proposing is the fix that is closest to = the > > > original intent, and takes into account the reason for the = original > > > restriction. > > >=20 > > > Regards, Martin. > > >=20 > > >=20 > > > > Tim > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > > On July 9, 2020 at 3:09 PM Ted Hardie < ted.ietf@gmail.com = > wrote: > > > >> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney < = tim@dropnumber.com > > > >> >> = wrote: > > > >> > > > >> __ > > > >> Ted, > > > >> > > > >> Section 2 (Updated Requirements) of your draft says: > > > >> "All registrations in URI.ARPA MUST be for schemes which are = permanent > > > >> registrations, as they are described in BCP 35." > > > >> > > > >> I take that as: > > > >> We must update this because permanent registrations are not = required. > > > >> Otherwise there is no reason for an update. > > > >> > > > >> > > > >> The reason for the update is that IETF tree registrations *are* = required. > > > >> That effectively closes the registry, without the community = having made the > > > >> affirmative decision to do so. I want to fix that bug. > > > >> > > > >> I currently think that the closest replacement to the IETF tree = would be > > > >> permanent registration and that we should fix this by requiring = that. But I'm > > > >> happy to see a clear draft espousing some other way of fixing = the bug; if you > > > >> have an idea about that, please write the draft. > > > >> > > > >> regards, > > > >> > > > >> Ted > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> If you are going to argue both sides, my draft and I will just = stay out of > > > >> it. Here is your pointer. > > > >> https://www.ietf. = .org/id/draft-hardie-dispatch-rfc3405-update-01.html#s= ection-2 > > > >> < = https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01.html#secti= on-2 = > > > > >> > > > >> > > > >> Tim > > > >> > > > >> > > > >>> On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com = > > > >>> >> = wrote: > > > >>> > > > >>> Howdy, > > > >>> > > > >>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney < = tim@dropnumber.com > > > >>> >> = wrote: > > > >>> > > > >>> __ > > > >>> Hi Ben, > > > >>> > > > >>> Thanks for the heads up on the deadline, > > > >>> > > > >>> I am a little surprised that you are choosing to discuss this = at all > > > >>> with pending > > > >>> registrations and I obviously disagree with that. But if there = are > > > >>> more than 5 people besides Ted that think the current rules = for > > > >>> provisionals in the zone > > > >>> > > > >>> > > > >>> I don't think I've seen anyone but you argue that the current = rules > > > >>> permit provisionals in the zone; if I have missed others = reading the > > > >>> rules that way, I'd appreciate a pointer. > > > >>> > > > >>> I think, though, that the key thing is to get some clarity on = what the > > > >>> rules should be after the elimination of the IETF tree. Since = you > > > >>> obviously disagree with my proposal, having your alternative = spelled in a > > > >>> draft does seem like the best way forward. Wherever dispatch = sends the > > > >>> question would then have two clear proposals to choose = between. > > > >>> > > > >>> regards, > > > >>> > > > >>> Ted Hardie > > > >>> > > > >>> are > > > >>> too open and need to be further constrained then I will submit = a > > > >>> draft that does > > > >>> just that before the deadline. > > > >>> > > > >>> > > > >>>> On July 8, 2020 at 10:36 PM Ben Campbell < ben@nostrum.com = > > > >>>> >> wrote: > > > >>>> > > > >>>> Hi Tim, > > > >>>> > > > >>>> Do you plan to submit an internet-draft? If so, please be = advised > > > >>>> that the deadline for drafts prior to IETF108 is this coming = Monday > > > >>>> (7/13). If you submit a draft prior to the deadline, we can = consider > > > >>>> it along with Ted=E2=80=99s draft (either on the list or = possibly in the > > > >>>> IETF108 DISPATCH meeting). > > > >>>> > > > >>>> Thanks, > > > >>>> > > > >>>> Ben. > > > >>>> > > > >>>>> On Jul 7, 2020, at 9:03 AM, Timothy Mcsweeney < = tim@dropnumber.com > > > >>>>> >> = wrote: > > > >>>>> > > > >>>>> Hi All, > > > >>>>> > > > >>>>> Updating RFC3405 will necessarily require changes to RFC3401 = as > > > >>>>> stated in its > > > >>>>> introduction. "This document will be updated and or = obsoleted when > > > >>>>> changes > > > >>>>> are made to the DDDS specifications." > > > >>>>> > > > >>>>> We are now changing two RFCs so I don't think this fits as a > > > >>>>> "simple administrative". > > > >>>>> > > > >>>>> But, I may have a work around that is simple and also solves = the > > > >>>>> provisional registration problem as stated by Ted. I could = have > > > >>>>> ready in a day or so. > > > >>>>> > > > >>>>> Tim > > > >>>>>> On July 7, 2020 at 3:34 AM "Martin J. D=C3=BCrst" < > > > >>>>>> duerst@it.aoyama.ac.jp = > wrote: > > > >>>>>> > > > >>>>>> > > > >>>>>> On 23/06/2020 07:51, Ben Campbell wrote: > > > >>>>>>> Hi Everyone, > > > >>>>>>> > > > >>>>>>> The ART ADs have reminded the chairs that our charter = allows us > > > >>>>>>> to adopt =E2=80=9Csimple administrative=E2=80=9D work such = as IANA registration > > > >>>>>>> documents. This draft seems to fit squarely in that = category.. > > > >>>>>>> Does anyone see a reason we shouldn=E2=80=99t just adopt = it, with the > > > >>>>>>> expectation of going immediately to WGLC? (The last-call = timeline > > > >>>>>>> is the same either way, either 2 weeks WGLC and 2 weeks = IETF LC > > > >>>>>>> for a working group draft, or 4 weeks IETF LC for an AD = sponsored > > > >>>>>>> draft.) > > > >>>>>> > > > >>>>>> Triggered by the recent discussion, I had a look at Ted's = draft > > > >>>>>> and the > > > >>>>>> mail up to today. To me, both AD sponsored and Dispatch WG = look > > > >>>>>> reasonable, with a slight preference for the former (if = asked to > > > >>>>>> express > > > >>>>>> such a preference). > > > >>>>>> > > > >>>>>> With respect to "pending registrations", I do not think = these are > > > >>>>>> relevant, in particular because the thing in question isn't > > > >>>>>> actually a > > > >>>>>> scheme, as discussed on the relevant list. > > > >>>>>> > > > >>>>>> I have one comment: The abstract currently reads > > > >>>>>> "This document removes references to the IETF tree of URI > > > >>>>>> registrations > > > >>>>>> for registrations in URI.ARPA.". I found this hard to read, = and I > > > >>>>>> guess > > > >>>>>> it's because of the "registrations for registrations" = piece. > > > >>>>>> Unless one > > > >>>>>> is very familiar with the matter at hand, it's easy to = think that > > > >>>>>> both > > > >>>>>> occurrences of "registration" are referencing the same = thing. > > > >>>>>> While I'm > > > >>>>>> at it, it would also be good if the abstract mentioned = something > > > >>>>>> positive. I think a less normative version of (the single = sentence > > > >>>>>> that > > > >>>>>> is) Section 2 would serve well as the abstract. > > > >>>>>> > > > >>>>>> Regards, Martin. > > > >>>>>> > > > >>>>>>> Thanks! > > > >>>>>>> > > > >>>>>>> Ben (as co-chair) > > > >>>>>>> > > > >>>>>>>> On Jun 3, 2020, at 6:13 PM, Ted Hardie < = ted.ietf@gmail..com > > > >>>>>>>> >> = wrote: > > > >>>>>>>> > > > >>>>>>>> Howdy, > > > >>>>>>>> > > > >>>>>>>> This is one the shortest drafts I've ever written: > > > >>>>>>>> = https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ = > > > >>>>>>>> < https://datatracker.ietf. = .org/doc/draft-hardie-dispatch-rfc3405-update/= > > > > >>>>>>>> < > > > >>>>>>>> https://datatracker.ietf. = ..org/doc/draft-hardie-dispatch-rfc3405-update= /> > > > >>>>>>>> .. Basically, RFC 3405 used to require that registrations = in > > > >>>>>>>> URI.ARPA be from the "IETF Tree". That tree was = deprecated after > > > >>>>>>>> the document was published... As it happens, there are = very few > > > >>>>>>>> registrations in URI.ARPA, so we did not catch it and fix = it > > > >>>>>>>> before now. > > > >>>>>>>> > > > >>>>>>>> This draft updates RFC 3405 to require "permanent" scheme > > > >>>>>>>> registrations. The salient bit is this: > > > >>>>>>>> > > > >>>>>>>> All registrations in URI.ARPA MUST be for schemes which = are > > > >>>>>>>> permanent > > > >>>>>>>> registrations, as they are described in BCP 35. > > > >>>>>>>> > > > >>>>>>>> I'm hoping for a quick dispatch of this, but happy to = discuss. > > > >>>>>>>> > > > >>>>>>>> regards, > > > >>>>>>>> > > > >>>>>>>> Ted Hardie > > > >>>>>>>> _______________________________________________ > > > >>>>>>>> dispatch mailing list > > > >>>>>>>> dispatch@ietf.org > > > > >>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch = > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> _______________________________________________ > > > >>>>>>> dispatch mailing list > > > >>>>>>> dispatch@ietf.org > > > > >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch = > > > >>>>>>> > > > >>>>>> > > > >>>>>> -- > > > >>>>>> Prof. Dr.sc. Martin J. D=C3=BCrst > > > >>>>>> Department of Intelligent Information Technology > > > >>>>>> College of Science and Engineering > > > >>>>>> Aoyama Gakuin University > > > >>>>>> Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > > >>>>>> 252-5258 Japan > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> dispatch mailing list > > > >>>>>> dispatch@ietf.org > > > > >>>>>> https://www.ietf.org/mailman/listinfo/dispatch = > > > >>>>> _______________________________________________ > > > >>>>> dispatch mailing list > > > >>>>> dispatch@ietf.org > > > > >>>>> https://www.ietf.org/mailman/listinfo/dispatch = > > > >>>> > > > >>> > > > >>> _______________________________________________ > > > >>> dispatch mailing list > > > >>> dispatch@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/dispatch = > > > >>> > > > >> > > > >=20 > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch = > > > >=20 > > > -- > > > Prof. Dr.sc. Martin J. D=C3=BCrst > > > Department of Intelligent Information Technology > > > College of Science and Engineering > > > Aoyama Gakuin University > > > Fuchinobe 5-1-10, Chuo-ku, Sagamihara > > > 252-5258 Japan >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_4F2DBB38-1562-4B2D-A475-D013D7B7822C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m not sure, but I think something just resent a big dump of old = emails from Timothy.

On Nov 11, 2020, at 10:55 AM, = Eric Rescorla <ekr@rtfm.com> wrote:

Timothy,

You have sent quite a few messages to = this list on this topic in the past hour. However, this draft has = already been approved by the IESG and is in the RFC Editor queue, so = further discussion on this topic on dispatch is not really productive. = What are you trying to achieve?

-Ekr


On Wed, Nov 11, 2020 at 8:52 AM Timothy = Mcsweeney <tim@dropnumber.com> wrote:
text version:
Martin,

>The current BCP 35 doesn't contain such requirements, and
>therefore doesn't make any sense.

That's right, BCP doesn't contain such requirements.
Whether or not makes sense to you is immaterial.
Thank you for helping me state my case.

Tim


> On 07/13/2020 9:33 AM Timothy Mcsweeney <tim@dropnumber.com> wrote:
>
>
> Martin,
>
> >The current BCP 35 doesn't contain such requirements, and
> >therefore doesn't make any sense.
>
> That's right, BCP doesn't contain such requirements.
> Whether or not makes sense to you is immaterial.
> Thank you for helping me state my case.
>
> Tim
>
>
>
>
>
> > On July 12, 2020 at 7:43 AM "Martin J. D=C3=BCrst" < duerst@it.aoyama.ac.jp> wrote:
> >
> >
> > On 10/07/2020 04:43, Timothy Mcsweeney wrote:
> > > You're talking about the [ 10 < ]" rel=3D"noopener" = target=3D"_blank" data-mce-href=3D"https://tools.ietf.org/html/rfc3405#ref-10>]">https://tools.ietf.org/html/rfc3405#ref-10>] (https://tools.ietf.org/html/rfc3405#ref-10)
> > > reference in section 3.1.1 in 3405
> > > < https://tools.ietf.org/html/rfc3405#section-3.1.1> and = when I click on the
> > > reference it sends me right to BCP35 < " = rel=3D"noopener" target=3D"_blank" data-mce-href=3D"https://tools.ietf.org/html/bcp35>">https://tools.ietf.org/html/bcp35> = (https://tools.ietf.org/html/bcp35).
> > When I look at
> >
> > >>>>
> > [10] Petke, R. and I. King, "Registration Procedures for URL = Scheme
> > Names", BCP 35, RFC 2717, January 1999.
> > >>>>
> > it has two links, one for BCP 35 (which now redirects to = something else
> > which doesn't actually match the reference data) and one for = RFC 2717
> > (which matches the original reference, including author and = date of
> > publication).
> >
> > RFC 2717 then says:
> >
> > >>>>
> > 2.2 The IETF Tree
> >
> > The IETF tree is intended for URL schemes of general interest = to the
> > Internet community. The tree exists for URL schemes that = require a
> > substantive review and approval process. It is expected = that
> > applicability statements for particular applications will = be
> > published from time to time that recommend implementation of, = and
> > support for, URL schemes that have proven particularly useful = in
> > those contexts.
> > >>>>
> >
> > > >The reason for the update is that IETF tree = registrations *are* required.
> > Yes, and the closest to that ("URL schemes of general interest = to the
> > Internet community", "require a substantive review and = approval
> > process") we currently have is permanent registration, so = that's where
> > Ted's proposal (which I fully support) comes from.
> >
> > > That is now, scheme registration is required, including = provisionals. See, no bug.
> > No. That there's a link somewhere doesn't mean you can = interpret things
> > any which way. The reference you follow (in one specific way) = comes from
> >
> > >>>>
> > 3.1.1 Only Schemes in the IETF Tree Allowed
> >
> > In order to be inserted into the URI.ARPA zone, the subsequent = URI
> > scheme MUST be registered under the IETF URI tree. The = requirements
> > for this tree are specified in [10].
> > >>>>
> >
> > This means that the reference is for defining the requirements = of the
> > IETF URI tree. The current BCP 35 doesn't contain such = requirements, and
> > therefore doesn't make any sense. The old BCP 35 (RFC 2717) is = clear,
> > but is no longer in force. As a consequence, we have a = dangling
> > reference (IETF Tree is no longer defined in a valid IETF = spec). We
> > cannot just say "let's assume this means whatever suits me = best" or "by
> > chance there's a link (out of two) that leads to a spec that = includes
> > something that suits me", but we have to recognize that we = have a
> > problem with the spec (when updating BCP 35, its authors = forgot to
> > update RFC 3405), and have to fix that.
> >
> > And the fix that Ted is proposing is the fix that is closest = to the
> > original intent, and takes into account the reason for the = original
> > restriction.
> >
> > Regards, Martin.
> >
> >
> > > Tim
> > >
> > >
> > >
> > >
> > > > On July 9, 2020 at 3:09 PM Ted Hardie < ted.ietf@gmail.com> wrote:
> > >> On Thu, Jul 9, 2020 at 10:28 AM Timothy Mcsweeney = < tim@dropnumber.com
> > >> <mailto: tim@dropnumber.com>> wrote:
> > >>
> > >> __
> > >> Ted,
> > >>
> > >> Section 2 (Updated Requirements) of your draft = says:
> > >> "All registrations in URI.ARPA MUST be for schemes = which are permanent
> > >> registrations, as they are described in BCP 35."
> > >>
> > >> I take that as:
> > >> We must update this because permanent registrations = are not required.
> > >> Otherwise there is no reason for an update.
> > >>
> > >>
> > >> The reason for the update is that IETF tree = registrations *are* required.
> > >> That effectively closes the registry, without the = community having made the
> > >> affirmative decision to do so. I want to fix that = bug.
> > >>
> > >> I currently think that the closest replacement to the = IETF tree would be
> > >> permanent registration and that we should fix this by = requiring that. But I'm
> > >> happy to see a clear draft espousing some other way = of fixing the bug; if you
> > >> have an idea about that, please write the draft.
> > >>
> > >> regards,
> > >>
> > >> Ted
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> If you are going to argue both sides, my draft and I = will just stay out of
> > >> it. Here is your pointer.
> > >> https://www.ietf..org/id/draft-hardie-dispatch-rfc3405-upda= te-01.html#section-2
> > >> < https://www.ietf.org/id/draft-hardie-dispatch-rfc3405-update-01= .html#section-2>
> > >>
> > >>
> > >> Tim
> > >>
> > >>
> > >>> On July 9, 2020 at 11:57 AM Ted Hardie < ted.ietf@gmail.com
> > >>> <mailto: ted.ietf@gmail.com>> wrote:
> > >>>
> > >>> Howdy,
> > >>>
> > >>> On Thu, Jul 9, 2020 at 7:20 AM Timothy Mcsweeney = < tim@dropnumber.com
> > >>> <mailto: tim@dropnumber.com>> wrote:
> > >>>
> > >>> __
> > >>> Hi Ben,
> > >>>
> > >>> Thanks for the heads up on the deadline,
> > >>>
> > >>> I am a little surprised that you are choosing to = discuss this at all
> > >>> with pending
> > >>> registrations and I obviously disagree with that. = But if there are
> > >>> more than 5 people besides Ted that think the = current rules for
> > >>> provisionals in the zone
> > >>>
> > >>>
> > >>> I don't think I've seen anyone but you argue that = the current rules
> > >>> permit provisionals in the zone; if I have missed = others reading the
> > >>> rules that way, I'd appreciate a pointer.
> > >>>
> > >>> I think, though, that the key thing is to get = some clarity on what the
> > >>> rules should be after the elimination of the IETF = tree. Since you
> > >>> obviously disagree with my proposal, having your = alternative spelled in a
> > >>> draft does seem like the best way forward. = Wherever dispatch sends the
> > >>> question would then have two clear proposals to = choose between.
> > >>>
> > >>> regards,
> > >>>
> > >>> Ted Hardie
> > >>>
> > >>> are
> > >>> too open and need to be further constrained then = I will submit a
> > >>> draft that does
> > >>> just that before the deadline.
> > >>>
> > >>>
> > >>>> On July 8, 2020 at 10:36 PM Ben Campbell < = ben@nostrum.com
> > >>>> <mailto: ben@nostrum.com>> wrote:
> > >>>>
> > >>>> Hi Tim,
> > >>>>
> > >>>> Do you plan to submit an internet-draft? If = so, please be advised
> > >>>> that the deadline for drafts prior to IETF108 = is this coming Monday
> > >>>> (7/13). If you submit a draft prior to the = deadline, we can consider
> > >>>> it along with Ted=E2=80=99s draft (either on = the list or possibly in the
> > >>>> IETF108 DISPATCH meeting).
> > >>>>
> > >>>> Thanks,
> > >>>>
> > >>>> Ben.
> > >>>>
> > >>>>> On Jul 7, 2020, at 9:03 AM, Timothy = Mcsweeney < tim@dropnumber.com
> > >>>>> <mailto: tim@dropnumber.com>> wrote:
> > >>>>>
> > >>>>> Hi All,
> > >>>>>
> > >>>>> Updating RFC3405 will necessarily require = changes to RFC3401 as
> > >>>>> stated in its
> > >>>>> introduction. "This document will be = updated and or obsoleted when
> > >>>>> changes
> > >>>>> are made to the DDDS specifications."
> > >>>>>
> > >>>>> We are now changing two RFCs so I don't = think this fits as a
> > >>>>> "simple administrative".
> > >>>>>
> > >>>>> But, I may have a work around that is = simple and also solves the
> > >>>>> provisional registration problem as = stated by Ted. I could have
> > >>>>> ready in a day or so.
> > >>>>>
> > >>>>> Tim
> > >>>>>> On July 7, 2020 at 3:34 AM "Martin J. = D=C3=BCrst" <
> > >>>>>> duerst@it.aoyama.ac.jp <mailto: duerst@it.aoyama.ac..jp>> wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>> On 23/06/2020 07:51, Ben Campbell = wrote:
> > >>>>>>> Hi Everyone,
> > >>>>>>>
> > >>>>>>> The ART ADs have reminded the = chairs that our charter allows us
> > >>>>>>> to adopt =E2=80=9Csimple = administrative=E2=80=9D work such as IANA registration
> > >>>>>>> documents. This draft seems to = fit squarely in that category..
> > >>>>>>> Does anyone see a reason we = shouldn=E2=80=99t just adopt it, with the
> > >>>>>>> expectation of going immediately = to WGLC? (The last-call timeline
> > >>>>>>> is the same either way, either 2 = weeks WGLC and 2 weeks IETF LC
> > >>>>>>> for a working group draft, or 4 = weeks IETF LC for an AD sponsored
> > >>>>>>> draft.)
> > >>>>>>
> > >>>>>> Triggered by the recent discussion, I = had a look at Ted's draft
> > >>>>>> and the
> > >>>>>> mail up to today. To me, both AD = sponsored and Dispatch WG look
> > >>>>>> reasonable, with a slight preference = for the former (if asked to
> > >>>>>> express
> > >>>>>> such a preference).
> > >>>>>>
> > >>>>>> With respect to "pending = registrations", I do not think these are
> > >>>>>> relevant, in particular because the = thing in question isn't
> > >>>>>> actually a
> > >>>>>> scheme, as discussed on the relevant = list.
> > >>>>>>
> > >>>>>> I have one comment: The abstract = currently reads
> > >>>>>> "This document removes references to = the IETF tree of URI
> > >>>>>> registrations
> > >>>>>> for registrations in URI.ARPA.". I = found this hard to read, and I
> > >>>>>> guess
> > >>>>>> it's because of the "registrations = for registrations" piece.
> > >>>>>> Unless one
> > >>>>>> is very familiar with the matter at = hand, it's easy to think that
> > >>>>>> both
> > >>>>>> occurrences of "registration" are = referencing the same thing.
> > >>>>>> While I'm
> > >>>>>> at it, it would also be good if the = abstract mentioned something
> > >>>>>> positive. I think a less normative = version of (the single sentence
> > >>>>>> that
> > >>>>>> is) Section 2 would serve well as the = abstract.
> > >>>>>>
> > >>>>>> Regards, Martin.
> > >>>>>>
> > >>>>>>> Thanks!
> > >>>>>>>
> > >>>>>>> Ben (as co-chair)
> > >>>>>>>
> > >>>>>>>> On Jun 3, 2020, at 6:13 PM, = Ted Hardie < ted.ietf@gmail..com
> > >>>>>>>> <mailto: ted.ietf@gmail.com>> wrote:
> > >>>>>>>>
> > >>>>>>>> Howdy,
> > >>>>>>>>
> > >>>>>>>> This is one the shortest = drafts I've ever written:
> > >>>>>>>> https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-= update/
> > >>>>>>>> < https://datatracker.ietf..org/doc/draft-hardie-dispatch-rfc= 3405-update/>
> > >>>>>>>> <
> > >>>>>>>> https://datatracker.ietf...org/doc/draft-hardie-dispatch-rf= c3405-update/>
> > >>>>>>>> .. Basically, RFC 3405 used = to require that registrations in
> > >>>>>>>> URI.ARPA be from the "IETF = Tree". That tree was deprecated after
> > >>>>>>>> the document was published... = As it happens, there are very few
> > >>>>>>>> registrations in URI.ARPA, so = we did not catch it and fix it
> > >>>>>>>> before now.
> > >>>>>>>>
> > >>>>>>>> This draft updates RFC 3405 = to require "permanent" scheme
> > >>>>>>>> registrations. The salient = bit is this:
> > >>>>>>>>
> > >>>>>>>> All registrations in URI.ARPA = MUST be for schemes which are
> > >>>>>>>> permanent
> > >>>>>>>> registrations, as they are = described in BCP 35.
> > >>>>>>>>
> > >>>>>>>> I'm hoping for a quick = dispatch of this, but happy to discuss.
> > >>>>>>>>
> > >>>>>>>> regards,
> > >>>>>>>>
> > >>>>>>>> Ted Hardie
> > >>>>>>>> = _______________________________________________
> > >>>>>>>> dispatch mailing list
> > >>>>>>>> dispatch@ietf.org <mailto: dispatch@ietf.org>
> > >>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> = _______________________________________________
> > >>>>>>> dispatch mailing list
> > >>>>>>> dispatch@ietf.org <mailto: dispatch@ietf.org>
> > >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch
> > >>>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Prof. Dr.sc. Martin J. D=C3=BCrst
> > >>>>>> Department of Intelligent Information = Technology
> > >>>>>> College of Science and Engineering
> > >>>>>> Aoyama Gakuin University
= > > >>>>>> Fuchinobe 5-1-10, Chuo-ku, = Sagamihara
> > >>>>>> 252-5258 Japan
> > >>>>>>
> > >>>>>> = _______________________________________________
> > >>>>>> dispatch mailing list
> > >>>>>> dispatch@ietf.org <mailto: dispatch@ietf.org>
> > >>>>>> https://www.ietf.org/mailman/listinfo/dispatch
> > >>>>> = _______________________________________________
> > >>>>> dispatch mailing list
> > >>>>> dispatch@ietf.org <mailto: dispatch@ietf.org>
> > >>>>> https://www.ietf.org/mailman/listinfo/dispatch
> > >>>>
> > >>>
> > >>> = _______________________________________________
> > >>> dispatch mailing list
> > >>> dispatch@ietf.org <mailto: dispatch@ietf.org>
> > >>> https://www.ietf.org/mailman/listinfo/dispatch
> > >>>
> > >>
> > >
> > > _______________________________________________
> > > dispatch mailing list
> > > dispatch@ietf.org
> > > https://www.ietf.org/mailman/listinfo/dispatch
> > >
> > --
> > Prof. Dr.sc. Martin J. D=C3=BCrst
> > Department of Intelligent Information Technology
> > College of Science and Engineering
> > Aoyama Gakuin University
> > Fuchinobe 5-1-10, Chuo-ku, Sagamihara
> > 252-5258 Japan

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch = mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_4F2DBB38-1562-4B2D-A475-D013D7B7822C-- From nobody Wed Nov 11 09:22:30 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6A0F53A2B5C; Wed, 11 Nov 2020 09:22:16 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8253A13B0; Wed, 11 Nov 2020 09:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Kv9ohRr1PFYo; Wed, 11 Nov 2020 09:22:10 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7746B3A122C; Wed, 11 Nov 2020 09:16:08 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0M2bMR-1kKg3H3HyH-00sMtX; Wed, 11 Nov 2020 18:16:06 +0100 Date: Wed, 11 Nov 2020 12:16:06 -0500 (EST) From: Timothy Mcsweeney To: Brian Carpenter , Brian Carpenter via Datatracker , gen-art@ietf.org Cc: draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org Message-ID: <1924891844.13667.1605114966318@email.ionos.com> In-Reply-To: <1066090379.166058.1598958286518@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:U9Fqzk0XWJRq3W2Epv2+WTsmH3Lk/PFT7e/z0j/4eVN/YCulVl+ 1OjUE2gla1jQsM5MbsgaRF7ggAvTrqgBW/kbpash1qy/ywUKaRMfCNJWrATHa5MN1DTkXGW XTwXF3YGDHNLt+sicvzN2J7Y7A1DBfRvoO/Yywkab+sFciAnAipX8CmEAVyAqEWyD5hcUEY iBxH/Kn/h7tnGqpTtoFGQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:q8C+QGEz5bQ=:3jxPvPjAv3p2nW0JxAIs6b Kt06jU2GsUW5miolYkNZ/UwEGxiraumjhEQUQQCJz8+cBZCsAB75eMUVOYxlXV+1inos2E5Rt a/ZC2hN5nGULdvC1qTn+39btLwsCUFUsjTvs8Y37BSlBzS6wTLkEQ6H0XxhsN96BI+X3SYQa2 IF1PAXI9tP4+wSgYizCa4uCxcehiDkjIzHwZ/zIk7C9FgUCa+0bTz+ELP/qEPCd+WanLdM2st C73gzk6S6FaAhXTRYsGRcP5nzhKIZLMEBpXffSGqgCDha+ZFjltHM97LzwhEEo5/bPPldUMd4 +xyq6tIHC4ukq8wrE+sEuPCEOKtZDbLvxpYyuY3VurltAR/gD6I0Crhc4/xCcaSNkS15Swvk7 sxt4r4Vw5Viv9AXLIXx7IUURqY/3m3Mg5IJvRqNQkhWC5tL1S6qe34cHOS2HFBqov3TjXgGt/ BIEs4p2vXg== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172216.6A0F53A2B5C@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:22:16 -0800 (PST) Archived-At: Subject: Re: [dispatch] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:22:22 -0000 > On 09/01/2020 7:04 AM Timothy Mcsweeney wrote: > > > Hello, > > According to BCP26/RFC8126 section 5.3 Designated expert reviews, it says:" > When a designated expert is used, the documentation should give clear > guidance to the designated expert, laying out criteria for performing > an evaluation and reasons for rejecting a request. > I don't see the above in this document. This is going to have to be added to have any kind of validity or the IESG should reject to publication of this document. Especially because this entire document will updating the IANA considerations section of rfc3405. > > Tim > > > On 08/31/2020 11:23 PM Brian Carpenter via Datatracker wrote: > > > > > > Reviewer: Brian Carpenter > > Review result: Ready > > > > Gen-ART Last Call review of draft-hardie-dispatch-rfc3405-update-03 > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > . > > > > Document: draft-hardie-dispatch-rfc3405-update-03 > > Reviewer: Brian Carpenter > > Review Date: 2020-09-01 > > IETF LC End Date: 2020-09-24 > > IESG Telechat date: > > > > Summary: Ready (with micro-nit) > > -------- > > > > Nits: > > ----- > > > > > 1. Introduction > > > Part five of the Dynamic Delegation Discovery System (DDDS), RFC 3405 > > > [RFC3405], describes the registration procedures for assignments in > > > URI.ARPA. The document requires that registrations be in the "IETF > > > tree" of URI registrations. The use of URI scheme name trees was > > > defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395]. > > > Since the use of trees was discontinued, there is no way in the > > > current process set out in BCP 35 [RFC7595] to meet the requirement. > > This is indeed a nit, but I'd prefer s/the requirement/the above requirement/. > > The current text did make me briefly think "Which requirement?". > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Nov 11 09:22:33 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 71E1B3A2B6C; Wed, 11 Nov 2020 09:22:18 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608203A2B48; Wed, 11 Nov 2020 09:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 6vmowQ_51rQl; Wed, 11 Nov 2020 09:22:12 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0523A1265; Wed, 11 Nov 2020 09:16:39 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MdsFf-1kvuYK2F0n-00PhFU; Wed, 11 Nov 2020 18:16:37 +0100 Date: Wed, 11 Nov 2020 12:16:37 -0500 (EST) From: Timothy Mcsweeney To: Barry Leiba Cc: Brian Carpenter , draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org, "gen-art@ietf.org" Message-ID: <728878046.13697.1605114997046@email.ionos.com> In-Reply-To: <674529702.175704.1598975928192@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:HtJ70j4qwKzkWDaJll5QP5IKrZxeDWLT4JNpX+vmnn5427VuvWx 46qbTIPUaTMwCVquBeCPehhx4O3LqHo2FX8UHx+i+Fpc19E7e06clZ/6KCMwG/Xw04v+UwG 3ZCQwBQh9CvyGnwLNVjuVjQiCDE6kFkWNmThB3M3bYm9Q2LO1n6f5NIxJJeHthy/ri+E/AM KvXkg6WrvEiO7Rp1Uf0eg== X-UI-Out-Filterresults: notjunk:1;V03:K0:/2xQRpO0eYs=:yO0t5Ym3F4Hs7pO9F1NQxf D9SMCQCkxNVyPoEEJR4pAXRATCT93DoVbQRt44zgw6JiM5Qg8Eyeg8kvCZ00i5xNczJuPXVWz CkAWFxA5weCXr0fLA3xCrvrwK+ypmpPYuSpPioKyL7AXtHxmmpUo4QV1qPhFhfijuXgFKHeaS FY8tEgI/SqdVvUVQ9ZnJd9iLRIAgFurICenm6mQyJLlFygZ/ayzpG5c1q063eCK3GL7yBNkp7 JHa4Wbc/QHVzMouKoftxSHOaK8qy3wQxgsKJzt5Y8K5ecxHSG5iw+Yf51IhTLbORJq7IZ1Pua s5Dr+HuWm8pDrT3fd1S8RogkGm8Ae7zjRRKAYazhFrt31teqGKHsArnQ1kmKsWQkkD54RuTtN xJD7P4v5RxPPChujTbZlrUS+ABPM2ABrzmB/le/l9Kw2yuYMpzyCc7NEmTz+M6NJMTT9cA3Cw /JrzQR4E0w== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172218.71E1B3A2B6C@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:22:18 -0800 (PST) Archived-At: Subject: Re: [dispatch] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:22:24 -0000 > On 09/01/2020 11:58 AM Timothy Mcsweeney wrote: > > > Hi Barry, > > >While it's certainly possible to add such guidance now... > > Possible? It's the best current practice. Shouldn't it be imposed? > > > >While it's certainly possible to add such guidance now, this update is > >very narrowly targeted to fix a serious problem, and I would not want > >debate about additional text to get in the way of that. > > And doesn't using this draft as an update of the entire IANA considerations section effectively remove any means of registration through the mailing lists provided in that same section?? > > Tim From nobody Wed Nov 11 09:23:19 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6E41A3A1E38; Wed, 11 Nov 2020 09:23:13 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205933A2CBD; Wed, 11 Nov 2020 09:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ybyFLg4oNUTy; Wed, 11 Nov 2020 09:23:06 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45DBA3A1A88; Wed, 11 Nov 2020 09:17:13 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MXHWM-1knQHh0H54-00Yj8Y; Wed, 11 Nov 2020 18:17:11 +0100 Date: Wed, 11 Nov 2020 12:17:10 -0500 (EST) From: Timothy Mcsweeney To: "Murray S. Kucherawy" Cc: draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org, Barry Leiba , Brian Carpenter Message-ID: <1240897636.13721.1605115030582@email.ionos.com> In-Reply-To: <808181205.131590.1599043971572@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:o7Fk+IcOphqUb/nKqwOWJf67V5Ifb31TxIvaXo3cqNr+eTrnA3k VfEh2wq28UpmcTbfUzCwKXJNRFLJNNd2uz16cX0VpmWQ4YlI9eH/0rXHiGkD9mlRG29fTjH F6Bl0Mx1m71QWuKEyN+kpayEBtpXRG+21x5m+tGxtmiSHIdB1J7LvCPyAnuD813W1XwQepc gC1vBdMnlZuLHIx6rYfjw== X-UI-Out-Filterresults: notjunk:1;V03:K0:jTLrHIYNisc=:+O7PHO6QtwFuALmxDcFnxk EXZLx3SPqdySDfA1P2EHO7Rsodf0WHmg8VPFnPxrc5u0zydwZwb7Khr+sAr+twPogSJUkFOs2 kBV1sW7MehMhOi5A9FJuKD3cZOTBvBV+TD1ND75avs6rKUUxYbkP0dzR5B8ZnplHAeXl2RzH7 nCG6PyIpvitnqzyFv+EHOdTLyqQCnmi+DDnFQbyhsRWmKV/iBaTlaFPaLrTJPvJ2NNLuPhNfi mwtuNi1sQUcVQxv9o4TIqXfiTnsr93mon4ThUT0l7k86ddvqMJ0+l5QqLRiSNsBKyqc5fj3XM RaUXr+KySNCWkkJLDt4Vucyaf8cO0c3bumyXkQk5ISWN3uceTNpN8uzg9l32ErlzQpQSPvwno /6OeGi3D/6uVk/KJO7Ad6gYzL88nlMEWtnaJO7WRP0Ht0cTYmdwnotvATvBgQE9B8dr77U0gw PxMKXoZceQ== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172313.6E41A3A1E38@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:23:13 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:23:18 -0000 > On 09/02/2020 6:52 AM Timothy Mcsweeney wrote: > > > >>This draft doesn't replace the entire IANA Considerations section of RFC 3405, but rather amends it. > > Oh, ok, because the draft literally says "This entire document is updated instructions to IANA." > > > >>This draft could spell out each of those edits precisely, or just replace all of Section 3.1.1 with a new set of text.. > > And it should. There is no legitimate reason not to. > > > >>... seems equivalent and unambiguous to me. > > No surprise here. Maybe the IESG isn't a good fit for you. As a matter of fact, if I were Barry I would drop sponsorship of this draft for all the reasons above. > > > > > > > > > > On 09/02/2020 1:49 AM Murray S. Kucherawy wrote: > > > > > > On Tue, Sep 1, 2020 at 8:58 AM Timothy Mcsweeney wrote: > > > >While it's certainly possible to add such guidance now, this update is > > > >very narrowly targeted to fix a serious problem, and I would not want > > > >debate about additional text to get in the way of that. > > > > > > And doesn't using this draft as an update of the entire IANA considerations section effectively remove any means of registration through the mailing lists provided in that same section?? > > > > This draft doesn't replace the entire IANA Considerations section of RFC 3405, but rather amends it. That is, after this is published, to get the full IANA Considerations for BCP 65, you would read RFC 3405 and then apply this document as a sort of "patch". That's what we mean when we say "RFC Y updates RFC X", which will be the end result here. > > > > The specific effect of this document when published is to amend Section 3.1.1 of RFC 3405 such that instead of saying "registered under the IETF URI tree", it becomes "a registered permanent URI scheme", and then take "tree" out of the next sentence, and rename the section to something more appropriate. This draft could spell out each of those edits precisely, or just replace all of Section 3.1.1 with a new set of text, but it's such a small change that what's here seems equivalent and unambiguous to me. > > > > -MSK > > -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailman/listinfo/last-call From nobody Wed Nov 11 09:24:25 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 237C33A1AD5; Wed, 11 Nov 2020 09:24:19 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1F63A1FCF; Wed, 11 Nov 2020 09:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1Qnl6Py0TkGi; Wed, 11 Nov 2020 09:24:12 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24753A1FDB; Wed, 11 Nov 2020 09:17:55 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MV6ct-1kn99o23AL-00YNXo; Wed, 11 Nov 2020 18:17:53 +0100 Date: Wed, 11 Nov 2020 12:17:52 -0500 (EST) From: Timothy Mcsweeney To: Jeffrey Yasskin Cc: draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org, Barry Leiba , "Murray S. Kucherawy" , Brian Carpenter Message-ID: <1493928133.13766.1605115072968@email.ionos.com> In-Reply-To: <431078846.410242.1599068663591@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <431078846.410242.1599068663591@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:8+nAiy0Ef5GqnTWXW18iFbp/67EBiUSh48MUw3hZkrbJrsWDGEh /LVk78DMOjitRJjD0EHsMplJxvnocfJJW246ykwtI+Th0jjcqgCNU1RvaaCF7qaGYBcPp+U 79GBiRI4AfznvbkN3gRYJnIhwCsT755yVbCbeZuuRm3zUvV6ak6Nzyd+AcUSNllEA8ERiXF QT5P1FujLBFhjTsNnC3IA== X-UI-Out-Filterresults: notjunk:1;V03:K0:ijIIgx9PcDY=:Dm4y11om1fWcH5LQtxIa1M G4Jd31A0Bav67+GzEYyAbr03MgRgnJfew2ATk+ysK61Ul9PNw9kQPF5W8K+uceI3lav7a8pgj HmgzxQdg460/yDvrIkS5/YZ8l+Ynge7S14HrSNaoQ3xKJgAYhcO3C7uJHnm4wC8WZ/MtpQHYG qwKV1ANuAxsQtxb8Ui/YaaUTOL1707UbkJveeuPlLaLjB7AyWsIeaZe3SXCEYfMDJogsEwyIN +FXmjsBdLb0/muSALcN3scoQ8RsjDsdEnsWnwKxuZnV267RlZ4Uw3Z0pwqOT//dFXwPOsRh9d ZQeUUBn1w6Pcc/pLUatUz9O0TsM9vJL/JDi+x8DdO5IYMqGXVRHsn3uEwFOnmi5pYED+iEhAW XkgabGY2GxLJd+8YUzAIkuo/haI/J9PvWWeTGJPS32W9VNfl9UbPg1+ZH8hiGzU27KcFtzIGj OtGhg0dcTA== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172419.237C33A1AD5@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:24:19 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:24:23 -0000 > On 09/02/2020 1:44 PM Timothy Mcsweeney wrote: > > > Jeffrey, I sent you a DM. I would have rather posted my reply to the modeartors email here on this list but I'm not sure if that would have broken the same rule several more times. > > Tim From nobody Wed Nov 11 09:24:51 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DB1B03A20D6; Wed, 11 Nov 2020 09:24:43 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C0C3A1ADF; Wed, 11 Nov 2020 09:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OYhlr5k1I8TC; Wed, 11 Nov 2020 09:24:36 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9FC3A20A9; Wed, 11 Nov 2020 09:18:12 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MiaDb-1k7waT162B-00fhL7; Wed, 11 Nov 2020 18:18:10 +0100 Date: Wed, 11 Nov 2020 12:18:09 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org, Barry Leiba , Brian Carpenter Message-ID: <560713636.13779.1605115089799@email.ionos.com> In-Reply-To: <597003237.420857.1599076554610@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <597003237.420857.1599076554610@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:QhPxPkldi4YtLAJydgpJZOxyPkN5EUUyjn/bld/3QhXJbKZNSuq Za87rfB5KTnRupSPAkYEaXN9uM5nRvWIXVf3xShV7SNpy/3zyfhNXswgl/oF3561/umfbKL 9qt8Xkjtm5W1eskW22tkl9sqCBVd6Xt8F5TANZfLbdfFIfBvh3m0v+opg/KlaRAG+DKREcw Wb/f2FzWtZT7h//8rklRw== X-UI-Out-Filterresults: notjunk:1;V03:K0:FVpCnQMgaM4=:9YI66vIVZY5ueQFjfaSiVO B2OyANlhfB0pdmsyIe6EE3LvQQR6r3+bdofPL4tuK8ulRDKpiM1JT/LVl4Uh0e4Ds5PGE5Arl Qw5oaRPib+c/Ht+R2OxxA3sHAicomUdTqvC78m1kdH/emDLWPsS5DPj7sCEjFf4XgIOt2PSxz yNPVVWjMqp6hJEeQ22odJdOoV6sPsA4pzuTDufkI26LiNb/dvpKqq1cQf3gpdgZ8nI9si0107 fKsE3Mqlcezt9F3qAVJhUkMzrxxksxv+aEDfDMHr78WUUNDCw2t9LFAjxLvt2Orn7CytHEGbn oYPTooUjPLEaU7I+XxNUWg6FdMxLkwUCdfWnTzV5rPCWXU/tTyXCW3L9TGzDgSupjAz+XzzEY hoG4CEH57eGtq+8O58I6EP1cwlJLa85xAc523yy1ogcN+E/jDsR8IvdHl1HaLimDxudL63Xie 2OLGXZuEcg== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172443.DB1B03A20D6@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:24:43 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:24:50 -0000 > On 09/02/2020 3:55 PM Timothy Mcsweeney wrote: > > > >Is that right? > > > The first thing I would change in your draft is from this: > > 3. IANA Considerations > > This entire document is updated instructions to IANA. > > > > To this: > 3. IANA Considerations > > This update does not change the IANA Considerations in RFC 3405 > > https://tools.ietf.org/html/draft-hardie-dispatch-rfc3405-update-03#section-3 > From nobody Wed Nov 11 09:25:12 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8F3403A2FA9; Wed, 11 Nov 2020 09:25:06 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42FB3A1894; Wed, 11 Nov 2020 09:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FNuyN7NdtBr1; Wed, 11 Nov 2020 09:24:59 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB353A188A; Wed, 11 Nov 2020 09:18:28 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LoWaK-1k6Z1U33NK-00garV; Wed, 11 Nov 2020 18:18:26 +0100 Date: Wed, 11 Nov 2020 12:18:26 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org, Barry Leiba , Brian Carpenter Message-ID: <53565268.13795.1605115106256@email.ionos.com> In-Reply-To: <1773111715.104993.1599083716164@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <597003237.420857.1599076554610@email.ionos.com> <1773111715.104993.1599083716164@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:+/CNXD1uVIcSaP6dJKRU2NKysSHpoRxfXuyDqF82RDqn2y9+amu FQVDas2keVtcBgHwzt9ZEESOOpSkSGjnVzYD+lkCNHoz5zV2hjnCB77pCudtUHM1HcADBG5 I4mYJEoTdKoQMmhwo7+8QEeJTLEbH5Gg3Bi3lxzW4JupqALG3tuNx54OepUHF8nmwKOluHY pnres61Tgua2mpBNet9Iw== X-UI-Out-Filterresults: notjunk:1;V03:K0:vBB9DcnS3aw=:YbQTNIry0DkqSTmtjXPliH PpvUB6dKo8v/ZUbkclU+xKpoHYq2EfoYyaiUz+d46qjqlakkJVCQ81zkBjS6ADFke7i+/RlvF pW6TwUxl9zd0e+qk0R1Vo0k0oBAYKhl5ku91Zay7aFFSNTj1ZA9PhZuNnTIneDDfAOppwumHC ptsrxooT+gkrP9KevijhYRMNl1XPHxWHsyVgkqO8xUQuE/mOk+672/oel9hn3gbF5MRZnB4kR +cUf5O7zshhM+77/T30eJvc2MGJRX7pvhhjIM37qR60bbI1E65QRspzuaqNFjCKkxnC296OKt OjjsXnEZg0qrZC0RsMXjjzqxbnrd6TWZh1Xkr5FH9P9faeuCWTknWeohh/jVpwCtPUyuwNXs9 +JYyHEliLBlj+ppdDJxibyPCfTkn8krSlXVqIefvWlPgqkO6Kb706XWNNfrL8m9rPSaL2NKBn k4YLmGn0NVlObfGDBtGa432udxKN1RDONI8HPxq2HT3p6rOY0oXA Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172506.8F3403A2FA9@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:25:06 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:25:11 -0000 > On 09/02/2020 5:55 PM Timothy Mcsweeney wrote: > > > Ted, > > > I think the clearest way to register that opposition is simply to oppose publication. > > I want to help you improve this document. > > > > Tim From nobody Wed Nov 11 09:25:48 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1B5F13A30E3; Wed, 11 Nov 2020 09:25:39 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E883A1F60; Wed, 11 Nov 2020 09:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3CV-RyUGp1fz; Wed, 11 Nov 2020 09:25:33 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0278F3A18C9; Wed, 11 Nov 2020 09:18:47 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MTAx6-1klFT93RGo-00S4qk; Wed, 11 Nov 2020 18:18:45 +0100 Date: Wed, 11 Nov 2020 12:18:45 -0500 (EST) From: Timothy Mcsweeney To: Brian E Carpenter , Ted Hardie Cc: draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org, Barry Leiba Message-ID: <775949794.13812.1605115125351@email.ionos.com> In-Reply-To: <592053892.283347.1599127247758@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <592053892.283347.1599127247758@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:HrgMl3dR6aWx4Zc+rt+89jznbt7kruQ5Ep/YCtPBQ1Ch5ahZncY 3yNGKQB9mTbb66LHxX4nYL1Y4HH/K1ZTNh9oo80vOLBWIDS15XnDSovwi/ljDsmMxbSv7KI GkGaJxAtBZj+0MO+Bz/KAXmWdtu/lq3mWMBD4fpjzo76aSdLmhQ0GhSqSMhSrOpA6sHJSzV uQc7WphrnfFerlJf6EnQg== X-UI-Out-Filterresults: notjunk:1;V03:K0:ytVDZ5CbhY0=:CQ30wHLCMl+z66InQrUh/p KU4hIs71tXGA8x2I5dwowgTI4YcJ9hBMOUCIqSgGW+O9Sh5gylfmtzxcP/Fc/X42pO8B1KoYY zVbiuzS5WSwMoNvt6odB7U9xQs8LUMj2C5Ca3SOMvx3TXNi3Q+eU0a9+rR7F/FfOh0eWuvF4+ RXke9ed04SoSmUsfm6lUcEzXpZq0CZpbL0A1gW2ImQs/m/Udk2d0l6uV5MUt44hsM8cgi/1O+ TRTVw69kiwMaEhhGi7gqw2gr7WL0BKWzSQymNeV+QY4BPHN0C/MZI73kO6FXC7TnoKmuWa3bI k+XTckDBCjCbVShOxNW18fjJ4zHpjpOmu4BDVbx/wzjKDaLPSuut+PZES1OFOgl5jHTlPxEF+ hyDTQaJ6XFX8QjE8Ej626gSaIVTPwXnKNXY3uEV1KTG43fhJobJZ91fKg31NWLjF78Wow9IKz CYlxIRCPbQ== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172540.1B5F13A30E3@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:25:39 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:25:46 -0000 > On 09/03/2020 6:00 AM Timothy Mcsweeney wrote: > > > Hi Brian, > > >Re-assuming my hat as a Gen-ART reviewer for this draft, I think that this > >change would be a mistake, as it no longer explicitly informs the reader > >what has been changed in RFC 3405. > > >If we really want to be precise, I suggest: > > >2. Updated Requirements > > >This document removes the normative requirement from section 3.1.1 > >of RFC 3405 for registrations in URI.ARPA to be from the IETF URI Tree. > > >All registrations in URI.ARPA MUST now be for schemes which are > >permanent registrations, as they are described in BCP 35. > > > In the interest of brevity, we probably don't really need that second sentence. And it might help to open things up a bit. > > > Tim From nobody Wed Nov 11 09:26:28 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E69A03A2291; Wed, 11 Nov 2020 09:26:21 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32C23A226A; Wed, 11 Nov 2020 09:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1XSsTTCTaB_t; Wed, 11 Nov 2020 09:26:14 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12553A226F; Wed, 11 Nov 2020 09:19:02 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MX2Z8-1kp50r1KHE-00VuiE; Wed, 11 Nov 2020 18:19:01 +0100 Date: Wed, 11 Nov 2020 12:19:00 -0500 (EST) From: Timothy Mcsweeney To: Brian E Carpenter , Ted Hardie Cc: draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org, Barry Leiba Message-ID: <1813718741.13831.1605115140845@email.ionos.com> In-Reply-To: <916398430.283512.1599128074641@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <916398430.283512.1599128074641@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:iBC8wUwtwVEIXnrMsRraAZSmCNO91jgjAxrzNj6T8Mt3rOHHUhJ zS9k8c0fKctyWBgdVTpaoQ98jwGDLxpOap9rNgYH9zEiGo/Iu4XXM2heIcmnDv2lUHLWETU SLNwugF/HTaetASTZnmq9ydocY3EZj1nwL07rWEBw6n9YWbi9KkRypqpkVBw4LFrqzJpUfU 1aJ2K9utRxLRLm4eI1mPg== X-UI-Out-Filterresults: notjunk:1;V03:K0:h5CKCulkEC0=:t8hwtQaI0DeM1DJ37dCT/0 4fN0tuiTsPSXEu3CBZhelRrCCOPmmsBuex54bTeqLksUpizyVu9zlVKOkRi9JlOK4y2r/MoxB m2uEtA641+cYhu2rJzsyNk0JCyXevonV74vtaunV66OpjAE4Uouar1Rsfr8CaYdiIfcbWeJNi w2u7RJZ4QUTZsfZ62aWTnoAiW6Ya/wRYSfUynztEUBBS+PD8DALFHxLiRh2xQ5Z+u7x8gl8lD jVTvkZ3MvM3x6Hb9JnO5jwOXeJlB2XMefNMq5LBvSCdcBqW9x237Mzuzzx5yIYZ8ISOAjZXrj y7K4S8IBFpo9FCUOQf7tRDN84EJP1twim7fly+WjRyGliUQIwHRpoh+tZHq5Blt8BOmYE4Ic4 UyvaRuuyfF+HMgqvTQDiSUU05UfsAeCMRscJPZkx2vhzXc6auhmspj1jqgWfoUDo6OtIvABe0 11TK9rF3bw== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172621.E69A03A2291@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:26:21 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:26:27 -0000 > On 09/03/2020 6:14 AM Timothy Mcsweeney wrote: > > > Hi Brian, > > >Re-assuming my hat as a Gen-ART reviewer for this draft, I think that this > >change would be a mistake, as it no longer explicitly informs the reader > >what has been changed in RFC 3405. > > >If we really want to be precise, I suggest: > > >2. Updated Requirements > > >This document removes the normative requirement from section 3.1.1 > >of RFC 3405 for registrations in URI.ARPA to be from the IETF URI Tree. > > >All registrations in URI.ARPA MUST now be for schemes which are > >permanent registrations, as they are described in BCP 35. > > > > Sorry, I want to make my last comment more clear. > In the interest of brevity, we probably don't really need that second sentence. And its removal might help to open things up a bit. So section two would now look like: > > 2. Updated Requirements > > This document removes the normative requirement from section 3.1.1 > of RFC 3405 for registrations in URI.ARPA to be from the IETF URI Tree. From nobody Wed Nov 11 09:26:57 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 62F933A24B9; Wed, 11 Nov 2020 09:26:50 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673643A33C1; Wed, 11 Nov 2020 09:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GYSlQ9UnTjKJ; Wed, 11 Nov 2020 09:26:43 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82143A2489; Wed, 11 Nov 2020 09:19:21 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MJAJI-1kbF5I0dEA-002n8s; Wed, 11 Nov 2020 18:19:18 +0100 Date: Wed, 11 Nov 2020 12:19:17 -0500 (EST) From: Timothy Mcsweeney To: "Salz, Rich" , Brian E Carpenter , Ted Hardie Cc: "draft-hardie-dispatch-rfc3405-update.all@ietf.org" , "last-call@ietf.org" , Barry Leiba Message-ID: <82097538.13847.1605115157574@email.ionos.com> In-Reply-To: <5651394.455176.1599144091918@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <592053892.283347.1599127247758@email.ionos.com> <862B493D-1189-459C-8C39-FF60F7C2C085@akamai.com> <5651394.455176.1599144091918@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:S871GO+avD3LU1E1J4yWVqp7V0F4Oz/e9vgcZptBlk81gDFi98B vCG25zdCGakRJWz3GOgRx6d3cq8+KGiieRsMe8VQt6Mjna6CZ/B5TDtgX25SQrM2f/h+tVm HPP28iYe9pssU0/etoD4EPdpUlfWIny+yA8YaUQTkIAOPT32yEYWyd//8w4x2vDCqbUiOaU 1Qf+N+pGOzxYixfI5WnfQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:no9pN3rovMw=:5whGbSfHEACOrnuE3RHBsy JudIWmOjgSdS8cT5UyGw/NI3Sd+2+oxFW89ajQH7GSKZC5Me6j3Jz9ap2Ilg9HvZttItptXD/ oJ6I+9CIDP2iNr8nlnUJgSjt5qiEVCAKu0yTHcUcSwgWILyw2sA6xYmqrwrw0TpSN7YAu3PxH nzIaP1tvx79coAAe/AcP2/CzRVicXZGl458CKLLz8r2L/GI2HCirFPuELOLCDmEeu7HbzwJLQ kVneXnnamGDDRvO9Fa4nPxvQRKsRQxKlkiqwfEj+ofhjKm4csCrYpmxP6Kpg/78RjbmqKAXDF rdXNaQFyWuyvdR9jhXTgXwS1s0xrjP2VGTvIE39l2r4QotfwCqSNZ7THswG2cOvApRGMyDVFd a3ORQ5fo9OnOCnIw2dtULpbPDvyoKZ9EvXKHDZt/quX8ilwm83uGSDPKWFHdsUT8EMyglfVmu ivbGRMy2OGGRDTOOe4+IzfWEZMR3AMi765JijkdU0+4qa8cuZyzw Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172650.62F933A24B9@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:26:50 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:26:56 -0000 > On 09/03/2020 10:41 AM Timothy Mcsweeney wrote: >=20 >=20 >=20 >=20 > >Strongly disagree. We don=E2=80=99t want to open things up a bit. > Who is we? > From nobody Wed Nov 11 09:27:18 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7FB993A3480; Wed, 11 Nov 2020 09:27:12 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4053C3A2581; Wed, 11 Nov 2020 09:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 N09ZEdpddsWi; Wed, 11 Nov 2020 09:27:05 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310693A2572; Wed, 11 Nov 2020 09:19:37 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MYhG8-1kqjhM3sRe-00VMIW; Wed, 11 Nov 2020 18:19:34 +0100 Date: Wed, 11 Nov 2020 12:19:34 -0500 (EST) From: Timothy Mcsweeney To: "Salz, Rich" , Brian E Carpenter , Ted Hardie Cc: "draft-hardie-dispatch-rfc3405-update.all@ietf.org" , "last-call@ietf.org" , Barry Leiba Message-ID: <1633267038.13861.1605115174391@email.ionos.com> In-Reply-To: <1039507146.458563.1599146775391@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <592053892.283347.1599127247758@email.ionos.com> <862B493D-1189-459C-8C39-FF60F7C2C085@akamai.com> <5651394.455176.1599144091918@email.ionos.com> <1039507146.458563.1599146775391@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:MHYDDOQexcUAJ0K1+8MR88/yNT2WPF+NeXQVPV6++0Fo0LT7BWs 6GzXpJ85RC1KZ3cwNaJOsYAV16LtbHxPbwInghWucjzeQDtT6fKLHTOJP1g4Nc2YxKCf/qa dj9449VMu3G3aT48slYMxMCcB2AMu2HMFjp0xSruV5w6+GCVlMc9AZs8V/n75T/UJ0IwP3N z+zs1WROtY+xpsSHBEhTQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:GxbwdioaZpo=:hNDK9NrR9OiHfTfHBeunIM 6YRDYdaVPerzmbyRPmEVbozZL1cRJdvNrfxLM/HL2ZMJaX09ZMQooshV9MZJn7oHLxPoNY5WB Dd+qxB6urDtX5WsyixqtQC6jvq8h+vjVZA+02NkG+eW7z000PALMJuyKXRbdOKg2QXeEw2DC8 3u8LJDt6rTltUuGSsULkdmnsVClDEJ7m2IKbXQrhPwCUlbK9aioBFKyu1iCMa6WbkFQKDBIp7 w0okYlBKsdX9KzpOdgDXnE7kGD1/k2cetkPnJ1E/sw9Z8oJVeF/3YTwrsnfbLNzqt1MPgFFCs JHxTJDI4LDCEVUB/qPaPCCxBOcNygUhnVVXa2HQg686FV0wd9YDfk9/O3kwQ/9o4WzHZoN3Rn YqEoKuUyNhjgySZ6buUSH/IwTYipm/67UiSTyqx8Iaq7m3e8ml9OcvH9ycElgi0W6SVhwfeb0 lPTHthXlNg== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172712.7FB993A3480@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:27:12 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:27:18 -0000 > On 09/03/2020 11:26 AM Timothy Mcsweeney wrote: >=20 >=20 > >I don=E2=80=99t think you are participating in good faith. Please stop > Rich, you have to attack the ball and not the player. >=20 > But to your point, I am acting in good faith. >=20 > >We don=E2=80=99t want to open things up a bit. >=20 > I am trying to open up an standard that is closed so tight that nobody ha= s used in almost twenty years. As best I can tell, all those who are opposi= ng me have never, and will most likely never have any interest in presentin= g a new uri for that registry. That fact should give my opinion at least eq= ual weight in this debate. >=20 > Tim From nobody Wed Nov 11 09:28:22 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 88B1B3A2731; Wed, 11 Nov 2020 09:28:15 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC98E3A1299; Wed, 11 Nov 2020 09:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LJ1CSVipaTq8; Wed, 11 Nov 2020 09:28:08 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2493E3A274F; Wed, 11 Nov 2020 09:20:24 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MJiny-1kbnKM2fUi-0019fY; Wed, 11 Nov 2020 18:20:14 +0100 Date: Wed, 11 Nov 2020 12:20:13 -0500 (EST) From: Timothy Mcsweeney To: Ben Campbell Cc: draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org, Ted Hardie , Barry Leiba , Brian E Carpenter Message-ID: <1190678700.13888.1605115213983@email.ionos.com> In-Reply-To: <384677436.461410.1599148896274@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <916398430.283512.1599128074641@email.ionos.com> <9C86A277-47EA-47D8-8B09-1236BFDD1530@nostrum.com> <384677436.461410.1599148896274@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:3kOxex7Tm6e7dA39FGrGoKzHtLrtTNbsMpYGSF7LxOlIzfTuAPh LLg9eHmOOVpm7/kwYeGK5OAG43ulI81VCKNAfdZ7K9O/K5PxV3sfMY/zXNRHdFoFtuBbGGh tW+14OssTvlobQlVYKt8cp6ZUfMOwWYjkWSKokYV83RieheuZEWmriPDFbxLuRRJ8e4rsQS utH9Wh3eRk9zzxN2Q0e9Q== X-UI-Out-Filterresults: notjunk:1;V03:K0:8srDzFvaqhQ=:MGBszAg0t8uUfOhpJXWK42 SpdLm0n4KUSC5WTuX4V2zek/EreEVGkLKJvtTtIqOiwfrmA+CssKLKsCV0vTThC8tmhc7APsj 3rIFNfej3W0n5fZaJHCaGb1gnhF3kmEqXkHH0RswUsrbi/2WaIEcMu+zfJxF/dv/uhsyBeMqH VnK5seWt6XLN1fhXanlH3/VJR6V739R7UQ677C3dzU2fn6QhQPakNX2GL4fGRf99gJiZZXb5N 85tKaacmabhRKWYmKornYYd/m6/yo0u8L5sLX6bR1Oj95uIL0klZAbBegdubjtiEbFFQiuo5o 2LZlTkFRz7KEyRFl3nEnMoo7udpBmimFJ4Wx2iVaCvPUE185WJ2KFtULdbUCt0DKlmvqhJiVq wayo1WF60vC5LDUciSnxAceDny3mkozpn4SckcpW2bo7hf8nV5ZrjMvVbSGG8kPG8JGC/6cTZ eg4UTUeA7A== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172815.88B1B3A2731@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:28:15 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:28:20 -0000 > On 09/03/2020 12:01 PM Timothy Mcsweeney wrote: >=20 >=20 > Hi Ben, >=20 > >I don=E2=80=99t think it=E2=80=99s appropriate to add schemes to the URI= .ARPA zone without substantive review. >=20 > Why do you say that? If all the DDDS rules are followed the records enter= ed into the zone should not have any technical problems. From nobody Wed Nov 11 09:28:41 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8A7E63A1783; Wed, 11 Nov 2020 09:28:34 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8137E3A363F; Wed, 11 Nov 2020 09:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JUAvihg_Mv6D; Wed, 11 Nov 2020 09:28:27 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82183A27E1; Wed, 11 Nov 2020 09:20:38 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MjSkQ-1jtPyJ0ajq-00kuXV; Wed, 11 Nov 2020 18:20:29 +0100 Date: Wed, 11 Nov 2020 12:20:28 -0500 (EST) From: Timothy Mcsweeney To: Ben Campbell Cc: draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org, Ted Hardie , Barry Leiba , Brian E Carpenter Message-ID: <760893042.13893.1605115228626@email.ionos.com> In-Reply-To: <80653043.461504.1599148969376@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <916398430.283512.1599128074641@email.ionos.com> <9C86A277-47EA-47D8-8B09-1236BFDD1530@nostrum.com> <80653043.461504.1599148969376@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:5zM8Ostq3U9IbJg4kRL3azT5gOEN4IthFXZ59twhehb0WcStBfW iTUsg19GBHviJHYyMqvHvjwCVnGnqoRDqUbX7N6rwoYjNmK5zgAdpBirpblufyl/8kqiyr/ ga6Gm6ap0iJQFg/JUdxdTYhF2dPlvc4e+lupnq/yl4aa2mHywI495QHYcbu6D1MZkdMpqlg PGGMq6ZCDgMOEmnG627PA== X-UI-Out-Filterresults: notjunk:1;V03:K0:5Swuxs2htkc=:vix9oB77zsPnLYVRsdgTwB n4xaZgYMRaKIXbfixY62mLEUO1HzFMKORsavLHG7DzReXUPVjelaZxRhh6q/MQjd7da7SeS4I qZYjmBUNB3Dm6o0JGnN0AyeDtZKLRNTqhL8fwZ4uVGd031SHakz/dVN9j7XpcMdEQlPCJIGip v2VTbyYXJlJjM6BeclQ69t5H78PuTG0mMFxOD9V8ru6Y2MfPjOogrE+tSWc3xMMGlUVMafiT0 xwKeHPVoLOIhjF6Cr5N7yEymRGFmFOUyaN3+7/ebZwjTTo1JjhqFYx/KBHzRd3hbLvha7aOEk 6D8D5ArkPWljpy0lxRqle28TSuERzBO0CtyFubYg9E8vEU36eARkMqvfRG3eSxUNFNgnYtteI u5U5OQp+qLuNhfxQMY80CYv2lf9hRxA17MVEIis4v9lv+mZTgSiVRIj+8W9KR8KY4DYIKkpUN Ef2ePn0I/A== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111172834.8A7E63A1783@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:28:34 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:28:40 -0000 > On 09/03/2020 12:02 PM Timothy Mcsweeney wrote: > > > > > >The sentence you propose to remove is one of the main points of the document. > > Not really. Its a sub-point of a sub-point of a main point....just like 3.1.2. Come to think of it, I'm working on some language for 3.1.2 also. So for now the document would look like this: > > 2. Updated Requirements > > This document removes the normative requirements from section 3.1.1 > of RFC 3405 for registrations in URI.ARPA to be from the IETF URI Tree > and 3.2.1 > > 3. IANA Considerations > > This update does not change the IANA updates in RFC 3405 > > > From nobody Wed Nov 11 09:28:46 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAFB3A36A9 for ; Wed, 11 Nov 2020 09:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OQDI8tMCu5Kw for ; Wed, 11 Nov 2020 09:28:39 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21AAF3A2824 for ; Wed, 11 Nov 2020 09:20:44 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Levg9-1jwyCU1JEN-00qjLw; Wed, 11 Nov 2020 18:20:41 +0100 Date: Wed, 11 Nov 2020 12:20:40 -0500 (EST) From: Timothy Mcsweeney To: Julian Reschke , dispatch@ietf.org Message-ID: <993033151.13906.1605115240962@email.ionos.com> In-Reply-To: <507665075.474397.1599158958769@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <592053892.283347.1599127247758@email.ionos.com> <507665075.474397.1599158958769@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:HvV5LKSkpu1LmQG5mPP3dYhh0scH9JzwvfD17AfXpUOrLqQv5ip WOfa7u2z7x5s5uEHLpIbPmesmo5NT5S0DG8oZLAH8j8ZSVs7qf3HAT7BXoDtdAJ3Jt0WqBi BaxBkyeCSY9B6zRj0Wgp+hAUzdvNumhNPdz7DkO+znDdP6303oN/k0TeXhbLGSyIiuMfgnF 5IZhf6J1TKvoGLa35S8lg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Fb26wdA9TBU=:f12uPbz+kO0QLTZCcxc6Uw XcdIephAjukJpBxKPfoemnUnW8K4LTrjJpBRQKm+RdDfs7uRrlkRRPaUhgico4UDTIi2AGull 26I165+7zrorWcMbj4qVr3vTIOaBaERxWoapyVaq72MQO9kB0nX+M4SPna7A7aswqlsj+yuJQ qBy50RGEjgU/Ise39zR2yi2N62Q9EOh0sx8VpedWF8PCy5vKq/5CVqMy+pONWkZDzQAVyUZCj cM2TdIrPXY+X4TigebvOFiXvPxK86r5nlxfY14fFXNrDa3Pee/N6F+grxouYrgnFxoKAIDEu1 T5n1ViqWXAELON5hfVJi0yZPXxqWBycJ5KqFWrLqOr4EhmtBTujeBRfNUbyIOT2JHZ1suyLQU DyMkEMVYblOZjmRUH0Wvnw84mZfJ6/Wwr6xcB7r4WKg8WVJq+OsShDrRWF85QpGFaLzijxqAQ ttp2cIq+aQiSIz17BGSsIun4IzPdRt1Bavwz1zgGNy4UoKmTsCy7 Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:28:46 -0000 > On 09/03/2020 2:49 PM Timothy Mcsweeney wrote: > > > Hi Julian, > > >So even if that sentence was gone, you still wouldn't be able to > >register something that has not been registered as a URI scheme, because > >of saying "The creation > >of a given URI scheme or URN namespace id (NID) follows the appropriate > >registration documents for those spaces." (Or am I missing something?). > > That is clarified with the procedures from next sentence in that paragraph. (URI schemes > follow "Registration Procedures for URL Scheme Names" (RFC 2717 (https://tools.ietf.org/html/rfc2717)) [10 (https://tools.ietf.org/html/rfc3405#ref-10)].) > > >How would that help you for your use case? > > I already have a registered scheme name. > > > > > > From nobody Wed Nov 11 09:29:10 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ACD3A1431 for ; Wed, 11 Nov 2020 09:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GufWp9VVWwVd for ; Wed, 11 Nov 2020 09:29:03 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 235853A28D0 for ; Wed, 11 Nov 2020 09:21:00 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0M91ND-1kR5xF46sX-00CSzD; Wed, 11 Nov 2020 18:20:57 +0100 Date: Wed, 11 Nov 2020 12:20:56 -0500 (EST) From: Timothy Mcsweeney To: Julian Reschke , dispatch@ietf.org Message-ID: <1368413779.13919.1605115256641@email.ionos.com> In-Reply-To: <2033779822.474697.1599159197736@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <592053892.283347.1599127247758@email.ionos.com> <2033779822.474697.1599159197736@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:tobGNt1nEq9J1n+nSLeoHMXm1iKCSN2owzjHdOn8Ccj3OyDMXGk yW6nPbAhh6KscJ7kX/hr2AoFUR+Vg8PjWZKjnnvzMtKUv0ViXqJjbKn+PPf3ZiHb3N7JmDU MXyy6Wb36w2v6bholU8hAi5UtnttiVZZrNky6L6fTKbB3ZG58VX3nE5/fMZc9EtNKi/FFIb OmzteKsCjjWmTP1TlBJQQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:Lwy3we3ftP8=:ytbSwv6i6WZqL946JXkz82 TDY1LbXhmGITK60uHU62sVHV/gPTmaH6xz984MyXsR9t6TQFpMqF1sK5nD+ko8gVOhqCwScmr Hu3Tjb57bXZENrTzHNaHCIuM+HEzp3YEuUGEOcVD+xCY7TRJbyrZXx17rKd6CFYoPg+aYSKVQ dH7BEPZHd0e6AbTJjSknuo9VczIZYnulDJlz9Q1yl2XFLE2xWxM3ZHP2ZWUkVDwBpJyq18e7f cRvXClKVxe2m5tl52uI8vaqyQISnknikxUsdWB5n7mKAWSWm58e91SgL4/j4whHP9CqLFhO+6 WECUFB8gkTCF096ufgEoaA0X8cCyPKUO/EqDg9aPoVTmDdTWHr/7faNBlbnuypyF3opLutZyP eGRJWbbM4Xd/LUDBkmF50LYad5E5oLdP8UDOY1F6N68vT6LUf7CgXtEYUB0sUc4gDsy8t1prJ CU1uMRpR5Q== Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:29:09 -0000 > On 09/03/2020 2:53 PM Timothy Mcsweeney wrote: > > > >So even if that sentence was gone, you still wouldn't be able to > >register something that has not been registered as a URI scheme, because > >of saying "The creation > >of a given URI scheme or URN namespace id (NID) follows the appropriate > >registration documents for those spaces." (Or am I missing something?). > > >How would that help you for your use case? > > Maybe 'URI scheme' in that first sentence should be changed to 'URI scheme name. Does that sound good to you Julian? From nobody Wed Nov 11 09:29:28 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13003A2938 for ; Wed, 11 Nov 2020 09:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 e0c08AJVwxeZ for ; Wed, 11 Nov 2020 09:29:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB22C3A2943 for ; Wed, 11 Nov 2020 09:21:15 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MAP2t-1kSkfT22HL-00BrC9; Wed, 11 Nov 2020 18:21:12 +0100 Date: Wed, 11 Nov 2020 12:21:10 -0500 (EST) From: Timothy Mcsweeney To: Julian Reschke , dispatch@ietf.org Message-ID: <1937215699.13926.1605115272137@email.ionos.com> In-Reply-To: <467698485.476440.1599160424490@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <592053892.283347.1599127247758@email.ionos.com> <2033779822.474697.1599159197736@email.ionos.com> <467698485.476440.1599160424490@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:h6t8w+zgG18hKLQTGM7MaLD9LSK563FJurgcDXavOxMtOYmKDuy IjUkrRgFIO4cDjG3rwrMZC3w5a0myNpz1u5gwaP6/9B6IExHG3+eDaMdicuiXsXXj82w0tJ m5AdjWA/nOmMejQy0qPQiXfCpqtUoYmhabbVjfICe8ggBSeAVGxJhDR2ZiGsCLrXYQFo74k xZ3OVmK5ibWwY6/W1bqlg== X-UI-Out-Filterresults: notjunk:1;V03:K0:PeXgJrmxCOo=:4dcmroQJRdyZwUDk6CPrbf b4qloQweZjDCcmGGeGbdM+j3RVy0/SUad3I2r36RQrL+e7Kbq2E2m4C+4WA7mCr+ot7KKuar0 OwGMMJ05UzSjTmFueSlQGiXCmwj6427N4qI526z/h0+hcXovm8e5XPN2kg3MSFMdxKaz9sMWe r1iDNQAPUxsjKjSFQH70qDTjStjgRk8wYWrapyz5Wrs6xKQOHK6GuDERW6Tv7lgb5hHjsDwAh csHqoqJctFpm2ZGF7HDBIcV4zIOO4xdT1wAKaDkslwTw26QdzHdmwW2XGg+updpOERg4l5e09 dqgR4bCw4AAnLDDLNeLwFnV9rOLbD6ijqZ0zBMsAo9Maum62ud4ef/+0sZNm1sJQ959DK/1r9 5pD1GvEMK8sBKzHr+Z2xR7obVvfNSY0biKtdjHHN7ePKhN4DoLs/5dSFBF3ugaYltorAGfCV/ 4+bFxQ6wLQ== Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:29:27 -0000 > On 09/03/2020 3:13 PM Timothy Mcsweeney wrote: > > > >I actually believe that we shouldn't register things as URIs which are > >not URIs. But maybe I'm in the rough here. > > So do you think we should add that clarification for future generations or just leave how it is? From nobody Wed Nov 11 09:30:15 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 3AC273A160B; Wed, 11 Nov 2020 09:30:10 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B283A19B5; Wed, 11 Nov 2020 09:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Rf4reFf4eZxI; Wed, 11 Nov 2020 09:30:04 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB853A15F7; Wed, 11 Nov 2020 09:21:48 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MGkbP-1kYn4c1dJ3-00DYSR; Wed, 11 Nov 2020 18:21:39 +0100 Date: Wed, 11 Nov 2020 12:21:38 -0500 (EST) From: Timothy Mcsweeney To: Ben Campbell Cc: draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org, Barry Leiba , Brian E Carpenter Message-ID: <1760923241.13949.1605115298919@email.ionos.com> In-Reply-To: <1541395114.285974.1599580192738@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <916398430.283512.1599128074641@email.ionos.com> <9C86A277-47EA-47D8-8B09-1236BFDD1530@nostrum.com> <80653043.461504.1599148969376@email.ionos.com> <1541395114.285974.1599580192738@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:HUNMSEX55B6Sp7FdlFEmyHPntPKNWfG2tPRN018iUBWMI7fHec5 57jpOO87VoEeHJyUtQTLO5YjSVecB3HovzSvXLM0cVd5IG92zM+C6lBeNalwr03QN4VK79y C+Qe10T5WPGOITEWl2TvA73eS+4gg2UEawXxdGqso6hR60WAd1Wvl2Y2gKIG7ikoDTnt3dF xyusXjWCYPzFiqMjJBfJQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:bZEQfmBKIDc=:KkRa6cH7oLuBlojWFqIPej j0xNHhvkYk8gb27L1gn9QwINkNXoyYrL3qu50NCaOJstzAcfiBaG5hqskzqgUTLDb8M7L/Ltw 9e+74hDKS3i7pmAA8lyo+aKyCpPcIcJ593Nrt2HmS5c/Bh1Vo+Fv15JyjQJ83KP75MdNJFfrL b0eL+0EiWm+e9GS/6kVFgTZxCDYbqTfOdLzUQMPbST0P+gnvaZnBWBHdmkWkdhqIhTDxuFTuF z7DjXqlSQlamkroCiq0aluVwvtfnaYEfOFBYNhAjzU7STfiLi3fvRMgi67k2afhdZCMOQgrIJ Ur2fB9XmMLK6aDAvcCMQt0+zpntOuSbHrA4EB+gjRZNQJO6tZ/l8j3Wkps1tL+9nHHksUS1c6 VaP8fwkSBp8yVAlCOQDncjMUV9mgd4NtxIqkVSqnfs1FTFZiXSU3L8zioV9kgBq82wwJRimQi H8eN+pgs0g== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111173010.3AC273A160B@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:30:10 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:30:14 -0000 > On 09/08/2020 11:49 AM Timothy Mcsweeney wrote: > > > How about: > > 2. Updated Requirements > This document removes and replaces the normative requirements from sections 3.1.1 > and section 3.1.2 of RFC3405 with: > > The registration of a NAPTR record for a URI scheme MUST NOT precede registration of that scheme. IANA will review the request against for > > 1. correctness and technical soundness (eg. valid databases, service parameters etc.) and > 2. consistency with the published URI resolution application specification, and > 3. to ensure that the NAPTR record for a DNS-based URI does not delegate resolution of the URI to a party other than the holder of the DNS name. This last rule is to insure that a given URI's resolution hint doesn't hijack (inadvertently or otherwise) network traffic for a given domain. > > 3. IANA Considerations > > This update does not change the IANA submission procedure in Section 5 of RFC 3405. > From nobody Wed Nov 11 09:30:39 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 943203A2B13; Wed, 11 Nov 2020 09:30:32 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17ACE3A39A5; Wed, 11 Nov 2020 09:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0vSbK5qITPUx; Wed, 11 Nov 2020 09:30:24 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6953A2AF8; Wed, 11 Nov 2020 09:22:02 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MFvO4-1kXxrV1SeU-00EvZf; Wed, 11 Nov 2020 18:21:51 +0100 Date: Wed, 11 Nov 2020 12:21:50 -0500 (EST) From: Timothy Mcsweeney To: Ben Campbell , "Salz, Rich" Cc: "draft-hardie-dispatch-rfc3405-update.all@ietf.org" , "last-call@ietf.org" , Barry Leiba , Brian E Carpenter Message-ID: <1621999862.13960.1605115310791@email.ionos.com> In-Reply-To: <903208889.160640.1599644667966@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <916398430.283512.1599128074641@email.ionos.com> <9C86A277-47EA-47D8-8B09-1236BFDD1530@nostrum.com> <80653043.461504.1599148969376@email.ionos.com> <1541395114.285974.1599580192738@email.ionos.com> <78D63CAD-1598-4973-9393-368E708BD354@akamai.com> <93E4AA86-9CF4-4635-9E95-2A40C62E026B@nostrum.com> <903208889.160640.1599644667966@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:H08hwNuEoB+cjOiKS7/DFfkWZxsgB/Y+zPvonMDY/Pr4Guxb0vg MseueeQxBRc8Xfgcsf+geSDTBy6Bms4LZskKyCpl+jbIY8hsMrnDDzbGYtbpMCWRcJBZQCm cUG9lME4rVxdLnwgZ0GgN+li8QXgNTXcKVxOI4F6D1vPQcF55J1N+wW9QlOBpwH5CAGHoOw KumKv0CWqTQ0IXDZtXlzA== X-UI-Out-Filterresults: notjunk:1;V03:K0:vp3yn7+U/qQ=:gYtNOhSRIc6KamKObtEtmy txj1teM/Y4wuvSL+AWT9XYc5v9aBKHuIMP1ABkuw+KsnXstkqeTkXZ1KupU/N+uOjHisXQedZ GdfUVJoSxafZBTlRrKQBytwzItXP/U6otP2If65SKHzXFQqdtoNNNIDgapNewbPTNTrTGgepm N+82jcb3fz+8ddbPLZvIcEhbtxn2d9DujeH43WUPy58+eMkCw74Wkwq96vK1qbengf4bIJYcK 1OAUtUHyepsBgaiw2qkAyjZ0qx6eUWn3M2hflTr9toNTRp1b6AqSlA/gts17nZfeE96ag0spH CVt7mXN+s8ouMfIf6X3ZrTqEv5Oba8P1FtuO+VEidpBNvIsSw0PYTDtwnuQFYcT7giN15482e t59D02mgXcAGSxYXnlcGQJP71YgC00udw5bTS2Mh8Mk912/ZHw/ufKrUJak/TSICgkm1jU/UH 2gh3AcjJdriYVp6q/XP+9/9q4rJM003L0TkOUzyqBuTe+tKjBH0c Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111173032.943203A2B13@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:30:32 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:30:38 -0000 > On 09/09/2020 5:44 AM Timothy Mcsweeney wrote: >=20 >=20 > I'm not sure what was meant by Rich's comment about IANA being hired staf= f but, when it comes to the DDDS, > you really can't get any more expert in an review without them. They alre= ady: >=20 > 1. manage the zone > 2. manage the name registration > 3. manage the submission procedure > 4. manage the list for vetting registrations in the zone > 5. have an engineering team to report any technical problems >=20 >=20 >=20 > > On 09/08/2020 1:37 PM Ben Campbell wrote: > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > > On Sep 8, 2020, at 12:15 PM, Salz, Rich wrote: > > > Does anyone else feel this way? I am opposed. > > >=20 > > > It *appears* that this change removes the requirement for proper URI= =E2=80=99s, or at least moves the responsibility to IANA, which is hired st= aff. > >=20 > >=20 > > I continue to oppose any approach that removes the requirement that the= URI scheme itself go through an expert review. It seems appropriate that s= uch review happen at the time of scheme registration (as opposed to the tim= e of requesting inclusion in uri.arpa). The requirement for permanent regis= tration of the scheme gives us that. > >=20 > > There may be other ways to achieve the same thing, but they would almos= t certain require more complicated specification changes than simply saying= =E2=80=9CThe scheme MUST be permanently registered=E2=80=9D. > >=20 > > Ben. > > -- last-call mailing list last-call@ietf.org https://www.ietf.org/mailm= an/listinfo/last-call From nobody Wed Nov 11 09:31:12 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7D6203A1A11; Wed, 11 Nov 2020 09:31:07 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34C23A19E8; Wed, 11 Nov 2020 09:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4eUJeg2tEsSe; Wed, 11 Nov 2020 09:31:00 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267063A2B99; Wed, 11 Nov 2020 09:22:27 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MAOsu-1kSThb0GKI-00BYVQ; Wed, 11 Nov 2020 18:22:17 +0100 Date: Wed, 11 Nov 2020 12:22:16 -0500 (EST) From: Timothy Mcsweeney To: "Salz, Rich" , Ben Campbell Cc: "draft-hardie-dispatch-rfc3405-update.all@ietf.org" , "last-call@ietf.org" , Barry Leiba , Brian E Carpenter Message-ID: <65724106.13975.1605115336382@email.ionos.com> In-Reply-To: <1960569540.433567.1599665347597@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <916398430.283512.1599128074641@email.ionos.com> <9C86A277-47EA-47D8-8B09-1236BFDD1530@nostrum.com> <80653043.461504.1599148969376@email.ionos.com> <1541395114.285974.1599580192738@email.ionos.com> <78D63CAD-1598-4973-9393-368E708BD354@akamai.com> <93E4AA86-9CF4-4635-9E95-2A40C62E026B@nostrum.com> <903208889.160640.1599644667966@email.ionos.com> <1960569540.433567.1599665347597@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:qSQ3jj+Wv6aQoQHqSEpWW0D3ajm7fO1hydAg7IdtB7dxZ8xLuEt I08IcpSB/7suz+PxBWNdqvjxIfAIcoevoue+XSLUP1wXwaxBdshD5vF5UhkES/cIkudR0I6 8idF+vLY/cQUylHhk0DJemsTj9aMgvpO6/Yxiz+RsLYbvdc4ew59t2rR0Y8ADMp6CZhXE/3 h3G7s4qECZ8yYBERS7org== X-UI-Out-Filterresults: notjunk:1;V03:K0:NllBe/teAIc=:zm5Eey58qD5zq+NSUtBqhE 9OAuhnvNfGfoh0Pt6KPpFFnzSaym39RumwCGAqQCjoYG1fAd9hPatH+dEX2qLW2cwOiRUtZ0k ppBzKq+8p+0Rp9jnpGERNsnTcq/uqyv924uT1XeChtqAIIUi2CSbvFfTK10cdqdTDxVtN9YSs xI0bBfZcp/srRfmd64u8cBs8ECTj/k/5gxXQ2cZRyPhjncRQYMogb7PnXzK0PpuVPU68B/bRM 7mmGXoKurkWswn6ieNpqRHayuSquuztzXpu4/lru7ysJQjY7sp5t7jO2jT5PMnhFkIhtOFoao eyCpuZc+XY/McffYYKW2utbubClBQ8fiRidfLSlNkfnL1gk77g8bIubYbHgICT5C4J5+o0QOj KW4dewCwN8E95pP7BW+RSbBZkIH0JVMnYQIVpy9+9BQYjdEqlKSg8wHP1TXijrKeJmCOPNNdE J7WJR8b4pg== Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111173107.7D6203A1A11@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:31:07 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:31:12 -0000 > On 09/09/2020 11:29 AM Timothy Mcsweeney wrote: >=20 >=20 >=20 > >They are not experts. They are hired to do administrative stuff. The thi= ngs you list do not require technical expertise, but rather >operational ex= pertise. That=E2=80=99s not to denigrate ops, of course. > Of course. >=20 > >I am a member of the TLS designated experts, so I know first-hand how ex= pert review works. > I have very limited experience with expert reviews, which part of the nap= tr record worries you most? Beyond that I'm not sure what needs a review. >=20 > >So far you are the only one trying to remove it. > Well, at the moment, there is no designated expert for for uri.arpa so an= ything incoming would have to be reviewed by the IESG. That seems like a wa= ste of resources for them to look at some regex. > From nobody Wed Nov 11 09:35:25 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 66ED63A40D1; Wed, 11 Nov 2020 09:35:19 -0800 (PST) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F0F3A40A5; Wed, 11 Nov 2020 09:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ph6leLI2gTqI; Wed, 11 Nov 2020 09:35:13 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA0A3A20B6; Wed, 11 Nov 2020 09:25:13 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1Ml7Am-1jrlFn3GEW-00lSvC; Wed, 11 Nov 2020 18:19:55 +0100 Date: Wed, 11 Nov 2020 12:19:55 -0500 (EST) From: Timothy Mcsweeney To: Ben Campbell Cc: "Salz, Rich" , Brian E Carpenter , Ted Hardie , "draft-hardie-dispatch-rfc3405-update.all@ietf.org" , "last-call@ietf.org" , Barry Leiba Message-ID: <1413702225.13875.1605115195205@email.ionos.com> In-Reply-To: <968507419.461369.1599148856288@email.ionos.com> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> <1066090379.166058.1598958286518@email.ionos.com> <674529702.175704.1598975928192@email.ionos.com> <808181205.131590.1599043971572@email.ionos.com> <592053892.283347.1599127247758@email.ionos.com> <862B493D-1189-459C-8C39-FF60F7C2C085@akamai.com> <5651394.455176.1599144091918@email.ionos.com> <1039507146.458563.1599146775391@email.ionos.com> <968507419.461369.1599148856288@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:ZYVGcqSFNuQ76lbSZAX5fbKuC7Y05HlBHYKMyPWGsFOFBZq84q4 +nwoqQinInf/XjEheI4s5q1xpFuDiKcRM1XKo/g6GkXGbmD66H6qbCFnAIEOQa9YvYUKBBF l0LBW5in5f0D1RAsGF6SQxZjcsYqytYGWqF5LaoVUNgruLoc35FdwkJQjF8e3cHiZTJCTyU tEVmvq+Rbel0ZUVHwCccg== X-UI-Out-Filterresults: notjunk:1;V03:K0:8DszERhJBxU=:HVI36rOdrSwm3ZAC2oEzN2 YS6iprsc5ethdtB4kAofd4qnkPK1dh90JvDyCRJUZzYRpyiSN8bvF6bOqjQuWXG9v8Hpq3A+K xI1WwTiPlKDotDkofaDYuEvQFjEB9wmtxyFtAKNCsNv6aZzZFXlZ+MWPjJzTpfeCiSXacqlsn HzKYLo+6E5v9C4h/pIOwI25pS8UmFCAYYW6m7DFSNK0/+YdAjLc7mT4azTXsmvZHih6h4vda2 zLR7SKIVj3S7Ptq+QIwCch6vUEdwuXm1Of2uM5zO0f7gxj2oYfF/FLh1WV2nJkggW5HAj4953 9R9/PUGXoFJPCf270uvEbppCS0ivi4SL4PwkkiGBPayW+PuN8KS2Qb1kJCyhs/+Re9XX/a70t 2hYOUXxpRep/VXzlKklk3tYELEVqXUOES6M64EQPcotWhriSDQk2m7QPEz6R/6nDyrqOvEtt6 eM86Tyiw8R1zOQM/HZ1EdPSYltUBghnlVSRpnY6aRQMJqszXu4FVNypqY/oEWWPTmrHrUROwl qbdk1kgsFZrkzWXZL/WLHk= Resent-From: Resent-To: ted.ietf@gmail.com, barryleiba@computer.org, barryleiba@gmail.com, superuser@gmail.com, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201111173519.66ED63A40D1@ietfa.amsl.com> Resent-Date: Wed, 11 Nov 2020 09:35:19 -0800 (PST) Archived-At: Subject: Re: [dispatch] [Last-Call] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:35:24 -0000 > On 09/03/2020 12:00 PM Timothy Mcsweeney wrote: > > > We are talking about URI.ARPA Ben > > From nobody Wed Nov 11 09:39:43 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E9D3A273B; Wed, 11 Nov 2020 09:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 60DE98mll0a1; Wed, 11 Nov 2020 09:39:32 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130A03A1765; Wed, 11 Nov 2020 09:28:07 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MCauF-1kUxPx2adn-009dvx; Wed, 11 Nov 2020 18:28:06 +0100 Date: Wed, 11 Nov 2020 12:28:06 -0500 (EST) From: Timothy Mcsweeney To: internet-drafts@ietf.org, barryleiba@gmail.com, dispatch@ietf.org, spencerdawkins.ietf@gmail.com Message-ID: <1357535404.14208.1605115686165@email.ionos.com> In-Reply-To: <695687617.30027.1602790280802@email.ionos.com> References: <160278762498.6279.12834691771462136672@ietfa.amsl.com> <695687617.30027.1602790280802@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:zUSlo89l/tZiwAxHN7Qz4QvvDH5OVwIS02Czw1Hzn445PAeCPTg 1stzZ8M1X83t2BOOyNnOATX3/u4wZNF0zoOXxBqeediXoJcApyAozmFaeG2jH5ynKTSff8b Aoqlte0JvnRyCvpEigqnH+9c5Qr3Z/+BgoQD63ldBMDRydJim1CZkYZZVnHDdo7JkR/HcZf p9y6jafjN/WnfbRMgehiQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:4dbFRDzxrGw=:+T8curiKquB+bJJSubGiQu Z5EZ68lrWDrZtceG/RGX+Fgf27W1yBzo/QwEkBpV2EPQBpLCWyFYawM56rOUwHJJ8D32rMYG4 ByJTmph6sq1KLIvyVhr/26vryK6ABhOXjT1X7Xa6fgpgwiNHrikA2m5C+s+wcBakufD3xDSBp cA3ittm4AixCn/92jPpBjekrOplxv2EpQjtMD++PL/jM+z6yKIO6QOuncS7z8BDARCwROQD34 lETNpcydsSaTroGFWe6IQFT0n/wyYusSnlsjdKUJJyRe4KRfjxKjKo7Ob5z4Rab6hAFzwEBNB H0r5Qihej4oGe+3JlpnSyvu3ydVx2Wac4y/mlEQ5W3YXNEf7FHwLvoH1Qx3DXnkksPNey2SZw nrlhRzuLxObcWMIQy2S+NdA02C7IHANbsMXkdES3hdC/JT25M6fiGJiA2aaeuQM3zjEUb3U15 jrbLEVS8ew== Archived-At: Subject: Re: [dispatch] New Version Notification - draft-hardie-dispatch-rfc3405-update-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:39:39 -0000 > On 10/15/2020 3:31 PM Timothy Mcsweeney wrote: > > > I would like to see the following changes made to this version (-04) because it does not specify what will be exactly will be reviewed: > > 2. Updated Requirements > This document removes and replaces the normative requirements from sections 3.1.1 > and section 3.1.2 of RFC3405 with: > The registration of a NAPTR record for a URI scheme MUST NOT precede registration of that scheme. IANA will review the request against for > 1. correctness and technical soundness (eg. valid databases, service parameters etc.) and > 2. consistency with the published URI resolution application specification [RFC3404], and > 3. to ensure that the NAPTR record for a DNS-based URI does not delegate resolution of the URI to a party other than the holder of the DNS name. This last rule is to insure that a given URI's resolution hint doesn't hijack (inadvertently or otherwise) network traffic for a given domain. > > 3. IANA Considerations > > This update does not change the IANA submission procedure in Section 5 of RFC 3405. > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch From nobody Wed Nov 11 09:40:03 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837EC3A27B6 for ; Wed, 11 Nov 2020 09:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KoQuOk-LsNKh for ; Wed, 11 Nov 2020 09:39:55 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4C93A196B for ; Wed, 11 Nov 2020 09:28:23 -0800 (PST) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MdJp7-1kvOGz0ktv-00IUFB; Wed, 11 Nov 2020 18:28:22 +0100 Date: Wed, 11 Nov 2020 12:28:21 -0500 (EST) From: Timothy Mcsweeney To: Ted Hardie Cc: Barry Leiba , Dispatch WG , Spencer Dawkins Message-ID: <626573394.14217.1605115701756@email.ionos.com> In-Reply-To: <894177016.33315.1602793596709@email.ionos.com> References: <160278762498.6279.12834691771462136672@ietfa.amsl.com> <695687617.30027.1602790280802@email.ionos.com> <894177016.33315.1602793596709@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:DpJIyeBVaarnxJOMayo8l43akfTchmcMUR8VRz8IxDuOrkNbM83 1eRGoIBdqBtKS0pqFwrH6SE8UN9FXj4ZXJSbuPd57ll+gDQ06jc81jkhkEzKPkodfWynwu0 U/xu6DyfJmRoIxW2Vsgp8yGHMq/A7qES+Fb+rr6c0fVpgLi+SCYgy7rhlsWnYmfC2RGIM+N xhTj8DG6fMnUntlYnuFmA== X-UI-Out-Filterresults: notjunk:1;V03:K0:KdmtqUzZzyM=:6PrpU9KsOxYk+GZdR0xBak SpuazkEZlCP7exXSpnBM58Xd4K8QZhgtI2JK7QrSSy12PAdzEqtuzaBzUKrNVx/Fn4+NyxaSq y1UsXLLJq5Qa4QIFmz7t4svboP7nR7733t7LuiXI780BANWEIzv5sSXJ56IlSbrjY9YeYy7BO DDx2xExFYe3Kf/bcSxMe3MQARsMQvXXwvG5AxSbwv1jrfC9BpXPE3eTajhQKqydyZfMhlKrcD RIA/u7BN7aP6/fL007wbZvImE7ry2oMsIsqZDuAcIhIsXO79jPr/LEHIHRzUuXhSphmp6kIlQ gklBLjJfMpw1GQceBpDx4zzl/PZuHxO1KEO7p6LBPxnVaqi9E6eNcZ+txLbbptP7aaXPVxKUL CKOMgrzZ2WwWWBKmdgsYGwAePxPu/SEv/gBgNgG1Wt1LuStU48FzgGYqgBdNAWQFyTXYP6zat scXSOM46NYElIEK/Wn7DmYs+JrMZTmnu6ZRWNRpT3ITiYRr/Grox Archived-At: Subject: Re: [dispatch] New Version Notification - draft-hardie-dispatch-rfc3405-update-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2020 17:40:02 -0000 > On 10/15/2020 4:26 PM Timothy Mcsweeney wrote: > > > Ted, > These changes were already proposed during the last call of your update but the Shepard did not do anything about them. So I don't understand where you are coming from. > > Tim > > > On 10/15/2020 4:18 PM Ted Hardie wrote: > > > > > > Hi Timothy, > > > > The two small changes done for this version were to respond to IESG comments which sought to improve the clarity of the existing proposal; they did not introduce new elements to the proposal in the document. I think your comments propose a much more significant change, and document updates post-IESG processing is not the time for that type of change. If you wish to see other changes, I suggest you propose them in a new document. > > > > regards, > > > > Ted Hardie > > > > > > On Thu, Oct 15, 2020 at 12:33 PM Timothy Mcsweeney wrote: > > > I would like to see the following changes made to this version (-04) because it does not specify what will be exactly will be reviewed: > > > > > > 2. Updated Requirements > > > This document removes and replaces the normative requirements from sections 3.1.1 > > > and section 3.1.2 of RFC3405 with: > > > The registration of a NAPTR record for a URI scheme MUST NOT precede registration of that scheme. IANA will review the request against for > > > 1. correctness and technical soundness (eg. valid databases, service parameters etc.) and > > > 2. consistency with the published URI resolution application specification [RFC3404], and > > > 3. to ensure that the NAPTR record for a DNS-based URI does not delegate resolution of the URI to a party other than the holder of the DNS name. This last rule is to insure that a given URI's resolution hint doesn't hijack (inadvertently or otherwise) network traffic for a given domain. > > > > > > 3. IANA Considerations > > > > > > This update does not change the IANA submission procedure in Section 5 of RFC 3405. > > > > > > > > > > _______________________________________________ > > > > dispatch mailing list > > > > dispatch@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Nov 13 16:36:36 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F703A1075 for ; Fri, 13 Nov 2020 16:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 i8ZtYmaHo3m0 for ; Fri, 13 Nov 2020 16:36:32 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9723A1067 for ; Fri, 13 Nov 2020 16:36:32 -0800 (PST) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0AE0aQs2044561 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 13 Nov 2020 18:36:28 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1605314191; bh=5YAhu3kYLkjewjTCZ7Yo+XwBDuasyHdAiGX5c1NW+1Q=; h=From:Date:Subject:Cc:To; b=vjCcANwxhlrd1OzlvWM2nKF4GgtA4QAt1R444sEozQZ3nTQn8s/dLzwpBWZNewclx pDhebLR3D5KTBbDuoiQSm+hc+z5Pqr1JcZDGP0v4zGusr9Q2tXdBz6q0/NsWQ5KbDB +4m3e9v88kcm2gJIIu23eRO4iZZdQ7NSHYmR2B2o= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 13 Nov 2020 18:36:21 -0600 To: DISPATCH WG Message-Id: <671702B3-E52C-46A9-B708-F648CADBF217@nostrum.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [dispatch] Note Takers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 00:36:35 -0000 Hi Everyone, We need a couple of note takers for Monday=E2=80=99s (or Sunday=E2=80=99s,= depending on your time zone) DISPATCH meetings. Volunteers will have = fame, glory, and the eternal gratitude of the chairs. And for everyone else: I=E2=80=99m sure our glorious notetakers, whoever = they may be, would love getting some help from the rest of us on = CodiMD[1]. [1] https://codimd.ietf.org/notes-ietf-109-dispatch Thanks! Ben. From nobody Sat Nov 14 03:27:05 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5893A14F4 for ; Sat, 14 Nov 2020 03:27:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=XjN6XeAj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=B8GhogYM 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 e0uvhAfRHNvG for ; Sat, 14 Nov 2020 03:27:00 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94CBD3A14F0 for ; Sat, 14 Nov 2020 03:27:00 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AA6CA5C0032 for ; Sat, 14 Nov 2020 06:26:59 -0500 (EST) Received: from imap38 ([10.202.2.88]) by compute2.internal (MEProxy); Sat, 14 Nov 2020 06:26:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=3DWO1NE VhVTsO8qj5BIhxag5Zqbw4FO8E38gVUAYS0A=; b=XjN6XeAj+vpbICv4+nW+Rya Sg7dvKAQqcQK9sJNQgmBqsLI3yWEf3KtbJFOPMc0641VF8MDxz29BTCFtqWpcSjh s0GdOGFWkY1Yfx8WsOwfSs7//HuzSw5DI7sDvGKeO4MxBZ0FEiDfE4SrD5BCC7dK MYri/2iJqYyEMS/55vlTfsqSd3y1hTZ2OGIyJmRUKqLxfcm2ODlK31mzRqY1wyS+ qzdUXLH56JmfD03jVLW4eQC0Yx2xu5V04dDLaf3AA34bKFa1AB9KbQKhvQCooqgJ eGCRdJSI8PtbEH9z5sLazSkdLElF1LGN7WUH75QE0gKzMxthmqmClA5YuSjj8Hw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=3DWO1N EVhVTsO8qj5BIhxag5Zqbw4FO8E38gVUAYS0A=; b=B8GhogYM9GVFVdlReCxEgF 63pWmcYDzbjwzo0BE+ZIpHGGMQeTXHHckxRRRdlngIvJE0T97vTsl/L2Z4Bct9EO hK2bz8G4YPs9v2+6SZV+9KWgAGQn+vf8XPCWm/FNBMeCGhpOxWlOmFob4GcYnEW7 ac3zOFZwIIbA6a5M8/IItU9DKb8+pki7CFH4bDeZYoPz5CKnxxvma29XLsqFy/pz 2QPLFkHmHPkf3GQpowb6XGuoD6KsCN5pptCqAm145AgezxfVXwJMI8bR3+/qcqPU wGhIfol8XK0govpJHpSzKrH8ZM4PzoSUKGIVGyvkNdb66iXcQeweDzzWDhR+mDAQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddvjedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffvdekfeegle eiueettddtffehveevffefkeduvddttdekiefgjeduvdfhvdduleenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 09DFC4AA0069; Sat, 14 Nov 2020 06:26:58 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-577-gfa46959-fm-20201110.004-gfa46959d Mime-Version: 1.0 Message-Id: <472bb184-7281-4d75-a48b-8cf36312565d@www.fastmail.com> In-Reply-To: <671702B3-E52C-46A9-B708-F648CADBF217@nostrum.com> References: <671702B3-E52C-46A9-B708-F648CADBF217@nostrum.com> Date: Sat, 14 Nov 2020 22:26:37 +1100 From: "Bron Gondwana" To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=59b97ba8d8c14ad8b01d2c11b22692ce Archived-At: Subject: Re: [dispatch] Note Takers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 11:27:03 -0000 --59b97ba8d8c14ad8b01d2c11b22692ce Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable I mean... I'll be there and I'm not presenting anything, so I'll almost = certainly be taking notes... On Sat, Nov 14, 2020, at 11:36, Ben Campbell wrote: > Hi Everyone, >=20 > We need a couple of note takers for Monday=E2=80=99s (or Sunday=E2=80=99= s, depending on your time zone) DISPATCH meetings. Volunteers will have = fame, glory, and the eternal gratitude of the chairs. ... but I have taken notes at these things before, and I can tell everyo= ne that you'll be getting one of these at most. > And for everyone else: I=E2=80=99m sure our glorious notetakers, whoev= er they may be, would love getting some help from the rest of us on Codi= MD[1]. >=20 > [1] https://codimd.ietf.org/notes-ietf-109-dispatch I'm in. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --59b97ba8d8c14ad8b01d2c11b22692ce Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
I mean... I'll be there and I'm not presenting anything, s= o I'll almost certainly be taking notes...

On Sat, Nov 14, 2020, at 11:36, Ben Campbel= l wrote:
Hi Everyone,

We need a couple = of note takers for Monday=E2=80=99s (or Sunday=E2=80=99s, depending on y= our time zone) DISPATCH meetings. Volunteers will have fame, glory, and = the eternal gratitude of the chairs.

... but= I have taken notes at these things before, and I can tell everyone that= you'll be getting one of these at most.

And for everyone else: I=E2=80=99m sure o= ur glorious notetakers, whoever they may be, would love getting some hel= p from the rest of us on CodiMD[1].


I'm in.

Cheers,

Bron.
<= /div>

--
  Br= on Gondwana, CEO, Fastmail Pty Ltd
&nb= sp; brong@fastmailteam.com

<= /div>

--59b97ba8d8c14ad8b01d2c11b22692ce-- From nobody Sat Nov 14 11:51:18 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2588C3A1089 for ; Sat, 14 Nov 2020 11:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 TwGLnJTCd_py for ; Sat, 14 Nov 2020 11:51:14 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910113A1064 for ; Sat, 14 Nov 2020 11:51:14 -0800 (PST) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0AEJp9Lc064607 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 14 Nov 2020 13:51:10 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1605383471; bh=VBGlDKyfUt0aWJVMm8cYau9eB/mQr8zy3ARnJZU4dVs=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=SFcVlXTJaPCM4tiGD5YscqOqR8byU8fGoGvmH7aKvCPcqvNnqgWJ0TRhvF1B+H+4m MJC/jffIC+JLU5EW5/HhKlZLt1/g/MSmnw5jVIo2d7kx0CSYWOvHn2NC2FNtZOyWoh JKemh6fa1h6PIXZvKu8O7AyfHdnhr793RlAumyYg= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <9745CC8C-FC16-4B86-BCC9-D2CAF3A53A62@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C8ACA25A-ABBC-4B01-9C0F-2354F5A59155" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 14 Nov 2020 13:51:02 -0600 In-Reply-To: <472bb184-7281-4d75-a48b-8cf36312565d@www.fastmail.com> Cc: dispatch@ietf.org To: Bron Gondwana References: <671702B3-E52C-46A9-B708-F648CADBF217@nostrum.com> <472bb184-7281-4d75-a48b-8cf36312565d@www.fastmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dispatch] Note Takers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 19:51:16 -0000 --Apple-Mail=_C8ACA25A-ABBC-4B01-9C0F-2354F5A59155 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Excellent, Bron, thank you!! Can we get one more volunteer? I assume the =E2=80=9Cone of these=E2=80=9D is the chair gratitude. (And = yes, we are still grateful for last time.) We may need to crowdsource = the others :-) Ben. > On Nov 14, 2020, at 5:26 AM, Bron Gondwana = wrote: >=20 > I mean... I'll be there and I'm not presenting anything, so I'll = almost certainly be taking notes... >=20 > On Sat, Nov 14, 2020, at 11:36, Ben Campbell wrote: >> Hi Everyone, >>=20 >> We need a couple of note takers for Monday=E2=80=99s (or Sunday=E2=80=99= s, depending on your time zone) DISPATCH meetings. Volunteers will have = fame, glory, and the eternal gratitude of the chairs. >=20 > ... but I have taken notes at these things before, and I can tell = everyone that you'll be getting one of these at most. >=20 >> And for everyone else: I=E2=80=99m sure our glorious notetakers, = whoever they may be, would love getting some help from the rest of us on = CodiMD[1]. >>=20 >> [1] https://codimd.ietf.org/notes-ietf-109-dispatch = >=20 > I'm in. >=20 > Cheers, >=20 > Bron. >=20 > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_C8ACA25A-ABBC-4B01-9C0F-2354F5A59155 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Excellent, Bron, thank you!!

Can we get one more volunteer?

I assume = the =E2=80=9Cone of these=E2=80=9D is the chair gratitude. (And yes, we = are still grateful for last time.) We may need to crowdsource the others = :-)

Ben.

On Nov 14, 2020, at 5:26 AM, Bron Gondwana <brong@fastmailteam.com> wrote:

I mean... I'll be = there and I'm not presenting anything, so I'll almost certainly be = taking notes...

On = Sat, Nov 14, 2020, at 11:36, Ben Campbell wrote:
Hi Everyone,

We need a = couple of note takers for Monday=E2=80=99s (or Sunday=E2=80=99s, = depending on your time zone) DISPATCH meetings. Volunteers will have = fame, glory, and the eternal gratitude of the chairs.

... but I have = taken notes at these things before, and I can tell everyone that you'll = be getting one of these at most.

And for everyone else: I=E2=80=99= m sure our glorious notetakers, whoever they may be, would love getting = some help from the rest of us on CodiMD[1].

[1] https://codimd.ietf.org/notes-ietf-109-dispatch

I'm in.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_C8ACA25A-ABBC-4B01-9C0F-2354F5A59155-- From nobody Sun Nov 15 21:16:24 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90BF43A1334; Sun, 15 Nov 2020 21:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 pzXBi_g7if9w; Sun, 15 Nov 2020 21:16:21 -0800 (PST) Received: from mail-vs1-f46.google.com (mail-vs1-f46.google.com [209.85.217.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C923A1335; Sun, 15 Nov 2020 21:16:21 -0800 (PST) Received: by mail-vs1-f46.google.com with SMTP id y78so8490314vsy.6; Sun, 15 Nov 2020 21:16:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=z9v2uvJSM/7LzADlRMQGHhmfVVaskPpaGXGLLhK2lKk=; b=mJFluQS06d4F/jjxYSMG9m4VEHKtqsQKve1YI9Yj9dCoXlZlGP7Wl9+DI0kvOMNAQE 4JiTD2/jNr/dZ3cp2x2YcTohA/x5tUWHodlDXcHeD2PStYvHjuJ7G92hO+M4RG/DmDWj sQ91/HHXKrLb49MfzzP5dTaG2MbPyKnGe0/jpnPHaCD7g9592QWMKuA3twigmz23oxN8 VybbzZfwUSWD0ZIclZt3NCpwjoMUeiCw93jhn0uyIozbwdgBf05STinXlQQ9FbRT95y3 BtWHNbmljCr0W6qW4cEGEGO742HTekaBu88IgXecrhlc6USNMftDn5roUkZZOx1//uVT jQlg== X-Gm-Message-State: AOAM5314dHc4mZeORrLEnaHtS4xE2E7ouskIyBE8QmgVY3n60EjCopku W8TDDjLmVmRscwxv1crBvLJ2X8IZAhQsIMI0fgz9Lbh7Kqw= X-Google-Smtp-Source: ABdhPJzFufmrek4Qoe9Cnz+K/Acxsf559lr3dMfESoumPBPC0feVcAYz7LqdDpheEE4FrR5pLjnTid/uT+BD1Tq8Nfc= X-Received: by 2002:a05:6102:10d0:: with SMTP id t16mr7160454vsr.9.1605503780031; Sun, 15 Nov 2020 21:16:20 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Mon, 16 Nov 2020 00:16:08 -0500 Message-ID: To: DISPATCH Cc: art@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [dispatch] Change of DISPATCH chairs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 05:16:23 -0000 As I just announced in the IETF 109 DISPATCH session, we have been rotating chairs in DISPATCH over time, and we're doing another rotation now: Ben Campbell is rotating out, and let's all please thank Ben for the work he's done as DISPATCH chair in the past two years since he stepped down from the AD position. This leaves Ben with no blue dot, but he does have a red dot as an IAB member. Kirsty Paine, from the UK National Cyber Security Centre (NCSC), is our new chair, and is a first-time chair in the IETF -- a brand new blue dot. Thanks, Kirsty, for agreeing to step into the chair position! Patrick McManus continues as Kirsty's co-chair, and thanks, Patrick for your continued service as chair. Barry From nobody Mon Nov 16 07:06:53 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7488B3A1121 for ; Mon, 16 Nov 2020 07:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5x3Rj0iWLjic for ; Mon, 16 Nov 2020 07:06:48 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9990D3A1135 for ; Mon, 16 Nov 2020 07:06:48 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0AGFAKnH022933 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 16 Nov 2020 07:10:20 -0800 From: Dave Crocker Reply-To: dcrocker@bbiw.net To: dispatch@ietf.org References: <160337881491.27133.9061463868224826181@ietfa.amsl.com> Organization: Brandenburg InternetWorking Message-ID: <2f578f07-e110-12b1-ffd1-75e7937578be@dcrocker.net> Date: Mon, 16 Nov 2020 07:06:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <160337881491.27133.9061463868224826181@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] React: Indicating Summary Reaction to a Message X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 15:06:52 -0000 G'day, Murray and Barry advised pursuing this through Dispatch... This draft has had some useful discussion on the ietf-822 mailing list. There is no email-related, existing working group for pursuing it further -- it is out of scope for emailcore -- and it is much too small to warrant its own working group. That makes AD-sponsored the most appropriate path for this draft, within the IETF RFC stream. The goal is to have this published as Experimental. (If there is a strong feeling that it could go straight to Proposed Standard, that would be fine, though unexpected.) > Abstract > > The popularity of social media has led to user comfort with easily > signaling basic reactions to an author's posting, such as with a > 'thumbs up' or 'smiley' graphic indication. This specification > permits a similar facility for Internet Mail. ... > 1. Introduction...> This facility defines a new MIME Content-Disposition, to be used in > conjunction with the In-Reply-To header field, to specify that a part > of a message containing one or more emojis be treated as a summary > reaction to a previous message. d/ -------- Forwarded Message -------- Subject: New Version Notification for draft-crocker-inreply-react-03.txt Date: Thu, 22 Oct 2020 08:00:14 -0700 From: internet-drafts@ietf.org To: Ricardo Signes , R. Signes , Dave Crocker , Ned Freed A new version of I-D, draft-crocker-inreply-react-03.txt has been successfully submitted by Dave Crocker and posted to the IETF repository. Name: draft-crocker-inreply-react Revision: 03 Title: React: Indicating Summary Reaction to a Message Document date: 2020-10-22 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-crocker-inreply-react-03.txt Status: https://datatracker.ietf.org/doc/draft-crocker-inreply-react/ Htmlized: https://datatracker.ietf.org/doc/html/draft-crocker-inreply-react Htmlized: https://tools.ietf.org/html/draft-crocker-inreply-react-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-crocker-inreply-react-03 -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Nov 19 20:20:32 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CDB3A0CD6 for ; Thu, 19 Nov 2020 20:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 Nxlxr_XJmyVA for ; Thu, 19 Nov 2020 20:20:29 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 483FD3A07BD for ; Thu, 19 Nov 2020 20:20:29 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id fxu4kg41jBbHHfxuOk1rpV; Fri, 20 Nov 2020 04:20:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1605846028; bh=q9VWFY+9TFsyC9e5COjY6D432xFU/HfFS3Cuyftj6W4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=VK4FvbLbYlUtyyG/mGWvwwcN7yVDMBL4ipzrEh75/8Ip0V3MVBq6MFQKWtnfiQLVv koL2xS0+9ME9TvSBIkovnsDRvLRJlkCvgbSmuR04VUJ/dFt8qz3h++8hvWZKkZLaqc OOBzBsf+c+riu9dOF/oHg5cgm2nFBUMmf1ugez/+dl69EThKODb9pyTB/EAETUKXp7 MzzaYYgsSt2yoj8Kwk69j3ztGFL4zgFoxiy9WrwWk34grbvWpp+MwdeNP1+L787r2U REGO78p+cnEhUf9KfTTJHVuHwo0lgcuBaBVTYUjpUsw18HhR8hQPkShEUtaLPwj74X z6icVbJT+lsMA== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with ESMTPA id fxuMksjDgLXv8fxuNk1mFl; Fri, 20 Nov 2020 04:20:27 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0AK4KPpL005702; Thu, 19 Nov 2020 23:20:25 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0AK4KOln005699; Thu, 19 Nov 2020 23:20:24 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: David Singer Cc: dispatch@ietf.org, cullrich@immersion.com, ymuthusamy@immersion.com In-Reply-To: (singer=40apple.com@dmarc.ietf.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 19 Nov 2020 23:20:24 -0500 Message-ID: <87wnygveuv.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 04:20:31 -0000 David Singer writes: > I don't think we should mix up what's needed for sub-type > registration, with establishment of the top-level type. Yeshwant can > and should cite examples in the industry, but it's not for him to > register other people's formats, of course. As a general rule, I agree. But in practice, the best thing to drive the creation of a top-level media type is a bunch of subtypes that people *want* to see registered. And the best thing to drive that is minimally-encumbered interoperabilty. Dale From nobody Fri Nov 20 01:00:01 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0F33A1AD6 for ; Fri, 20 Nov 2020 00:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=dKmIFDcs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FpopPtAv 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 zsKoXmhPFA1J for ; Fri, 20 Nov 2020 00:59:58 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140623A1AD4 for ; Fri, 20 Nov 2020 00:59:57 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 74A655C0151; Fri, 20 Nov 2020 03:59:56 -0500 (EST) Received: from imap21 ([10.202.2.71]) by compute1.internal (MEProxy); Fri, 20 Nov 2020 03:59:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=zZwbSyB4MKMMxsdF01qjLDXaG9+u8tr +/CAp1PRep5c=; b=dKmIFDcsvVmVIlMQrivYMaF3Evk8urYejtrg4/48+3GTiGE b40hm+zvme+ED8PAPxU5jjlLp84Z77u5KT+dU/CiNX4cnmsMNMXMWLxV62qiuXwG lrX329K0G3VMhOyWYhioNgXTjhHSCnUfBHdpBP23SyLR05cbC9VfbgyQNFu9QH4v MtipXN7FwOfi2d4tdGsvp4GLK/a3q2HdPIhtT8fE44SuuqbvX9sKruurQi+bUD0Q mWJ77CX0K5w07a7as6EnlleWUBm/u4765s2dRxzlT4LbDfnhMYFlYS+7989A4l8A r+qVen98LrwxGylqORfo5+7NlQqQAomPyQcL+Vw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=zZwbSy B4MKMMxsdF01qjLDXaG9+u8tr+/CAp1PRep5c=; b=FpopPtAvLaDHTvNDuN87kh 09oU36cjkQOr5xZ3S2JzHzyuSPSyfV+4hBIBQD+v05QBJs9CnuoPddAbbSxIJ5Eb 6wp0k89AEi466D4Oomqql5XDAAC5DDZWzivwxXk4RoBjVNxclULSxIuUQ3rS7hia xIiy9v7MDkIO1SPBKSgiZ4NBxJwgzh+ykJUemLjk6QBdBYzIkfw0a7rVCkxXfHAP pADLOkYUSfLc0n9vtnN35KspkALrmQAFN9TvM9JkeTpT8RebV93Qerws/YX22b2I ZmQHnmuJsn8mSHFG62pwOwZYPZOdG3s297aI+4gPQGxcUROKSrqAnzJ5g2xlFHLA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefledgledvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecuggftrfgrthhtvghrnhepgeetvefghfevgeevjedvffdtueefjeelveeltedt ffektddthfekfeefffeivddtnecuffhomhgrihhnpehivghtfhdrohhrghdpsggsihifrd hnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep rggrmhgvlhhnihhkohhvsehfrghsthhmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 18C13660069; Fri, 20 Nov 2020 03:59:44 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <0bdb3691-90f8-4d31-bc6b-b76d4db0c77d@www.fastmail.com> In-Reply-To: <2f578f07-e110-12b1-ffd1-75e7937578be@dcrocker.net> References: <160337881491.27133.9061463868224826181@ietfa.amsl.com> <2f578f07-e110-12b1-ffd1-75e7937578be@dcrocker.net> Date: Fri, 20 Nov 2020 08:59:34 +0000 From: "Alexey Melnikov" To: "Dave Crocker" , DISPATCH Content-Type: text/plain Archived-At: Subject: Re: [dispatch] React: Indicating Summary Reaction to a Message X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 09:00:00 -0000 On Mon, Nov 16, 2020, at 3:06 PM, Dave Crocker wrote: > G'day, > > Murray and Barry advised pursuing this through Dispatch... > > This draft has had some useful discussion on the ietf-822 mailing list. > There is no email-related, existing working group for pursuing it > further -- it is out of scope for emailcore -- and it is much too small > to warrant its own working group. > > That makes AD-sponsored the most appropriate path for this draft, within > the IETF RFC stream. > > The goal is to have this published as Experimental. (If there is a > strong feeling that it could go straight to Proposed Standard, that > would be fine, though unexpected.) I like it. I might even implement it. > > > Abstract > > > > The popularity of social media has led to user comfort with easily > > signaling basic reactions to an author's posting, such as with a > > 'thumbs up' or 'smiley' graphic indication. This specification > > permits a similar facility for Internet Mail. > ... > > 1. Introduction...> This facility defines a new MIME Content-Disposition, to be used in > > conjunction with the In-Reply-To header field, to specify that a part > > of a message containing one or more emojis be treated as a summary > > reaction to a previous message. > > > > d/ > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-crocker-inreply-react-03.txt > Date: Thu, 22 Oct 2020 08:00:14 -0700 > From: internet-drafts@ietf.org > To: Ricardo Signes , R. Signes > , Dave Crocker , Ned Freed > > > > A new version of I-D, draft-crocker-inreply-react-03.txt > has been successfully submitted by Dave Crocker and posted to the > IETF repository. > > Name: draft-crocker-inreply-react > Revision: 03 > Title: React: Indicating Summary Reaction to a Message > Document date: 2020-10-22 > Group: Individual Submission > Pages: 6 > URL: https://www.ietf.org/archive/id/draft-crocker-inreply-react-03.txt > Status: https://datatracker.ietf.org/doc/draft-crocker-inreply-react/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-crocker-inreply-react > Htmlized: https://tools.ietf.org/html/draft-crocker-inreply-react-03 > Diff: https://www.ietf.org/rfcdiff?url2=draft-crocker-inreply-react-03 > > > > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Fri Nov 20 10:29:34 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3AA3A0115 for ; Fri, 20 Nov 2020 10:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=immr.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 yMSAwdYR0qpB for ; Fri, 20 Nov 2020 10:29:31 -0800 (PST) Received: from outbound-ip20b.ess.barracuda.com (outbound-ip20b.ess.barracuda.com [209.222.82.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10DF3A0DE1 for ; Fri, 20 Nov 2020 10:29:18 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2051.outbound.protection.outlook.com [104.47.46.51]) by mx10.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 20 Nov 2020 18:29:12 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CgUF/C1FaqLZwEzNN4tD217PsMONjnbbZi/eAo7Lsc4VO/xIfOTGS7DSBocQr97BR47csPO+pQXN3KU1yfYGm4zTTCeXBw27I6OwnU7qJUhhOZaIBrfHEn0qaQv6U1a2bHuZ1gL8lXI1uZpm8h+5Dgtbyi2hp9WVzOMXyfBA0DHgHAztoMItTsa0PsijbdGiVJGEPes885fsZeeCGPj6TOZELChQiV0XnXla2wSrcBOSt/DKu82r1Pljc8nYr5F/rU5LbgTUEKUlVzmdkEU331zfbWXYMhT9zv9jmy2LejT/DlAcdygWCASMfzkOHdxJ56ZXljvb+20lSpyoq7pHGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5dp2vWuEcSBtkfFMGO0FIpDtRGaEqEd+x5alwnrRNZg=; b=Omvv6Z2OJ3PFJ65/TffKU1bVbOBiv7sr7zR73kFQorAjhk/3sJxXd3SLGwVGeu9HQcWYE5YZgRXw+jopUImCb7a+y6S6lmMSxpK/4y6iBm7aeMuWPCJu6UvNcK5gPWEM29JAd+DDpLpJiI3/g3p00trVErrQQieOwzxBx8Vtc9FVIP92e1cQi3q+nkJ6UpbhFcZ+3a+YE65RIaKUU2zuCJQzFSe9+U2V0uaEUOvZDM79JuwCVN4p6lCLIHVMwD/aB3nNGt68GsxHggaQG0vHz5mrob2beobrG643IUdyEOQ6pKqfkvn80yl1Y5rlDvddoW30onXY9OQMkug+4xQqgQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=immersion.com; dmarc=pass action=none header.from=immersion.com; dkim=pass header.d=immersion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=immr.onmicrosoft.com; s=selector2-immr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5dp2vWuEcSBtkfFMGO0FIpDtRGaEqEd+x5alwnrRNZg=; b=WJMmvoSkraH5F9pB8UYwo0+oOMnD34MsyXI/fmkHWJY1NtnSQ9mVy9Jk9qjVuFe1AmhV7bLDUCNOL2k25IbuZgbbD9BE9sA+9lWoq2GSv96y6ndwxUu1UGlMcbW5sPukofOlYGnQF7fcxpSAkppsg+BDe6Nd9b0fzrcaP4XOXuQ= Received: from DM6PR16MB3912.namprd16.prod.outlook.com (2603:10b6:5:2b8::23) by DM6PR16MB3734.namprd16.prod.outlook.com (2603:10b6:5:2b5::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Fri, 20 Nov 2020 18:29:10 +0000 Received: from DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::d575:2e21:20a3:3488]) by DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::d575:2e21:20a3:3488%8]) with mapi id 15.20.3564.034; Fri, 20 Nov 2020 18:29:10 +0000 From: Yeshwant Muthusamy To: "Dale R. Worley" , David Singer CC: "dispatch@ietf.org" , Chris Ullrich , David Singer Thread-Topic: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] Thread-Index: AQHWvvR8uoFk+DxQoEaXrywl0SFcMKnRVucw Date: Fri, 20 Nov 2020 18:29:10 +0000 Message-ID: References: (singer=40apple.com@dmarc.ietf.org) <87wnygveuv.fsf@hobgoblin.ariadne.com> In-Reply-To: <87wnygveuv.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ariadne.com; dkim=none (message not signed) header.d=none;ariadne.com; dmarc=none action=none header.from=immersion.com; x-originating-ip: [47.188.32.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca448810-b00a-4a78-b34e-08d88d822c9f x-ms-traffictypediagnostic: DM6PR16MB3734: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vvDSyg8I+EBosiHWhbZXNFrc1uvbD4hpjoF/He7cjIbwPoun9CcpSgUf1GMFTnR86ZqV4w93XovsJLTa/JywmeLt6ePsoQs92nQhooo/ynGWb+6EK9O5jbTytvie6kSW0S2yWc5ozCDIgDvuxuhfxZg3ww1493TLICjvtHIe/jRRaCj8V0t5/H2veQgk6Ljw7uOTVFgQ3uzk4F79c0c4EkK/JDQfSTqwYuMA90gSDaVwpleUPDL7qbTQOGlv8O0Fwpg6SKwTdFis4j/2JxvdYyy+ORZh+bX2Z+zxdbv0eArxK2HkJuQH9hhKcLkhpJrexmBvAPjmPs2UjrV4wvAR7dBn8AZjL9LbVrKy1Cw7VBV7lE7vD3Aa1lX4dfy0NslU0jakVKCh3mboBEkBXYW06g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR16MB3912.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(396003)(39830400003)(366004)(136003)(52536014)(966005)(6506007)(316002)(7696005)(8936002)(8676002)(33656002)(55016002)(83380400001)(54906003)(110136005)(4326008)(53546011)(186003)(478600001)(86362001)(26005)(76116006)(5660300002)(66476007)(66446008)(66556008)(66946007)(64756008)(2906002)(71200400001)(9686003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: E3f0CbQ3maHKwqV9eIPq8GwcVv7Yb6b77wNc+KpJ47cclYOCoviXKSSWeWfgbGSh4hBTKbVCxYfYmVi2FRTEaMgzeBiW/8LxIFNCFDaFFnDLeTq8Gl0dvw91xfVNwPGKVDWuGwrhrJpdjM8i6yRnP3fEgGePAAgzsRtvlcFaZWxXC8jcMAvo0sLqgkXW5mWhPN7su3+IGY86Qnj8SI7PPrIl8n3tNeDyKzRFtPr2rxO65IILbjIo7L1M2JlXfOPYHdLhdjwIcSdG6709VUeaCjEEDdX2yrvg4kLA5EDy39qmEPDy7QSDu+0pPiey1LHJkUVXrELVr1GbTPIYXA5R7sZ9g/qdiy0IYoAJzTswVW2qbU1eY5uhQxgaMR31uSfFso4CG6B3+5oVLbHVn/R01Ddh5Z4VGBpbfFtBHfr+KFJM6p0hpSnt/0puvFsL7WhXKgLTQVsTIDcrwzvp1vTzyQYg67mF2pzncdxEDLskUh75RqHQCA8GQmNty0PtZoH/+MscY1LhcQOBLDompfhSxh5o79syld7tjm0mOxo9CN9IDylF94F8G+LrQqeKPc+4ZVWZUvwXQCvb+INEOTZnvr+TnytawAcCZFX0m/+EIbhXOc/XQZkWzgaqO/SnlYcew4DmLwuw+ubxh97lgp3vAQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: immersion.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR16MB3912.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca448810-b00a-4a78-b34e-08d88d822c9f X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Nov 2020 18:29:10.5429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f05e41a-59b8-413a-ae19-d5df3dfd0fb5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GwtbwuGSqCk00ph0Yxc1EfSCxXZoOkFH05jxBGrz+2nLBwBWKPGwcdzV7OPmjqx1fAb5LpehrOPOqLkPDc4OWtjt84BLFbip3Hln0N5OKd8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR16MB3734 X-BESS-ID: 1605896952-893019-24036-1612-1 X-BESS-VER: 2019.1_20201120.1751 X-BESS-Apparent-Source-IP: 104.47.46.51 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.228322 [from cloudscan23-205.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS117783 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 18:29:33 -0000 Hi Dale, Not sure if you were aware, but I posted a new version of the haptics I-D l= ate Sunday evening: https://datatracker.ietf.org/doc/draft-muthusamy-dispatch-haptics/ It was sent out just in time for my presentation in the DISPATCH session at= IETF 109.=20 This new version (hopefully) addresses all the feedback that I received on = version 00, including draft registration of subtypes. Comments/questions welcome. Regards, Yeshwant Yeshwant Muthusamy, Ph.D. | Senior Director, Standards ymuthusamy@immersion.com | +1 469-583-2171 -----Original Message----- From: Dale R. Worley =20 Sent: Thursday, November 19, 2020 10:20 PM To: David Singer Cc: dispatch@ietf.org; Chris Ullrich ; Yeshwant Mut= husamy Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media = type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] David Singer writes: > I don't think we should mix up what's needed for sub-type=20 > registration, with establishment of the top-level type. Yeshwant can=20 > and should cite examples in the industry, but it's not for him to=20 > register other people's formats, of course. As a general rule, I agree. But in practice, the best thing to drive the c= reation of a top-level media type is a bunch of subtypes that people *want*= to see registered. And the best thing to drive that is minimally-encumber= ed interoperability. Dale From nobody Sun Nov 29 06:13:23 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22683A1539 for ; Sun, 29 Nov 2020 06:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 8D-RPwb32jdz for ; Sun, 29 Nov 2020 06:13:20 -0800 (PST) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D6A3A1536 for ; Sun, 29 Nov 2020 06:13:16 -0800 (PST) Received: from [192.168.0.109] (c-24-130-62-181.hsd1.ca.comcast.net [24.130.62.181]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0ATEGsdC006966 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 29 Nov 2020 06:16:55 -0800 Reply-To: dcrocker@bbiw.net To: dispatch@ietf.org References: <160337881491.27133.9061463868224826181@ietfa.amsl.com> <2f578f07-e110-12b1-ffd1-75e7937578be@dcrocker.net> <0bdb3691-90f8-4d31-bc6b-b76d4db0c77d@www.fastmail.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Sun, 29 Nov 2020 06:13:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <0bdb3691-90f8-4d31-bc6b-b76d4db0c77d@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] React: Indicating Summary Reaction to a Message X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2020 14:13:22 -0000 On 11/20/2020 12:59 AM, Alexey Melnikov wrote: > I like it. I might even implement it. Excellent. Anyone else have comments? (I've also gotten an initial expression of interest from someone with Thunderbird.) What are the next steps for getting this published? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Nov 30 09:56:26 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694813A1074 for ; Mon, 30 Nov 2020 09:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 bfVUI59dpYbp for ; Mon, 30 Nov 2020 09:56:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91993A105B for ; Mon, 30 Nov 2020 09:56:19 -0800 (PST) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0AUHuE52065716 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 30 Nov 2020 11:56:15 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1606758976; bh=t0xFtF8hDvXzhyaecMCnSzzGrq8OguNFI7XjDN/HR2I=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=iXhyeZSWPHrOq2ZOqIhyrD6t2Yvbd9jdKOdS+4XjUeEgQvmP1O1zK+8thrz8xbsyT xiUcRL9rVJ/NOzDkOO+hI9LHgbHdbdqjjcEvTdCFmhdQrLijTyxEPpGlk2b6t4/ETm XPG6VH1endwAfRYtC0n874BJWfWt77Pw6lfx3m6U= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Ben Campbell , "dispatch@ietf.org" Cc: Alex Gouaillard References: <085505e3-9899-f817-b6df-db8022d52e26@gmail.com> <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> From: Adam Roach Message-ID: <06c5e46a-49b4-8e04-78ed-4f343268ce7a@nostrum.com> Date: Mon, 30 Nov 2020 11:56:09 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> Content-Type: multipart/alternative; boundary="------------39059C837EA2F45F44FEF870" Content-Language: en-US Archived-At: Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 17:56:25 -0000 This is a multi-part message in MIME format. --------------39059C837EA2F45F44FEF870 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Having read through the proposal and watched the corresponding segment of the DISPATCH meeting from two weeks ago, I think that having something like this standardized would be very useful, both for the handful of broadcasting tools that exist as well as for the various WebRTC broadcast networks that are being deployed. So I definitely think we should pursue this work in the IETF. It's a little less clear to me whether we want to slot this into something like MMUSIC or to create a short-lived working group. I'm leaning towards the second, for a couple of reasons. First, I found Ted's comments at the DISPATCH meeting to be kind of illuminating as far as the kinds of additional work that might be necessary (and I have my own list of things that might need some refinement, like negotiation of authentication mechanisms); and that nudges the effort into a "maybe a little larger than just one work item in a long-standing working group." More importantly, this work straddles the real-time media and web disciplines, and I'd like to make sure we have people from the latter group putting eyes on it. I seriously doubt we can get HTTP experts showing up at MMUSIC, but there's at least a fair chance that we might get them interested in a lower-volume mailing list such as a dedicated WHIP WG. I think this mirrors, for the most part, the tentative conclusion that came out of the DISPATCH discussion earlier this month. If we decide to take this path of creating a short-lived WG, I'm happy to help craft a charter and plan to be actively involved in the technical work. /a On 10/28/2020 3:10 PM, Ben Campbell wrote: > Hi Everyone, > > Did anyone have feedback or other thoughts on Sergio’s proposal? > > Thanks! > > Ben. > >> On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo >> > > wrote: >> >> Hi all! >> >> >> While WebRTC has been very successful in a wide range of scenarios, >> its adaption in the broadcasting/streaming industry is lagging >> behind. Currently there is no standard protocol (like SIP or RTSP) >> designed for ingesting media in a streaming service, and content >> providers still rely heavily on protocols like RTMP for it. >> >> These protocols are much older than WebRTC and lack by default some >> important security and resilience features provided by WebRTC with >> minimal delay. >> >> The media codecs used in older protocols do not always match those >> being used in WebRTC, mandating transcoding on the ingest node, >> introducing delay and degrading media quality. This transcoding step >> is always present in traditional streaming to support e.g. ABR, and >> comes at no cost. However webrtc implements client-side ABR, by means >> of simulcast and SVC codecs, which otherwise alleviate the need for >> server-side transcoding. Content protection and Privacy Enhancement >> can be achieve with End-to-End Encryption, which preclude any >> server-side media processing. >> >> We have been working on a proposal for a simple HTTP based protocol >> that will allow WebRTC endpoints to ingest content into streaming >> services and/or CDNs to fill this gap and facilitate deployment: >> >> * https://tools.ietf.org/html/draft-murillo-whip-00 >> * https://github.com/murillo128/webrtc-http-ingest-protocol/ >> >> >> We have already implemented it on Janus and Medooze media servers: >> >> * https://www.meetecho.com/blog/whip-janus/ >> * https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7 >> >> >> And added support into a WebRTC version of OBS studio: >> >> * https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2 >> >> >> We also plan to have an interop session on the next IETF hackhaton, >> that will allow to check the interoperability between different >> WebRTC implementations. >> >> >> What would be the best way of moving this forward? Obviously, any >> feedback will be very welcome. >> >> >> Best regards >> >> Sergio >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------39059C837EA2F45F44FEF870 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Having read through the proposal and watched the corresponding segment of the DISPATCH meeting from two weeks ago, I think that having something like this standardized would be very useful, both for the handful of broadcasting tools that exist as well as for the various WebRTC broadcast networks that are being deployed.

So I definitely think we should pursue this work in the IETF.

It's a little less clear to me whether we want to slot this into something like MMUSIC or to create a short-lived working group. I'm leaning towards the second, for a couple of reasons. First, I found Ted's comments at the DISPATCH meeting to be kind of illuminating as far as the kinds of additional work that might be necessary (and I have my own list of things that might need some refinement, like negotiation of authentication mechanisms); and that nudges the effort into a "maybe a little larger than just one work item in a long-standing working group." More importantly, this work straddles the real-time media and web disciplines, and I'd like to make sure we have people from the latter group putting eyes on it. I seriously doubt we can get HTTP experts showing up at MMUSIC, but there's at least a fair chance that we might get them interested in a lower-volume mailing list such as a dedicated WHIP WG.

I think this mirrors, for the most part, the tentative conclusion that came out of the DISPATCH discussion earlier this month. If we decide to take this path of creating a short-lived WG, I'm happy to help craft a charter and plan to be actively involved in the technical work.

/a


On 10/28/2020 3:10 PM, Ben Campbell wrote:
Hi Everyone,

Did anyone have feedback or other thoughts on Sergio’s proposal?

Thanks!

Ben.

On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

Hi all!


While WebRTC has been very successful in a wide range of scenarios, its adaption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it.

These protocols are much older than WebRTC and lack by default some important security and resilience features provided by WebRTC with minimal delay.

The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality. This transcoding step is always present in traditional streaming to support e.g. ABR, and comes at no cost. However webrtc implements client-side ABR, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding. Content protection and Privacy Enhancement can be achieve with End-to-End Encryption, which preclude any server-side media processing.

We have been working on a proposal for a simple HTTP based protocol that will allow WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment:


We have already implemented it on Janus and Medooze media servers:


And added support into a WebRTC version of OBS studio:


We also plan to have an interop session on the next IETF hackhaton, that will allow to check the interoperability between different WebRTC implementations.


What would be the best way of moving this forward? Obviously, any feedback will be very welcome.


Best regards

Sergio



_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--------------39059C837EA2F45F44FEF870--