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

[Itsuma TANAKA <[e-mail]>]

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

Mark Jones wrote:
> Hi Itsuma-san,
> 
> Thank you for the review. Comments inline.
> 
> On Wed, Oct 6, 2010 at 6:01 AM, dime issue tracker <[e-mail]> wrote:
>> #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.
>>
> 
> 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.”
> 
>>  [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.
>>
> 
> Makes sense.
> 
>>  [Comment 3]
>>  Editorial in Section 4, the first sentence.
>>  "The basic Diameter Peer Discover principles"
>>  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
> 
>