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

["McCann Peter-A001034" <[e-mail]>]

Thanks, Jouni.   This version addresses all my comments.

-Pete


jouni korhonen wrote:
> 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