[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 <[email protected]> on behalf of
"[email protected]" <[email protected]>
*Date: *Friday, 29 November 2019 at 11:30
*To: *Andrew Alston <[email protected]>
*Cc: *"[email protected]" <[email protected]>, 'SPRING WG List'
<[email protected]>, "[email protected]" <[email protected]>
*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:[email protected]] *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.
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
