[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on the latest GSSAPI draft changes
It would not seem much effort to change the numbers and would save a great
deal of trouble. It is really a small thing.
As to shipping based on drafts: It may be foolhardy, but is unquestionably
necessary both from a business point of view and for specification
improvement -- there is no testing ground like the real world.
Paul Kierstead
TimeStep Corporation
mailto:pmkierst@timestep.com http:\\www.timestep.com
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@network-alchemy.com]
> Sent: Thursday, October 14, 1999 2:06 PM
> To: Brian Swander (Exchange)
> Cc: 'ddp@network-alchemy.com'; ipsec@lists.tislabs.com
> Subject: Re: comments on the latest GSSAPI draft changes
>
>
> Brian,
>
> Those are from the "private use" range anyway which is what
> drafts are
> supposed to use. This is to flush out any problems with the protocol.
> If and when the draft is advanced it will be assigned real numbers by
> IANA. So if and when that happens you'll have interop
> problems with NT*
> or any other implementation that is shipping with code written to a
> draft. Note that XAUTH also claims use of 65001-65010.
>
> Internet Drafts are working documents and it is foolhardy to ship
> code based on them. This is the price you pay if you do.
>
> Dan.
>
> On Thu, 14 Oct 1999 10:21:55 PDT you wrote
> > Derrell, there are serious problems with the IDs in your
> latest rev. of the
> > draft.
> >
> > In the prior version of the draft, the next payload for the
> GSS_API payload
> > was 129. In the latest, it is 128. Also, the auth id for
> GSS_API/Kerberos
> > in the previous version was 65001. In the current version,
> it is 65003, and
> > the generic GSS_API id is 65001.
> >
> > In the presentation of the GSSAPI+Kerberos that I gave at
> the IETF, I gave
> > the numbers 129, 65001 as the numbers to use. These are
> the numbers in the
> > current version on NT5, and NT5 is shipping with these numbers.
> >
> > Your change of these numbers will make it very difficult
> for other vendors
> > to implement the GSSAPI draft, and interop with NT5. I
> know of a few
> > vendors out there who want to do this. It will also make
> it very difficult
> > for later versions of NT to interop with NT5.
> >
> > I see no security concerns, or any other valid reasons for
> changing these
> > IDs, and respectfully request that you put them back to
> their original
> > values.
> >
> > Interoperability with GSSAPI will be tough enough since
> everyone building
> > this will need to build in backwards compatibility code
> anyway when we move
> > to the IANA assigned numbers. At least that backwards
> compatability is
> > possible. Given your current changes, backwards
> compatibility and general
> > interop is next to impossible.
> >
> > I think it will be a major obstacle to the adoption of this
> draft if these
> > numbers stay as they are. Also, please push to get IANA
> assigned numbers
> > ASAP, so we never have to deal with the floating number
> problem in GSSAPI
> > again.
> >
> > bs
> >
> >
>