Hello Jun
I think this is a misinterpretation of the mandate. Pointing on IETF work done
outside SAVI like RFC-to-be 8505 and AP-ND does not constitute creating a
solution yourself. It is in the interest of the reader to find the reference in
your doc.
Suresh, what do you think ?
Pascal
Le
On 2018-11-13 13:27, Tom Herbert wrote:
> On Mon, Nov 12, 2018 at 3:56 PM, Ron Bonica wrote:
>> Tom,
>>
>> OK. Let's see if the following text works any better for you.
>>
>> Ron
>>
>> 7.1. For Protocol Developers
>>
>>Protocol
On Nov 12, 2018, at 6:28 PM, Pascal Thubert (pthubert)
mailto:pthub...@cisco.com>> wrote:
Hello Jun
I think this is a misinterpretation of the mandate. Pointing on IETF work done
outside SAVI like RFC-to-be 8505 and AP-ND does not constitute creating a
solution yourself. It is in the
Tom,
OK. Let's see if the following text works any better for you.
Ron
7.1. For Protocol Developers
Protocol developers SHOULD NOT develop new protocols that rely
on IP fragmentation. However, they MAY develop new protocols
Notes below...
> On Nov 12, 2018, at 3:56 PM, Ron Bonica wrote:
>
> Tom,
>
> OK. Let's see if the following text works any better for you.
>
>Ron
>
> 7.1. For Protocol Developers
>
> Protocol developers SHOULD NOT develop new
Quoting the minutes on draft-carpenter-limited-domains-04:
> EK: This looks like a way to get execptions for things you otherwise wouldn't
> be allowed to do. Sometimes things jump domains. I don't think I agree
> philiosophically that this is
> a good idea.
Unfortunately I wasn't on meetecho
On Mon, Nov 12, 2018 at 3:56 PM, Ron Bonica wrote:
> Tom,
>
> OK. Let's see if the following text works any better for you.
>
> Ron
>
> 7.1. For Protocol Developers
>
>Protocol developers SHOULD NOT develop new protocols that rely
On Tue, Nov 13, 2018 at 3:13 AM Joe Touch wrote:
> >> Fragment forwarding is a MUST in our standards.
> >
> > I believe you are talking about routers supporting forwarding
> > fragmented packets, not about policy decisions. While the
> > recommendations in the draft (not to filter ICMP PTB
> On Nov 12, 2018, at 6:31 PM, Jen Linkova wrote:
>
> On Tue, Nov 13, 2018 at 3:13 AM Joe Touch wrote:
Fragment forwarding is a MUST in our standards.
>>>
>>> I believe you are talking about routers supporting forwarding
>>> fragmented packets, not about policy decisions. While the
>>>
Quoting the minutes on draft-carpenter-limited-domains-04:
> RV: The hints that I'm hearing are that if you have well structured systems
> there are infinite ways to break the structure. If one allows people in the
> wild to
> do whatever they want, you get trends like this. It's not a trend
Dear Pascal，
Thanks for the explanation.
You didn't mention your RFC-to-be 8505 in the previous email, so I didn't get
what you meant.
If you just hope we point it as a reference, I think that would be no problem.
Best Regards,
Jun Bi
From: Pascal Thubert (pthubert)
Date: 2018-11-13
> And none of these update RFC1812.
>
> These things can be rolled out in any numbers you like - they are creating
> the problem that only they can clean up. Killing capability in the rest of
> the Internet to make these mechanisms work isn’t a viable solution and never
> has been.
And if
On Nov 12, 2018, at 1:36 AM, Ole Troan wrote:
>> And none of these update RFC1812.
>>
>> These things can be rolled out in any numbers you like - they are creating
>> the problem that only they can clean up. Killing capability in the rest of
>> the Internet to make these mechanisms work
> On 12 Nov 2018, at 11:11, Joe Touch wrote:
>
>
>
> On Nov 12, 2018, at 1:36 AM, Ole Troan wrote:
>
>>> And none of these update RFC1812.
>>>
>>> These things can be rolled out in any numbers you like - they are creating
>>> the problem that only they can clean up. Killing capability in
> See my suggested text - I.e., if you can’t handle the fragments they way you
> WANT, then you need to forward them.
To where?
When the forwarding decision is based on L4 information, as it is inthe IPv4
Internet, the best we could do is to send an ICMP destination unreachable back.
>
> IMO,
> On Nov 11, 2018, at 4:02 PM, Jen Linkova wrote:
>
> On Fri, Nov 9, 2018 at 2:32 AM Joe Touch wrote:
>>> (https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-02#section-7.4)
>>>
>>> recommends that operators do not filter ICMPv6 PTB. I believe it would
>>> be beneficial to make an
On 2018-11-11 20:11, S Moonesamy wrote:
> Hi Amelia,
>
> I read draft-andersdotter-intarea-update-to-rfc6302-00 (expired)
> several months ago. I unfortunately did have time to comment because
> of a significant increase in workload. I had an email exchange [1]
> with one of the RFC authors
On Mon, Nov 12, 2018 at 10:35 AM, Ron Bonica wrote:
> Folks,
>
> It warms my heart to see old friends share a spirited debate ;-)
>
> But what does this mean for draft-ietf-intarea-frag-fragile? The draft
> observes that some stateless middle boxes behave poorly in the presence of IP
>
Ron
As I noted, SHOULDs always need to explain why they are not MUSTs and under
what conditions they should be excepted... see below...
Joe
> On Nov 12, 2018, at 10:35 AM, Ron Bonica wrote:
>
> Folks,
>
> It warms my heart to see old friends share a spirited debate ;-)
>
> But what does
Hi Amelia,
At 10:32 AM 12-11-2018, Amelia Andersdotter wrote:
E-mails in this thread:
https://www.ietf.org/mail-archive/web/int-area/current/msg06335.htmlÂ
and here:
https://www.ietf.org/mail-archive/web/int-area/current/msg06434.html
It was my sense that the feeling in the group was that,
Folks,
It warms my heart to see old friends share a spirited debate ;-)
But what does this mean for draft-ietf-intarea-frag-fragile? The draft observes
that some stateless middle boxes behave poorly in the presence of IP fragments.
In order to avoid this situation, the draft makes the
See my suggested text - I.e., if you can’t handle the fragments they way you
WANT, then you need to forward them.
IMO, if you don’t know what to do with fragments you can’t process AT ALL, then
your middlebox service is either improperly designed or improperly deployed.
Joe
> On Nov 12, 2018,
Jen,
This is a good idea. I will add it to the next draft version.
Ron
> recommends that operators do not filter ICMPv6 PTB. I believe it would be
> beneficial to make an explicit recommendation to permit fragmented packets
> to/from operator's
Dear Pascal,
Thanks for your comment.
Regarding reliability of snooping, we agree that packet loss can happen in
WLAN. However we’ve already mentioned that in Section 3.3:
Data packet with non-bound source IP address with a limited
rate is collected to handle DAD message loss in SLAAC
On Mon, Nov 12, 2018 at 1:08 PM, Ron Bonica wrote:
> Joe, Tom,
>
> Does the following text work for you?
>
> Ron
>
> ===
>
>
> 7.1. For Protocol Developers
>
>Protocol developers SHOULD NOT develop new
Joe, Tom,
Does the following text work for you?
Ron
===
7.1. For Protocol Developers
Protocol developers SHOULD NOT develop new protocols that rely
on IP fragmentation. However, they MAY develop
26 matches
Mail list logo
