Realm-Based Redirection In Diameter
draft-ietf-dime-realm-based-redirect-13

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?

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.

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".

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.

Thanks for addressing my discuss points.

S

Is there an attack whereby the original domain is misconfigured to direct traffic to to a victim domain?