Opened 9 years ago

Closed 9 years ago

#13 closed enhancement (fixed)

Avi Lior Review of draft-ietf-dime-extended-naptr-02

Reported by: lionel.morand@… Owned by: Avi Lior [avi@…
Priority: major Milestone: milestone1
Component: extended-naptr Version: 1.0
Severity: In WG Last Call Keywords:
Cc: dime@…


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 ==========


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


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


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


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


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?

Change History (1)

comment:1 Changed 9 years ago by jouni.nospam@…

  • Resolution set to fixed
  • Status changed from new to closed

Resolved in the -05.

Note: See TracTickets for help on using tickets.