Re: [Sidrops] AD Review of: draft-ietf-sidrops-rfc6482bis - "A Profile for Route Origin Authorizations (ROAs)"

Job Snijders <> Sat, 09 September 2023 23:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 43734C151522 for <>; Sat, 9 Sep 2023 16:16:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Status: No, score=-7.104 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gtOXm0JMLt1V for <>; Sat, 9 Sep 2023 16:16:35 -0700 (PDT)
Received: from ( [IPv6:2001:4860:4864:20::31]) (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 (Postfix) with ESMTPS id 855D0C15109C for <>; Sat, 9 Sep 2023 16:16:35 -0700 (PDT)
Received: by with SMTP id 586e51a60fabf-1d577c89a4fso1046047fac.1 for <>; Sat, 09 Sep 2023 16:16:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1694301394; x=1694906194;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aSGJTtY8vY8Pz8VEiEy54uhFtOHBpXRCgX1YnHzB9tA=; b=rb5IE1eI8hA9R0abQS5CHCVjfE+r0xzqQ97mAlxA0/xP8FDYHuyGPeE5vHD3pCMw0h cemBbnqOFIpIirUTxAcaqSZaqeCbcMGHMLCcDVa0WHIO6P8pwiF0BBAQGCLMiSGYaWGw TaXZl2cGVHleDNe7Pd++Zxyl4oULPoNBbOV/A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1694301394; x=1694906194; 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=aSGJTtY8vY8Pz8VEiEy54uhFtOHBpXRCgX1YnHzB9tA=; b=D5VcSkffKpqJFrV/tmtd6XXXJObvYmWkDT8/ui33qKbqCeLvLiTq1UZqKdRD3GVoKr nNX9M8UyHWzBvALDkvqdiky2H1L/3QqgXPEbpRWEve9Zclv2llEw055lTaoRbjOrtexY cqQl79stnNQfeptkLXibDPR7M1B7Uyq7SB0ohgWX912qZuSoWkznpJfwNCaVoHts8PCQ scd83f/JbK7TiGdQ7SpbPf2nLfxeSJOJ+2jSlV1MeDE2jin5SzBumQbpnkNCGWuGrvzv MNo1/Uysi7If3yADTP1xjTIJ/9obAp6hltlCPqGA+P675rnk1BsRRoB0kB3xor9MbygC 2Igg==
X-Gm-Message-State: AOJu0YzSzLxgjcqHX5zWxQ7QapWTPrEVDwik0ZgFA4M3CrtuZrnO3sMG R6xxYCP9V42vbIZa7ClU7z8X0l+mtTrgZ/8ZAe77RznGvvxuyTnOTsM=
X-Google-Smtp-Source: AGHT+IGvDn3g1/JbHNw6xtY6wbT9cBDlAyQS6Qr9ANNrK8ScA+OrlaIthp7FE8lI9TiXPt/SKe+C+GttTGumBIPWA4E=
X-Received: by 2002:a05:6870:e305:b0:1d5:6149:90c with SMTP id z5-20020a056870e30500b001d56149090cmr7004312oad.23.1694301394650; Sat, 09 Sep 2023 16:16:34 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Job Snijders <>
Date: Sun, 10 Sep 2023 07:53:38 +0900
Message-ID: <>
To: Warren Kumari <>
Cc: SIDR Operations WG <>,
Content-Type: multipart/alternative; boundary="000000000000c55fc90604f54819"
Archived-At: <>
Subject: Re: [Sidrops] AD Review of: draft-ietf-sidrops-rfc6482bis - "A Profile for Route Origin Authorizations (ROAs)"
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 09 Sep 2023 23:16:39 -0000

Hi Warren,

In the RPKI world when it’s detected a “MUST” is violated, the profile at
hand is deemed corrupted, and thus validators will end up reporting errors
and ignore the entire ROA. (With “ignore” I mean, for example, no attempt
will be made to extract data from the ROA’s eContent to transform into RTR

For example, this following code is equivalent of what all sane validators
- each “MUST” is checked, and if there is a problem of any kind the code
jumps to the error path.

The internet-draft/RFC document style so far has been to document exactly
what’s valid; and not point out at each instance that if the object data at
hand doesn’t comply with the stated conformity requirement at hand it
thusly is invalid. And indeed, the “cop-out” route is quite unattractive.

I don’t see much value in rewording each “MUST” requirement as a “TRULY
MUST”, so do you have some suggestion in mind? :-)

Kind regards,


On Sun, 10 Sep 2023 at 07:25, Warren Kumari <> wrote:

> Dear authors and WG,
> Thank you for this document.
> I only have a single comment — throughout, the document says things like:
> S  Element maxLength
> "If present, the maxLength MUST be:
>    *  an integer greater than or equal to the length of the accompanying
>       prefix, and
>    *  less than or equal to the maximum length (in bits) of an IP
>       address in the applicable address family: 32 in case of IPv4 and
>       128 in case of IPv6."
> Oh, fine. But, what happens if the maxLength is **less** than length of
> the prefix? Should implementations simply ignore this prefix? Should they
> view the ROA as invalid? Should they call the police and report it? This is
> just one example of this sort of concern, there are a bunch of similars
> ones too.
> I guess that the argument could be made that this document only specifies
> a profile, and that it is the responsibility of other documents to handle
> this (and other violations), but that feels like somewhat of a cop out…
> W
> P.S: I had a quick look at RFC6488, RFC9319, and a few others, and didn't
> see that particular issue handled, so I don't really know if other
> documents are addressing all of the errors….