Subject: RE: [IPTEL] A plea for help from the iptel working group

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Nov 2000 00:08:11 -0500

I think we are going to move forward with that plan. Given that we are not
sure we need it, not sure how to do it, and can't locate expertise to help
us, it seems like the right thing. We can add support for this later, I
think, if the need arises.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, November 21, 2000 2:21 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'; [email-masked]';
> [email-masked]'; [email-masked]'
> Subject: [IPTEL] A plea for help from the iptel working group
> 
> 
> 
> Jonathan,
> 
> Maybe this is irrelevant since the draft deadline
> passed, but I predictably am in favor of avoidance
> of problems that cry out for public key solutions
> unless there is some absolute and unavoidable
> reason why they are necessary. If this were BGP,
> I would be *very* concerned about the implications
> of the number of public key signatures and
> verifies. However, TRIP is not BGP, so it's hard
> for me to guage whether it's unavoidable or not.
> 
> Maybe it really would be the better part of valor
> to leave it out until we have some operational
> experience?
> 
> 			Mike
> 
> Jonathan Rosenberg writes:
>  > Folks,
>  > 
>  > There is only one remaining open issue with TRIP
>  > http://www.ietf.org/internet-drafts/draft-ietf-iptel-trip-03.txt
>  > 
>  > and it is one that the authors cannot resolve without assistance.
>  > 
>  > THe issue is authentication for attributes. The authors 
> think that this
>  > feature is still useful. However, we need to have a set of 
> algorithms, and a
>  > specific encoding format for those algorithms, to be 
> included in the spec. I
>  > believe that this authentication encoding will need to include the
>  > certificate for the signer, since an LS may not have a pre-arranged
>  > relationship with the originator of a route.
>  > 
>  > We need help in coming up with a set of algorithms (we 
> suspect DSA and RSA,
>  > but need additional guidance on what more, if anything, 
> needs to be said)
>  > and their encoding, including the certs, within TRIP. 
> Actual text for
>  > inclusion in the draft is specifically what we want, not 
> suggestions like
>  > "check out protocol foo", since invariably, what protocol 
> foo has isn't
>  > quite right (i.e., uses ASN.1 or XML or something we don't have). 
>  > 
>  > So, this is a PLEA for assistance. 
>  > 
>  > If someone cannot contribute some text here, we may be 
> forced to remove this
>  > feature all together in the baseline draft, and relegate 
> it to a separate
>  > I-D. That may or may not go over well with the A-Ds either.
>  > 
>  > Thanks,
>  > Jonathan R.
>  > 
>  > ---
>  > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
>  > Chief Scientist                             First Floor
>  > dynamicsoft                                 East Hanover, NJ 07936
>  > [email-masked]                     FAX:   (973) 952-5050
>  > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
>  > http://www.dynamicsoft.com
>  >  
>  > 
> 
> _______________________________________________
> IPTEL mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/iptel
> 

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Dhaval Shah <[email-masked]>
Date: Tue, 21 Nov 2000 21:14:42 -0800

I second that.

Thanx,
Dhaval