Re: [Int-area] Introductions of 2 new drafts in Intarea wg

Hi, Thanks for you documents, inline a few comments > On 11 Nov 2020, at 18:25, Jiayihao (Network, 2012 Lab) > wrote: > > Dear All, > > Last week I submitted 2 I-D on Intarea WG under the topic of a flexible IP > address structure. > I’d like to share the key points of these 2 I-D before

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

Hi, > On 3 Mar 2021, at 12:05, Pascal Thubert (pthubert) > wrote: > > Hello Stewart, Brian and Toerless: > > Interestingly RFC 8138 took one step in that direction. Yes you’re going to > need a new Ethertype but it’s still IPv6 I. IMHO, from an architectural point of view I would argue that

Re: [Int-area] Using ISO8473 as a network layer to carry flexible addresses

> On 3 Mar 2021, at 14:18, Toerless Eckert wrote: > > Carsten: > > Thank you, fully agree. The first time i saw "backward compatibity" pop up in > these discussions was in questions from ISOCI people in discussions > about future evolution of IP/Internet - of course without any clear > specifi

[Int-area] On the importance to have regular meetings to discuss routing and addressing research

Hi All, In the last months a few meetings/events have been held on routing and addressing (https://github.com/danielkinguk/sarah ), which have been quite successful. The format looks interesting whilst missing an official specific venue. From informal

Re: [Int-area] [EXTERNAL] Re: Side meeting follow-up: What exact features do we want from the Internet?

Hi Fred, I see AERO and OMNI as examples of technologies trying to fill a gap (or a few gaps), falling exactly in what has been done in the Gap Analysis draft: surveying technologies that are filling gap in the addressing model. Ìt would be wonderful if you could formulate the gap(s) that AERO

Re: [Int-area] Side meeting follow-up: What exact features do we want from the Internet?

Hello, I find the MTU discussion interesting. It pops up from time to time in different mailing list, a clear sign that we lack a solution and the discussion here show that there are different ideas of how the solution should look like. Having said that, this is not caused by addressing itself,

[Int-area] Where/How is the features innovation happening?

Dear all, We have had a very nice discussion in the previous thread about what kind of features we would want from the Internet. We wanted to come back on another interesting point that has been raised during the side meeting held during IETF 112, namely is where the innovation happening?

Re: [Int-area] Where/How is the features innovation happening?

centralized service. Is it clearer? Ciao L. > On 16 Dec 2021, at 11:00, Alexandre Petrescu > wrote: > >  > >> Le 16/12/2021 à 10:09, Luigi Iannone a écrit : >> Dear all, >> We have had a very nice discussion in the previous thread about what kind of >> f

Re: [Int-area] Where/How is the features innovation happening?

Hi Alex, A few comments inline L. Sent from my iPad > On 16 Dec 2021, at 12:48, Alexandre Petrescu > wrote: > >  > >> Le 16/12/2021 à 12:29, Luigi Iannone a écrit : >> Hi Alex, >> Thanks, I might have been unclear. >> By “where” I mean

Re: [Int-area] Where/How is the features innovation happening?

> On 16 Dec 2021, at 23:35, Dino Farinacci wrote: > >> If we don't want to share a common transmission resource, then why do we >> need globally unique addresses to use in IP packet headers? Locally unique >> addresses would do just as well. > > Just to answer this question specifically. We

Re: [Int-area] Where/How is the features innovation happening?

> And Luigi, you shouldn't trust the devices that are close to you. Even if you > manage them you can't trust the vendors that make them. > Fair enough. And if we push this further I cannot trust the very device I am using to write this mail. ;-) Revising the trust model was/is discussed in

Re: [Int-area] Where/How is the features innovation happening?

> On 18 Dec 2021, at 04:19, Dino Farinacci wrote: > >  >> >> As a network layer person I personally find this a pretty sad situation, and >> I would like it to be otherwise. But the capital markets don't listen to me. >> They are busy talking up the content and cloud folk who are busy pushin

Re: [Int-area] Where/How is the features innovation happening?

2021, at 10:09, Luigi Iannone wrote: > > Dear all, > > We have had a very nice discussion in the previous thread about what kind of > features we would want from the Internet. > > We wanted to come back on another interesting point that has been raised > during the s

Re: [Int-area] [arch-d] Continuing the addressing discussion: what is an address anyway?

Hi Geoff, Dirk, I wanted to add a couple of comments on your excellent points, see inline. (trimmed a little bit of the text) Ciao L. > On 27 Jan 2022, at 08:51, Dirk Trossen > wrote: > [snip] > > There is also a second factor, that of sunk cost. Nobody wants to pay to > upgrade existi

Re: [Int-area] Next steps for draft-jia-intarea-internet-addressing-gap-analysis

From: Juan Carlos Zuniga (juzuniga) mailto:juzun...@cisco.com>> Sent: Wednesday, 22 June 2022 21:16 To: Luigi IANNONE mailto:luigi.iann...@huawei.com>>; jiayi...@huawei.com <mailto:jiayi...@huawei.com> Cc: Wassim Haddad mailto:wassim.had...@ericsson.com>>; Eric Vync

[Int-area] Rebooting Addressing Discussion

Hi All, During the last INTArea meeting the discussion on the two drafts related to Internet addressing had three the clear outcomes: 1. The issue seems to go beyond what the INTArea has been chartered for. 2. The pain points (aka the problem) have to be scoped in a better way. In th

Re: [Int-area] Rebooting Addressing Discussion

Hi Jens, A few comments inline. From: Int-area On Behalf Of Jens Finkhaeuser Sent: Friday, 30 September 2022 11:21 To: Luigi Iannone Cc: int-area Subject: Re: [Int-area] Rebooting Addressing Discussion Hi all, since I found myself contributing to the draft, it should be obvious that I&#

Re: [Int-area] Rebooting Addressing Discussion

Hi Roland > -Original Message- > From: Int-area On Behalf Of Bless, Roland (TM) > Sent: Tuesday, 4 October 2022 18:08 > To: Luigi Iannone ; int-area > Subject: Re: [Int-area] Rebooting Addressing Discussion > > Hi Luigi, > > a related question would als

Re: [Int-area] Rebooting Addressing Discussion

ed up the text in the first paragraph somehow, now corrected. > > On 06.10.22 at 11:32 Bless, Roland (TM) wrote: > > Hi Luigi, > > > > see inline. > > > > On 05.10.22 at 10:14 Luigi IANNONE wrote: > >> -Original Message- > >>> From: In

Re: [Int-area] Rebooting Addressing Discussion

Hi Robert, A couple of comments inline. From: Int-area On Behalf Of Robert Moskowitz Sent: Thursday, 6 October 2022 17:37 To: Jens Finkhaeuser ; Luigi Iannone Cc: int-area Subject: Re: [Int-area] Rebooting Addressing Discussion On 9/30/22 05:20, Jens Finkhaeuser wrote: Hi all, since I

Re: [Int-area] Rebooting Addressing Discussion

I am available to contribute. Bob [LI] Awesome :-) ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Rebooting Addressing Discussion

meet Thursday November 10Th at 18:30 (London Time) at the registration desk and find a place to seat and discuss a bit. If you plan to come consider drop me a private email, just to have a sense of the size of the place we need. See you in London Ciao L. From: Int-area On Behalf Of Luigi

Re: [Int-area] Rebooting Addressing Discussion

Hi All, Hope you are having a great IETF week. Just a small reminder for those that are interested in talking about addressing, let’s meet 18h30 this evening @ registration desk. Ciao L. From: Luigi IANNONE Sent: Wednesday, 19 October 2022 16:24 To: 'Luigi Iannone' ; int-area S

[Int-area] Fwd: Following up on RTG WG interim meeting in June 2022 with discussion paper on multicast

Hello, This may be of some interest for some of you. Ciao L. Begin forwarded message: > From: Dirk Trossen > Date: 28 November 2022 at 15:46:12 CET > To: rt...@ietf.org > Subject: Following up on RTG WG interim meeting in June 2022 with discussion > paper on multicast > >  > Dear all, >

Re: [Int-area] New -00 draft: draft-augustyn-intarea-ipref-00

Hi, I was wondering if it make sense to use it in an IoT deployment. In that context IP addresses are often compressed, so instead of compression small sized references can be used. On the flip side, and in the general case, references reduce privacy w.r.t. other technologies like e.g. NAT.

Re: [Int-area] New -00 draft: draft-augustyn-intarea-ipref-00

023 04:25 > To: Luigi IANNONE ; Evan Pratten > > Cc: int-area@ietf.org > Subject: Re: [Int-area] New -00 draft: draft-augustyn-intarea-ipref-00 > > It can certainly be used. The references are only carried up to the gateway > where they're used to produce local I

Re: [Int-area] What is in a name - draft-ietf-intarea-schc-ip-protocol-number

Hi, [snip] > Thus the old draft name no longer reflects the new content.  There is a > mechanism when you submit a draft to link it to a prior draft so the draft > history is properly maintained (it does not support linking to multiple prior > drafts or splitting an old draft into multiple, for t

Re: [Int-area] WGLC for draft-ietf-intarea-rfc7042bis-04

Support publication. Ciao L. From: Int-area On Behalf Of Wassim Haddad Sent: Friday, 5 May 2023 08:17 To: Internet Area Cc: intarea-cha...@ietf.org Subject: [Int-area] WGLC for draft-ietf-intarea-rfc7042bis-04 Dear Intarea WG, This email starts an Intarea WG Last Call on draft-ietf-in

Re: [Int-area] [IPv6] New Draft - ICMPv6 Loopback

For FreeBSD it looks like code MUST be 0 or the packet is dropped: (file netinet6/icmp6.c line 550: http://fxr.watson.org/fxr/source/netinet6/icmp6.c#L550) case ICMP6_ECHO_REQUEST: icmp6_ifstat_inc(ifp, ifs6_in_echo); if (code != 0)

Re: [Int-area] The CBOR section of draft-ietf-intarea-rfc7042bis...

> -Original Message- > From: Int-area On Behalf Of Donald Eastlake > Sent: Wednesday, 13 September 2023 20:21 > To: Eric Vyncke (evyncke) > Cc: int-area@ietf.org; c...@ietf.org; Murray S. Kucherawy > ; Francesca Palombini > ; draft-ietf-intarea- > rfc7042bis@ietf.org > Subject: Re:

Re: [Int-area] The CBOR section of draft-ietf-intarea-rfc7042bis...

Hi, I’ve just updated the writeup to track the discussion about section 2.4. This can be found in bullet 5 of the writeup: https://datatracker.ietf.org/doc/draft-ietf-intarea-rfc7042bis/shepherdwriteup/ Ciao L. > On Sep 14, 2023, at 15:09, Luigi IANNONE wrote: > > > >

Re: [Int-area] intarea charter

+1 Luigi On Sep 30, 2009, at 23:52 , Laganier, Julien wrote: I support creation of the WG for all the good reasons Jari listed below. --julien -Original Message- From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On Behalf Of Jari Arkko Sent: Wednesday, September 3

[Int-area] Re: Call for WG adoption of draft-chroboczek-intarea-v4-via-v6

Support. L. From: Juan Carlos Zuniga (juzuniga) Sent: Monday, May 12, 2025 4:19 PM To: Internet Area Subject: [Int-area] Call for WG adoption of draft-chroboczek-intarea-v4-via-v6 Dear IntArea WG, Draft https://datatracker.ietf.org/doc/draft-chroboczek-intarea-v4-via-v6/ was presented at IE

[Int-area] Re: Shepherd review of draft-ietf-intarea-icmp-exten-hdr-len

-hdr-len/ Can you ask the secretariat to fix the issue? Ciao L. > On 18 Jun 2025, at 11:19, Luigi Iannone wrote: > > Dear Authors, > > I will shepherd this document through the usual IETF process. > I reviewed the document, which is very well written, short and to the point. &

[Int-area] Shepherd review of draft-ietf-intarea-icmp-exten-hdr-len

Dear Authors, I will shepherd this document through the usual IETF process. I reviewed the document, which is very well written, short and to the point. I have just a couple of comments: Section 1, last paragraph, there is a typo after the SHOULD, replace “aways” with “always”. Section 4, mi

[Int-area] IPR check for draft-ietf-intarea-icmp-exten-hdr-len

All, Currently, there are no IPR disclosures in the datatracker against the document in the subject. If anybody is aware of any relevant undisclosed IPR, please respond to this email. @Authors, please respond to this email even if you are _not_ aware of any relevant undisclosed IPR. Thanks

[Int-area] Mail regarding draft-ietf-intarea-icmp-exten-hdr-len

Authors, Chairs, I’ve just submitted the writeup for this document. Note that there are a few warnings that show up with the idnits tool and the datatracker metadata needs to be fixed (details in the writeup). The above can be done during AD review, hence from my side you can hit the publish but

[Int-area] Shepherd Review for draft-ietf-intarea-extended-icmp-nodeid-02

Dear Authors, thanks forwriting this document, which is quite clear. As a shepherd I went through the document and have a few comments. I think the the definition of _unique_ Node ID is a bit hidden in the document and not clearly spelled out. The second paragraph of the abstract is close but n

[Int-area] Re: AD review of draft-ietf-intarea-icmp-exten-hdr-len-01

Hi Eric, I just updated the writeup. Ciao L. From: Eric Vyncke (evyncke) Sent: Monday, July 7, 2025 1:09 PM To: int-area@ietf.org Cc: Ron Bonica ; he...@chinatelecom.cn; xiao.min2 Subject: [Int-area] AD review of draft-ietf-intarea-icmp-exten-hdr-len-01 # Éric Vyncke, INT AD, AD review o

[Int-area] Re: AD review of draft-ietf-intarea-icmp-exten-hdr-len-01

From: Ron Bonica Sent: Monday, July 7, 2025 6:39 PM To: Eric Vyncke (evyncke) ; int-area@ietf.org Cc: he...@chinatelecom.cn; xiao.min2 Subject: [Int-area] Re: AD review of draft-ietf-intarea-icmp-exten-hdr-len-01 Erik, Thanks for the careful review. I have posted a version-02 that addresses a

[Int-area] Re: AD review of draft-ietf-intarea-icmp-exten-hdr-len-01

You are actually right Ron. Thanks for the explanation. L. From: Ron Bonica Sent: Friday, July 11, 2025 2:38 PM To: Luigi IANNONE ; Eric Vyncke (evyncke) ; int-area@ietf.org Cc: he...@chinatelecom.cn; xiao.min2 Subject: Re: AD review of draft-ietf-intarea-icmp-exten-hdr-len-01 Luigi, In

[Int-area] Re: AD review of draft-ietf-intarea-icmp-exten-hdr-len-01

### Section 4 Even if the text is better in -02, the operational considerations / backward compatibility are still vague. As I said in my review, on this point I think that Section 7 of RFC 4884 applies: In particular the text: Having received an ICMP message with extensions, applicatio