Re: REVISED description of open IAB meeting

["James Kempf" <kempf@docomolabs-usa.com>]

to avoid: seamoby,send,mip,capwap bof (not scheduled yet),problem

        jak

----- Original Message -----
From: "Leslie Daigle" <leslie@thinkingcat.com>
To: <iab@ietf.org>; "Iesg (E-mail)" <iesg@ietf.org>
Sent: Friday, June 13, 2003 2:57 PM
Subject: REVISED description of open IAB meeting


> Howdy,
>
> I have revised the proposal for the IAB open meeting -- below.
> Chiefly, I've attemped to address Erik's point to make it
> more constructive (not just talking about "problems").
>
> We'd like to hold this as an open IAB meeting during a regular
> meeting slot; before I ask the Secretariat to schedule it,
> I'd really appreciate people's input on major scheduling
> conflicts to avoid.  Yes, I know -- the list will (should)
> be long, but lets give it a try.
>
> To avoid:
>
> CRISP
> ....
>
> Thanks,
> Leslie.
>
> ====8<==========8<=========8<=========
>
>
>
> IAB Open Architecture Meeting, IETF57
>
> We have specified an Internet that works, at the network layer,
> using relatively stable but not permanent identifiers for connection
> endpoints, which are allocated and administered using a topology
dependent
> model, which implies a service provider dependent model.
>
> But we run into problems (the architecture doesn't quite fit) when
> we try to address some scenarios encountered in real life:
>
> . multihoming
> . assembling a local network without necessarily
>   having to contact an ISP to obtain address space
>   (e.g., home net)
> . renumbering local networks without significant pain
>
> Some proposed solutions are challenged in terms of:
>
> . providing referential integrity - how is referential
>   integrity maintained when identifiers are not globally
>   unique or are overloaded?
>
> . choosing between different identifiers for an object which
>   has different "reachability" and the reachability is
>   context-dependent
>
> . security/transiting trust in layered address
>   resolution - how do we secure dynamic update of the
>   "reverse path" if the trust relationship between a
>   DHCP server an a DHCP client is very weak?
>
> . providing solutions that work across all layers of
>   the stack and all areas - how do we find a solution
>   that is great for routing but also great for security?
>
>
> Specific cases where we have encountered these discussions:
>
> . the proposal of site-local addresses for IPv6
> . globally-unique but not globally routable addresses
> . IPv4 link-local addresses
> . local naming (LLMNR)
>    . when used with global names (e.g. www.ietf.org)
> . when used with local names (e.g. laptop.local.arpa)
>
>
> The IAB will hold an open meeting during IETF57 to collect input
> from the IETF community at large to gain a better understanding
> of where there are stresses and strains.  The purpose of the meeting
> will be to capture a list of the actual issues encountered, not to
propose
> solutions, nor to debate the merits of solutions that have been
> proposed in the past.  The output of the meeting will be used
> to update the IAB's list of "current known architectural issues",
> and will ultimately help focus future IETF work on architectural
> improvements for protocols that work across areas.
>
> The planned meeting format is to have 60-90min of presentations
> from people who haverequested a slot (and prepared at MOST 3
> slides) in advance, followed by 30-45min of further contributions
> from the room, and wrapup.
>
> Agenda
>
> 0. Intro, agenda bash [Chair, 1min]
> 1. Set stage for discussion [Chair, 5min]
> 2. Prepared input [Individual contributors; 5min presentation
>    of problem; 2-3 min clarifying questions from the room]
> 3. Input from the room
> 4. Wrapup
>
>
> Folks wishing to say a few words about the problems they
> perceive needing addressing (i.e., agenda item #2) should
> send a note to the IAB (iab@iab.org) before July 1.
>
>
>
> --
>
> -------------------------------------------------------------------
> "Reality:
>      Yours to discover."
>                                 -- ThinkingCat
> Leslie Daigle
> leslie@thinkingcat.com
> -------------------------------------------------------------------
>
>
>
>
>
>