[Sidrops] Modification of draft-sidrops-bgpsec-validation-signaling

["Borchert, Oliver (Fed)" <[e-mail]>]

Hello and I hope everyone is doing well these times.

I know it is already some time ago but during the presentation of the draft-sidrops-bgpsec-validation-signaling  (https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-01) during IETF 106 in Singapore, a discussion around the draft started that will change the current state of the draft and will revert all requests stemming from the discussion on the list that were made during the adoption call.
Before I submit the modification I want to query the list if the changes to be made are in synch with the working group.

To remind you, the original proposal (https://tools.ietf.org/html/draft-borchert-sidrops-bgpsec-validation-signaling-01) was to add a BGP path attribute for signaling the validation result of path validation in the same manner as described for prefix origin validation as specified in RFC 8097.  During the adoption call a discussion started to instead creating a new path attribute to just add the path validation information into the reserved flag of RFC 8097 and hence updating RFC 8097.

After uploading the draft 00 which reflects the version of the adoption call, we went ahead and added the modifications as they were discussed on the mailing list during the adoption call. The current form of the draft (01) reflects these modification by now updating RFC 8097 which included the modification of the PDU and subsequently the modification of error handling and clarification and renaming the attribute field names to reflect the correct meaning. The question that came up from our side if these changes warrant to obsolete RFC 8097 which would allow a much cleaner approach.

During the presentation in Singapore though multiple participants spoke up in favor of not perusing this path and keeping path validation as well as  prefix origin validation signaling separate. One major reason that was mentioned, was implementation related regarding mapping the zero value of the reserved field in filters which would not work anymore if we are combining both values going forward. On a personal thought regarding that issue, the RFC clearly states that the receiver MUST ignore the reserved field, so filtering on the reserved fields value is an implementation shortcut that breaks conformance to the RFC.

So, before I go ahead and revert the changes within the draft back to its 00 state and therefore separate the validation state signaling back into independent documents respectively and dealing with path validation only as initially proposed, I like to query the list if there is consensus in doing so.

Please let me know so I can go ahead and make the necessary modifications,

Thanks and stay safe,
Oliver