Subject: DNSEXT WGLC Summary GSS-tsig-03

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 20 Nov 2001 00:59:54 -0500 (EST)

On Tue, 23 Oct 2001, Ólafur Gudmundsson/DNSEXT co-chair wrote:

> 
> The TSIG protocol provides transaction level authentication for DNS.
> TSIG is extensible through the definition of new algorithms.  This
> document specifies an algorithm based on the Generic Security Service
> Application Program Interface (GSS-API) (RFC2743).
> 
> This WG last call ends November 8'th 2001.
> 

The Working group last call has completed, with minor comments. 
Following are minor clarifications that the chairs and document
editors have agreed on for clarity. 

There seems to be consensus that this document is complete and 
implementable. Thus the working group recommends to advance it to
proposed standard. 

Minor comments that need to be fixed before advancement:

1. (Introduction, second line. )
	"lightweight end to end authentication", 
To avoid confusion that the words "end to end" should be dropped.
In DNS context I think of end-to-end as the whole path from authorative
server to resolver. In this context you are talking about protecting 
one hop. 

1. (third paragraph (bottom of page 2)), the word "may" shows up 2 times
is this supposed to be MAY ? 

1. (last paragraph) add "MUST NOT" and the other negatives to your 
list as some of them are used in the document. 

3.1.1 OBJECT IDENTIFIFIER 
this is the location where the use of Kerberos 5 is first required. 
For clarity reasons please state this in the second paragraph in section 3.

3.1.2 (last line)
uses MUST NOT, not on the list of required keywords (see section 1
comments).

3.1.3.1 (second paragraph second sentence from bottom). 
"The client MUST continue to waiting for a response to ..." 
This is a new requirement on servers and clients that it can not
abort after getting the first answer. 

It can be argued that this is a good thing to do and we may want to 
add this capability in other places but this is not the document to 
update RFC1035.  For now tone the MUST down to SHOULD or MAY. 

3.1.3.2 (first paragraph last sentence). 
s/must/MUST/
and suggest a firm limit or point to section that suggests a limit. 

NOTE this text is replaced in 3 different places in this section please
update all. 

7. Security considerations, add a sentence that says that all the security
considerations from RFC2845 and RFC2930 apply here as well as the ones
for GSS-API. 

12. Author addresses, 
3 of 6 authors do not have e-mail addresses. 

	Olafur

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 20 Nov 2001 14:36:36 +0100 (CET)

Should the AD wait for an updated document before starting to review it
for the IESG?

  Erik

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 20 Nov 2001 14:28:34 -0500 (EST)

> Should the AD wait for an updated document before starting to review it

Yes, it should be submitted today. 

	Olafur