RE: tsv-dir review of draft-garcia-shim6-applicability-03

> -----Original Message-----
> From: Alberto García [mailto:alberto@...]
> Sent: Tuesday, March 06, 2012 9:07 AM
> To: 'Dan Wing'; 'IETF discussion list'
> Cc: 'Transport Directorate'; tsv-area@...; joe.abley@...;
> 'marcelo bagnulo braun'
> Subject: RE: tsv-dir review of draft-garcia-shim6-applicability-03
>
> Hi Dan,
> Thank you very much for your review
>
> |  -----Mensaje original-----
> |  De: Dan Wing [mailto:dwing@...]
> |  Enviado el: jueves, 01 de marzo de 2012 3:56
> |  Para: 'IETF discussion list'
> |  CC: 'Transport Directorate'; tsv-area@...; joe.abley@...;
> |  'marcelo bagnulo braun'; alberto@...
> |  Asunto: tsv-dir review of draft-garcia-shim6-applicability-03
> |
> |  I have reviewed this document as part of the transport area
> directorate's
> |  ongoing effort to review key IETF documents. These comments were
> written
> |  primarily for the transport area directors, but are copied to the
> document's
> |  authors for their information and to allow them to address any
> issues
> |  raised. When done at the time of IETF Last Call, the authors should
> consider
> |  this review together with any other last-call comments they receive.
> Please
> |  always CC tsv-dir@... if you reply to or forward this review.
> |
> |  This draft is basically ready for publication, but has nits that
> should
> be fixed
> |  before publication.
> |
> |
> |
> |  Nits:
> |
> |  Section 1:
> |
> |     Such problems are not specific of Shim6, but
> |     are suffered by the hosts of any site which is connected to
> multiple
> |     transit providers, and which receives an IPv6 prefix from each of
> the
> |     providers.
> |
> |  It might be useful to add a non-normative reference to RFC5220 at
> the end
> |  of that sentence.
> Ok
>
> |
> |
> |  Section 3.4:
> |
> |     The use of HBA is more efficient in the sense that addresses
> require
> |     less computation than CGA, involving only hash operations for
> both
> |     the generation and the verification of locator sets.  However,
> the
> |     locators of an HBA set are determined during the generation
> process,
> |     and cannot be subsequently changed; the addition of new locators
> to
> |     that initial set is not supported, except by re-generation of the
> |     entire set which will in turn cause all addresses to change.
> |
> |  I think that paragraph is too harsh, as it implies the old addresses
> have
> to be
> |  invalidated immediately.  I expect existing connections could
> continue
> with
> |  the old addresses, and, if the host wanted to, could even have new
> |  connections use the old addresses.  If that is not possible, the
> draft
> should
> |  explain why.  If that is possible, the draft should probably explain
> it
> is
> |  possible.
> |
>
> I have rewritten the paragraph:
>
>    "The use of HBA is more efficient in the sense that addresses
> require
>    less computation than CGA, involving only hash operations for both
>    the generation and the verification of locator sets.  However, the
>    locators of an HBA set are determined during the generation process,
>    and cannot be subsequently changed; the addition of new locators to
>    that initial set is not supported.  Therefore, a node using an HBA
> as
>    ULID for a Shim6 session can only use the locators associated to
> that
>    HBA for the considered Shim6 session.  If the node wants to use a
> new
>    set of locators, it has to generate a new HBA including the prefixes
>    of the new locators (which will result with very high probability in
>    different addresses to those of the previous set).  New sessions
>    initiated with a ULID belonging to the new HBA address set could use
>    the new locators."
>
> Do you think it is now more clear?

> |
> |  Section 4:
> |
> |     In order to configure source and destination address selection,
> tools
> |     such as DHCPv6 can be used to disseminate a [RFC3484] policy
> table to
> |     a host.
> |
> |  It might be useful to add a non-normative reference to draft-ietf-
> 6man-
> |  addr-select-opt.
> Sure
>
> |
> |
> |  Section 4:
> |
> |  The sentence ending with "properties exhibited by REAP." needs a
> reference
> |  to RFC5544, which seems to be the RFC defining REAP.
> Ok
>
> |
> |
> |
> |  Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by
> the
> |  Shim6 node knowing its IPv6 address after NPTv6 translation.
> Probably
> not
> |  worth adjusting the document, though, as NPTv6 is experimental.
>
> Well, this would not work for HBA, since in this case the addresses are
> fixed once generated.

> |
> |
> |  Section 7.7:
> |
> |     Note that an Application Level Gateway designed to modify the
> Shim6
> |     control packets would not be able to generate a valid signature,
> in
> |     case a CGA is being used, or a Parameter Data Structure binding
> the
> |     translated locator to the other locators of a node, in case a HBA
> is
> |     being used.  Therefore, the same failure cases described before
> would
> |     remain.
> |
> |  Applications are layer 7, Shim6 is layer 3, so an "Application Layer
> Gateway"
> |  that modifies Shim6 control packets seems an abuse of terminology.
> |  Suggest:
> |
> |  OLD:
> |     Note that an Application Level Gateway designed to modify the
> Shim6
> |     control packets would not be able to generate a valid signature,
> in
> |  NEW:
> |     Note that modification of the Shim6 control packets by the IPv6
> NAT
> |
> .............^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |  ^
> |     would not be able to generate a valid signature, in
>
> Changed.

> Thanks again,
> Alberto
>
> |
> |  -d
> |
> |
> |
> |
> |
> |
> |