Re: [regext] Murray Kucherawy's Discuss on draft-ietf-regext-data-escrow-07: (with DISCUSS and COMMENT)

"Murray S. Kucherawy" <> Thu, 09 April 2020 14:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9AE93A046D; Thu, 9 Apr 2020 07:19:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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_DNSWL_BLOCKED=0.001, 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 EBe6Ero-zpY9; Thu, 9 Apr 2020 07:19:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E040B3A087D; Thu, 9 Apr 2020 07:18:37 -0700 (PDT)
Received: by with SMTP id o14so511502uat.13; Thu, 09 Apr 2020 07:18:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A+wx19lOcnAH6bKbrTFopKnIt3sUdD1w5BfyMsI3X/U=; b=Eyc5hh9BG5ec3zOObjQwAtl1micCksFzq4d0+XayBB6JVvKaXzQ41Vkvez9B9F9uNh Sg0TMYAJiXZGebvs4dnotJ5BOelLzzl7rQVsX2+pkiPDLNJoBLj6HW6Q2dNMtC7+euPN 989sIoWYOh8x4xYhmFVh9d15pDwfFl3DwfxibrGQMDwGtYsVsQizFjHA/U71CEubrVyk wX/vKw/FsrihR4vb/E5aJOjXl/pDqUUztVf+fUYmBq+AQ1bf1BxpGbK70DwH2t872V62 98VLbslBtR3sAp39eOqeo2LRPyp0YwW+UfjQ+g0HFP/ciaHvfCCFBOFO12vgXgt9KPtu S5lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A+wx19lOcnAH6bKbrTFopKnIt3sUdD1w5BfyMsI3X/U=; b=f5oLrUxWwnmFVmTc2EY7YnPfw82VBjeI7D7jMKhFDaoVcGTTpKvoVUBw7SnFrsnS0s OiEkOLZCrPK6ZX3xAb9WYREXdjRN2OH2lp48tfYo1ykxC4/LHDZBrrVyIuN9fUF7H2vJ nehZLr8U7XRfZafDsNZoeh9FQqcC+F5m6qngi1MfK2Rmo4MmpkejMuXXvOk8XV6t8AGv 0CxedALdlzvHI3ZfQXeeFjll1vLwtcTeVKK1v+HUDHUmswgWXENgCilCvylSGrNtcXEU mYnZIxcpkQHXic2H7leKOc0oQYHbP/+ufik0LViB4bFo2sxk43QeN2iNxvEVG8ZE2lHi 2YPg==
X-Gm-Message-State: AGi0PuaZ4byVrjYRbZyoIYHHCbofg7UCi9aXkHi9ObdKJujKenLYf4q9 CdyqFlnIhznsTOS/4IH4OWlyRiRI0P6EAU20xqg=
X-Google-Smtp-Source: APiQypIHH3kYnPFvqADEUyLyskA/gSs7Nb6RBat14YDuRXO2wk88HQU+pNq0/qvRoNB0s9ggM5BJVs8xbOAeVXhveg4=
X-Received: by 2002:ab0:710a:: with SMTP id x10mr9124275uan.76.1586441916724; Thu, 09 Apr 2020 07:18:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: "Murray S. Kucherawy" <>
Date: Thu, 09 Apr 2020 07:18:25 -0700
Message-ID: <>
To: Barry Leiba <>
Cc: The IESG <>, regext-chairs <>, James Gould <>, regext <>,
Content-Type: multipart/alternative; boundary="000000000000e73b9405a2dc4a3e"
Archived-At: <>
Subject: Re: [regext] Murray Kucherawy's Discuss on draft-ietf-regext-data-escrow-07: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Apr 2020 14:19:06 -0000

On Thu, Apr 9, 2020 at 6:45 AM Barry Leiba <> wrote:

> > Section 5.1.3: "This element SHOULD be present in deposits of type
> Incremental
> > or Differential."  This makes it sound like a deposit of those two types
> not
> > using this element might be non-compliant.  I suggest instead "This
> element is
> > only used in Incremental and Differential deposits."  (Or instead of
> "used",
> > maybe "meaningful".)
> >
> > Section 5.1.4: " It SHOULD be present in all type of deposits."  Same
> issue.
> > Maybe "It is valid for use in all types of deposits."
> I don't understand this: "SHOULD" means that "there may exist valid
> reasons in particular circumstances to ignore a particular item, but
> the full implications must be understood and carefully weighed before
> choosing a different course."  The text in this document isn't saying
> that these make sense in the places they specify: the document *does*
> mean "SHOULD" here.  Certainly, "there are no relevant items to
> include" is a valid reason.
> What's the point of your objection?

The way I have always seen SHOULD used, consistent with that definition,
causes me to read 5.1.3 in a way that expects the "delete" element to be
present other than in exceptional circumstances.  However, I don't think
(and based on his comments I believe Robert agrees, though he can correct
me if not) that the absence of a "delete" element is really unusual; a diff
might genuinely -- perhaps even commonly -- only contain new items that
need to be applied to the backup with no delete actions.  The same goes for
5.1.4, where "contents" could legitimately be omitted merely because the
diff describes some canceled registrations that need to be removed.

RFC2119 also says "In particular, [2119 words] MUST only be used where it
is actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions)" and I don't
thnk that's the case here.