Subject: [Dime] Gen-ART Review of draft-ietf-dime-nai-routing-02

From: "McCann Peter-A001034" <[email-masked]>
Date: Mon, 3 Aug 2009 14:17:29 -0400

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-dime-nai-routing-02
Reviewer: Pete McCann
Review Date: 2009-08-03
IETF LC End Date: 2009-08-04
IESG Telechat date: unknown

Summary: Two major issues need discussion

Major issues:

The draft seems to address only routing of Request commands.  What
about Answers?  Are Diameter proxies required to re-write the
Origin-Realm and Origin-Host AVPs as the request gets routed?
Are they required then to maintain state to map the responses back
to the originating realm?  The processing rules seem to strip off
the decoration from the NAI; there might be a need for the home AAA
server to know the path that was taken through the network (routing
the Answer commands is only one possible reason).  Maybe the solution
is to provide a decorated Origin-Realm that is recomputed by each
hop.

> 4.2. Ensuring Backwards Compatibility
>
>   Implementations compliant to this specification MUST define a new
>   Diameter application.  This requirement is set to guarantee
backwards
>   compatibility with existing Diameter implementations, applications
>   and deployments.  Diameter agents not compliant with this
>   specification will not advertise support for these new applications
>   that implement the enhanced routing solution based on Decorated NAIs
>   and will therefore be bypassed.

This requirement troubles me; does this mean that every Diameter
application
will need to define a whole set of Application-IDs, based on the
cross-product
of every feature that gets introduced?  Maybe this is a general problem
with
Diameter application versioning, and it's too late to fix it.  Is there
a 
better way to somehow indicate support for this feature?

Minor issues:

Nits/editorial comments:

End of Section 3:

>   [RFC5113] Section 2.3. also discusses NAI decoration related issues
>   with EAP [RFC3748] in general.
Seems there is an extra period after "Section 2.3".  Suggest changing
the reference pointer to text, i.e.,
>   Section 2.3 of RFC5113 also discusses NAI decoration related issues
>   with EAP [RFC3748] in general.

Section 4.1:

>   an uniform
SHOULD BE:
>   a uniform

Section 6:
>   In this case the NAS to the Diameter server AAA communication rely
on
SHOULD BE:
>   In this case the NAS to Diameter server AAA communication relies on

---

From: jouni korhonen <[email-masked]>
Date: Tue, 4 Aug 2009 20:19:59 +0300

Hi Peter,

Thanks for the review. See my comments inline.

> about Answers?  Are Diameter proxies required to re-write the

Answers follow the reverse path the request traversed. The answers are  
processed according to base RFC3588.

> Origin-Realm and Origin-Host AVPs as the request gets routed?

No. Both Origin-Realm and Origin-Host correspond to the entity that  
originated the request.

> to the originating realm?  The processing rules seem to strip off

Not really. Intermediating agents only need to maintain a transaction  
state. This is the same as required for normal RFC3588 request-answer  
processing.

> is to provide a decorated Origin-Realm that is recomputed by each

RFC3588 Route-Record AVP already provides this information. I see no  
reason to go any further here regarding to changes/enhancements to  
RFC3588 answer processing.

> better way to somehow indicate support for this feature?

It indeed is a general issue with Diameter application versioning  
(some SDOs have introduced their own versioning schemes to avoid  
defining new applications for e.g. every new release). There was  
lengthy discussion of possible choices how to solve it for this I-D.  
Requiring a new application seemed to be the easiest way to get  
forward. Generally, one application can/should include several "new  
features" so the explosion on applications should not become a problem..

>>  In this case the NAS to Diameter server AAA communication relies on

Thanks. Will fix these.

Cheers,
	Jouni

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Tue, 4 Aug 2009 13:41:34 -0400

Hi, Jouni,

Thanks, I went back and re-read Section 2.8 of RFC 3588 and
refreshed my understanding of Diameter Answer routing.  You are
correct that the reverse path routing is taken care of by the 
transaction state.  Perhaps you could add one sentence about 
the Answer routing with a reference to Section 2.8 of RFC 3588?

I suppose using the Application ID for expressing support for
the feature is ok if that is the will of the working group.

-Pete

jouni korhonen wrote:
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft (for background on Gen-ART, please see
>> Please resolve these comments along with any other Last Call
>> comments you may receive. 
>> 
> Answers follow the reverse path the request traversed. The answers
> are processed according to base RFC3588. 
> 
>> Are they required then to maintain state to map the responses back to
>> the originating realm?  The processing rules seem to strip off
> 
>>>  backwards compatibility with existing Diameter implementations,
>>> applications and deployments.  Diameter agents not compliant with
>>> this specification will not advertise support for these new
>>> applications that implement the enhanced routing solution based on
>>> Decorated NAIs and will therefore be bypassed.
>> 
>> application will need to define a whole set of Application-IDs, based
>> on the cross-product of every feature that gets introduced?  Maybe
>> this is a general problem with Diameter application versioning, and
>> it's too late to fix it.  Is there a better way to somehow indicate
>> support for this feature?
>

---

From: jouni korhonen <[email-masked]>
Date: Tue, 4 Aug 2009 21:06:48 +0300

Hi Peter,

> the Answer routing with a reference to Section 2.8 of RFC 3588?

Will add this.

> the feature is ok if that is the will of the working group.

I would say it fulfilled the description of a rough consensus.  
Everybody was equally unhappy ;)

Cheers,
	Jouni

>>> to

---

From: jouni korhonen <[email-masked]>
Date: Wed, 19 Aug 2009 11:19:02 +0300

Hi Pete,

I have updated the I-D based on your comments. The -03 version should  
be available readily in draft repositories.

Cheers,
	Jouni

---

From: "McCann Peter-A001034" <[email-masked]>
Date: Thu, 27 Aug 2009 11:50:41 -0400

Thanks, Jouni.   This version addresses all my comments.

-Pete

jouni korhonen wrote:
>> Thanks, I went back and re-read Section 2.8 of RFC 3588 and refreshed
>> my understanding of Diameter Answer routing.  You are correct that
>> the reverse path routing is taken care of by the transaction state.
>> Perhaps you could add one sentence about the Answer routing with a
>> reference to Section 2.8 of RFC 3588?
>> 
>> I suppose using the Application ID for expressing support for the
>> feature is ok if that is the will of the working group.
>> 
>> -Pete
>> 
>> jouni korhonen wrote:
>>> Hi Peter,
>>> 
>>> Not really. Intermediating agents only need to maintain a
>>> transaction state. This is the same as required for normal RFC3588
>>> request-answer processing. 
>>> 
>>>> the Answer commands is only one possible reason).  Maybe the
>>>> solution is to provide a decorated Origin-Realm that is recomputed
>>>> by each hop.
>>> 
>>>> application will need to define a whole set of Application-IDs,
>>>> based on the cross-product of every feature that gets introduced?
>>>> Maybe this is a general problem with Diameter application
>>>> versioning, and it's too late to fix it.  Is there a better way to
>>>> somehow indicate support for this feature?
>>> 
>>>>> [RFC5113] Section 2.3. also discusses NAI decoration related
>>>>> issues with EAP [RFC3748] in general.
>>>> Seems there is an extra period after "Section 2.3".  Suggest
>>>> changing the reference pointer to text, i.e.,
>>>>> Section 2.3 of RFC5113 also discusses NAI decoration related
>>>>> issues with EAP [RFC3748] in general.
>>>> 
>>>> Section 4.1:
>>>> 
>>>>> an uniform
>>>> SHOULD BE:
>>>>> a uniform
>>>> 
>>>> Section 6: