Re: transmech editorial comments

[Erik Nordmark <Erik.Nordmark@sun.com>]

Thanks for the careful read. I've applied all of them. 
One question below.

>   -    The exit node of the tunnel (the decapsulator) receives the
>         encapsulated packet, reassembles the packet if needed, removes
>         the IPv4 header, updates the IPv6 header, and processes the
>         received IPv6 packet.
> 
> ==> why would the exit node update the IPv6 header?  I assume that would be
> done for Hop Limit processing, but that's already covered by the further
> processing

Correct. fixed.


> ==> this seems a bit unclear forwarding for the case where the tunnel is not
> used for forwarding when the hop limit is not decremented.  I tried to think
> of a better rewording, but perhaps the easiest fix would be to remove:
> 
> That is, the
>    IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the
>    tunnel.

How about replacing it with?
	That is, forwarding
	packets into a tunnel or packets received on a tunnel has the same
	impact on the IPv6 hop limit as for other interfaces.

>    -    Determine when to fragment and when to report an ICMP "packet
>         too big" error back to the source.
> 
> ==> s/ICMP/ICMPv6/ or IPv6 ICMP

I also found text in several places with "IPvX ICMP" which I replaced 
with "ICMPvX".

>    Implementations MAY provide a mechanism, for example IP Tunnel MIB
>    [RFC2667], to allow the administrator to configure the IPv4 TTL.
> 
>                 [RFC3168] for issues relating to the ToS byte and  
> 
> ==> s/ToS/Type of Service/ (I wonder if we should call the field DSCP...)

DSCP is 6 bits out of the byte AFAIK, so keeping Type-of-service makes sense
to me.


>    Any IPv6 options are preserved in the packet (after the IPv6 header).
> 
> ==> this seems like an irrelevant sentence, could be removed?

Sure. (Especially since IPv6 doesn't have options after the base header - it
might have extension headers which contain options ...)

  Erik