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

RE: comments on the latest GSSAPI draft changes

Agreed.  But, shipping based on internet drafts is a necessary evil.  Given
that some vendors find this necessary, the question is:

Do we want to make changes to the internet drafts to minimize interop
problems with prior versions, or to maximize them?  

The purpose of the internet draft, as you said, is to flush out problems.
It is also to work towards a draft that is mutually acceptable to all.  
However, Derrell's latest ID changes in the GSSAPI don't flush out any
problems, and just create new problems.

So the question still remains:  will the arbitrary ID changes be put back to
their original values, or will we have a large divergence from the IDs in
the draft, and IDs in the marketplace?  

I fully support changing drafts for new functionality, or to fix a real
problem.  For instance, the latest GSSAPI draft fixed the limited round trip
problem in the old GSSAPI draft, and therefore is a substantial improvement.
I only object to random changes that only cause problems, and solve nothing.


If we are leaving the IDs as in the new draft, can someone provide a better
justification than: "the draft a work in progress, so it can be arbitarily
changed at will."  

bs

-----Original Message-----
From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM]
Sent: Thursday, October 14, 1999 11:06 AM
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
> 
>
Follow-Ups: