Re: Q: Conflict between TSIG RFC and GSS-API documents

[Edward Lewis <edlewis@arin.net>]

I'm not sure that I understand the question.

The base TSIG PS document proscribes behavior in conflict with the
proposed GSS-API.  This conflict is allegedly removed either via an
improvement to the base TSIG or by restricting the GSS-API proposal.
As the former (improving the TSIG base) is more desirable, all things
considered, the proposal is that GSS-API is allowed to proceed
unmodified and that the TSIG base is improved.

If I recall correctly, the above is what I think is being said.

Although I agree with that assessment, that doesn't mean that I think
it is a good idea to thaw the GSS-API document.  I think it should be
thawed in tandem with a document that proscribes the needed
improvement to the TSIG base.  I.e., a document specifying an
extension to TSIG's base is needed before allowing an extension that
would otherwise be in conflict.

Basic principle: Make sure we have a clear base.  Only then attempt
modifications.  Failure to heed this has proven in the past to lead
to unpredictable consequences ("corner cases") when composing
extensions and bases.

At 14:36 -0500 1/31/03, Ólafur Gudmundsson/DNSEXT co-chair wrote:
> From the minutes in ATLANTA:
>
>
> > GSSAPI and TSIG conflict:
> >      DNSEXT wg generated TSIG RFC
> >      DNSEXT wg processed gssapi TSIG
> >          just before rfc editor started 48hour period we got a report
> >          that there was a conflict between two the documents.
> >          TSIG specifies that TSIG can only be used if original query
> >            contains TSIG
> >          GSSAPI specifies that last message in TKEY exchange has TSIG
> >            last message is empty, and this proves the key negotiated is
> >            working from security point of view this is a good thing
> >
> >          TSIG needs minor updates before advancing to draft standard:
> >               is this extensions one of them?
> >
> > The sense of the room was that this was a reasonable extensions and the
> > chair is instructed to take this question to the mailing list.
> Does the mailing list agree with this assessment and give
> its consensus that the lock on the GSS-API document be lifted ?
>
> Silence will be taken as agreement.
>
> Please post objections before Feb 12'th.
>
> thanks
>         Olafur
>
>
>
>
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer


--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>