[Sidrops] Re: Rechartering: implementation policy

[Luigi Iannone <[e-mail]>]

Hi,

> On 23 Oct 2025, at 17:57, Job Snijders <[e-mail]> wrote:
> 
> On Thu, Oct 23, 2025 at 04:36:36PM +0100, Nick Hilliard wrote:
>> Luigi Iannone wrote on 22/10/2025 16:05:
>>> - change to an assertive form, like “the Working Group will ask the IESG
>>> for publication of Standard Track documents for which there exists at
>>> least two implementations”
>> 
>> The text in the github issue was chosen because that / similar text has been
>> adopted in other working group charters. Unless there's a compelling reason
>> to charge, or some additional meaning, it would be better to use text that
>> the IESG is known to be generally ok with.
>> 
>>> Note as well that only standard track documents need to follow the
>>> policy. May sound trivial but better be clear.
>> 
>> This came up on the Github issue:
>> 
>> https://github.com/ietf-wg-sidrops/charter/pull/2#discussion_r2409944525
>> 
>> I'm inclined to agree: if there are protocol specifications coming out
>> of this WG, they need implementations before submission for
>> publication.
>> 
>> Implementation reports are a thing, so there's already structures in
>> place to handle this.
> 
> To add to this, while Luigi asserts "only standards track documents need
> to follow the policy", I think this aspect needs further consideration.
> I'm not convinced the policy should apply ONLY to STD track documents.
> 
> Russ' email from December 2023 DID NOT restrict the policy scope to just
> 'standards track': https://mailarchive.ietf.org/arch/msg/sidrops/54iqtt-Ug2lzMbr9KpQOnWsh2JM/
> Russ talks about "a document" (as in, 'any document').
> 
> In the last few years this WG wasn't even supposed to publish STD
> documents, and yet so far all docs that exited the WG the implementation
> requirement was met (if applicable). In other words, I believe the
> implementation requirement should apply to all documents that
> change/update/add/remove something in relationship to RPKI protocol
> implementations - because interpretation aligns with the current
> practise of this WG.

And wouldn’t these change/update/add/remove be STD track documents? 


> 
> To echo another thing Nick said, in other WGs this type of wording is
> used:
> 
> SSHM: "Protocol documents should not be submitted to the IESG for
> publication before they have at least two demonstrably interoperable
> implementations." (FYI: SSHM was very recently IESG approved & chartered)
> https://datatracker.ietf.org/doc/charter-ietf-sshm/
> 
> PLANTS: "The Working Group will not submit specifications for
> publication to the IESG before demonstrating two interoperable
> implementations." (FYI: PLANTS is being chartered at the moment)
> https://github.com/davidben/merkle-tree-certs/blob/main/charter-ietf-plants.md
> 
> To me it seems that the WG is leaning towards a scope that encompasses
> "protocol documents" (meaning both INFO + STD). And I think everyone
> intuits that BCPs, are not something one would generally *implement*,
> BCPs also are not protocol documents.
> 
> I think it is important to ensure there is no 'cheat code' to publish
> unimplementable or poorly specified documents through this WG, simply by
> labeling the doc's track as INFO. Even if a document is intended to be
> published as Informational RFC, *THIS WORKING GROUP* should mandate
> multiple implementations exist. This WG's objective should be production
> of protocol documents which specify interopable concepts.

Informational documents do not necessarily represent a consensus (please see: https://www.ietf.org/process/process/informational-vs-experimental/)
In this case how can you mandate two implementations?
STD track looks to me as a way to represent the WG consensus and, hence, can be used to mandate the two+ implementation policy.

I do agree that “protocol specifications” is what need to have 2+ implementation, but to me “protocol specifications” that are the product of this WG should be STD track and reflect the consensus of the WG.
Yet, if the group, as a whole, prefers to keep the generic “protocol specification” wording that is fine to me.

L.


> 
> Should an author team NOT wish to abide to this WG's charter, then the
> "Independent Stream Editor" is another path to publish Informational
> RFCs that have seen limited (or zero) implementation.
> 
> I suggest merging https://github.com/ietf-wg-sidrops/charter/pull/2 as
> it currently is.
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]