Subject: [Hipsec] A concrete HIP WG & RG proposal as feed for thought

From: [email-masked] ([email-masked])
Date: Mon Dec 1 09:49:01 2003

Hi Pekka,

> Taking a different angle on how to organize the HIP work,
> I think that it is also useful to think in very concrete
> terms.  My previous mail tried to focus on the various
> in-the-large aspects that we have to consider here.  This
> mail puts forward a concrete but certainly not ready proposal
> for a HIP WG and an RG with a slightly larger scope.  Both
> groups could use the same mailing list, at least initially.

I think that it is an excellent idea to try to have a more
concrete discusson about ths.  In general, I agree with the=20
split you are proposing, but I do have a few comments and=20
questions.

> HIP WG
>=20
> Chairs: David Ward, Gonzalo Camarillo

Technically, Thomas and I will choose the chairs for this
WG.  We do appreciate your suggestions, though!
=20
> A 6-9 month WG that would produce the following documents:
>=20
>   1. HIP base protocol specification.  Experimental RFC.
>      Base document: draft-moskowitz-hip-08/09.txt
>      Document Editor: Petri Jokela
>=20
>   2. Basic mobility and multi-homing with HIP.  Experimental RFC.
>      Base document: draft-nikander-hip-mm-01.txt (-00 is not=20
>      good enough)
>      Document Editor: Pekka Nikander

These both look good.  Were you also planning to publish a WG
version of the architecture?  Or is the individual submission
version good enough for now?
=20
>   3. DNS resource record for storing HIP Host Identifiers and HITs.
>      Experimental RFC.
>      Base document author: Michael Richardson
>      Document Editor: Needs to be defined
>=20
>      This is a simple RR that is very much like IPSECKEY RR.
>      It just stores a public key and/or a hash of a public key.
>=20
>   4. A simple rendezvous server for HIP.  Experimental RFC.
>      Base document author: Pekka Nikander
>      Document Editor: Needs to be defined
>=20
>      This is a simple node that forwards I1 packets to a
>      registered IP address and does nothing else. [...]

Both of these look good, too.  What is the timeframe for having
first drafts of these documents?

> LOC/ID SPLIT AND HIP (LISHIP) RG

I think all of the RG topics look interesting.  One question:  Would
you want this to be an open RG, or a closed one?

Also, I would probably break the HIP work into two separate mailing=20
lists once these things spin up...   I think that would help to keep=20
the WG focused on the short-term deliverables.
=20
>   -  Applications guideline.  Informational RFC.
>=20
>      How something like HIP would affect the applications.
>      There is also a new mailing list, aulli, for discussing
>      some related aspects.

I'm wondering if this should be done in the RG or in the WG...
We may want to talk to the applications folks about this, and
figure out what makes the most sense.  I'd also expect this
document to be interesting and useful for the multi6 folks.
 =20
> Now, as you can see, there seems to be enough of food for both
> a working group and a research group.  There seems also to be
> enough of people that actually want to use HIP so that the WG
> would most probably be manned and produce useful things.  On the
> other hand, so far there definitely has been enough of people
> interested on researching HIP so that I would expect the RG to
> be fairly lively and actually produce output.

I agree, and I think that this makes sense as a way to move
forward.  What do others think?

Margaret

---

From: [email-masked] (gabriel montenegro)
Date: Mon Dec 1 10:08:01 2003

I think having a HIP WG and a RG is a good idea.
What I'm wondering is if the RG should be limited to
HIP. Pekka himself has said there are other alternatives.
Should we not encourage looking at other variants of
id/loc separation or even id/loc relationship (separation
is just one possible such relationship). As an exampel of
another possibility, I was very enthusiastic about the
possiblity of conjoining id/loc in as per CGA/SUCV. Now,
it seems like all that is shot due to IPR concerns.
Nevertheless, perhaps there's ways around it or ways]
to influence IPR.

My concern stems from some discussions I took to heart
in the NSRG whereby the id/loc decision was explicit.
The reason as eloquently put forth by Steve Deering was
that having them conjoined is actually a feature.
The problem is when you don't want it, granted, but
having the option of this massively distributed database
which is the routing fabric do the id/loc resolution
would indeed be sweet (whenever that works).

This is one example, but I'm sure there's other proposals
before or after HIP that attempt explorations along the
id/loc separation space (e.g. FARA)
and might benefit from a common area for discussion.

Oh, and I vote it be an open RG.

-gabriel

---

From: Spencer Dawkins" <[email-masked] (Spencer Dawkins)
Date: Mon Dec 1 21:00:01 2003

If I may express an opinion...

If I learned anything from the Late Unpleasantness on site-local
addressing, it's that the more visibility something like HIP has in
the applications community, the better.

I agree with the thought that "effect on applications" is also
significant for multihoming, and (although we don't talk about
renumbering much these days) renumbering as well.

I am concerned that putting this topic in the IRTF, in a HIPish RG,
will bury it (from an APPS perspective) more effectively than
site-local was buried in an IETF INT WG, and expect that if HIP or
anything like it "takes off", we'll wish that we hadn't buried it
(from an APPS perspective).

What are alternatives that would have more visibility in the APPS
community?

Spencer

p.s. I'm leaping past the part where TSV cares about multihoming,
assuming that since path characteristics will be different when paths
change, TSV will need to see paths change.

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, December 01, 2003 9:20 AM
Subject: RE: [Hipsec] A concrete HIP WG & RG proposal as feed for
thought

---

From: [email-masked] (Pekka Nikander)
Date: Tue Dec 2 03:50:01 2003

Margaret,

> version good enough for now?

 From my point of view, the individual submission version is good
enough.  If it appears that we need changes to the architecture,
I think that it would be better to do it after rechartering.
Personally, I do not believe that any of the proposed WG work
items would produce any pressure to change the architecture document.
Some of the research items may do that, though.

> first drafts of these documents?

Well, I have two other HIP drafts in my queue before I can write
the simple rendezvous server draft.  But definitely before Seoul.
What comes to the DNS RR draft, I haven't talked to Michael lately;
need to do that....done.  We'll see how he answers.

> you want this to be an open RG, or a closed one?

I don't see any reason for a closed one.  There has been also
other people voicing for an open one.  So be it.  (Frankly,
I didn't even remember that there is the option of running
closed RGs...)

> Also, I would probably break the HIP work into two separate mailing 
> lists once these things spin up...   I think that would help to keep 

I'm OK with that.  I just want to avoid dead mailing lists...

> I'm wondering if this should be done in the RG or in the WG...

I don't have any strong opinion.  IMHO, it's probably best for
the APPS folks to decide.  Or maybe they want to do it separately
in a short term APPS area WG or something.  I really don't know.

--Pekka