Dear all,













I have reviewed current version of this document as part of the security


directorate's ongoing effort to review all IETF documents being processed by


the IESG.


These comments were written primarily for the benefit of the security area


directors.


Document editors and WG chairs should treat these comments just like any


other last call comments.













* Section 3.2, page 5:







  The initiator calls GSS_Init_sec_context(), using the







  input_context_handle for the current proto-security-context and its







  fixed set of input parameters, and the input_token received from the







  acceptor (if not the first iteration of the loop).





Your use of proto-security-context would make it seem like this is a


parameter specified in RFC2473 but it is not. So I'd recommend to remove


the hyphens. (BTW, at times you refer to "proto-security-context" while


at others to just "security context"... why?)








* Section 3.2, Page 5:










(if not the first iteration of the loop)





Please rephrase as "(if this is not...)"








* Section 3.2, page 5:







However, there are some known







     implementations of certain mechanisms which do produce empty







     context negotiation tokens.  For maximum interoperability,







     applications should be prepa





It would be great if you could provide examples of such implementations.








* Section 3.4, page 6







It is likely appropriate







  for the acceptor to report this error condition to the acceptor via







  the application's communication channel.








It should say:


  It is likely appropriate


  for the acceptor to report this error condition to the initiator via


  the application's communication channel.








* Section 3.5, page 7:







  The GSS acceptor calls GSS_Accept_sec_context(), using the







  input_context_handle for the current proto-security-context and the







  input_token received from the initiator





Again, remove the hyphens








* Section 4.1, page 10







Additional information can be







  available in GSS-API Naming Extensions, [RFC6680].





s/can be/is/








* Section 5.1: You should clarify what's the convention for the return


codes of send_token() and receive_token(). Otherwise it's not clear


whether, when you use these functions, you're checking the return codes


correctly.














Thank you,


Tina