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

From: "dime issue tracker" <[email-masked]>
Date: Wed, 29 Sep 2010 08:36:09 -0000

#13: Avi Lior Review of draft-ietf-dime-extended-naptr-02
----------------------------------------------+-----------------------------
 Reporter:  lionel.morand@…                   |       Owner:  Avi Lior [avi@…                      
     Type:  enhancement                       |      Status:  new                                  
 Priority:  major                             |   Milestone:  milestone1                           
Component:  extended-naptr                    |     Version:  1.0                                  
 Severity:  In WG Last Call                   |    Keywords:                                       
----------------------------------------------+-----------------------------
 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?

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/13>
dime <http://tools.ietf.org/wg/dime/>