Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D16512DD85; Sun, 17 Feb 2019 18:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 qia7W5ECxQpo; Sun, 17 Feb 2019 18:35:52 -0800 (PST) Received: from mail-it1-f169.google.com (mail-it1-f169.google.com [209.85.166.169]) (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 42A711295EC; Sun, 17 Feb 2019 18:35:52 -0800 (PST) Received: by mail-it1-f169.google.com with SMTP id m137so7960871ita.0; Sun, 17 Feb 2019 18:35:52 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5HqE8A1OCApYcSNaeoqfRusUAXY5F+9z044nRYkqadc=; b=JNCNnw2hjVfuYcT8vWCvhb/UGVS8hJCf04XW79lneBq1lb6ybkBLbDSrn2A679OvAa tk7KmtNKva1dYxFEol5kpFy2J/VnjArgk4Va9Zj531XLERKmFYBA/AAeNd68CJfSRdrA zqFoh0b0+hrIvgTujJ7RuR16FTJCPW3AjhYq7eIlz7kH5XWnl08nkU5poWcyBMcbWy5t ODdUZDsvbnpQIevdeP5G+up91fTnuK4qJRVMswMlvGmm0fWkQTXXNNplIlBEmItlO4nL 02lS5bAD7mcaNQWXma1/RkLVCbnWDE1sY+a1TFxUaVDCiNISfdWKdW172bx6VmTZ1Ohk 7Lmw== X-Gm-Message-State: AHQUAuaMiETw3+zJzASroSjXEiyyWRzg2jbjUfLjzcO27HlsRszfKPyf bFlYdkQ4oa09Bv9Lc0QTBgN4CEGEcedlazwl6Oc= X-Google-Smtp-Source: AHgI3IasvJEmZ0sNuxa+cWwEteZ32N+/aO/h1mY5i6E1fzrGIHBC3IzxqA+45aB1Zx9fOVyY5JqeH/VHE8sb3LIn3qQ= X-Received: by 2002:a24:dd0a:: with SMTP id t10mr10544335itf.122.1550457351104; Sun, 17 Feb 2019 18:35:51 -0800 (PST) MIME-Version: 1.0 References: <154886569351.10484.4703007670359734409@ietfa.amsl.com> <1317558B-24DD-4CB7-BBB6-95E5946EF87A@mnot.net> In-Reply-To: From: Barry Leiba Date: Sun, 17 Feb 2019 21:35:39 -0500 Message-ID: To: Mark Nottingham Cc: IETF , IETF SecDir , Kathleen Moriarty , draft-nottingham-rfc5785bis.all@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-nottingham-rfc5785bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 02:35:55 -0000 > > If the document says to see the registry for registration instructions, there had better be instructions there, no? > > Yes, but if we put the instructions in the RFC, people are likely to follow them -- even when they have been > changed down the line. Also, it creates confusion as to whether it's necessary to update the RFC if they change. > > The text we're discussing is sourced from RC8288: > https://tools.ietf.org/html/rfc8288#section-4.2 > ... which didn't have any such discussion around it. If we're going to continue this, I'd like to hear from IANA > itself about what level of instruction it'd like. As I've said, the last time around (8288), I got feedback from them > that such a level of detail in the RFC was counterproductive, and that we could trust folks -- and our > process -- to do the right thing. I agree with all that, but that still misses the point: When someone reads in the RFC that they should follow the instructions in the registry, and they go look at the registry and see nothing, what are they to do? b