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