[Int-area] SNAC BoF and mailing list

[If you see this a lot of times, I really apologize—I think it's relevant to all the mailing lists I'm sending it to, but I know that that's a lot. Please reply to s...@ietf.org, not here.] You may have seen an announcement yesterday for the s...@ietf.org mailing list. The point of this

Re: [Int-area] New draft: The IETF Will Continue Maintaining IPv4 (draft-schoen-intarea-ietf-maintaining-ipv4)

On Tue, Mar 15, 2022 at 2:59 PM Seth David Schoen wrote: > When we presented our reserved address space drafts at the previous IETF > meeting, we noticed that the most common concern was not so much about > the substance of our proposals as about the question of whether intarea > and the IETF

Re: [Int-area] Introducing IPv4 Unicast Extensions with new draft-schoen-intarea-lowest-address

What's the problem you're trying to solve here, John, that's not already solved by just using IPv6? I'm not saying there isn't one, but if there is, I'm not seeing it. The ability to free up IPv4 addresses to monetize doesn't seem like it would pay back the people who would be doing the work to

Re: [Int-area] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

On May 5, 2021, at 11:44 AM, Michael Richardson wrote: > The end user might suffer slightly by having locally served > reverse names that are no longer connected: they should obsolete that zone > when they realize that their PD hasn't been renewed, until such time, > (if it was a flash renumber),

Re: [Int-area] Dear intarea chairs: int-area time planning

On Mar 12, 2021, at 6:13 PM, Juan Carlos Zuniga wrote: > We have had multiple issues trying to accommodate late requests (arriving > after we have already requested the time slot to the IETF meeting planners). > However, we will try to avoid this trend and will request a longer slot for > the

Re: [Int-area] IPv10 draft (was Re: FW: [v6ops] v6ops - New Meeting Session Request for IETF 109 - IPv10)

On Sep 19, 2020, at 8:10 AM, Khaled Omar wrote: > I can keep trying as long as walking on the right road. Why do you think you are walking the right road? Sometimes it’s true that a person can be a voice in the wilderness crying out a truth that others refuse to see, it’s true. But another

Re: [Int-area] IPv10 draft (was Re: FW: [v6ops] v6ops - New Meeting Session Request for IETF 109 - IPv10)

On Sep 17, 2020, at 10:31 AM, Khaled Omar wrote: > I’m not a code developer, really we are repeating same requirements, so what > is the meaning of a work group?! If you can’t write code, what business do you have proposing standards? Proposing standards is an additional skill on top of

Re: [Int-area] FYI/Feedback for draft-bryant-arch-fwd-layer-ps-00

On Mar 24, 2020, at 1:52 PM, Toerless Eckert wrote: > But without a longer term architectural track doing work like this > in parallel to current WGs, it will be difficult for the IETF to really drive > innovation at the network / forwarding layer longer term. Is this something we are even

Re: [Int-area] Adam Roach's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)

On Jan 22, 2020, at 11:44 AM, Tommy Pauly wrote: > The mitigations fall into two general categories: (1) ensuring that clients > can be less easily tricked into being complicit in the attack; (2) and having > the HTTP server protect itself. For a DDoS attack, if you get to (2) you are already

Re: [Int-area] Adam Roach's Discuss on draft-ietf-intarea-provisioning-domains-10: (with DISCUSS and COMMENT)

On Jan 22, 2020, at 10:53, Tommy Pauly wrote: > Network operators SHOULD restrict access to PvD Additional > Information to only expose it to hosts that are connected to the local > network... [this] can be implemented by > whitelisting access from the addresses and prefixes that the router

Re: [Int-area] WGLC on draft-ietf-intarea-provisioning-domains-05

On Jun 18, 2019, at 6:39 PM, Wassim Haddad wrote: > This email starts an Int-Area WG Last Call on the latest version of > draft-ietf-intarea-provisioning-domains (“Discovering Provisioning Domain > Names and Data"): > > https://tools.ietf.org/html/draft-ietf-intarea-provisioning-domains-05.txt

Re: [Int-area] Main change in draft-ietf-intarea-provisioning-domains-03: connection sharing

FYI this document is being referenced now by the Homenet Naming Architecture Document, in the Resolution section. Question: >The values of the R-bit, Router Advertisement message header and > >Options field depend on whether the connectivity should be shared > >only with PvD aware

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On May 9, 2018, at 11:38 AM, Dave O'Reilly wrote: > Indeed, I would go further and assert that the IETF is on a developmental > trajectory that actively seeks to eliminate evidence (and attribution of > online activity in particular). I cite, for example, the work that has been

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On May 2, 2018, at 6:02 PM, Dave O'Reilly wrote: > All of these points are addressed in the current version of the document. > It’s perhaps not put in a way that refers so directly to the regulatory > alternatives but they are discussed. Specifically, an entire section (Section

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On May 2, 2018, at 9:02 AM, Ted Lemon <mel...@fugue.com> wrote: > That's a much better approach to take if you want to convince the working > group that this is worth doing. BTW, if you are going to take that approach, you should bear in mind that most of us assume that pervasiv

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On May 2, 2018, at 6:14 AM, Dave O'Reilly wrote: > No, what you said was that “it’s not clear that the work is in scope of the > working group anyway”. And I was asking you, if it isn’t, where would be a > more appropriate place to have the discussion? It's possible that the

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On May 1, 2018, at 12:36 PM, Dave O'Reilly wrote: > 3. If there is a more appropriate forum for discussion, what do you think it > is? I didn't say that there was a better forum. I said that you haven't said anything to convince me that the IETF in particular should be

Re: [Int-area] Int-area Digest, Vol 152, Issue 52

On Apr 26, 2018, at 11:44 AM, Dave O'Reilly wrote: > I don’t understand what you mean when you say "And it doesn't say what you > want to say—you're talking about the other end of the connection. So yes, > it can be used as a pretext as written, but that's actually a problem,

Re: [Int-area] Int-area Digest, Vol 152, Issue 52

On Apr 26, 2018, at 11:18 AM, Dave O'Reilly wrote: > Well, the IETF - this group in fact - is already saying this in RFC6302. Yes, but this is an old document that has been superseded at least in spirit by more recent work. I do not think we would publish RFC 6302 as written

Re: [Int-area] Int-area Digest, Vol 152, Issue 52

On Apr 26, 2018, at 11:08 AM, Dave O'Reilly wrote: > I thought we had already agreed that if it makes sense to log IP address, it > makes sense to log source port (ref: > https://www.ietf.org/mail-archive/web/int-area/current/msg06389.html >

Re: [Int-area] Int-area Digest, Vol 152, Issue 52

On Apr 26, 2018, at 10:50 AM, Dave O'Reilly wrote: > No, you’re absolutely right about that. However I do not think that this has > any bearing on the relevance of the recommendations in my document. I think this is the crux of the disagreement. > In response to this point I

Re: [Int-area] Int-area Digest, Vol 152, Issue 52

On Apr 26, 2018, at 10:27 AM, Dave O'Reilly wrote: > Let me clarify: I’m not saying that there are no problems with judicial > systems around the world but I was commenting, in response to your point, > that IP address will usually form part of the evidence and will not

Re: [Int-area] Int-area Digest, Vol 152, Issue 52

On Apr 26, 2018, at 5:14 AM, Dave O'Reilly wrote: > In my experience it’s a pretty poor investigator that would rely on IP > address only for the purposes of identifying a real-world identity. I mention > this point in both of the draft documents that I have published. Any

Re: [Int-area] Int-area Digest, Vol 152, Issue 52

On Apr 25, 2018, at 2:49 PM, Povl H. Pedersen wrote: > If we have performance issues, a drill down might be performed when the right > people are involved. And in a few cases we have located some low and slow > attacks and ended up blocking IPs. Usually 1 or 2. So it is

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 25, 2018, at 9:50 AM, Dave O'Reilly wrote: > In that case - that’s substantially all that’s in my Internet Draft. Where do > you see a difference between the content of the Internet Draft and this > apparent consensus? In order to answer this I'm going to have to

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 25, 2018, at 9:44 AM, Dave O'Reilly wrote: > Sorry, I may have misread your email. Are you saying that there are times > when it makes sense to log IP, but NO times in which it makes sense to log > source port? Or something different? No, I'm saying that if it makes

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 25, 2018, at 9:36 AM, Dave O'Reilly wrote: > OK, and what are the disadvantages of logging source port? Specifically, what > are the differential disadvantages between logging IP address and source port > versus only logging IP address? I don't think there are times

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 25, 2018, at 5:47 AM, Dave O'Reilly wrote: > Considering the examples I provided, would you be prepared to agree that > there exist situations where it would be useful to have source port logged > alongside IP address? I think I already agreed that that was true. I

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 24, 2018, at 6:53 PM, Brian E Carpenter wrote: > I have trouble with that. When a user complains that "my transaction at 23:59 > UTC > yesterday failed", it's too late to switch on logging. So I think in > practice, logging > for problem debugging needs to

Re: [Int-area] draft-andersdotter (was RE: WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 24, 2018, at 7:57 PM, Brian E Carpenter wrote: > Clearly not, but operations people are much more likely to apply a "log > everything we can store" approach than to be selective in advance. I think > it's privacy law, not IETF BCPs, that will make them think

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 24, 2018, at 11:30 AM, Dave O'Reilly wrote: > Could you give me an example of when you think it would be appropriate to log > source port and when it would not be? It's not appropriate to log source port if there's no potential for abuse by the connecting party, or if

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 24, 2018, at 9:11 AM, wrote: > What sort of trade-offs can be added to Dave’s document? Do you have in mind > something like: > (1) > -Warranting that logging may be misused for tracking users? > -Logging information

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 24, 2018, at 5:11 AM, Dave O'Reilly wrote: > Part of the problem that I have noticed is that the discussions of privacy > vs. law enforcement access to data are very ideologically motivated - on both > sides - with neither side apparently willing to accept that the other

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 24, 2018, at 1:58 AM, wrote: > [Med] I confirm that Dave’s I-D does not define a new behavior. It has the > merit to discuss issues related to source ports. I do agree this is a minor > contribution, but I like it because it

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 23, 2018, at 1:32 AM, mohamed.boucad...@orange.com wrote: > - **DOES NOT** define a new behavior: it relies on existing IETF RFCs. > - **DOES NOT** require logging another yet information: again, it relies on > the various schemes discussed in existing RFCs. If it doesn't define new

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

FWIW I think both Brian and Stephen have raised good points here. I don't mean to say that there isn't a problem here, but I don't think it's really the right match for the IETF in general or for IntArea in particular to be publishing a document on how to facilitate monitoring on legacy

Re: [Int-area] Review of draft-ietf-intarea-provisioning-domains

On Mar 28, 2018, at 10:53 AM, Eric Vyncke (evyncke) wrote: > While the authors will review your comments and come back to the list, I want > to stress that the HTTPS/JSON is really at the core of our proposal in order > to add network information to the application (notably

[Int-area] Review of draft-ietf-intarea-provisioning-domains

As requested, I'm doing a review of the document. Executive summary: I don't think the document is ready. I don't actually think the proposed model for doing multiple RAs makes sense. I don't think it makes sense to tie in the HTTP/JSON stuff. It feels vague and underspecified. I

Re: [Int-area] Comments on current MPvD draft.

On Nov 16, 2017, at 12:03 AM, Eric Vyncke (evyncke) wrote: > This could be an alternative but I can only imagine the pile of changes to be > done... RA-guard, RFC 4890, ... Wouldn't these changes be required as well if you used a different multicast address? > In either

Re: [Int-area] Comments on current MPvD draft.

annot be fragmented. > > > > Expect more discussions/proposals on the list on this topic > > > > -éric > > > > *From: *Int-area <int-area-boun...@ietf.org> on behalf of Ted Lemon < > mel...@fugue.com> > *Date: *Wednesday 15 November 2017 at 14:52 &

[Int-area] Comments on current MPvD draft.

I'd like to have a bit of discussion today on the architectural choices in the current draft, if possible. There are two issues I want to discuss: The assumption that each PvD will have its own router The expected behavior of hosts that do not support MPvD in the presence of multiple routers

Re: [Int-area] [v6ops] Fwd: WG Adoption Call: Discovering Provisioning Domain Names and Data

On Sep 21, 2017, at 11:02 AM, Suresh Krishnan wrote: > The intarea working group is considering adoption of a draft concerning > provisioning domains. The response to the adoption call has been a bit on the > quieter side but generally positive. I am spreading out

Re: [Int-area] IPv10.

On Sep 12, 2017, at 4:01 PM, Tim Chown wrote: > I believe you can request an IETF mail list, e.g. ip...@ietf.org > to discuss your proposal. This is subject to approval from the IESG, and typically requires that (many) more than one person express

Re: [Int-area] IPv10.

On Sep 12, 2017, at 2:54 PM, Khaled Omar wrote: > This means that the issue is not on the technical details, the issue is > personal that shouldn't be at the IETF because it doesn't matter from where > the author is or people looking for more things other than

Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03

On Fri, May 20, 2016 at 6:13 AM, Xuxiaohu wrote: > Thanks for your comment. Note that it’s WG adoption call rather than WGLC. > If I understand it correctly, as long as it’s worthwhile to provide > fine-grained load-balancing of Softwire service traffic by leveraging the >

Re: [Int-area] Call for adoption of draft-baccelli-intarea-adhoc-wireless-com-01.txt

On Oct 13, 2015, at 8:13 PM, Suresh Krishnan wrote: > Please state whether or not you're in favor of the adoption by replying > to this email. If you are not in favor, please also state your > objections in your response. This adoption call will complete on

[Int-area] Fwd: Update on ³Hybrid Access for Broadband Networks² (WT-348)

chair" jari.ar...@piuha.net, "Brian Haberman, Internet Area Director" br...@innovationslab.net, "Ted Lemon, Internet Area Director" ted.le...@nominum.comCc: "Christophe Alter, Broadband Forum Technical Committee Chair" christophe.al...@orange.com, David Allan I

Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04

On Jul 23, 2014, at 8:11 AM, Eggert, Lars l...@netapp.com wrote: I wanted to repeat my comment from the meeting. Given that at least in my read of RFC6967, there exist to sane mechanism to even exchange host IDs across the network, I don't really see why INTAREA should spend any more time

Re: [Int-area] Call for adoption of draft...

On Jun 12, 2014, at 4:23 AM, Chris Prince Udochukwu Njoku udochukwu.nj...@unn.edu.ng wrote: Agreeing to Dirk's observations, I also submit that the draft be adopted. FWIW, messages of this sort in a consensus call have no value to the chairs or to the AD. If you think it should be supported,

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On Jun 9, 2014, at 4:10 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I thought we were discussing whether to document the use cases. Is there some value in documenting the use cases? Do people have plans? ___ Int-area mailing list

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On Jun 6, 2014, at 4:11 AM, mohamed.boucad...@orange.com wrote: Adding a discussion on potential misuses can be considered to address the comment from Stephen if those are not redundant with the text already in http://tools.ietf.org/html/rfc6967#section-3. The document hasn't been adopted

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On Jun 5, 2014, at 4:28 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I have to call you on that. WG adoption is not approval. It's agreement to work on a topic. It is not OK to attempt a pocket veto on adoption because you don't like the existing content. WG adoption is a pretty

Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

It also seems doubtful that this would be useful outside the carrier network, since service providers would have to implement it and middleboxes would have to support it, neither of which is something we can depend on. Inside of the carrier network, solutions like A+P at the very least are

Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

On Oct 9, 2013, at 4:09 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: MPLS fits my example, so does provider bridging. You take a packet, smack on a label or additional header, send it elsewhere (inbetween boxes doesn't need to know what is in the packet, thus solving scaling), destination

Re: [Int-area] Call for adoption of draft-nachum-sarp-06.txt

On Oct 3, 2013, at 6:42 PM, Linda Dunbar linda.dun...@huawei.com wrote: [Linda] I understand that many people are still not convinced of the need for hosts within one subnet to be placed in different server racks. Again, Linda, I'm really sorry to keep harping on this point, but the problem

Re: [Int-area] New Version Notification for draft-nachum-sarp-06.txt

On Jul 18, 2013, at 8:34 AM, Linda Dunbar linda.dun...@huawei.com wrote: Thank you very much for the advice. We will clean up the acronyms in the next revision. Great, thanks! ___ Int-area mailing list Int-area@ietf.org

Re: [Int-area] New Version Notification for draft-nachum-sarp-06.txt

On Jul 15, 2013, at 12:09 PM, Linda Dunbar linda.dun...@huawei.com wrote: Many Thanks to Ted Lemon in asking many good questions and providing good suggestion on the text. We have updated the draft based on Ted's input. Thanks for taking some of my suggestions. I still strongly advise you

Re: [Int-area] New Version Notification for draft-nachum-sarp-05.txt

On Jul 15, 2013, at 7:18 AM, Linda Dunbar linda.dun...@huawei.com wrote: This document describes a proxy gateway technique, which is called SARP throughout this document, to reduce switches' FDB (MAC table) sizes and ARP/ND impact on network elements in an environment where hosts within one

Re: [Int-area] FW: New Version Notification for draft-nachum-sarp-05.txt

How does this relate to the work being done in the trill and nvo3 working groups? ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Privacy red herrings [ My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting]

On Nov 18, 2011, at 10:18 AM, Dan Wing dw...@cisco.com wrote: I would not want to say that Baidu's use of NAT66 (or NPTv6) provides justification for an internet service provider to use NAT66 or NPTv6. Indeed, when this showed up on the chart, it was difficult to understand what purpose the

Re: [Int-area] mic comments on draft-matsushima-v6ops-transition-experience

On Mar 29, 2011, at 3:32 PM, Alain Durand adur...@juniper.net wrote: The routing optimization only works if is no IPv4 address overlap. But of course there will be IPv4 address overlap. Here is how the routing optimization outright fails -- Alice wants to communicate with Bob. But she will

Re: [Int-area] miccomments on draft-matsushima-v6ops-transition-experience

On Mar 29, 2011, at 5:02 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: I don't think it is right to equate incremental deploymnet with transition mechanism. IRON is both incrementally deployable and a widely applicable long-term solution. I didn't mention IRON—I was referring

Re: [Int-area] Ted's slides on dhcp-auth

On Mar 24, 2010, at 11:08 AM, Alper Yegin wrote: Fine. I won't bother explaining anymore. Excellent. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Ted's slides on dhcp-auth

On Mar 24, 2010, at 2:24 PM, David W. Hankins wrote: Suppose that it is shown that DHCP is only a transport protocol in your words from your presentation yesterday. You are taking what I said out of context. I said that if we decouple the EAP and DHCP state machines, then DHCP is functioning

Re: [Int-area] Ted's slides on dhcp-auth

On Mar 23, 2010, at 1:58 PM, Alper Yegin wrote: - Still you need the DHCP relay to send packets (for transporting EAP retransmissions, initiating EAP re-authentication), I agree that this is still needed, but why is it a problem? - Proxy vs. relay confusions continues, The relay does the

Re: [Int-area] DHCP-based subscriber authentication

On Mar 17, 2010, at 6:13 PM, Richard Pruss r...@cisco.com wrote: In broadband deployments, the DHCP state machine starts in init state, then is paused while we run EAP state machine and then resume the DHCP machine normally. I'm not familiar with the RFC (or other document) that describes

Re: [Int-area] practical issues with using v4-mapped addresses for nat64

On Jul 23, 2008, at 10:27 PM, Pekka Savola wrote: Why is using the mapped addresses on the wire such a holy grail of v6-only operation? As a destination address, it might result in IPv6 DFZ being polluted with the corresponding v4 routes except if you only use it in very restricted environments

Re: [Int-area] practical issues with using v4-mapped addresses for nat64

On Jul 22, 2008, at 5:31 PM, Dave Thaler wrote: No IPv4 addresses to hand out == IPv6-only network (for purposes of this discussion anyway) -ish. You may have IPv4 addresses only for selected hosts. But you're right that I didn't catch that part of what you were saying... :'}