2 Jul 2008 13:46
Gen-ART Last Call review of draft-ietf-mext-aaa-ha-goals-01.txt
Eric Gray <eric.gray <at> ericsson.com>
2008-07-02 11:46:47 GMT
2008-07-02 11:46:47 GMT
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mext-aaa-ha-goals-01.txt Reviewer: Review Date: IETF LC End Date: 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"...