https://www.ietf.org/mailman/listinfo/spring
--
Fernando Gont
e-mail: ferna...@gont.com.ar
PGP Fingerprint: 7F7F 686D 8AC9 3319 EEAD C1C8 D1D5 4B94 E301 6F01
___
spring mailing list -- spring@ietf.org
To unsubscribe send an email to spring-le...@ietf.org
nt, one does not
need to worry about it when implementing 8754. Based on that and my
understanding of "updates", I would not expect this document to assert
that it updates 8754.
Yours,
joel
On 10/1/2020 3:10 AM, Fernando Gont wrote:
Pablo & IESG,
May I ask why, if you are g
chitecture is to be changed, the IETF as a whole should be
involved (since that would probably be even out of the scope of 6man).
Thanks,
--
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
ay want to [PC] enable ICMPv6 packet
processing for OAM purposes.
[]
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerpr
t does
not describe “how” since that is clearly outside the scope of this
document and part of the individual routing protocol extensions.
(17) [nits]
s/an network operator/a network operator
s/one billionth and one millionth of the assigned address space/one
billionth and one millionth of the available address space
s/packet's h
Hello, Alvaro,
On 3/6/20 15:29, Alvaro Retana wrote:
On June 3, 2020 at 1:16:48 AM, Fernando Gont wrote:
[]> ...
Note: I fail to see your analysis regarding technical objection #3: Your
analysis focuses on RFC8200 (the focus of technical objection #2), but
doesn't even mention
jection #3).
For the sake of transparency, while I haven't talked to my fellow
Appellants about your response, I for one plan to Appeal to the IAB to
resolve this issue. That said, I'd appreciate your response to the
comments made above.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail
above comment is meant neither in favor nor against CRH, but rather
a reminder that source routing existed well before Spring, RFC8754, and
others, and, as a result, well before Spring monopoly on routing headers
(?) was declared.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.co
is a "call for adoption", not a "call for
publication". Once a document is adopted, it typically goes through
multiple revisions, is subject to WGLC, IETF LC, and IESG review.
So I'm not sure why you are implying otherwise.
Thanks,
--
Fernando Gont
SI6 Networks
e-m
,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
w" vehicle could run faster, while ignoring that other folks and
vehicles need those very same roads to be safe and reliable.
P.S.: Sorry, I couldn't help it.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4
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:/
y and openness).
* Appellants:
Fernando Gont
Andrew Alston
Sander Steffann
* Description of the Dispute
Recently, Spring WG consensus to progress
draft-ietf-spring-srv6-network-programming was declared. However, we
believe that major concerns raised as part of the WGLC of this document
rem
the community, then concerns are addressed, and *then* you
declare wg consensus?)
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
spring mailing list
s
Ping
On 31/3/20 03:31, Fernando Gont wrote:
Folks,
May I ask what's the status of this I-D, and what are the next steps?
Another WGLC? Ship to the IESG?
Thanks,
Fernando
On 27/3/20 14:42, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Int
rafts/
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076
On 11/3/20 23:34, Brian E Carpenter wrote:
On 12-Mar-20 10:44, Fernando Gont wrote:
On 11/3/20 18:30, Brian E Carpenter wrote:
[]
However, I can't find anything in RFC 4291 that forbids addresses
having semantic meanings rather than being pure locators. It goes
against one of my d
in address bits considered harmful"
in the RFCs.
Didn't *you* write that document? ;-) : RFC7136
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
__
hey issues they raised have been addressed.
Thanks,
--
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.o
e they were dismissed
during WGLC.
Thanks,
--
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
Folks,
Ping?
On 6/3/20 06:25, Fernando Gont wrote:
Marting & Bruno,
May I ask what's the status of this I-D? -
On one hand, both of you declared consensus to move it forward. On
another hand, the authors keep making changes to address comments (good)
so what the wg will shi
s/document-writeups/document-writeup-working-group-documents/
be rephrased to something else?
At least for non-native English speakers, the phrase "Has anyone
threatened an appeal" gives Appeals a very negative connotation...
(Is a formal update to RFC4858 needed for that?)
Thanks!
u claimed consensus. Besides, the datatracker lists the document
as "in WGLC".
So:
What's the status of this document?
And.. are you planning to do a second WGLC?
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9
aimed consensus. Besides, the datatracker lists the
document as "in WGLC", as opposed to "Waiting for WG Chair Go-Ahead" or
"WG Consensus: Waiting for Write-Up".
Last, but not least, are you planning to do a second WGLC?
Thanks,
--
Fernando Gont
e-mail: fern
.
Thanks,
--
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
sides, the datatrackers lists the
document as "in WGLC".
Thanks,
--
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
On 3/3/20 12:49, bruno.decra...@orange.com wrote:
Fernando
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando Gont
Sent: Monday, March 2, 2020 9:23 PM
To: Martin Vigoureux; spring@ietf.org
Cc: 6...@ietf.org; 'i...@ietf.org'; draft-ietf-spring-srv6-network-programmi
7;t.
If it is, RFC8200 should have an explanation of how PMTUD and error
reporting works. And it doesn't have one.
In that light, I'm curious how folks can state that eh insertion/removal
is allowed.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
P
because the current destination address of the incoming packet
is the address of the node executing the PSP behavior.
A node that does PSP essentially processes the SR header twice. How is
that compliant with draft-ietf-6man-segment-routing-header itself?
--
Fernando Gont
SI6 Networks
e-mai
-R]
https://mailarchive.ietf.org/arch/msg/spring/eSP4xVYVgjtCmAMGMkqHedv80jU/
[SID]
https://mailarchive.ietf.org/arch/msg/spring/2ApHpreqPTS689pAEyhiZEdTf7k/
[SR-V]
https://mailarchive.ietf.org/arch/msg/spring/Xrcclo0s4pnug9upG9rUinYMv1I/
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
removal of IPv6 extension headers. This violated
RFC8200 that prohibits such behaviour, and also violates the
specification of routing headers.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25
should be updating RFC8200, and probably even the
segment-routing-header I-D.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
spring mailing list
spring@ietf
__
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
.
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6netw
a
proceed like this.
Thanks,
--
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
On 2/3/20 14:28, bruno.decra...@orange.com wrote:
Fernando,
From: Fernando Gont [mailto:ferna...@gont.com.ar]
Sent: Monday, March 2, 2020 6:14 PM
To: DECRAENE Bruno TGI/OLN; S Moonesamy; Martin Vigoureux; Suresh Krishnan
Cc: spring@ietf.org
Subject: Re: [spring] WGLC - draft-ietf-spring-srv6
act that the errata was marked as "held
for document update" days *after* you made your decision should be a
datapoint.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
__
the same
comment if someone had flagged the same situation for any other
document, and a co-author/contributor was shepherding the document or
calling consensus.
As noted, I disagree with your declaring of consensus to move this
document forward. But I provided a rationale for my disagreement, and
never linked the outcome of the consensus call to the aforementioned
conflict of interest.
Thanks,
--
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
be fixed (this is not the only bug in the
EH-processing part of RFC8200, as noted by Brian, myself, and others).
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
__
the current architecture.
Rather than focusing your energy in making your case for changing it,
all these discussions have been wasting everyone's time trying to make
each of us believe that these behaviors are currently supported by IPv6.
Thanks,
--
Fernando Gont
SI6 Networks
e-mai
The concerns of this document violating RFC8200 were dismissed by
stating that the AD had not accepted the erratum I had submitted.
Clearly, if Bruno had meant "not processed", he couldn't have dismissed
the erratum like that.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar |
.
I'll be contacting many of you during the next few days to get the text
together.
I also find the behaviour of the WG chairs does not befit their
responsibilities.
I agree.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7
ite/modification privilege on the
text in this document, and I'm not part of the authors email alias, this
would not be ideal for me to take the decision to forward this document
to the IESG. I've discussed this with our AD (Martin) and he agreed to
make the formal decision to send the
I was clear that
it needed to be removed for it to progress from 6man. The authors removed the
insertion mode from the draft.
No, we are not clear: PSP does extension header removal.
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
P
interested reader, a longer explanation of the issue:
https://mailarchive.ietf.org/arch/msg/ietf/sbb95BqdPifuRb_NPc3aeiqBbfM/
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
anything. And that's what Errata's are for.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
d seems to be unfair with
participants, and a dis-service to the group.
Thanks,
--
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
sprin
Bruno,
On 27/2/20 05:41, bruno.decra...@orange.com wrote:
Fernando,
-Original Message-
From: ipv6 [mailto:ipv6-boun...@ietf.org] On Behalf Of Fernando Gont
Sent: Thursday, February 27, 2020 12:45 AM
Hello, Eric,
On 26/2/20 20:18, Eric Vyncke (evyncke) wrote:
Writing this without
On 27/2/20 04:51, Dirk Steinberg wrote:
On Thu, Feb 27, 2020 at 1:45 AM Fernando Gont <mailto:fg...@si6networks.com>> wrote:
Hello, Eric,
On 26/2/20 20:18, Eric Vyncke (evyncke) wrote:
> Writing this without any hat,
>
> Please note that on the logi
On 27/2/20 04:51, Dirk Steinberg wrote:
On Thu, Feb 27, 2020 at 1:45 AM Fernando Gont <mailto:fg...@si6networks.com>> wrote:
Hello, Eric,
On 26/2/20 20:18, Eric Vyncke (evyncke) wrote:
> Writing this without any hat,
>
> Please note that on the logi
protocol in your network) and aiming at
consistency in our specs.
We are a standards organization. If we can't keep our specs consistent,
and we violate our specs at will, I'm not sure our work will be taken
seriously.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6netw
ata to RFC8200 which clarifies the intended behaviour:
* https://www.rfc-editor.org/errata/eid5933
(that's what Errata's are for, after all... and it should be clear that
the EH processing part, overall, needs improvements).
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-m
of RFC8200.
(I don't remember of the top of my head if PSP was the only part of the
document violating RFC8200, hence my general comment).
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
__
t the document. I simply asked the
existing specifications be complied with.
It's a waste of time to be rehashing the same discussions all the time.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55
g technology.
I have technical concerns about the proposal (expressed ad nauseam), and
also concerns about how this process has been going on.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
__
tion
(i.e., outside of a small group of big vendors) are highly discouraged
from participating at the IETF.
It is a shame we have had to insist on this so much.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55
t down if it wasn't being pushed by a big vendor.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
probably missed the "small" detail of having rough consensus to
change an existing spec.
Just sayin'...
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
only works based on the DA -- there's no other way to
specify waypoints.
If you claim otherwise, that can be, at best, a major misunderstanding
of how IPv6 works.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945
RFC publication. And eventually can led
to errata, bis document, deprecation…
So... is the plan to ship a document that violates RFC8200?
Should participants stop wasting time in constructive comments, and
rather work and prepare to submit a formal appeal, instead?
Thanks,
--
Fernando Gont
e
t a formal specification update if
they mean to change IPv6 -- as opposed to try to circumvent the spec for
the n-th try.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
___
of thought any further
The fact that this is still going on is at least alarming.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
spring mailing list
spring
t and fwd based on the original DA.
>>
>> Seems very simple :)
>
> Right, but the language in the PSP sub-section does not talk about
> decapsulation.
Because it's not. :-) They are deleting an EH.
Thanks,
--
Fernando Gont
e-mail: ferna...@gont.com.ar || fg
On 12/12/19 22:56, Suresh Krishnan wrote:
> Hi Fernando,
>
>> On Dec 11, 2019, at 7:22 PM, Fernando Gont > <mailto:fg...@si6networks.com>> wrote:
>>
[]
>>>
>>> RFC8200 *clearly* speaks about the possibility of the destination
>>> addr
On 11/12/19 19:04, Suresh Krishnan wrote:
> Hi Fernando,
> Answer inline.
>
>> On Dec 7, 2019, at 9:31 AM, Fernando Gont wrote:
>>
>> On 7/12/19 04:19, Suresh Krishnan wrote:
>>> (responding on spring mailing list)
>>>
>>> Hi Fernand
;> ignore it, declare consensus, and ship and request publication of this
>> document.
>
> Noted.
> I'm not ignoring it. Quite the contrary I'm the one engaging the discussion
> with you in order to understand the real
m that this text is violated.
> - Why have _you_ filled an errata against RFC 8200, in order to change the
> technical content of this section, if you don't agree that one may red "
> Destination Address field of the IPv6 header" as the IPv6 address present in
> the Des
e says it all: "Penultimate Segment Popping". You remove the SRH
at a place other than the final destination.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
_
On 10/12/19 21:23, Fernando Gont wrote:
> Joel,
>
> On 10/12/19 19:49, Joel M. Halpern wrote:
>> Fernando, I really wish I could agree with you.
>> But I can't.
>>
>> In 8200, it is clear that the meaning fo "Destination Address" for an
>> I
ne could indeed argue that the wording in RFC8200 could have been
better. However, the intent is clear, and also since RFC8200 does not
specify any routing header type, in the context of RFC8200 packets
there's no possible destination other than the ultimate destination.
Maybe an errata is warran
ich one :)
Could you please point at any RFC that inserts EHs or deletes EHs at any
place in the network other than the source or the ultimate destination?
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C
rds Track work while violating an
Internet Standard is simply amusing.
If you want to do that, formally update the relevan spec. *That* is the
way to go, as opposed to find your own reason for circumventing existing
specifications.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP
On 10/12/19 08:16, bruno.decra...@orange.com wrote:
> Fernando,
>
>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando Gont
>> Sent: Sunday, December 8, 2019 1:55 AM
>>
>> On 7/12/19 15:40, Robert Raszuk wrote:
>>> Hi Fernando,
>>>
an has consensus to proceed on
>> that path.
>
> Not the preferred path as of today.
Yes, it should be evident that it seems the preferred path has been
(starting with EH insertion at the time) to circumvent existing
specifications.
>
>> P.S.: I will go through the document once again... but the same
>> reasoning should be applied to any EH-insertion/removal at a place other
>> than the source of the packet or its final destination.
>
> It looks to me that SRH insertion and SRH removal are to be treated
> differently.
I don't see how or why. Both violate the same requirement in RFC8200.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
On 10/12/19 08:16, bruno.decra...@orange.com wrote:
> Fernando,
>
>> From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Fernando
>> Gont Sent: Sunday, December 8, 2019 1:55 AM
>>
>> On 7/12/19 15:40, Robert Raszuk wrote:
>>> Hi Fernando,
>>>
I expect WGs to operate. The later shows a clear path
to a huge pile of documents stuck at IESG review, simply because so
later in the process folks found out that the document turns out to
violate existing specs. With the risk of an AD pressing "YES", and hence
IETF has been circumvented.
T
ld be processing (hence the name of the
mechanism).
That said, of course the fact of having to resort to "assumptions" or
"rumors" is kind of antagonistic to the meaning of "specification". So I
agree with you.
Thanks,
--
Fernando Gont
SI
will go through the document once again... but the same
reasoning should be applied to any EH-insertion/removal at a place other
than the source of the packet or its final destination.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3
final destination.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
om the spring chairs (if any), and a response from the RTG AD(s).
Then I will escalate the problem as required, including a formal appeal,
if necessary.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
consider #3 closed as this is clearly
> complying with RFC8200.
Sorry Darren. Which wg do you chair?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
sprin
ough for the
community to be aware about what's going on (including the formal appeal
process).
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
___
spring maili
uation (what happened in the context of rfc2460bis), I will
raise the issue in other forums.
I guess it should be clear to everyone that we are being mocked at. And
I think the situation is unacceptable.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 3
clude this thread.
Can you tell me which address, other than the address of the final
destination, can be present in the DA of a pcket, in the context of RFC8200?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
On 7/12/19 04:19, Suresh Krishnan wrote:
> (responding on spring mailing list)
>
> Hi Fernando,
>
>> On Dec 7, 2019, at 11:07 AM, Fernando Gont > <mailto:fg...@si6networks.com>> wrote:
>>
>> On 6/12/19 23:47, Brian E Carpenter wrote:
>>>
On 7/12/19 07:13, Ketan Talaulikar (ketant) wrote:
> +1
>
>
>
> For some strange reason the PSP behaviour is being mixed with EH
> insertion and likely there is some misunderstanding here.
You mean we're mixing EH insertion with EH removal?
--
Fernando Gont
On 7/12/19 04:19, Suresh Krishnan wrote:
> (responding on spring mailing list)
>
> Hi Fernando,
>
>> On Dec 7, 2019, at 11:07 AM, Fernando Gont > <mailto:fg...@si6networks.com>> wrote:
>>
>> On 6/12/19 23:47, Brian E Carpenter wrote:
>>>
On 6/12/19 23:47, Brian E Carpenter wrote:
> Again, comment at the end...
> On 07-Dec-19 14:37, Fernando Gont wrote:
>> On 6/12/19 22:15, Brian E Carpenter wrote:
>> [...]
>>>
>>>> and if such a thing is required, an update to RFC8200 should be done.
>
tell from the jargon whether "insert" means "insert on the fly" and
> whether "Pop the SRH" means "delete on the fly". Should those terms be
> clarified before the draft advances?
Well, if it's not clear to you, it would seem to me that the simpl
hey please.
A formal update is also warranted because, otherwise, if I read RFC8200
(and there's no metadata that points to EH-insertion), I can assume that
this packet mangling doesn't occur. But then if the same organization
(IETF) publishes another document that says how to mangle with I
On 6/12/19 19:02, Ole Troan wrote:
>
>
>> On 6 Dec 2019, at 22:09, Fernando Gont wrote:
>>
>> I don't think there is much room for interpretation here, but anyway I
>> should ask: are you suggesting that I have attacked or been attacking
>> the process?
have simply been trying hard for the decisions to be taken
by the wg (as opposed to "magical consensus"), and for the existing
specs to be respected and complied with unless there's formal consensus
not to do so.
Is being loud about that "attacking the process"? Or is that
sions of the document.
Can the authors clarify what this means?
That this mean "this will not work as expected if there are other EHs"?
If not, why the statement? If yes, what happens if you do receive
packets with other EHs (say, FH, IPsec, or others)?
Thanks,
--
Fernando Gont
e-mail:
t. As
> I said earlier, it’s hard to say when that will be done. Otherwise, I think
> the other work should be compatible with what is in RFC8200.
Agreed. And this answers the question I posed above.
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP
e the ones we are discussing now.
That is obviously not true.
Even when RFC8200 does not have RFC2119, it does have wording that uses
"must" in the area of not mangling with EHs. In fact, I should remind
you that rfc2460bis wouldn't go past its first IETF LC without making
this change
comments to the SPRING WG list, no later than December 20.
>
> I think there are plenty of already documented reasons that this draft should
> have never been thrown into WGLC in the first place.
+1
Also, as noted, I support Ron Bonica's WGLC comments.
Thanks,
--
Fernando Gont
e-
ent Popping) that causes the
SRH to be removed while on flight to the destination.
Since such text violates RFC8200, it should be removed from the document
(in the same way that the authors have already removed the insertion part).
Thanks!
Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6ne
your position on this now.
> There is of course a lot more nuance to this argument.
Could you please, as wg chair, elaborate on this?
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
r to the
>> rest of the wg participants.
>
> Which process are you talking about? Is that documented in an RFC?
Yes: RFC2026 and RFC2418.
> You seem to take it on yourself to represent the "rest of the wg
> participants", but from my perspective it looks like a few v
we have not been following the processes that
should be followed. This has happened repeatedly over time, for this
very same topic. The process seems to be biased, and thus unfair to the
rest of the wg participants.
Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprin
the document "as is" would be an outright
violation of our existing standards.
This has been repeated numerous times already.
I think we are at a point where the ADs should take action. Most
importantly Int-AD, since the spec being violated is RFC8200.
Thanks,
--
Fernando Gont
SI6 Networ
1 - 100 of 150 matches
Mail list logo
