comments on draft-ietf-cat-gssv2-cbind-04.txt

John Linn <linn@cam.ov.com> Mon, 07 April 1997 21:37 UTC

Received: from cnri by ietf.org id aa24911; 7 Apr 97 17:37 EDT
Received: from pad-thai.cam.ov.com by CNRI.Reston.VA.US id aa24622; 7 Apr 97 17:37 EDT
Received: (daemon@localhost) by pad-thai.cam.ov.com (8.8.5/) id <TAA29415@pad-thai.cam.ov.com>; Mon, 7 Apr 1997 19:47:31 GMT
Message-Id: <199704071947.PAA12565@gza-client1.cam.ov.com>
To: cat-ietf@mit.edu
Cc: linn@cam.ov.com
Subject: comments on draft-ietf-cat-gssv2-cbind-04.txt
Date: Mon, 07 Apr 1997 15:47:16 -0400
From: John Linn <linn@cam.ov.com>
Precedence: bulk

Here's a set of comments and questions re draft-ietf-cat-gssv2-cbind-04.txt,
many of which are editorial: 

CONTENT-LEVEL COMMENTS/QUESTIONS

p. 13: Can/should we apply any constraints on the acceptable combinations
of routine and supplementary status values (i.e., may any value of
routine error be accompanied by CONTINUE_NEEDED or token replay 
detection status)?

p. 15, bullet (b): I believe (trying to think strictly here) that the
*format* of the string name is defined in conjunction with the namespace
OID, not the mechanism.  The processing applied to a name of a given 
type, however, may vary for different mechanisms supporting that type. 

p. 22, GSS_S_DUPLICATE_TOKEN: this states that the status may be returned
for some cases even if replay detection isn't being provided, which 
diverges from RFC-2078.  I'd be inclined against adopting this change, 
since it might surprise applications which hadn't requested the optional 
service.

p. 82-83: Are all of these nametypes required for all implementations,
or should we declare some optional (as they had been in RFC-1964)
and propagate this back to 2078bis?

EDITORIAL

I think the number of lines per page is non-standard; at least with the
2-up printer program I'm using, each "page" extends its footer onto the
next page.

p. 8, 1st para, 12th line, suggest rewording "to accept the default
mechanism" to "to request and accept the default mechanism".

p. 9, 1st para: the statement here about a credential-element
conceptually containing [exactly] two credential references seems to imply
that all credentials must be type BOTH.  

p. 16, 2nd para, 5th line, typo: "contigous" -> "contiguous". 

p. 16, 3rd para, 4th line, typo: "operation" should be plural. 

p. 23, 1st para, 7th line, typo: "value us" -> "value is".

p. 25, 1st para after param list, 2nd line, typo: "return a" ->
"return an". 

p. 34, 2nd para: This paragraph refers to gss_acquire_cred, which
isn't the call being described.  Should the paragraph be revised or
deleted?

p. 34, 3rd para, 2nd line, typo: "may chooses" -> "may choose". 

p. 34, 4th para, 2nd line, typo: "newly-acquire" -> "newly-acquired". 

p. 52, GSS_S_UNAUTHORIZED, typo: doubled period at end. 

p. 61, "targ_name", typo: redundant text in 5th line. 

p. 65, "initiator_lifetime": bullet's formatting around "GSS_C_ACCEPT"
seems odd. 

p. 77, gss_wrap_size_limit, 2nd para after param list, last line:
suggest changing "fragment messages" to "fragment messages into
efficiently-sized fragments" or some such. 

p, 94: should reference RFC-2078, not the precursor I-D. 

--jl