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