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
