Subject: [MSEC] TESLA bootstrapping in MIKEY

From: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Fri, 19 Nov 2004 14:32:56 +0100

Hi,
during the meeting in Washington, we discussed about an appropriate
place for the new draft on TESLA bootstrapping with MIKEY, presented
by Steffen. The alternatives discussed were proceeding with the work as 
standalone, or integrating it within MIKEY itself, by initiating a
MIKEY bis. There were different opinions during the meeting, and
we said to take this to the list.

Steffen and I discussed further and agreed to maintain the TESLA
bootstrapping a standalone draft. 

A main reason is that we believe that it is anyway too soon for a 
draft bis for MIKEY. The TESLA bootstrapping is very modular and can 
constitute a contained RFC.
Another reason is of course time related. Starting a bis work
takes quite some time and will require much effort from the
people involved. This will delay the other work.
A draft bis would make sense if there are more extensions
popping out, which is not the case for the moment. Also,
having a bis would open up the question of adding there existing
things like DHHMAC, and the MBMS extension (which definitely can't 
wait). At the time being, there exists 4 documents dealing with MIKEY 
and extensions (MIKEY RFC, DHHMAC, MBMS extension, TESLA bootstrapping). 
Let's assume that in the future more extensions are being defined. 
Then we have again the problem of multiple MIKEY documents. We might 
in that case consider what to do, for example we could write an Info RFC
that links the different pieces together, which has also the advantage
that it is more easy to keep updated compared to add changes in MIKEY.

We would like to hear if this is ok with you folk, or if there
are any strong opinion against.

Thanks
cheers
/Elisabetta
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Euchner Martin <[email-masked]>
Date: Mon, 29 Nov 2004 15:03:17 +0100

No opinion against but slightly in favor.

MEU: agree.

Also,

MEU:> Given time and resource constraints, I share your view that MIKEY-bis draft may be too early in time. Let's mature first the other MIKEY dos first. Still, I would consider such a long-term effort useful, to consolidate the existing material within one document.

Until the time is right for this, let me suggest an interim yez more lean approach:
Instead of the MIKEY-bis draft, let's create an informational RFC, such as "MIKEY: Overview and Applications". This rather short document would summarize the existing (known) work by giving an overview of the various MIKEY documents and their scope and applications. The new document should not reiterate the specs; just provide some summary and make pointers to the docs; technical spec content is left subject to the various MIKEY docs.

Once time will have arrived, and we all feel that MIKEY has matured, then the informational RFC can be superseded by the MIKEY-bis RFC.

Does this make sense?

Martin.

---

From: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Mon, 29 Nov 2004 16:32:59 +0100

Hi Martin, 
I personally feel that the time is still quite early also 
for such Informational RFC. In addition, there are not that 
many pieces around MIKEY, which would motivate such tight 
tracking. 
I think that the suggestion could be valid if more additions 
are popping out.

Cheers
/E

>-----Original Message-----
>From: Euchner Martin [mailto:[email-masked]]
>Sent: den 29 november 2004 15:03
>To: Elisabetta Carrara (KI/EAB); [email-masked]; Euchner
>Martin
>Cc: Fries Steffen
>Subject: RE: [MSEC] TESLA bootstrapping in MIKEY
>
>
>MEU:> Given time and resource constraints, I share your view 
>that MIKEY-bis draft may be too early in time. Let's mature 
>first the other MIKEY dos first. Still, I would consider such 
>a long-term effort useful, to consolidate the existing 
>material within one document.
>
>Instead of the MIKEY-bis draft, let's create an informational 
>RFC, such as "MIKEY: Overview and Applications". This rather 
>short document would summarize the existing (known) work by 
>giving an overview of the various MIKEY documents and their 
>scope and applications. The new document should not reiterate 
>the specs; just provide some summary and make pointers to the 
>docs; technical spec content is left subject to the various MIKEY docs.
>
>
>Once time will have arrived, and we all feel that MIKEY has 
>matured, then the informational RFC can be superseded by the 
>MIKEY-bis RFC.
>
>Does this make sense?
>
>
>Martin.
>