Document: draft-ietf-mext-aaa-ha-goals-01.txt
Reviewer: Eric Gray [eric.gray@ericsson.com]
Review Date:  7/2/2008
IETF LC End Date: 7/3/2008
IESG Telechat date: Unknown 

Summary: 

This draft is not ready for publishing as an Informational RFC.

Comments: 

In general, I thought this draft was exceptionally well written.

I was confused by the use of RFC 2119 requirements level terminology 
in this draft.  I am under the impression that - because Informational 
RFCs typically are not treated as if they define standards - they tend
to have a lower bar for acceptability for publishing as an RFC.  Yet 
use of the RFC 2119 requirements level terminology seems to indicate 
this document is intended to define one or more required outcomes.

The qualification added ("unless otherwise stated these words apply 
to the design of the AAA protocol extension, not its implementation 
or its usage") appears to clarify that these terms are intended to
apply to separate protocol designs/specifications (or other documents
intended to define solutions), but also implies that there may be 
exceptions.  This inspired me to try to determine what exceptions 
there might be.

In several places in this draft, it is not clear whether these terms
are used to define requirements of a solution, required elements of
a solution, or required features of an implicitly assumed solution.
However - looking at MUST level requirements - I found many cases in
which requirements are defined for specific entities, implying that 
a solutions specification would simply define specifics of how these 
requirements are met.  I believe this is reasonably correct (though
it would be less ambiguous if a statement like "NAS MUST" was stated
as "a solution MUST define how an NAS will" - however this could make
the document more difficult to read).

SHOULD is a different case.  This draft defines requirements for a
solution and resulting implementations.  Typically, in defining 
requirements, anything that is not a MUST is optional.  Had the less 
ambiguous form (e.g. - for "The AAAH SHOULD" substitute "A solution
document SHOULD define how the AAAH will" or "A solution document
MUST define how the AAAH SHOULD"), the problem with using this term
would be more obvious.

To make the problem more difficult, for some time, we've been asking
draft authors to describe the considerations that might apply if one
were to not do what is specified as a "SHOULD" (or do that which is 
specified as a "SHOULD NOT").  It seems to me this would be difficult 
to do in a requirements document.

Take the requirement "The AAAH SHOULD be able to indicate to the HA 
if the MN is authorized to autoconfigure its Home Address."  Do you
ask the question "what are the consequences of having a solution that
does not specify how this would be done", or do you ask "what are the 
consequences of an implementation that does not do this"?  Is this an
optional requirement?

There are not that many SHOULDs in this draft.  Perhaps the author(s)
could reconsider whether or not these could be changed to clarify the
intended meaning?

Also, if there are exceptions (as implied in the qualification of the
terminology's usage), the author(s) should explicitly call them out.
If there are no exceptions, then maybe the qualification should be
modified.  The closest thing I could find to an exception was in the
Security Considerations section, where you say "links between the HA 
and the AAA server of the MSA and between the NAS and the AAA server 
MUST be secure."  However, even in this case, I think what you're
really saying is that this is a required aspect of a solution.
_____________________________________________________________________

NIT - in the acknowledgements section, "aithors" should be "authors"
and "contribbuted" should be "contributed"...