Hi Brian, Thanks for the comments.
|> 3.1.1. Transport | |Probably useful to state that this is layer 4. I understand that over |at the ITU-T they have changed the meaning of the word 'transport' to |mean layer 2 (presumably in an effort to forget about OSI). Sure thing. BTW, my understanding is that the PSTN folks were using 'transport' long ago to describe their TDM hierarchy. In fact, it was these newfangled packet folks that redefined 'transport'. ;-) |> The consensus of the |> group is that such site renumbering is a completely unacceptable |> requirement and as such, these types of solutions are not |of interest |> for further exploration. | |Mild rewrite as | | The consensus of the | group is that such site renumbering is widely unacceptable for | operational reasons and thus, these types of solutions are not of | interest for further exploration in this group. Sure. |> 3.1.2. Translation | |Reading further, it occurred to me that this really should |be called Map & Translate, and that we should distinguish |stateful and stateless translation. True, but ALL solutions require mapping. |Also distinguish reversible and non-reversible translation. I agree with the differentiation, but I'm really less interested in refining the taxonomy from section 3.1 unless there's some clear, tangible benefit. At this point, I'm much more interested in putting our efforts into the section 3.3 approach. |> 4.1. No manual renumbering of end hosts |> |> There is clear consensus in the group that renumbering of |sites must |> not require manual intervention on a per-host basis. | |Yes. You might consider a reference to draft-carpenter-renum-needs-work |(the -02 draft will be out in a day or two). I'm not suggesting that |should be an RRG document; in fact it's being discussed in the IETF |Ops Area. But it does discuss exactly this topic. Plug added. ;-) Tony _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
