Subject: Re: [BEHAVE] 2nd WGLC, draft-ietf-behave-v6v4-xlate-stateful-08

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 06 Mar 2010 16:10:37 +0100

Hi,

thanks for the review.
I have corrected all these in the next version of the document.

Regards, marcelo

El 15/02/10 21:07, Dave Thaler escribió:
> Just some editorial nits...
>
> Section 1.2.1:
>    
>> Using DNS64, an IPv6 client obtains an IPv6 address that embeds the
>>      
> Since stateful NAT64 has no hard dependency on DNS64, suggest:
>
>    
done
>> Using a mechanism such as DNS64, an IPv6 client obtains an IPv6 address that embeds the
>>      
>          ^^^^^^^^^^^^^^^^^^^
>
> Point being that if some other mechanism is used rather than DNS,
> NAT64 will still work.  The last paragraph of Section 1.2.2 is
> good, which already makes this point.
>
> Section 1.2.2:
>    
>> uses the Well-Know Prefix 64:FF9B::/96 defined
>>      
>                  ^^^^
>    
>> local name server uses the Well-Know prefix 64:FF9B::/96 to create
>>      
>                                    ^^^^
>
> s/Know/Known/
>
>    
ok

> Section 1.2.3:
>    
>> packets are not specific to the NAT64 and therefore is not described
>>      
>                                                        ^^
> s/is/are/
>
>    
ok

> Section 2:
>    
>> pair.  Used to translate the addresses and ports/Query Identifiers
>>      
> s/Query/ICMP/
>
>    
ok

> Section 3:
>    
>> implementations are free use different data structures but they MUST
>>      
> s/free use/free to use/
>
>    
ok

> Section 3.5.1:
>    
>> The NAT64 sets (or resets) the timer in the Session Table Entry to
>> maximum session lifetime.
>>      
>   ^
>
> Insert "the"
>
>    
ok

> Section 3.5.1.1:
>    
>> (this behavior is
>> recommended in REQ 3-a of [RFC4787])
>>      
> s/this/This/
> Add period before ")"
>
>    
ok

> Section 3.5.2.1:
>    
>> and forwards packet in both directions for a short period of time
>>      
> s/packet/packets/
>
>    
ok

> Section 5.1:
>    
>> Any protocols that protect IP header information is essentially
>>      
> Either s/protocols/protocol/
> Or s/is/are/
>
>    

ok
> Section 5.2:
>    
>> targeting the internal network.  To avoid these type of abuse, some
>> NAT64 MAY keep track the sequence number of TCP packets in order to
>>      
> Replace "these type" with either "this type" or "these types".
> s/some NAT64/a NAT64/
> Replace "keep track" with either "track" or "keep track of"
>
>    
ok

> -Dave
>
>    
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Dan Wing
>> Sent: Friday, February 12, 2010 11:18 AM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [BEHAVE] 2nd WGLC, draft-ietf-behave-v6v4-xlate-stateful-08
>>
>> ** We need at least 5 reviewers to tell us this document is ready
>> ** for submission to IESG.  Please email [email-masked]
>> ** with a subject line containing the document name, and "ready
>> ** to submit to IESG" or "not ready to submit to IESG" in the
>> ** message body.  If not ready to submit, please propose new text.
>>
>>
>> This email starts the 2nd WGLC for draft-ietf-behave-v6v4-xlate-
>> stateful-08,
>> ending in one week (Friday, February 19).  For reference, the first
>> WGLC was
>> for draft-ietf-behave-v6v4-xlate-stateful-07.
>>
>> Differences between 07 (first WGLC) and 08 (2nd WGLC) are:
>>
>> http://tools.ietf.org/rfcdiff?url1=draft-ietf-behave-v6v4-xlate-
>> stateful-07&ur
>> l2=draft-ietf-behave-v6v4-xlate-stateful-08.txt
>>
>> -d
>>
>> _______________________________________________
>> Behave mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/behave
>>      
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>