At Sat, 7 Mar 2020 12:13:23 +0100, Robert Raszuk <rob...@raszuk.net> wrote:
> > But, again, I expect not everyone agrees on this idea. You probably > > won't; then I'll respect that. Sometimes we just have to agree to > > disagree. > > Well perhaps to your surprise I am all for clarity in the specifications. > So I have nothing against this spec (or any other spec) to formally update > RFC8200. But correct me if I am wrong - but this would require also 6man > WGLC if I am not mistaken in the process ? Assuming you mean draft-bonica-6man-ext-hdr-update, yes, and it will first need to be adopted way before that, and it's not even guaranteed. > But as you just mentioned there was "hundreds if not thousands of email > messages" regarding header insertion/deletion in flight on 6man and that is > why some authors may be actually resisting to take that path - just to keep > the pandora box closed. Perhaps. While I strongly suspect it's an accidental bug rather than an intentional art of obfuscation, I'm afraid we don't have an evidence to prove (or deny) that in a court. > Maybe a compromise is to either start a parallel effort to issue RFC8200bis > or just propose a one page new 6man draft with clear statement that routing > headers can be removed by nodes listed in the SRH segment list and move fwd > ? Hmm, what I proposed for draft-ietf-spring-srv6-network-programming is essentially just that (in the context of, and with other restrictions such as limiting it to the penultimate node, specific to srv6-network-programming). But if writing a separate document just focusing it (in which case network-programming would refer to it as an example of that update) makes the process faster, that can be an option. -- JINMEI, Tatuya _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
