Re: [secdir] [Last-Call] Secdir last call review of draft-thaler-iftype-reg-05

Suresh Krishnan <> Tue, 29 October 2019 03:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07525120047; Mon, 28 Oct 2019 20:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I0Ebb-AM_PHl; Mon, 28 Oct 2019 20:17:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E6BB8120046; Mon, 28 Oct 2019 20:17:44 -0700 (PDT)
Received: by with SMTP id h202so4874658ybg.13; Mon, 28 Oct 2019 20:17:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0SqsQqGhJSXSYi9gr3RIuFwq9w7blgEQRYYkvWBjIxQ=; b=HJ7EeUxe4IGB78EEEraxCjHglw8Zxf2v2LYwaVRtQbV4x9WDCijkF40+KXAaIWlYx5 WnJ/0OaTVWkrYSzYCRQvQ9B1NFlf5uD1N4onukFSpqL5m4IJgrQbK/Yq9IcTjRZDlLbi rwsr3p/epTgUloNHQAL9HqBq5txmck4+ZCfJc4uvzPQ3zj39rReR+2IxGG8+/YeI3/YJ GqY/DMGRH6Lb7WyP5JAwFbJgTgyKuQERe2hGGcsvbWFnlGNSckjInBuWCfTh/mQx1+x2 zC3ZY0gU9ASmsaEtAP/1qs9RTDobx+aBQ0x0HeWUbb8t5SmghYP6jdg3DvHG0tBFvu3y llHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0SqsQqGhJSXSYi9gr3RIuFwq9w7blgEQRYYkvWBjIxQ=; b=Wdgs/twuji6fSjSrlnfF0LTS2FbZy160PSYQ+TDnb0I2glMX9B6ajC8OKNh1jWJkpA mv4B66zTs4g0NhyCNaAmUup6VKOD0j0GIC74GJ1bmFObjWH3cllvWt5Lkrrd9Jrz6LRx rsZ1We9G/oRYwkMHqtSyJfMlBdNx/6BdgoIpo2K7CxrR3Rhvsr4UxF+AUkk3PQbd+2dn HvLQFtWTW1uN/hvlVrIX8nXjPp7XD/45VPpMXzSv4yJ2IYLRTtH6vp+v/W7aX1xQJRY+ Bi103d86t0DAJD9hcqbhBBsWmKaPt94gNqGIiVT00FGCQLTxWRhosi3o696o1+PScLAd w01Q==
X-Gm-Message-State: APjAAAVBt5Nnx/NI2SkyyMB3uJSk/aNtq2CdM3xoQk0iW39Zsq6I41gM dwdQyS/7BGvGDPYuGo5ESJ6mD0sr
X-Google-Smtp-Source: APXvYqxQdngGwSBabcArW/bAJG6dJshRlUED5FaKJ1//6JejmQUyNrRpnHlGl6VrrBrh70KBf3Xetw==
X-Received: by 2002:a25:b845:: with SMTP id b5mr6139494ybm.288.1572319063879; Mon, 28 Oct 2019 20:17:43 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id q2sm3449936ywd.12.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Oct 2019 20:17:43 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Suresh Krishnan <>
In-Reply-To: <>
Date: Mon, 28 Oct 2019 23:17:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Melinda Shore <>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <>
Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-thaler-iftype-reg-05
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: Tue, 29 Oct 2019 03:17:50 -0000

Thanks a lot for your review Melinda! Authors, will you get a chance to look at this before the submission deadline?


> On Oct 25, 2019, at 11:07 PM, Melinda Shore via Datatracker <> wrote:
> Reviewer: Melinda Shore
> Review result: Has Issues
> This document is an update to RFC 2863, providing revised
> guidelines for the definition of new interface types and
> tunnel types.  In doing so it introduces some guidance for
> the development of YANG ifType and tunnelType modules, 
> which was not previously covered elsewhere.
> To be honest I found the writing occasionally difficult
> to follow, as the text was not as well-structured as we
> usually see in mature IETF documents.  Even the abstract
> doesn't really get to the point until the last sentence.
> Similarly, section 7 opens with a comment on some misguidance
> on request submission in the MIB module, while I
> think it would be much clearer to say "Requests may be
> submitted to IANA via email at, or via
> a web form at" followed
> by some text pointing out the misguidance.   The 
> request to IANA to update the MIB module could be dropped
> down into IANA considerations (section 8).
> Nit:  In section 7 "iana&" should be ""
> Security considerations:  It might be reasonable to argue
> that a document providing guidelines for registering a 
> new MIB or YANG interface type module has no security considerations,
> but it's worth noting that other documents do include some text.  
> See, for example, RFC 6117 on the registration of ENUM services,
> which does provide guidance on security considerations to authors 
> of new Enumservice Types), and RFC 8436, on DSCP Pool 3 IANA
> registration procedures, points authors to the documents
> defining new DSCP values.  Sections 6.3.1 and 6.3.2 could/should
> provide some broad guidance on writing security considerations
> for new ifType and tunnelType modules.
> So, I think there's a bit more to say there but ultimately this one 
> would be up to the OPS ADs.
> -- 
> last-call mailing list