[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on the latest GSSAPI draft changes


  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. 


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