Joe Looking some more, I think that the carefully defined terminology is not then used so carefully!
s.2.2 defines the term 'forwarder' but by 3.5, 'router' moves in and forwarder is never used again. Is this of technical significance, or just a question of the style of the author(?s)? I think the latter, but see it as introducing uncertainty. s.2.2 defines Link MTU, Path MTU, Tunnel MTU but the document then uses link MTU, path MTU, tunnel MTU. A common convention is for capitalised words to have a particular meaning, lower case not (a bit like SHOULD and should) so is this of technical significance, or just a question of the style of the author(?s)? I think the latter, but see it as introducing uncertainty. s.2.2 defines ingress as 'the virtual link interface of a tunnel which receives messages within a node, encapsulates them according to the tunnel protocol, and transmits them into the tunnel. ' which I think of as rather a lot for an interface to do but equally not all that needs doing, such as finding a path, selecting an interface, finding link and path MTU, inspecting the packet for such as DF=1, fragmenting when called for and so on. It could be that ingress is intended to cover all these box functions. (I would like to use the term 'node' here but that has been defined as 'a device that can act as an endpoint or forwarder, which does not seem to fit here). But reading on, in figure 4, I see the box that has everything to do labelled I(ngress) which suggests that Ingress includes everything. But when I get to s.3.3, I encounter 'ingress nodes' (um oxymoron?) and then 'source (ingress) ' - what does 'source' add that 'ingress' does not already have? - and then I get a mixture in s.3.6 of 'ingress' and 'tunnel ingress' - what does 'tunnel' add that ingress is not already defined to have? I think you get my laboured point. Technical writing, for me, is boring. Get a set of concepts, as small as is necessary, give them an identifier, easy to read, write, say as you read, and use them over and over again; boring, but easy to understand. (If I look at MTU, I expect I will find the same only more so). Tom Petch ----- Original Message ----- From: "Joe Touch" <to...@isi.edu> To: "t.petch" <ie...@btconnect.com>; "Templin, Fred L" <fred.l.temp...@boeing.com> Cc: <firstname.lastname@example.org> Sent: Tuesday, October 11, 2016 4:22 PM > Hi, Tom, > > I do agree that the terminology in the current version is confusing and > it would be useful to be both more clear and more consistent. > > As I noted, I'll discuss this with Mark further and revise. > > Joe > > On 10/11/2016 3:05 AM, t.petch wrote: > > ----- Original Message ----- > > From: "Joe Touch" <to...@isi.edu> > > Sent: Monday, October 10, 2016 7:15 PM > > > >> HI, Fred (et al.), > >> > >> ... > >>> IMHO, your draft is getting wrapped up with too many new acronyms > > for no > >>> good reason when simple English-language text would make things > > easier to > >>> understand. > >> We're dealing with legacy use of the term MTU and path MTU too, > > though. > >>> In 'draft-templin-aerolink', there are only five acronyms: > >>> > >>> MTU - the MTU of the tunnel as seen by the IP layer > >> That's the term we need to specify in more detail - to some, it's > >> one-hop IP MTU, to others it means path MTU, to others it means what > > we > >> would call egress reassembly MTU. > >> > >> We need to either avoid the term MTU in our definitions or provide an > >> adjective to specify each type (as I have done). > >> > >>> MFU - the maximum fragment size within the tunnel > >> This is confusing because the fragment could refer to the payload or > > the > >> entire IP datagram. > >> > >>> MRU - the maximum reassembly size supported by the egress > >> Sure. > >> > >>> ENCAPS - the size of the encapsulation headers inserted by the > > ingress > >> Sure. > >> > >>> PTB - an IP Packet Too Big message > >> ICMPv4 or IPv6... > >> > >> You have omitted the concept of a transit MTU, which is only the ERU > >> when the ingress supports fragmentation and reassembly (which not all > >> tunnels or links do). > >> > >> Therein lies the problem with "simple" English, IMO. > > Joe > > > > I echo Fred's point about acronyms; yes you need adjectives to qualify > > MTU but when I read > > ' The TMTU (d) is not limited by TIMTU (e), but by ERMTU (f), the > > tunnel equivalent of RMTU (c). ' > > I have to pause, expand and think. Spelling out the adjectives every > > time would make it easier. > > > > Likewise, when 'MTU' or 'protocol' or some such is unqualified, I have > > to stop and think which is meant. I think that most uses of MTU should > > have an adjective or two in front of them. > > > > I would say the same of protocol. At times, the I-D seems specific, > > that this is IP in IP and so protocol is IP but other usages seem more > > generic. After all, you can tunnel Ethernet in ATM and while I think > > that most of this I-D does not cater for that, I think there are some > > places where 'protocol' is not limited to IP so if IP protocol (or IPv4 > > protocol or IPv6 protocol) is intended, then I would write that > > explicitly. > > > > Tom Petch > > > > > >> Joe > _______________________________________________ Int-area mailing list Intemail@example.com https://www.ietf.org/mailman/listinfo/int-area