Re: [Gen-art] Genart Last Call review of draft-freed-smtp-limits-06

"Murray S. Kucherawy" <superuser@gmail.com> Sun, 17 September 2023 21:53 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADE5C151097; Sun, 17 Sep 2023 14:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsvqEfSdJJsA; Sun, 17 Sep 2023 14:53:30 -0700 (PDT)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07365C14CE33; Sun, 17 Sep 2023 14:53:30 -0700 (PDT)
Received: by mail-wr1-x42e.google.com with SMTP id ffacd0b85a97d-31f85854b9eso385391f8f.0; Sun, 17 Sep 2023 14:53:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1694987607; x=1695592407; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mDRW/NFLcVAwxd59N7qUj1SIkw2K4BkFd7nkfz2ZGks=; b=ioypUstTLvkNJCDt4D/U6LzrncJyEcC40O0vlCXh22hRs+p0WdZJJfeqp57rT34tuG ewSsic2r3MupidD+rDLXIEpO/oAUyqJKEskoOPIJQK647zUzuXPGa7XeCqDKlQ/htCal FIbmDbsGjt6mhM5BnQmthkU7MO60Ptc7OgHl6daQNxmR1GvkZBXsnBzPXiJlo9TqSw2G RHzJTsQgK8nhbqXT/rWXp90w+btQYtFWl7hYDIa0g9lX7oXFDyIRovQxKX8MmPQGrKlp R14z7rZ1Y3HGz1mQ6yz5/TOazZz+pQQciARJZZdTR1ehuAiQpR9rKG8bExxQETlgEUTV uURA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694987607; x=1695592407; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mDRW/NFLcVAwxd59N7qUj1SIkw2K4BkFd7nkfz2ZGks=; b=hBV8p1S84QqsO02Eswy1VW4zeZWFrGhPL4PWK3ELCKRdaU6WTMk6IHsREfHbYlub4p 1KxUJs5tYbiYg/DcXT7MpLbhY1AAIU2SeTLq0hCYKg2E4Er9BKpLk1FyGu1WS6458boZ VOmwhtxSNomGj6jibRP3T1B4IJ50mCGlC7NFP9KpA+ScApWIN8pJ0AsIcMjnMI2CQKjA DP6bPW/hDtU6ysRGF6wXZnUvJsqQZuyI5L5dd9fs3Ii8OTfdEiRBk53PFIrq7f/8rCQh /XlQMEAH9gwi2HgL5gw8MT3UErJqP7s5dxE+rsYncLSca6aQWwlFVCJ4oqGL69aN2o63 Wk+A==
X-Gm-Message-State: AOJu0YxG5YyDwXY5lb75wW7E6XDweKYI7qIHvrmqurX/cD5gvHBIhWMb /8GqgmxayAvmRwfJGteBHlwkCb6i5fHtLp0SVCEU3MpMC6wMVw==
X-Google-Smtp-Source: AGHT+IGSvoE09Razhwtv1xn33ZFd/wx7WClbTo5NzP7WkJQtWs27lTuZn3DFTlevOWbI61wVJMIQhTDZpg4JZg5i1nk=
X-Received: by 2002:adf:ec4f:0:b0:31f:edc3:c5fb with SMTP id w15-20020adfec4f000000b0031fedc3c5fbmr5939709wrn.5.1694987607239; Sun, 17 Sep 2023 14:53:27 -0700 (PDT)
MIME-Version: 1.0
References: <b245ea64-3685-cc78-5dad-41539a92591a@alum.mit.edu>
In-Reply-To: <b245ea64-3685-cc78-5dad-41539a92591a@alum.mit.edu>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Sun, 17 Sep 2023 14:53:16 -0700
Message-ID: <CAL0qLwYGHGT=+Oh2_FF0m7gkJwgMQVyn9OdJh7GNYtSmRuNT+Q@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: General Area Review Team <gen-art@ietf.org>, draft-freed-smtp-limits.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003a727a0605950e9a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/-dh8pxMJ6kVG-1gyE-VdwPbHfe8>
Subject: Re: [Gen-art] Genart Last Call review of draft-freed-smtp-limits-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Sep 2023 21:53:30 -0000

On Fri, Sep 15, 2023 at 9:49 AM Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

>
> Section 7.2 seems to conflate two things:
>
> - the information that must be provided in a specification
>    document that registers new limits
>
> - the information that is to included in the registry itself
>
> ISTM that the registry itself should contain the limit name and a
> reference to the specification document. It might also contain the value
> syntax, or at least an indication if a value is allowed.
>
> The descriptions of semantics, restrictions, and security considerations
> don't lend themselves to inclusion in the registry, but should be
> clearly spelled out in the specification.
>

This is an interesting observation.  I suppose I overlooked it because by
now I'm used to both types of registries.  A good example of this style is
the media types registry, where some of the details (e.g., option names)
that you might normally expect to find in the specification document only
are actually also required to be present in the registry.  That model of
registry has been around for a pretty long time and we seem to be fine with
it.  But most other newer registries are just a table of the reserved name
and a reference to the specifying document, with all of the details
typically stored in the latter, with maybe a "status" column included.

I'd be inclined to split the difference, and say either the registry has to
contain the limit value's syntax, or a reference to the defining document
where such can be found.  We allow this in the media types registry for
security considerations, for example.


> Also, the request for the new registry should probably include its exact
> name ("SMTP Server Limits"?), and that it should be included within the
> "MAIL Parameters" protocol registry.
>

I agree, precision here is never a bad thing.

-MSK