Hi Andy,
I've changed the part in question and replaced SHOULD with MUST in
revision -12.
Cheers,
Oliver
On 12/4/25 2:50 PM, Andy Newton wrote:
Hi Oliver,
I just looked at the diff for -11 and most of my points have been resolved.
Thanks very much for that. I just want a little more discussion on one
point.
On 03-12-2025 2:44 PM, Oliver Gasser wrote:
### Skipping Errors
237 Upon encountering an erroneous entry in a prefixlen file,
consumer
238 implementations SHOULD skip that entry, log the error, and
continue
239 processing the remaining entries.
Under what circumstances is it ok for a consumer to continue
processing an
entry it knows to be an error? If you think there are none, what
about this
proposed change:
Upon encountering an erroneous entry in a prefixlen file, consumer
implementations MUST skip that entry, and SHOULD log the error,
and continue
processing the remaining entries.
Consumers should be allowed to process erroneous entries if they can
derive the intended entry.
If this is to stay as a SHOULD, a qualification should be given (see the
IESG statement on BCP 14 language).
If the intent is to allow consumers that can derive information from
erroneous entries to continue
processing the entry, then perhaps:
Upon encountering an erroneous entry in a prefixlen file, consumer
implementations SHOULD skip that entry, log the error, and continue
processing the remaining entries if accurate information cannot be
derived from the erroneous entry.
However, in the spirit of keeping things simple, would you consider
changing
this SHOULD to a MUST? Doing so would stop two consumers from processing
different data sets from
the same file.
Consider an operator who publishes a CSV file and uses a reconciliation
process that does skip the entries.
That operator could be unaware that they are publishing a dataset with a
bad entry, and that
some of the consumers of their data do process the entry while others do
not. Diagnosis of this
scenario is more difficult than a scenario where all parties skip
erroneous entries.
-andy
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
