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]