Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-mext-aaa-ha-goals-01.txt

From: "Eric Gray" <[email-masked]>
Date: Wed, 2 Jul 2008 06:46:47 -0500

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"...
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Julien Bournelle" <[email-masked]>
Date: Fri, 18 Jul 2008 14:43:34 +0200

Hi Eric, all,

 Thank your very much for handling this review and for your
comments !

 We'd also like to apologize for the long delay. After some
internal discussions, we reach a consensus.

Basically, this document aims to provide guidance to solution documents
for the Mobile IPv6 bootstrapping problem. It is thus
a companion document to the following document:

 For RADIUS based solution:
 draft-ietf-mip6-radius

 For Diameter based solution:
 draft-ietf-dime-mip6-split
 draft-ietf-dime-mip6-integrated

 Hence, the goal was to catch what were the needed features that people
wanted to see in AAA applications.

 Having said that, I agree that it would have been better to say: "A solution
MUST define how an NAS will' instead of "NAS MUST" but as you said the
document would be really more difficult to read.

 Concerning the "SHOULD", we agree with you that we need to revisit our
requirement to clarify what we mean by this "SHOULD" in a requirement
documents. As a requirement document, we can not say if a feature as to be
a MUST or a SHOULD. We just require (or not) some features.

 Based on this remark, we propose the following modifications:

1/
 CHANGE:

 G4.4  The HA SHOULD be able to request the AAAH server to
     authenticate the MN with the value in the MN-AAA Mobility Message
     Authentication Option.

 TO:

 G4.4  The HA supporting the Authentication Protocol MUST be able
      to request the AAAH server to authenticate the MN with the value
      in the MN-AAA Mobility Message Authentication Option.

2/

CHANGE:

 G6.3  The ASP/MSP SHOULD be able to indicate to the MSA if it can
     allocate a Home Agent to the MN.  Therefore the NAS SHOULD be able
     to include suggested HA address in the ASP in the NAS - AAA
     interaction.

 TO:

 G6.3  The ASP/MSP supporting the allocation of a Home Agent MUST be
     able to indicate to the MSA if it can
     allocate a Home Agent to the MN.  Therefore the NAS MUST be able
     to include suggested HA address in the ASP in the NAS - AAA
     interaction.

3/ We do not want to change the following requirement (in section 5.5):

 The HA SHOULD be able to communicate to the AAAH server the Home
     Address allocated to the MN and the FQDN of the MN (e.g., for
     allowing the AAAH server to perform a DNS update on behalf of the
     MN).

 Because it is not clear if it would be a problem if a solution document
does not support it. Thus a SHOULD seems ok.

4/ Concerning the second requirement in section 5.5:

 The AAAH SHOULD be able to indicate to the HA if the MN is
     authorized to autoconfigure its Home Address.

 We think it is ok to let it but we want to add the following sentence:

 If the AAAH does not indicate to the HA if a MN is authorized to autoconfigure
its address, the MN is not authorized.

 If you agree with these modifications and if they address your comments,
we will produce a -02 version.

 Thanks again,

 Best regards,

 Julien Bournelle

---

From: Jari Arkko <[email-masked]>
Date: Sun, 20 Jul 2008 11:25:12 +0300

These changes seem reasonable. Also, I have placed the suggested 
modifications as an RFC Editor note. If Eric and Russ think the 
modifications are sufficient, we could approve the document.

Jari

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 21 Jul 2008 06:36:47 -0500

Julien,

	These proposed changes certainly address the more
important issues I addressed in my comments.  Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Julien Bournelle [mailto:[email-masked]] 
> Sent: Friday, July 18, 2008 8:44 AM
> To: Eric Gray
> Cc: Gerardo Giaretta; Ivana.Guardini; Elena Demaria; Rafa 
> Marin Lopez; [email-masked]; Jari Arkko
> Subject: Re: Gen-ART Last Call review of 
> draft-ietf-mext-aaa-ha-goals-01.txt
> Importance: High
> 
> Hi Eric, all,
>

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 21 Jul 2008 07:37:30 -0500

Jari, et al,

	I am unsure what "changes" this refers to.  Is there a 
new version?  Or is this relating to the proposed changes?

	If the latter, I think the proposed changes are fine.

--
Eric Gray
Principal Engineer
Ericsson  

> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Sunday, July 20, 2008 4:25 AM
> To: Julien Bournelle; Eric Gray; Russ Housley
> Marin Lopez; [email-masked]

---

From: "Julien Bournelle" <[email-masked]>
Date: Mon, 21 Jul 2008 14:43:29 +0200

It is related to proposed changes. We will produce a -02 version.

 Julien

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 21 Jul 2008 07:44:53 -0500

Julien,

	Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Monday, July 21, 2008 8:43 AM
> To: Eric Gray
> Cc: Jari Arkko; Russ Housley; Gerardo Giaretta; 
> Ivana.Guardini; Elena Demaria; Rafa Marin Lopez; 
> [email-masked]; [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Mon, 21 Jul 2008 15:47:13 +0300

I was referring to the RFC Editor notes, which were exactly as Julien 
proposed in his e-mail.

And I already sent the approval e-mail, so now its too late for a new 
version. If there's some additional adjustment that you want to do, take 
it up in AUTH48.

Jari