Realm-Based Redirection In Diameter
RFC 7075
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
(Benoît Claise; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
Just one non-blocking comment here: The Abstract is way too long, and has lots of explanatory stuff that should be in the Introduction, not in the Abstract (having an Abstract that's longer than the Introduction is a good clue to this sort of thing). The Abstract should just be enough to understand whether this is likely the document one needs to look at, and shouldn't be giving all the background explanation. I suggest replacing the first three paragraphs of the Abstract with this, or something close to it, an moving the rest of the explanatory text to the Introduction (or eliminating it, because it's really covered in Section 2 anyway): NEW The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when S-NAPTR is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server". END A comment about the shepherd writeup (not for the authors): In answer to Q12 in the writeup, the shepherd gave this: This is a requirements document and as such has not need for MIB Doctor, media type, and URI type reviews. This is not a requirements document, and this was clearly copied from another writeup and not updated. It makes me question the rest of the writeup: how much else is not correct for this document, and was copied from another?
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
Thanks for writing this spec. One small issue: Designers of new applications can incorporate the mechanism specified here into their application by normative reference to this document. I think the reference alone is probably not sufficient to specify the app, and is definitely not sufficient for the application software... I'd suggest rewording: A new application specification can incorporate the mechanism specified here by making it mandatory for the application, and referencing this specification normatively.
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
2: the restriction in [RFC6733] that the NAPTR replacement field SHOULD match the domain of the original query does not apply for realm-based redirect purposes. Strike "SHOULD". It is a 6733 requirement, and one that is overridden by this document. Having it here could lead to confusion. ...support of realm-based redirection MUST be specified as part of functionality supported by a Diameter application. ...it cannot be performed by a redirect agent as defined in [RFC6733], but MUST be performed instead by an application-aware Diameter node... These are not protocol requirements. Instead of "MUST", try "needs to".
(Sean Turner; former steering group member) No Objection
I support Stephen's discuss points. Note that on #2 I was worried that this redirection might somehow break the emu cryptobinding protocols wrt a) to keys made that use the realm but the emu protocols just use diameter as a transport and don't use diameter's realm when they make keys b) they'd be redirecting the inner methods somewhere different - but that doesn't seem to be happening.
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) (was Discuss) No Objection
Thanks for addressing my discuss points. S
(Stewart Bryant; former steering group member) No Objection
Is there an attack whereby the original domain is misconfigured to direct traffic to to a victim domain?