Re: [Dime] AD review for draft-ietf-dime-nat-control-06

[Shwetha <[e-mail]>]

Hello Dan,

Attached is a new version of draft-ietf-dime-nat-control with your comments
addressed as detailed below. Comments inline at [SB]. Please let us know if
you are ok with the latest version so that we can submit this version of the
draft.


On 1/25/11 7:09 PM, "Romascanu, Dan (Dan)" <[e-mail]> wrote:

> Please find below the AD review of draft-ietf-dime-nat-control-06. While
> the document is well written and in pretty good shape, there are a
> number of issues that need to be clarified and editorial nits that need
> to be cleaned up before the document can be sent to IETF Last Call.
> 
> The comments below are divided into T (Technical) and E (Editorial).
> 
> T1. Section 4.3 - Please explain what happens with the bindings existing
> prior to the reception of the Session Re-Authorization request in case
> of a BINDING_FAILEURE. Are these left in place?
> 
[SB] Existing session and bindings will not be affected if request to update
an existing session fails. The requestor has a policy to bring down the
session upon failure to change it, it has to be done explicitly using DNCA
session termination message. Hence we have added the note below the failure
scenarios for session update.
 Note: Already established bindings for the session will not be affected.
 
> T2. Section 4.6
> 
>> The
>    DNCA relies on DNCA Manager and DNCA Agent to have builtin redundancy
>    support to recover state in case of failure.
> 
> It looks like this requirement needs to be expressed in stronger terms,
> maybe as a 2119 MUST.
[SB] We have reworded it as below:
DNCA Manager and DNCA Agent MUST have builtin redundancy
support to recover state in case of failure.
 
> T3. What does the following mean in section 5.5?
> 
>>  Diameter applications conforming to this specification MUST advertise
>    support by including the value of TBD in:
[SB] We have reworded the section 5.5 on advertising Diameter application
support as in RFC4006:
  Diameter nodes conforming to this specification MUST advertise support for
DNCA by including the value of <TBD> in the Auth-Application-Id of the
Capabilities-Exchange-Request and Capabilities-Exchange-Answer command
[RFC3588].
> 
> 
> T4. The way [RFC4005] is referenced in section 8.3 implies that a
> Normative Reference is required.
[SB] Done
> 
> T5. The security requirements in sections 5.1 and 12 seem to be
> contradictory. While in section 12 it is stipulated that
> 
>> Securing the
>    information exchange between the authorizing entity (the DNCA
>    Manager) and the NAT device requires bilateral authentication of the
>    involved parties, authorization of the involved parties to perform
>    the required procedures and functions, and procedures to ensure
>    integrity and confidentiality of the information exchange
> 
> In section 5.1 identity verification and authorization of procedures are
> only MAY.

[SB] We have reworded section 12 as follows, to indicate that only if the
messages are to be secured, it MAY be done as specified in RFC3588 Diameter
protocol:
"To secure the information exchange between the authorizing entity (the DNCA
Manager) and the NAT device (the DNCA Agent) requires bilateral
authentication of the involved parties, authorization of the involved
parties to perform the required procedures and functions, and procedures to
ensure integrity and confidentiality of the information exchange MAY be
performed."

> 
> E1. idnits complains about the following:
> 
> tmp/draft-ietf-dime-nat-control-06.txt(1298): Line has weird spacing:
> '...ly with    wit...'
> 
[SB]Its in the FSM table, and the extra spacing is to distinguish each
column.
> 
> tmp/draft-ietf-dime-nat-control-06.txt(1828): Unexpected reference
> format: '...ocol,[RFC3588] to r...'
> 
[SB] It has been corrected
> 
> E2. Section 1: 
> 
>>     The query functionality complements
>        alternative information query mechanisms, such as Simple Network
>        Management Protocol (SNMP) based mechanisms, if available.
> 
> What does exactly 'complements' mean here?

[SB]We wanted to provide example of another protocol like SNMP that provided
SNMP query to gather information. As this line is not adding to the usecase,
we have removed reference to SNMP from the paragraph.

> E3. Expand LSN or include the abbreviation in the Conventions section
[SB] LSN has been substituted with NAT
 
> E4. Chose one formulation - either 'The DNCA' or 'DNCA'
[SB] 'The DNCA' has been changed to DNCA throughout the document

> E5. Section 3.3 - s/Diameter NAT Control Manager/DNCA Manager/
[SB] Done
> 
> E6. Write in a consistent manner DNCA Agent (and not DNCA agent as in
> section 4.1)
[SB] Done
> 
> E7. Section 4.2: s/Figure 5 shows the protocol interaction/Figure 5
> shows the initial protocol interaction/
[SB] Done
> 
> E8. Section 4.3 s/perfborm/perform/
[SB] Done
> 
> E9. RFC 3588 is sometimes mentioned as 3588, other times as [RFC3588] -
> the latest seems to be better
[SB] Done

Thanks,
Shwetha

>  
> Thanks and Regards,
> 
> Dan
> 
> 
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>