RE: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

["Ketan Talaulikar (ketant)" <[e-mail]>]

Hi John,

I believe that you have misrepresented my intentions and, in your email below, have put words in my mouth that are contrary to the points that I was trying to make. I find this very unfortunate.

Let me clarify that none of my arguments during this adoption call have been related to the use of CRH in the scope of SRm6 solution. Since the WG adoption is based on the premise that it is for use-cases other than Spring / Segment Routing (please correct me if that is not so).

So I am looking for documentation and explanation for the IPv6 Source Routing solution with CRH that is not-related the Segment Routing (i.e. Spring architecture) from the authors.

That was the context of my entire discussion thread with Brian : https://mailarchive.ietf.org/arch/msg/ipv6/DsRMOzMlHNoGNOHqFbq8CLdWyjQ/ 

There are these forwarding methods, method specific parameters, the semantics of the SID (e.g. its scope), etc. that are not well defined in the document. In my mind, these can be straightaway mapped to constructs in Spring Architecture with proper references. The authors could just use those references to explain them or in the case that they mean something different then we need to see those specified fully along with how they are going to be used.

Thanks,
Ketan

-----Original Message-----
From: John Scudder <jgs=[e-mail]> 
Sent: 23 May 2020 00:35
To: Ketan Talaulikar (ketant) <[e-mail]>
Cc: Brian E Carpenter <[e-mail]>; Bob Hinden <[e-mail]>; IPv6 List <[e-mail]>
Subject: Re: Adoption Call for "The IPv6 Compact Routing Header (CRH)"

Ketan,

> On May 21, 2020, at 11:10 PM, Ketan Talaulikar (ketant) <ketant=[e-mail]> wrote:
> 
> [KT] Definitely. We constantly build on existing work. SRm6 was trying to do that. But the current document does not provide any attribution to Spring architecture and body or work. The authors in fact deny this has anything to do with Segment Routing. It would seem like the authors are not giving the due to years of work done in Spring. And that makes one wonder why so because the previous versions of this document did have such references to Spring work that was purposefully removed by the authors.

I’m not aware of the authors having denied that CRH is factored out from their earlier work on SRm6 (it would be silly to do that since SRm6 cites CRH normatively), nor that SRm6 is in the SR space (it’s right there in the name). On the contrary, my recollection is that this has been explicitly acknowledged during one or more 6man meetings. Although I don’t speak for them, I have confidence the authors would be willing to update the acks as appropriate (for that matter, if it becomes a WG document it’s not solely the authors’ choice to make). 

I’m not an author so I won’t presume to answer for them regarding references that were removed, but generally when I’m writing a document I provide the references needed to support the body text, neither more nor less; if the refactoring of the work makes it possible to understand without reference to those documents, then they shouldn’t be in the references. The SRm6 draft does indeed cite the CRH draft, and this is as it should be — upper layers cite lower layers, not the other way around. BGP cites TCP, but TCP doesn’t cite BGP, etc. In fact, idnits will complain if a document is cited but never mentioned in the body text, this is so much of a best practice it’s baked into our tool chain.

Regarding “previous versions of this document did have such references to Spring work”, I looked back in the document history and see that 00 through 04 cite draft-ietf-6man-segment-routing-header, because those versions list all defined routing headers in the introduction, and that’s one of them. Later versions shorten the introduction and thus the reference isn’t needed. It seems like overreach to try to ascribe some kind of nefarious purpose to this simple edit. Various other RH were also cited by 00 through 04, and then the citations removed (e.g. to RFC 5095), for the same reason.

Your insinuation that there’s an attempt by the authors to engage in some kind of plagiaristic behavior is both hurtful and disruptive. If you can support your insinuations with facts, please present them if you feel it advances the dialogue, otherwise please stop.

Thanks,

—John