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

[Maoke <[e-mail]>]

hi Remi,

this acknowledges the part not belonging to technical issues.
2012/4/11 Rémi Després <[e-mail]>

> Maoke,
>
> Good to see that at least one who has read the 4rd-u draft still considers
> that technical considerations are worth working on.
>
>

sorry if you mean the "at least one" is me, i don't consider the technical
considerations are worth working on but i only share understanding for
others' judgement on the worthness.


>
> Thanks.
>
> IMHO, you did a great job to structure this (useful) discussion.
> Here are quick comments/suggestions/corrections I propose:
>
>

thanks for comments. basically the commentary is straightforward and any
statement with metaphysics should be avoided. from Mx to Tx, the author
appreciate any comments but the wording will based on what the author
understands. 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.

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).
>
>