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

6967#section-3> says that a host-id will be generated anew any time the endpoint IP address changes, perhaps more often. Is that wrong? It's hard to do a privacy audit if the behavior isn't agreed on. On Mar 10, 2014 1:05 PM, "Joe Touch" wrote: > > > On 3/10/2014

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

to be acceptable from a privacy point of view, unless the >> end system is at liberty to change it at random (like RFC 4941). > > Scott Brim said there are no privacy issues. I said I don't believe this introduces any NEW privacy issues, as long as host-ids change a

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

On Thu, Mar 6, 2014 at 4:28 PM, joel jaeggli wrote: > C. How we address concerns raised by the IETF community expressed > through draft-farrell-perpass-attack when evaluating scenarios and > beginning to address requirements and solution-space. http://tools.ietf.org/html/rfc6967#section-3 says t

Re: [Int-area] IP Connectivity Provisioning Profile (draft-boucadair-connectivity-provisioning-profile)

Would it be interesting to subsume IRS under this? https://datatracker.ietf.org/doc/draft-atlas-irs-problem-statement/ ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02

On Wed, Aug 8, 2012 at 10:49 AM, Joe Touch wrote: > > On Aug 6, 2012, at 5:29 PM, Dan Wing wrote: > >> ... >> During the INTAREA presentation, one suggestion I heard was >> a separate protocol (ident-like). I will submit an I-D towards >> that end, which I am dusting off from 2010 when I first >>

Re: [Int-area] Adoption of draft-boucadair-intarea-nat-reveal-analysis as WG draft

On Wed, Feb 8, 2012 at 09:33, Suresh Krishnan wrote: > Hi all, >  There was significant support to adopt this draft as wg item both in > the face-to-face meeting in Taipei and on the mailing list. There were > some significant privacy concerns raised concerning the draft, and they > needed to be a

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

On Wed, Nov 16, 2011 at 05:34, wrote: > We seriously considered the privacy comment; this is why we contacted the > IETF privacy mailing list hopping to receive feedback (see > http://www.ietf.org/mail-archive/web/int-area/current/msg02958.html) but > unfortunately only one comment was receive

Re: [Int-area] intarea status update before IETF-81

it.edu > > Subject: Re: [Int-area] intarea status update before IETF-81 > > > > > From: Scott Brim > > > > > You want a way forward for IRON. You need to drum up > > support and get > > > collaborators. > > > > Agreed. Tryin

[Int-area] intarea status update before IETF-81

On Tuesday, June 28, 2011, Templin, Fred L wrote: > At the last meeting, there was a scheduled timeslot for > IRON, but earlier presentations ran over and we ran out > of time. I would therefore assume that the missed timeslot > for IRON should carry over to this meeting, hence there is > somethin

Re: [Int-area] IRON issue discussion

On Wed, Jun 15, 2011 at 03:51, Bob Hinden wrote: > Fred, > > This sounds a lot like Mobile IPv6 with the extension that the client can change home agents if the client get's too far away from where the the home agent is. I am sure the details are different, but the functionality sounds similar.

[Int-area] Bringing RRG results into IntArea WG

Since the issue of bringing RRG discussion concepts into the working group came up ... Most of the things that were discussed in the RRG, and other things that impinge on the fundamentals of Internet architecture, have natural WG/RG homes already (e.g. VA -> GROW, SCTP -> TSVWG). Others such as I

Re: [Int-area] IRON issue discussion

Folks, speaking for myself: Regarding IRON, I heard support for discussion but very little actual discussion. It kind of died at the starting gate. Right now I don't see why IRON should have agenda time until there is clear disagreement or confusion. Tom said > Mangling my metaphors, build a b

[Int-area] IRON issue discussion

First, I've changed the subject (but kept the threading). Second, on this specific issue -- discussion of IRON topics to see if there are any that canNOT be clarified on the mailing list, and thus need agenda time -- Tom, you say > I think that what is wrong with Fred's list is point 1); a techni

Re: [Int-area] Steps to make the IntArea WG more productive

that connects clients >   to correspondents both within the ISP's overlay network >   as well as within the public Internet. > > Again, this is a partial list but should be sufficient > to initiate discussion. What would you like to see in > terms of next steps? > > Tha

Re: [Int-area] Steps to make the IntArea WG more productive

Hi Fred. Sorry for being late. I started the week with a 103.8F (39.9C) fever. That's all gone but I'm still moving slowly. > While the IRON architecture has already been published as RFC6179, I > do not believe there is yet a sufficiently wide understanding of the > technology such that it wou

Re: [Int-area] Steps to make the IntArea WG more productive

FYI I put this on the wiki at Scott ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Steps to make the IntArea WG more productive

Thomas: also on some of your points ... On Wed, May 4, 2011 at 15:26, Thomas Narten wrote: > - No presentations for new material (i.e., work to take on) without >  there first being list discussion for the proposal AND there being >  some minimal level of support on the list that haveing a >  pre

Re: [Int-area] Steps to make the IntArea WG more productive

On Wed, May 4, 2011 at 15:26, Thomas Narten wrote: > Hi Scott. > > I'm generally supportive of your suggestions. > > Some other thoughts: > > Be more selective in what you give agenda time to. The idea that we > start with a slot and fill it up is the wrong way to do things. We > should look at wh

Re: [Int-area] Steps to make the IntArea WG more productive

On Wed, May 4, 2011 at 14:51, Bob Hinden wrote: > > I am generally supportive of this approach.  It's the approach all working > groups should use. > > My only concern is that I wonder if the int area w.g. should be careful to > not take on big projects the end up excluding all else.  These migh

Re: [Int-area] Steps to make the IntArea WG more productive

On Wed, May 4, 2011 at 06:10, t.petch wrote: > Scott > > My experience of other lists, which could well apply to Intarea, is > that many, if not most, lists would be more productive were the > chairs more active:-) > Drawing on that experience of other lists, what chairs might do more of is >

[Int-area] Steps to make the IntArea WG more productive

Folks, the IntArea WG meeting in Prague was frustrating for some because there was not enough discussion time among the presentations. We have been talking about ways to do better, and how to make it easier for the WG to be productive. One potential improvement is more effective use of the mailing

Re: [Int-area] draft-ietf-intarea-ipv4-id-update-02.txt

On Tue, Apr 5, 2011 at 16:44, Iljitsch van Beijnum wrote: > On 5 apr 2011, at 18:51, Joe Touch wrote: > > >> This is the idea that an ID value can't be repeated for 120 (or 240) > >> seconds for the same 3-tuple. But why 120 seconds? Is there any > >> reasonable way that a packet gets fragmented,

Re: [Int-area] Scott Brim, intarea WG co-chair

On Wed, Mar 30, 2011 at 18:10, Francis Dupont wrote: > (oops, too happy, now with correct spelling :-) > > Welcome Scott! > > francis.dup...@fdupont.fr Thanks very much :-) ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinf

Re: [Int-area] [manet] SMF and intarea-ipv4-id-update

On Wed, Mar 30, 2011 at 14:34, Teco Boot wrote: > There are other ideas around, that could be applicable in MANETs. > You could check draft-briscoe-intarea-ipv4-id-reuse Bob's draft assumes Joe's draft. It may collide with other undocumented uses of the "reserved" flag. I never make assumptions

Re: [Int-area] testing concern about IPv4 ID (Joe and Bob et al)

r as well. > I'm not sure what testing you'd do when we don't even have IPv4 compliance > suites. Just to see if arbitrary bit settings get through intact, for example send packets in and echo them back. > On 3/29/2011 8:38 AM, Scott Brim wrote: >> >> I have a q

[Int-area] testing concern about IPv4 ID (Joe and Bob et al)

I have a question about reusing the IPv4 ID field. In theory it all looks good, but how sure are we that middleboxes are doing the right thing now? A particular concern is TCP "accelerators". I'm most familiar with them in cellular networks, where they often come with client and server pairs and

Re: [Int-area] intarea charter

Jari Arkko allegedly wrote on 10/12/2009 11:18 AM: > I believe there are two possible paths forward. The first is to keep the > group still as one group. The benefit of this approach is that time can > be spent where it is most urgently needed, e.g., a large area-wide topic > could take an entire m

Re: [Int-area] intarea charter

Jari Arkko allegedly wrote on 09/30/2009 12:26 PM: > The Internet Area Working Group (INTAREA WG) acts as a forum for > discussing far-ranging topics that affect the entire area. Such > topics include, for instance, address space issues, basic IP layer > functionality, and architectural questions.

Re: [Int-area] agenda for IETF-74

Excerpts from Phil Roberts on Tue, Mar 03, 2009 10:23:23AM -0600: > There will be a discussion of shared addresses in int-area, in ops-area, > and in the shara bof? Or are there multiple different forms of address > sharing that are going to be discussed, each with its own venue? and maybe Be

Re: [Int-area] [lisp] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

Excerpts from Brian E Carpenter on Tue, Feb 03, 2009 09:51:26AM +1300: > 1. Large companies with their own international networks will > surely never adopt a solution which doesn't allow them to have > a straightforward, consistent and 100% internally managed > addressing plan. > > 2. They also wo

Re: [Int-area] [rrg] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

Excerpts from Christopher Morrow on Mon, Feb 02, 2009 01:21:19PM -0500: > > According to your email to Robin, LISP/ALT currently makes the following > > tradeoff: Portability of EID prefixes is limited geographically in > > order to curb path stretch along the ALT topology to the maximum that > >

Re: [Int-area] RANGER BOF - call for participation

If you hold it, I will come. ___ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

Excerpts from Jon Crowcroft on Sun, Feb 01, 2009 09:30:55AM +: > you can push info multiply redundently > (or cross-post:) > and you get reliability with a silly overhead > > or you can push an update which is wrong and disconnect the entire > world, e.g. > http://googleblog.blogspot.com/2009/

Re: [Int-area] [rrg] [lisp] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

Excerpts from Christian Vogt on Sat, Jan 31, 2009 11:49:46AM -0800: > I think we should experimentally compare ALT with other mapping > systems before we decide whether pull-based or push-based mapping > systems are better. Dismissing push-based mapping systems without > corroborating data would b

Re: [Int-area] [rrg] Please respond: Questions from the IESG asto whether a WG forming BOF is necessary for LISP

Excerpts from Templin, Fred L on Thu, Jan 22, 2009 04:38:35PM -0800: > Not meaning to pick on you, but I don't understand why RANGER > hasn't made it onto the "short list" of proposals yet; maybe > you could answer that for me? AFAICT, RANGER is in the top-two > map/encaps proposals in terms of tec

Re: [Int-area] LISP agenda update

Excerpts from David Meyer on Thu, Jan 22, 2009 01:14:36PM -0800: > The Working Group will also develop security > profiles for the ALT and/or other mapping systems (presumably > using technology developed in the SIDR working group). Technology developed in SIDR would only be applicable to certain

Re: [Int-area] Please respond: Questions from the IESG as to whether a WG forming BOF is necessary for LISP

Excerpts from Olivier Bonaventure on Wed, Jan 21, 2009 09:52:12PM +0100: > > I think the work on EID allocation guidelines for RIRs is premature at > > this stage. > > I proposed this work item because I think that we need to integrate the > EID and RLOC allocation mechanisms in the development of

Re: [Int-area] new I-D available - tunnel issues

On 7/18/08 12:46 PM, Joe Touch allegedly wrote: Mark Townsley wrote: ... |> These sound okay but I would like to see "tunnels" split into two: one |> type where there is a setup phase and sharing state between the |> endpoints, and another where there is no shared state: an endpoint can |> enca

Re: [Int-area] new I-D available - tunnel issues

On 7/15/08 7:09 AM, Joe Touch allegedly wrote: John.zhao wrote: Hi, Joe Thanks. So it is can be learnt that GRE,Mini Encapsulation seem also can be discussed here, right? We intend to include broader discussion of other encapsulations in future versions; this was intended to be an init