Subject: [Dime] [dime] extended-naptr #14 (new): Itsuma Tanaka Review of draft-ietf-dime-extended-naptr-02

From: "dime issue tracker" <[email-masked]>
Date: Wed, 06 Oct 2010 04:01:39 -0000

#14: Itsuma Tanaka Review of draft-ietf-dime-extended-naptr-02
-------------------------------------+--------------------------------------
 Reporter:  tanakai@…                |       Owner:  tanakai@…              
     Type:  enhancement              |      Status:  new                    
 Priority:  minor                    |   Milestone:  milestone1             
Component:  extended-naptr           |     Version:  1.0                    
 Severity:  In WG Last Call          |    Keywords:                         
-------------------------------------+--------------------------------------
 I have reviewed draft-ietf-dime-extended-naptr-02.
 Let me provide some (mainly editorial) comments.

 [Comment 1]
 Introduction section should have a brief problem statement (i.e. what the
 problem this is trying to solve) so that the readability is improved.

 [Comment 2]
 Editorial in Section 3, "The DNS administrator of some domain SHOULD also
 provision base RFC 3588 style..."

 shouldn't this be

 "The DNS administrator of some domain SHOULD also provision *legacy* RFC
 3588 style...".. ?

 My proposal is to replace 'base' with 'legacy', so that the consistent
 expression is used throughout the specification.

 [Comment 3]
 Editorial in Section 4, the first sentence.
 "The basic Diameter Peer Discover principles"
 should be "The basic Diameter Peer Discovery principles"

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

---

From: Mark Jones <[email-masked]>
Date: Mon, 11 Oct 2010 17:18:43 +0200

Hi Itsuma-san,

Thank you for the review. Comments inline.

> #14: Itsuma Tanaka Review of draft-ietf-dime-extended-naptr-02

Agreed. Here is my latest attempt at the problem statement based on
feedback from Avi. Your comments are welcome.

“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 document describes an
optimization using S-NAPTR entries that allows peer discovery
including supported applications without doing CER/CEA exchange
beforehand.”

>  expression is used throughout the specification.

Makes sense.

>  should be "The basic Diameter Peer Discovery principles"

Agreed. The word "basic" also seems redundant in this sentence.

I'll incorporate these changes in the next revision.

Thanks
Mark

---

From: Itsuma TANAKA <[email-masked]>
Date: Tue, 12 Oct 2010 01:29:41 +0900

Dear Mark,

Thanks for the feedback.

The new introduction text looks OK to me, but is this 'optimisation' or
'improvement' or 'functional enhancement'?  I don't have strong opinion
here though.

BR, Itsuma