Subject: Re: [pcp] My review of draft-ietf-pcp-nat64-prefix64-02

From: <[email-masked]>
Date: Wed, 5 Jun 2013 10:19:20 +0200

Hi Teemu,

Thanks for your answer.
I tried to integrate your comments. Please check the new version available at:

http://www.ietf.org/id/draft-ietf-pcp-nat64-prefix64-03.txt 

If you still have any concern please let me know.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]]
>Envoyé : vendredi 31 mai 2013 14:56
>À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]
>Objet : RE: My review of draft-ietf-pcp-nat64-prefix64-02
>
>Hi Med,
>
>Thanks for quick reply.
>
>> [Med] I added this text:
>>   A more elaborated discussion can be found at
>>  [I-D.ietf-behave-nat64-learn-analysis].  A solution which solves some
>>   of these issues is specified in
>>   [I-D.ietf-behave-nat64-discovery-heuristic].
>
>I guess that is enough. Some discussion around might be nice (e.g.
>comparison, additional thoughts for why PCP option was standardized and why
>heuristic was not enough), but I'm not sure it is actually required.
>
>> [Med] I added this text to Section 3.2:
>>   This section provides some use cases to illustrate the problem space.
> >  More details can be found at Section 4 of
> >  [I-D.ietf-behave-nat64-learn-analysis].
>
>Ok.
>
>>>Now that you have explicit tool for provisioning Pref64::/n, why do you
>>>not provision also the suffix introduced in RFC6052? Wouldn't that make
>>>this more future proof? The format shown in 4.1 could have variable
>>>length suffix field. In fact, having suffix included would allow *fixed
>>>length*
>>>128 bit field-length, which might be optimized to be 96 bit field
>>>(128-32, with first bits for prefix and remaining for suffix - dropping
>>>bits for IPv4).
>>[Med] I'm not sure there is a value to configure the suffix. The
>implementation I'm aware does not allow to configure other suffixes. My
>personal opinion is we should not include it in the option format.
>
>AFAIK the suffix is defined in RFC6052 for some possible future uses
>(there's some discuss in RFC6052 section 4.1). If the PCP option would
>support delivery of the suffix information (esp. if suffix were to be a
>static value per deliver Pref64::/n and not e.g. facility for providing
>checksum neutrality), it might be more future proof if some use for suffix
>is actually taken into use some day.
>
>However, if the decision is not to deliver suffix, it could be worthwhile
>to have couple of word saying that in the generation of synthetic IPv6
>addresses, suffix of zero MUST be used and that if in the future the suffix
>is taken into use in protocol translation system, and the host can be
>involved in setting the suffix in sensible manner, a new PCP option may be
>needed.
>
>> [Med] I guess you are referring to what we had in
>http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option-
>02#page-6. The support of this >case will complicates the design option for
>a corner case. I added this sentence:
>>   This option does not solve the destination-dependent Pref64::/n
> >  discovery problem discussed in Section 5.1 of
> >  [I-D.ietf-behave-nat64-discovery-heuristic].
>
>Oh I had missed that draft revision text:) Sure, it would complicate.
>However, this consideration was really wanted to be included in the
>heuristic-draft, and hence I think it should be included in this document
>as well.
>
>Best regards,
>
>	Teemu