Simple Authentication and Security Layer (SASL)
draft-ietf-sasl-rfc2222bis-15

Please respond to Sam's satisfaction as Responsible AD (I don't need
to have an answer myself):

  The IESG may reassign responsibility for a SASL mechanism.  The most
  common case of this will be to enable changes to be made to mechanisms
  where the author of the registration has died, moved out of contact or
  is otherwise unable to make changes that are important to the
  community.

Is this an arbitrary grant of reassignment rights to the IESG?  Or just
of the standards track SASL mechanisms?  How well must the unreachability
be demonstrated before reassignment?  By what means?  This is not very
crisp, and when it comes time to actually take this action, it will need 
to be implementable.  One thought would be to state that the IESG has
discretion to announce that the registrant has been found to be unreachable
and therefore the registration is changed.

sect 2, 2nd bullet seems to be an incomplete sentence?

In sect 1.1. I see:

  1.1.  Document Audiences

  This document is written to serve several different audiences:

    - protocol designers using this specification to support
      authentication in their protocol,

    - mechanism designers that define new SASL mechanisms, and

    - implementors of clients or servers for those protocols which
      support SASL.

  While the document organization is intended to allow readers to focus
  on details relevant to their engineering, readers are encouraged to
  read and understand all aspects of this document.

But I must say that I find it difficult to read it as a protocol 
designer as per your first bullet.

-----

My successor Dan Romascanu also looked at this doc, and
I agree with his further comments/questions:

1. Clarification question:

Section 3.7 

  Once the security layer is in effect in the protocol data stream, it
  remains in effect until either a subsequently negotiated security
  layer is installed, or the underlying transport connection is closed.


How is a subsequently negotiated security layer installed? I suppose
that one would aim to keep the operational continuity of a protocol in
cases of re-keying, as mentioned in section 6.3.  If this is supported,
how does it happen? Is the SASL exchange repeated, needs the underlying
transport connection be torn down? Should multiple successful SASL
authentication exchanges be permitted for this purpose?

2. In section 6.1..5 - Should not 'must not' and the second 'should' be
in capitals? 

3. Section 7.1.1

 While this registration procedures do not require expert review,
  authors of SASL mechanisms are encouraged to seek community review and
  comment whenever that is feasible.  Authors may seek community review
  by posting a specification of their proposed mechanism as an
  Internet-Draft.  SASL mechanisms intended for widespread use should be
  standardized through the normal IETF process, when appropriate.

I am wondering whether this process is not too loosely formulated. It
seems to leave the door open for somebody requiring the registration of
a mechanism directly from IANA without going necessarily through a
review that checks that requirements defined in Section 5 are met. Maybe
a mandatory referring to advice from a group of SASL experts or review
on <ietf-sasl@imc.org> mailing list or by a Security AD would be useful.