RE: comments on the latest GSSAPI draft changes

[Paul Kierstead <[e-mail]>]

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:[e-mail]		http:\\www.timestep.com


> -----Original Message-----
> From: Dan Harkins [mailto:[e-mail]]
> Sent: Thursday, October 14, 1999 2:06 PM
> To: Brian Swander (Exchange)
> Cc: '[e-mail]'; [e-mail]
> 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
> > 
> > 
>