Re: [Gen-art] Gen-ART Review of draft-ietf-dime-nai-routing-02

[jouni korhonen <[e-mail]>]

Hi Pete,

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

Cheers,
	Jouni



On Aug 4, 2009, at 8:41 PM, McCann Peter-A001034 wrote:

> 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:
>> Hi Peter,
>>
>> Thanks for the review. See my comments inline.
>>
>>
>> On Aug 3, 2009, at 9:17 PM, McCann Peter-A001034 wrote:
>>
>>> 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
>>
>> 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.
>>
>>> Are they required then to maintain state to map the responses back  
>>> 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.
>>
>>> 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.
>>
>> 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.
>>
>>
>>>>
>>>> 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?
>>
>> 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..
>>
>>>
>>> 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
>>
>> Thanks. Will fix these.
>>
>> Cheers,
>> 	Jouni
>