Re: Expiration impending: <draft-thubert-6man-ipv6-over-wireless-06.txt>

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 23 November 2020 00:29 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CE73A1082 for <ipv6@ietfa.amsl.com>; Sun, 22 Nov 2020 16:29:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=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 qe4Y7T7WUmrz for <ipv6@ietfa.amsl.com>; Sun, 22 Nov 2020 16:29:39 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E983A3A1081 for <ipv6@ietf.org>; Sun, 22 Nov 2020 16:29:38 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 67EDA389B6; Sun, 22 Nov 2020 19:30:49 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tVv44fd9FxTU; Sun, 22 Nov 2020 19:30:48 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 49523389B5; Sun, 22 Nov 2020 19:30:48 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B4FB77D; Sun, 22 Nov 2020 19:29:35 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: "Pascal Thubert \(pthubert\)" <pthubert=40cisco.com@dmarc.ietf.org>, 6man WG <ipv6@ietf.org>
Subject: Re: Expiration impending: <draft-thubert-6man-ipv6-over-wireless-06.txt>
In-Reply-To: <25884378-4e75-73b7-8a73-429f7b5d0a43@gmail.com>
References: <160603202606.8188.11893701417034577472@ietfa.amsl.com> <7B0EBC9E-4831-4005-98D9-5010CD1097F6@cisco.com> <25884378-4e75-73b7-8a73-429f7b5d0a43@gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Sun, 22 Nov 2020 19:29:35 -0500
Message-ID: <21672.1606091375@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GtETzWj-jo8tjr_l9YJgLDT8D3E>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Nov 2020 00:29:40 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    > Can you explain why this is proposed as a standards track document? As
    > far as I can see it doesn't define any new protocol elements.

because it's a particular way of doing things, and there is a compliance
activity around implementing and testing it.

    > If it is, as I suspect, simply an explanation of how various other
    > standards fit together to provide WiND, it might be equally useful as
    > Informational, as well as much easier to get it published. Viewed that
    > way, I think it is very useful work.

Would you be okay for an RFP to go out citing an informational RFC?
True, the trade tribunals don't know the difference, but we do.

    > (There is also the standards track option of an Applicability
    > Statement, which the IETF uses very rarely and most people don't know
    > about.)

I'd be happy with using that.

    > One comment you would surely get from reviewers is that the Security
    > Considerations should at least contain a summary of issues, even if the
    > details are in the references.

    > One nit is that if you want to promote the "WiND" acronym, it should be
    > included in the document title.

I'm skeptical that this TLA will survive :-)


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide