Re: [spring] Thoughts and concerns

[Martin Vigoureux <[e-mail]>]

[simply replying to the latest e-mail of the thread]

Hello

I believe that discussing the content of such type of materials on 
SPRING’s mailing list is not the most productive thing to do, primarily 
because I can’t see how having such a discussion could serve the 
objectives of the WG.
I have read that some of you were concerned by the content and I fully 
respect that, but the IETF, as an organisation, has little to none 
control over what is written in such type of document. Do not hesitate, 
however, to directly contact me if needed.

Nonetheless, it appears that the document was modified. I thus hope that 
this will no longer be discussed and that the work of the WG can resume 
peacefully.

However, since I am quoted/referenced in this document, would like to 
clarify very strongly that I did not participate in any form whatsoever 
to its elaboration and publication.

Thank you
Martin

Le 2019-12-02 à 21:06, Bertrand Duvivier (bduvivie) a écrit :
> FYI, the authors updated the document as follows:
> 
> Old   text: SRv6 network programming draft is on track with an on-going 
> SPRING last call.
> 
> New text: SRv6 network programming draft is on track with an on-going 
> SPRING last call request.
> 
> Best Regards,
> Bertrand
> 
> *From: *spring <[e-mail]> on behalf of 
> "[e-mail]" <[e-mail]>
> *Date: *Friday, 29 November 2019 at 11:30
> *To: *Andrew Alston <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>, 'SPRING WG List' 
> <[e-mail]>, "[e-mail]" <[e-mail]>
> *Subject: *Re: [spring] Thoughts and concerns
> 
> Andrew,
> 
> I think we have enough with technical discussions to be held on the so 
> called ‘Beyond SRv6’ subjects.
> 
> I don’t think that commenting on non IETF documents or initiating a 
> thread which has a possibility of been heated and which is not likely to 
> bring progress with regards to the technical choices and directions that 
> we want to follow, is going to be useful or a good use of everyone’s time.
> 
> I would rather encourage you to work on the next steps which have been 
> proposed by the chairs during IETF 106.
> 
> Several solutions on the table. Need to be explicit about the goals and 
> the costs of each proposal.
> 
> ■ Authors are invited to explicit both in their document (short text)
> 
> https://datatracker.ietf.org/meeting/106/materials/slides-106-spring-sessa-chairs-slides
> 
> So regarding the document that you have quoted, or any document or video 
> that you may find in the Internet, or any vendor roadmap that you may 
> disagree with, I think that I would be more efficient that you engage 
> with their authors or the representative of the companies you are 
> working with (or not working with). I can hear that from an network 
> operator standpoint, sourcing issues do exist, but this is not an IETF 
> business. Coming back to a related comment that you previously made, the 
> IETF has worked and standardized SR-MPLS for IPv6 prefixes/FEC. The fact 
> that some vendors do not implement it (soon enough) is not a standard 
> issue not something that the IETF can work on. In itself, it’s also not 
> a (strong) reason for the IETF to work on another solution.
> 
> Regarding IETF protocol work, again, we have multiple solutions on the 
> table. Let’s go a bit deeper with the technical discussions about the 
> goal(s) and means proposed by each solution. Let’s see if we can 
> identity the technical points that are worth discussing and try to gain 
> consensus on that. Keeping in mind that both on the requirements and 
> solutions aspects, tradeoffs are likely involved.
> 
> Let’s go further than ‘my solution is the best/simplest/more beautiful’. 
> I’m even dreaming that we could go further than my solution is better on 
> KPI/requirement X. (disregarding other KPI/requirements).
> 
>   * The forth bullet point is really interesting - because I have yet to
>     see a last-call for this document on the mailing list - unless I
>     missed it - which is explicitly required as per RFC2418 Section 3.2
> 
> If this is a point for spring chairs, that they have not yet initiated 
> the last call, nearly a week after the IETF 106 meeting, ok, point taken.
> 
> Thank you,
> 
> --Bruno
> 
> *From:*spring [mailto:[e-mail]] *On Behalf Of *Andrew Alston
> *Sent:* Thursday, November 28, 2019 4:27 PM
> *To:* 'SPRING WG List'
> *Subject:* [spring] Thoughts and concerns
> 
> Hi Guys,
> 
> I have some questions - I ran across a document which has me deeply 
> concerned - that purports to be written by the authors of SRH and makes 
> direct reference to this working group.  And since the claims in it are 
> deeply worrying - I think its time to ask for some answers. I fully 
> realize that well - what people publish outside of the IETF is probably 
> no business of the IETF - but, a document that claims to be published by 
> the authors of a draft - that makes false claims about the working 
> groups very charter - that - concerns me.
> 
> The document itself can be found at: 
> https://www.segment-routing.net/images/20191029-02-Update-on-SRv6-standardization-activities.pdf
> 
> Now - here is my issue
> 
> Firstly - the second bullet point in that document runs *DIRECTLY* 
> contrary to what is stated in the spring charter - to quote the charter:
> 
> /_The Source Packet Routing in NetworkinG (SPRING) Working Group is the 
> home of Segment Routing (SR) using MPLS (SR-MPLS) and IPv6 (SRv6)._/
> 
> /_SPRING WG serves as a forum to discuss SPRING networks operations, 
> define new applications of, and specify extensions of Segment Routing_/
> 
> /_technologies._/
> 
> The forth bullet point is really interesting - because I have yet to see 
> a last-call for this document on the mailing list - unless I missed it - 
> which is explicitly required as per RFC2418 Section 3.2
> 
> I am not going to bother with the rest of the document - because well - 
> people are free to their own technical opinions - but it greatly bothers 
> me when the authors of a draft are publishing what are in effect blatant 
> untruths in order to promote their work - and I believe it should bother 
> everyone in this working group when such appears.
> 
> Thanks
> 
> Andrew
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> 
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> 
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> 
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> 
> they should not be distributed, used or copied without authorisation.
> 
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> 
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> 
> Thank you.
>