Re: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt

[Maoke <[e-mail]>]

2012/4/13 Rémi Després <[e-mail]>

>
> on the other hand, repeating what 4rd-u draft has stated in another draft
> is trivial.
>
>
> in details, the following comments (regarding section 4) will be reviewed
> but the author won't adopt some of them, especially when it contains
> metaphysics beyond the context.
>
>
> Why you consider points below to be metaphysics is obscure to me.
> They are believed to be operational and/or technical.
>
> Your listing your own view of 4rd-u motivations, while refusing mine,
> remains your responsibility.
>
>

i said "won't adopt some of them" but all will be reviewed and referenced.
the text, sure, as signed by me, is my responsibility.

- maoke


>
>
>
> RD
>
>
>
> thanks and regards,
> maoke
>
>
>>
>>
>>
>> 4.1. (M2) Rather than "simplification of L4 protocol treatment" the
>> motivation is "Full IPv4 transparency, with never modified payloads and
>> IPv4 fragmentation semantics"
>>
>> 4.1. (M4) a motivation to be added:  "No constraint on subnet-ID
>> assignments in customer sites"
>>
>> 4.2. (O1) "4rd-U argues that IPv4 end-to-end transparency should be as
>> ensured as in MAP-E" instead of "4rd-U argues it should be supported no
>> matter how minor it is observed in practice".
>>
>> 4.2. (O1) "4rd-u leaves it to ISPs to decide which kind of tunnel they
>> prefer, concerning DiffServ architecture, provided users cannot make the
>> difference" instead of "4rd-U argues ToS should be kept unchanged when the
>> packet traverses the IPv6 domain, except the ECN bits".
>>
>> 4.2. (O5) "it also argues that checksum transparency ensures IPv6 packet
>> validity of IPv4 tunneled packets, for all present and future protocols
>> that have ports as the same place as TCP and the same checksum algorithm,
>> without being concerned with where these protocols have their checksum
>> fields"  instead of "it also argues checksum validity should be ensured
>> through address in order to simplify L4 processing"
>>
>> 4.2. (O6)- to be added
>> "UDP null checksums: [RFC6145] can be configured either to drop all IPv4
>> packets having null checksums, or drop only those that are fragmented.
>> 4rd-u argues that this lack of IPv4 transparency should be avoided."
>>
>> 4.2. (O7)- to be added
>> "Free assignment of subnet IDs:  subnet IDs that follow customer-site
>> prefixes in native IPv6 addresses are so far freely chosen for each
>> customer site. 4rd-u argues that this freedom should not be lost, despite
>> the need to distinguish IPv4-originated packets from native IPv6 packets at
>> customer-site entrances.
>>
>> 4.2. after (T6) CNP and V octet, because they are related to (M4), (O6),
>> and (07), should IMHO be considered in scope (if a new version is issued).
>>
>>
>