Le 2012-04-12 à 18:15, Maoke a écrit : > > hi Remi, > > this acknowledges the part not belonging to technical issues. > 2012/4/11 Rémi Després <[email protected]> > 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 Sorry to learn that. > 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. Agreed. > from Mx to Tx, the author appreciate any comments but the wording will based > on what the author understands. Of course. > 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. 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). >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
