Zafar,
I will be very open and straightforward:
* I don't care myself about CRH. i.e., I'm not pushing that effort
forward, and have no kind of agenda whatsoever around it.
* Your claims are attacking myself, because you seem to imply that the
appeal was intended as a political attack against the spring chairs or
responsible AD, or to benefit other work such as CRH.
In that light, I'm going to be quite open and transparent:
1) I asked numerous times for the Spring chairs and responsible AD to
become involved, so that I wouldn't have to formally appeal the spring
process. I did it multiple times, both on-list and off-list -- I even
did so on the i...@ietf.org mailing-list, and well before spring wglc
consensus was declared. Other people (please see the references in the
appeal text) did the same. But the chairs and AD dismissed our concerns,
and went ahead.
2) I made it public, numerous times, that I would Appeal the decision.
That was even reflected in the document shepherd's writeup for the
network-programming draft.
3) I have been the one that wrote 100% of the text in the Appeal. Not
99%, but 100%. In the process, I asked quite-publicly, on-list, that
folks send me the issues that they had raised and felt that had been
dismissed, such that the Appeal would be as complete and well-documented
as possible.
I had the Appeal text ready a week or so after Spring WGLC consensus was
declared, but had to wait to submit it because it took the Spring chairs
over a month to reflect their decision on the datatracker.
In the mean time, I contacted many 6man participants, and sent them my
draft version of the appeal, asking if they had any comments or corrections.
I was planning to submit the Appeal alone. But while doing the last pass
on the appeal text, I happened to talk to Andrew and Sander (Appeal
co-signers) about the issue of the IPv6 address space involved. And
during that last exchange, they expressed that they would like to sign
the appeal (noting that it was up to me).
I agreed with them to sign the Appeal, in the same way that I would have
agreed with any other participant signing the Appeal if they agreed with
the points being raised by the Appeal.
4) It is not my business whether folks (say, CRH authors or whoever),
benefit from the Appeal. Because my motivation for submitting the Appeal
has been my technical concerns with the network-programming draft, and
with the lack of transparency (at best) of the procedures that led to
Spring shipping that document to the IESG. Other times I had experienced
other arbitrary decisions, and experience has shown that silently
accepting those turns out to be a bigger problem over time, and they
kind of become established practice. So this time it was "enough is
enough" for me.
So, as far as the Appeal is concerned, I hope you can rectify your
statements, because they are, at best, defamatory and unfounded.
Thanks,
Fernando
On 15/5/20 13:43, Zafar Ali (zali) wrote:
Hi Andrew,
Now that you mentioned you are “SHOCKED that more people cannot see the
smoke and mirrors” …
let me remind everyone.
CRH work is to propose an alternative encapsulation in SPRING against SRH.
There are several SRH/SRv6 net pgm compliant compression techniques that
are far better than CRH proposal (in efficiency) and that requires no
SRH change and no SRv6 CP change [list-of-competing-solutions].
It appears, not able to defend against that argument, the authors took a
strange path:
* Launched a political attack against the SPRING chairs and AD via
calls for resignation and subsequent appeals resulting in derailing
work in SPRING, including all work on compression (of which SRm6 was
one option).
* Removed all reference to SRm6 from this CRH document.
* Attempted to get 6man to adopt CRH ahead of SPRING resuming its work
on compression.
Yes, people can see the smoke and mirrors.
*Ref: List of competing solutions in SPRING*
[1]
https://datatracker.ietf.org/doc/draft-cl-spring-generalized-srv6-np/?include_text=1
[2]
https://datatracker.ietf.org/doc/draft-li-spring-compressed-srv6-np/?include_text=1
[3]
https://datatracker.ietf.org/doc/draft-mirsky-6man-unified-id-sr/?include_text=1
[4] https://datatracker.ietf.org/doc/draft-decraene-spring-srv6-vlsid/
[5]
https://datatracker.ietf.org/doc/draft-filsfils-spring-net-pgm-extension-srv6-usid/?include_text=1
Thanks
Regards … Zafar
*From: *Andrew Alston <andrew.als...@liquidtelecom.com>
*Date: *Friday, May 15, 2020 at 9:15 AM
*To: *"Zafar Ali (zali)" <z...@cisco.com>, John Scudder
<j...@juniper.net>, "6man-cha...@ietf.org" <6man-cha...@ietf.org>
*Cc: *"spring@ietf.org" <spring@ietf.org>, "6...@ietf.org" <6...@ietf.org>
*Subject: *RE: Adoption call criteria for CRH? [was: Re: CRH and RH0]
Zafar,
Let me give another perspective on this.
In Montreal – people screamed – no use case – a use case was provided –
and for months after – people kept screaming – no use case – until they
couldn’t scream it anymore because the mails showed clearly that use
cases had been supplied
Then – we moved onto the “We need an architecture” – and you yourself
misquoted a participant in 6man claiming they demanded an architecture –
when they clearly didn’t – see the interim meeting minutes – and when it
was claimed that this is a building block –
It became – omg its an rh0 replacement – and pick on that aspect of it.
(Those last 2 might be in different orders)
Then – there was this bizarre claim that a vendor “wanted” something
despite the fact that they hadn’t said it.
What I can say is – rather that come with technical arguments against it
– what I am seeing is smoke and mirrors – pulling things out of thing
air – twisting words – trying to mis-portray things – and the only
reason for that is – because there are no solid technical arguments
against it. I am SHOCKED that more people cannot see the smoke and
mirrors and twisting of words going on here.
Because from my perspective – when someone runs out of ideas – they
start making things up out of thin air – one after another – please –
see my earlier email about obstruction and how its not helping any of us.
Lets debate the document on technical merits – what are your direct
technical arguments against this – or are we continue to continue with
misdirection?
Andrew
*From:* ipv6 <ipv6-boun...@ietf.org> *On Behalf Of *Zafar Ali (zali)
*Sent:* Friday, 15 May 2020 15:54
*To:* John Scudder <jgs=40juniper....@dmarc.ietf.org>; 6man-cha...@ietf.org
*Cc:* spring@ietf.org; 6...@ietf.org
*Subject:* Re: Adoption call criteria for CRH? [was: Re: CRH and RH0]
Hi John,
You’ll recall what the 6man chairs said in Montreal and Singapore
regarding CRH:
During Spring session [1]:
“[Bob Hinden] As 6man co-chair, would like to understand whether SPRING
is interested in this work.”
Bob reiterated the same message during Singapore IETF
[https://mailarchive.ietf.org/arch/msg/ipv6/aWkqPfpvDRyjrW8snR8TCohxcBg/]
“Regarding the Spring related drafts … <snip> We did not see very much
value in also discussing them in 6man. Once items have been adopted in
Spring, we think it is appropriate to adopt the IPv6 relevant parts, but
that’s not yet the case now.”
Nothing has changed w.r.t. the competing solution review in Spring since
Singapore.
Instead of following the chair’s direction, in Feb 2020 the authors of
CRH just simply removed normative reference to the SRm6 to get 6man
adopt CRH ahead of SPRING compression discussion..
To achieve the said goal, the authors of CRH draft first positioned it
as a replacement of RH0.
Now RH0 has been removed from CRH draft.
There is no longer any architecture and use-case to justify adoption
call for CRH.
It is clear to all that the current draft and adoption request is an
attempt to circumvent the standard practice.
Ref:
[1] https://datatracker.ietf.org/meeting/105/materials/minutes-105-spring-00
Video: Under: Ron’s session on IPv6 Support for Segment Routing:
SRv6+ (10:44)
Thanks
Regards … Zafar
*From: *ipv6 <ipv6-boun...@ietf.org <mailto:ipv6-boun...@ietf.org>> on
behalf of John Scudder <jgs=40juniper....@dmarc.ietf.org
<mailto:jgs=40juniper....@dmarc.ietf.org>>
*Date: *Wednesday, May 13, 2020 at 4:02 PM
*To: *"6man-cha...@ietf.org <mailto:6man-cha...@ietf.org>"
<6man-cha...@ietf.org <mailto:6man-cha...@ietf.org>>
*Cc: *"6...@ietf.org <mailto:6...@ietf.org>" <6...@ietf.org
<mailto:6...@ietf.org>>
*Subject: *Adoption call criteria for CRH? [was: Re: CRH and RH0]
I’m a little confused about this conversation and I’d like to ask the
chairs for clarification. My actual questions are at the end of this
long(ish) message, and can be summarized as (1) does 6man require
consent from SPRING before defining routing headers, and (2) what
criteria are the chairs using to decide when an adoption call is OK?
It seems to me there are at least two, only vaguely related,
conversations going on. One of them is a debate about the assertion that
6man can’t even consider taking up CRH unless SPRING approves it. The
other is a more free-wheeling line of questioning about “what is CRH for
anyway”?
I presume both of these relate to Ron’s request for an adoption call.
Here’s what the minutes from the interim have:
Bob: Thank you Ron. I think it's too early for adoption call.
Ron: What is needed to get to adoption call.
Bob: I can't answer right now.
Ron: Can I ask on list?
Bob: OK.
Ole: Related to what's going on in spring.
Too bad we have no audio recording, but that’s not too far from my
recollection. Anyway, I don’t think I’ve seen this answered on list yet,
so I’m asking again.
Regarding the SPRING-related process stuff:
I have quite a bit of history with how SPRING was chartered; I was one
of the original co-chairs and helped write the charter, god help me. I
can tell you for certain there was no intent that SPRING should have
exclusive ownership of source routing in the IETF, the name isn’t a
power-grab, it’s a clever backronym, as we do in the IETF. If one entity
in the IETF were to take charge of all source routing, that sounds more
like a new area than a WG. But don’t take my word for it, go read the
various iterations of the charter. As anyone who’s looked at the Segment
Routing document set can tell, Segment Routing is one, very specific,
way of doing source routing. As Ketan and others have pointed out, it’s
a pile of architecture plus the bits and pieces to instantiate that
architecture. That is fine, but the idea that merely because a
technology might be used to instantiate part of that architecture, it’s
owned by SPRING, is overreach. Just because a sandwich is a filling
between two pieces of starch, doesn’t mean every filling between two
pieces of starch is a sandwich. [1]
But at any rate, the question for the chairs is: do you think 6man needs
SPRING’s permission in order to consider adopting CRH? Does 6man need
permission from SPRING for all routing headers, or just some, and if
it’s just some, what characterizes them?
Regarding the more general “what is CRH for anyway” stuff:
This seems to me to be exactly the kind of discussion one would normally
have in the context of an adoption call. Why is it not being had in that
context? To rewind back to the interim, if it’s still “too early for
adoption call”, what has to happen for it not to be too early?
Thanks,
—John
[1] https://cuberule.com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org <mailto:i...@ietf.org>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
i...@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
