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]

Reply via email to