Subject: RE: Working Group Last call - draft-ietf-cat-kerberos-set-passwd-05.txt

From: "John Brezak" <[email-masked]>
Date: Fri, 11 May 2001 11:49:18 -0700

We seem to have seperated into 2 camps - 1) Those that can use ASN.1 and
2) those that detest ASN.1.

A few points from this discussion:

- We cannot change what is already developed using ASN.1.
- ASN.1 does have its supporters and there is sufficient use already in
Kerberos
And other standard protocols.
- Tools seem to be an issue, but it appears that implementors do not
have an
issue with tools they are currently using.
- ASN.1 is already present in some form so the viable options are ASN.1
or raw.
(RPC/XDR and RPC/NDR are not in consideration because they would add
more to the
runtime footprint and cause whole other holy discussion - don't even
start one
on this thread :-).
- The ASN.1 encoding rules - DER/BER need to be specified in the I-D
- No other comments on the data and protocol at this point

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, May 11, 2001 11:07 AM
To: Paul Leach
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Working Group Last call -
draft-ietf-cat-kerberos-set-passwd-05.txt

Hi Paul,

Paul Leach wrote:
> 
> > From: Martin Rex [mailto:[email-masked]]
> > Sent: Friday, May 11, 2001 7:56 AM
> > 
> > I surely doubt that the use of ASN.1 to define the IPv6
> > protocol would have improved things.  However it would have 
> > prevent many people from participating the discussion and 
> > understanding the spec.
> 
> I think this is a weak counter example -- ASN.1 is not intended for 
> the definition of transport layer protocols.

Unnecessary complexity and awkwardness should be avoided at all layers.

>                                       And even if you hate it, like I 
> do, reading knowledge of ASN.1 should be required for anyone who 
> considers themselves competent is this field.

I have read RSA's layman guide to ASN.1 and can parse or create the
example ASN.1 data structures in there.  However I still consider myself
ASN.1 illiterate.  Using ASN.1 (or C-Style meta-code) to convey an idea
is one thing, using ASN.1 to write a protocol spec is something entirely
different (as is writing secure and robust C-code).

>                                               It's useful subset isn't

> really all that much different from the data structuring capabilities 
> of any high level language.

If that is so, why did they take so many stabs (i.e. Revs) at it and are
still not done yet?  If ASN.1 were such a simple and easy-to-understand
language, we would long have a 20-page RFC describing it, wouldn't we?

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 21:30:43 +0200 (METDST)

> - We cannot change what is already developed using ASN.1.

Which "already developed" implementation are you referring to:
   draft-trostle-win2k-cat-kerberos-set-passwd-02.txt    (informational)
or
   draft-ietf-cat-kerberos-set-passwd-05.txt   (last call for standards track)

The former looks *much* easier to convert to bits-on-the-wire to me.

> - ASN.1 is already present in some form so the viable options are ASN.1

If the ASN.1-fanciers could supplement a raw spec for the proposed
ASN.1 structures it would definitely help the non-ASN.1 implementors
and it would really help for the discussion whether there is to
much complexity in the current proposal.

Given the praise of ASN.1 by the ASN.1 fanciers, coming up with
a supplementary raw spec should be easy for *them*.  It certainly
isn't for people like me.

-Martin