Re: [BEHAVE] I-D Action:draft-ietf-behave-v6v4-xlate-06.txt

Hi Xing,

Thanks for the updated doc.

The chages seems good to me except for the wording in
 "3.1. Translating IPv4 Headers into IPv6 Headers"
which Senthil has pointed out in another e-mail.

I would wait for your response to Senthil and add comment to that thread
if anything.

Regards,
-- 
Kentaro Ebisawa <ebisawa@sablenetworks.net>

On Mon, 25 Jan 2010 18:24:39 +0800
Xing Li <xing@cernet.edu.cn> wrote:

> Hi, All,
> 
> For draft-ietf-behave-v6v4-xlate-05 during WGLC, we have 4 reviews, many
> active discussions on the mailing list and mails to the authors. Thanks
> for the reviews and comments. Here is a summary of the main issues
> discussed during WGLC.
> 
> (1) Discussion if translator is a router (for TTL/Hop-limit handling)
> Conclusion: Translator is a router. We made the wording consistent in
> different places of the document (in sections 1.4, 2.1, 2.7, 3.1 and
> 3.6. of the xlate-05)
> 
> (2) Discussion if the translator handles TTL/Hop limit before or after
> the translation.
> Conclusion: Leave it for the implementation.
> 
> (3) Handling of nested ICMP error messages.
> Conclusion: This process SHOULD stop at first embedded header and drop
> the packet if it contains more.
> 
> (4) Translating pointer in Parameter Problem
> Conclusion: Move Appendix 1 to sections 2.3 and 3.2 of the xlate-05.
> Remove ambiguous by setting the pointer value to the first octet of the
> specific field if that field contains multiple octets.
> 
> (5) What MUST/SHOULD a translator do if the derivation fails for a
> source address?
> Conclusion: Translator drops the packet which contains illegal source
> address.
> 
> (6) How to deal with ICMP packets coming from IPv6 addresses that aren't
> IPv4-translatable?
> Conclusion: In this case, the translator can ether do stateful
> translation or map them to an IPv4 address block as a holder for all non
> IPv4-translatable IPv6 addresses.
> 
> (7) Other technical and editorial comments
> We have updated the document based on the suggestions.
> 
> We also combined sections 2.2 and 2.6 of the xlate-05, since IPv4 UDP
> with checksum zero is a special case of Transport-layer Header Translation.
> 
> A general question: Should we add the terminology section in each
> document (for example in xlate)? Or list all terminologies in the framework
> document (as the current framework does)?
> 
> Do we have rough consensus for the above issues? Are there any other
> issues?
> 
> Regards,
> 
> X. Li, C. Bao, F. Baker
> 
> 
> 
> Internet-Drafts@ietf.org ミエオタ:
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.
> >
> >
> > 	Title           : IP/ICMP Translation Algorithm
> > 	Author(s)       : X. Li, et al.
> > 	Filename        : draft-ietf-behave-v6v4-xlate-06.txt
> > 	Pages           : 28
> > 	Date            : 2010-01-25
> >
> > This document specifies an update to the Stateless IP/ICMP
> > Translation Algorithm (SIIT) described in RFC 2765.  The algorithm
> > translates between IPv4 and IPv6 packet headers (including ICMP
> > headers) for both stateless and stateful modes.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-behave-v6v4-xlate-06.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >   
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Behave mailing list
> > Behave@ietf.org
> > https://www.ietf.org/mailman/listinfo/behave
> >   
> 
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave