Subject: [Dime] Avi Lior Review of draft-ietf-dime-extended-naptr-02

From: Avi Lior <[email-masked]>
Date: Tue, 28 Sep 2010 20:21:55 -0400

I have reviewed draft-ietf-dime-extended-naptr-02.  Here is my review:

Comment  1
==========

Improving understandability.

The introduction does not defines the problem statement that this document addresses.

Even the Abstract does not tell us what problem we are solving.

Why do we want the NAPTR queries to contain Diameter Application-Id information?

The answer is not reached until section 4 which presents a wonderful background to the problem.  But still does not present the problem.

Suggestion move section 4 material to the introduction.  Alternatively, add a Problem Statement / Background section as part of 1.0 

Comment
==========

Terminology 

"The Diameter base protocol specification (Section 1.4 of RFC 3588)
   defines most of the terminology used in this document."

Where is the rest defined??? or does it not matter???

Comment
========

Section 3:

Question:  Does NAPTR Service Field format always consists of Application Service tag and Application Protocol tag?

Check 3958

Comment
========
Editorial 

Section 3

supporting a specific Diameter application is show below.

s/show/shown

Comment
=========
Section 3 editorial(s)

Break the last par in this section after the first sentence.

Also change:
"The DNS administrator of some domain SHOULD also
   provision base RFC 3588 style NAPTR records [RFC2915] in order to
   guarantee backwards compatibility with legacy RFC 3588 compliant
   Diameter peers. "

To"

"DNS administrators SHOULD also
   provision base RFC 3588 style NAPTR records [RFC2915] in order to
   guarantee backwards compatibility with legacy RFC 3588 compliant
   Diameter peers." 

Comment
========

Editorial

Section 4 a:

s/The Diameter implementation performs/The Diameter peer performs/

or client???

Align with terminology used in step b.

"If "X" contains the required Application Identifier and "Y"
         matches a transport protocol supported by the client,"

Comment
========

Section 4  c:

"c: and d:" is existing behavior right?  So why are we talking about it.  I would mention it first and get it out of the way.  Just elaborate on the new stuff.

Comment
=========

5 Usage Guidelines

I am not getting this paragraph.

It is stating the problem (which we could do earlier).  But i am not getting the last sentence.

Why do we care if its a client or a peer: can this be not used by one peer looking for a particular another peer supporting an application and protocol

why does it have to only apply to client server?  What am I missing????

Comment
==========
IANA Consideration

6.1 

Is this a new registry????

Too bad we cant just say define a generic string/rule once and not require IANA to create a new entry for each new application.

Comment
========
6.2

Why are we doing this.  We should make the usage consistent with first come first served.

Why require an RFC????

Specifically if I have a vendor specific application id and I want to use this scheme now I have to write an RFC?

---

From: Mark Jones <[email-masked]>
Date: Wed, 29 Sep 2010 09:59:09 -0400

Hi Avi,

Thanks for the detailed review. Responses are inline.

> I have reviewed draft-ietf-dime-extended-naptr-02.  Here is my review:

Ok. I’ll craft a problem statement. Something along the lines of:

“Using dynamic peer discovery as described in RFC3588, a given realm
may advertise  multiple Diameter nodes without revealing which
Diameter application each node supports. A peer outside the realm
would have to perform a CER/CEA exchange with every node in order to
find which one supports the desired application. This draft describes
an optimization using S-NAPTR entries that allows peer discovery
including supported applications without doing CER/CEA exchange
beforehand.”

> Comment

Ok. I’ll add RFC3958 which introduces the S-NAPTR terms then remove “most of”.

> Question:  Does NAPTR Service Field format always consists of Application Service tag and Application Protocol tag?

No. It is S-NAPTR (and not NAPTR) that defines the
appn-svc:appln-proto format which is what this section is covering.

> Check 3958

Checked. I believe we're good on this one.

> supporting a specific Diameter application is show below.

Ok.

>   guarantee backwards compatibility with legacy RFC 3588 compliant

Ok.

> s/The Diameter implementation performs/The Diameter peer performs/

This text is consistent with Section 5.2 in RFC3588. Which is also
inconsistent between steps. ;)

>         matches a transport protocol supported by the client,"

I believe the "client" here is not a Diameter client but a NAPTR
client, i.e. the Diameter peer performing the NAPTR query. Pretty
longwinded but I'll try to reword to clarify.

> "c: and d:" is existing behavior right?  So why are we talking about it.  I would mention it first and get it out of the way.  Just elaborate on the new stuff.

I repeated step c for readability because I thought having the
S-NAPTR/NAPTR procedure steps would be more readable than having the
reader trying to figure out how to mesh it with the logic for dynamic
peer discovery in RFC3588. I believe I got the balance right here but
take a look at the full procedure in RFC3588 and let me know if you
disagree.

> Why do we care if its a client or a peer: can this be not used by one peer looking for a particular another peer supporting an application and protocol

Sure it could in a true peer-to-peer Diameter application there aren’t
any (AFAIK). The usage guidelines in this section only apply for
Diameter applications that define client/server roles.

> why does it have to only apply to client server?  What am I missing????

Let’s say I’m an MME (S6a client) looking for an HSS (S6a Server).
Since the S-NAPTR entry only identifies peers that support S6a then I
will discover all the other MME in the network in addition to the HSS.
Not very helpful.

> Comment

Nope. It reuses the S-NAPTR registry.

> Too bad we cant just say define a generic string/rule once and not require IANA to create a new entry for each new application.

Agreed but you can’t do that without a new DDDS application and it is
tough to justify that effort for this optimization.

> Why are we doing this.  We should make the usage consistent with first come first served.

Because we’re using an existing IANA registry (S-NAPTR) and are bound
by an existing allocation policy. This was discussed at IETF77 and the
conclusion in the room was that this was the lesser of evils.

> Specifically if I have a vendor specific application id and I want to use this scheme now I have to write an RFC?

Yes but the S-NAPTR allocation policy allows an RFC “of any category”
(not standards track) so this should not present a major impediment to
vendors/SDOs that require this optimization.

---

I'll make the above changes in the next rev along with any other
comments from WGLC.

Regards
Mark