[Pals] Re: Éric Vyncke's Discuss on draft-ietf-pals-p le-12: (with DISCUSS and COMMENT)
"Eric Vyncke \(evyncke\)" <[email protected]> Wed, 4 Dec 2024 06:25:28 +0000
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <PH0PR11MB496696510D5EF615400FA514A9372@PH0PR11MB4966.namprd11.prod.outlook.com> |
--===============5436810239625114983== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_PH0PR11MB496696510D5EF615400FA514A9372PH0PR11MB4966namp_" --_000_PH0PR11MB496696510D5EF615400FA514A9372PH0PR11MB4966namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good morning, Christian, As you have seen by now, I have cleared my DISCUSS: the fix was easy but th= anks for doing it promptly and for your comments below. Thank you as well for considering my COMMENTS below, look for EV> for some = comments of yours (but the -13 actually addresses all my comments). Regards -=E9ric From: Christian Schmutzer (cschmutz) <[email protected]> Date: Tuesday, 3 December 2024 at 22:37 To: Eric Vyncke (evyncke) <[email protected]> Cc: Christian Schmutzer (cschmutz) <[email protected]>, The IESG <iesg@iet= f.org>, [email protected] <[email protected]>, pals-c= [email protected] <[email protected]>, [email protected] <[email protected]>, stewa= [email protected] <[email protected]>, [email protected] <agmalis@= gmail.com> Subject: Re: =C9ric Vyncke's Discuss on draft-ietf-pals-ple-12: (with DISCU= SS and COMMENT) Hi Eric, Thank you for your review. Please see my responses inline via [cs], mention= ed changes are incorporated in newly uploaded -13 version. Christian > On 29.11.2024, at 16:38, =C9ric Vyncke via Datatracker <[email protected]>= wrote: > > =C9ric Vyncke has entered the following ballot position for > draft-ietf-pals-ple-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/about/groups/iesg/statements/handlin= g-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pals-ple/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > # =C9ric Vyncke, INT AD, comments for draft-ietf-pals-ple-12 > CC @evyncke > > Thank you for the work put into this document. > > Please find below one blocking DISCUSS points (trivial to address), some > non-blocking COMMENT points (but replies would be appreciated even if onl= y for > my own education), and some nits. > > Special thanks to Stewart Bryant for the shepherd's detailed write-up inc= luding > the WG consensus *but it lacks* the justification of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -=E9ric > > ## DISCUSS (blocking) > > As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a > DISCUSS ballot is just a request to have a discussion on the following to= pics: > > ### Section 2 > > When using the BCP 14 template, please use the most recent one. I told yo= u that > it was trivial to fix ;-) [cs] you surely got me there. I adjusted the section as follows The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD= ", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in= this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8= 174] when, and only when, they appear in all capitals, as shown here. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > ## COMMENTS (non-blocking) > > ### Added latency > > Should there be some guidance about the added latency due to the packetiz= ation > (could be reduced with packet size) and jitter buffer size ? Good suggestion OLD All PLE implementations MUST be capable of supporting the default payload s= ize of 1024 bytes. NEW All PLE implementations MUST be capable of supporting the default payload s= ize of 1024 bytes. The payload size SHOULD be configurable to be able to ad= dress specifc packetization delay and overhead expectations. I also added the following sentence to section 7.2.2: Considerations for choosing the pre-configured amount of payload required t= o be present for transitioning into the normal state: * Typically set to 50% of the de-jitter buffer size to equally allow compen= sating for increasing and decreasing delay * Choosing a compromise between the maximum amount of tolerable PDV and del= ay introduced to the emulated service > ### Abstract & section 1 > > s/This document describes/This document specifies/ in a PS ;-) > > Is `high-speed bit-streams` really part of this specification ? I.e., thi= s > technique could also be used with really slow links. [cs] agree =93high=94 is relative. the term =93high=94 is used because PLE = is expected to be implemented for services at 100s of Mbps or Gbps speeds a= nd to avoid to immediately start with a reference to SAToP (RFC4533) which = is limited to low Mbps (E1, T1, E3 and T3) in the abstract. Is the reference to RFC4553 and not using the word =93high=94 a better opti= on? If we agree so, I can change in a future version EV> I would suggest to do it as EV> 1) this document can be used as well for lower speed EV> 2) =93high=94 in ten years will probably look =93slow=94 > ### Section 1 > > Suggest to expand PE at first use even if it is a knows acronym as it is > expanded later in the text. [cs] my bad, I overlooked this instance of PE and only expanded in followin= g paragraph. Fixed now > > s/Ethernet connected/Ethernet-connected/ ? > > What is `Synchronous Ethernet`, honestly I do not know, hence an informat= ive > reference is welcome. [cs] good catch. There is a informative reference later, I added one here n= ow as well > Should there be an informational reference to `Fibre Channel` ? [cs] There are various references to specific Fibre Channel interface rates= later in the document. I have added a reference to the T11 committee=92s w= ebsite for the reader to have a starting point if needed. > A graphic for the SONET/SDH explanations would add to the text (even if t= he > text is clear as it is). Just a suggestion. > > `PDH` is not yet expanded at this point. [cs] fixed > ### Section 3.1 > > Just a suggestion for the reader, keep this section but also expand the > acronyms at first use (because then they are more understandable -- few r= eaders > will read and understand a terminology section that only contains expansi= ons > without explanations). > > ### Section 3.2 > > s/The local oscillators C/The local clock C/ ? > > Is it clock or frequency in `frequency synchronization available`? Becaus= e the > word frequency was never used before. [cs] clock synchronisation and frequency synchronisation are two terms that= mean the same thing. As the references G.8261.1 and G.8251 use the term fr= equency sync I reworded this paragraphs as follows OLD ... for achieving frequency synchronization available. NEW =85 for achieving clock synchronization, commonly also referred to as freq= uency synchronization, available. EV> this is good indeed > A reference (more than the expansion of section 3.1) for `BITS` will be w= elcome. [cs] reference now included > ### Section 5.1 > > Isn't it obvious that C-SID can be used ? =3D> suggest removing this sent= ence > (feel free to ignore). > > Suggest to have a sub-section for the SRv6 behaviours. [cs] good suggestion. Done > s/The next header field of the SRH or last extension header/The next head= er > field of the SRH or *the* last extension header/ [cs] done > > s/The push of the SRH/The *insertion* of the SRH/ also add "per RFC 8986"= . [cs] done > What is `pushed IPv6 header` ? If this is the SRH, then let's be clear (a= nd BTW > IPv6 is not MPLS, there is no "push" ;-) ). [cs] we followed wording of RFC8986 section 5.3 and 5.4 here. I reworded to= not improperly call the IPv6 heade+ SRH just header OLD =85 excluding the first SID in the SRH of the pushed IPv6 header. The first= SID is only placed in the destination address field of the pushed IPv6 hea= der. NEW =85 excluding the first SID in the SRH. The first SID is only placed in the= destination IPv6 address field. Also replaced all appearances of push with add / insert in the part of the = document EV> thanks, the text is easier to read with IPv6 eyes ;-) > > ### Section 7.2.1 > > Suggest to make it clear that all packets are of the same size in `fixed = size > PLE payloads` [cs] reworded as follows OLD Packetize the data received from the CE is into a fixed size PLE payloads NEW Packetize the data received from the CE is into PLE payloads, all of the sa= me configured size > ### Section 10 > > Suggest to add (e.g., via a reference) the URI of the IANA (sub)registrie= s. > > Also, there is no `Segment Routing Parameters`, only a `Segment Routing` = one ;-) [cs] done > ## NITS (non-blocking / cosmetic) > > ### Use of SVG > > Suggest trying the "aasvg" tool to have nicer graphics in HTML/PDF render= ing > (worth a try). [cs] I will try with future drafts > ### ethernet > > Check that Ethernet is always capitalised. [cs] done > > > --_000_PH0PR11MB496696510D5EF615400FA514A9372PH0PR11MB4966namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Aptos; panose-1:2 11 0 4 2 2 2 2 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:12.0pt; font-family:"Aptos",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} span.EmailStyle19 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} --></style> </head> <body lang=3D"en-BE" link=3D"blue" vlink=3D"purple" style=3D"word-wrap:brea= k-word"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">Good morning, Christian,<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">As you have seen by now, I have cleared my DISCUSS: = the fix was easy but thanks for doing it promptly and for your comments bel= ow.<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">Thank you as well for considering my COMMENTS below,= look for EV> for some comments of yours (but the -13 actually addresses= all my comments).<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">Regards<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US">-=E9ric<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <div id=3D"mail-editor-reference-message-container"> <div> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;mar= gin-bottom:12.0pt;margin-left:36.0pt"> <b><span lang=3D"EN-US" style=3D"color:black">From: </span></b><span lang= =3D"EN-US" style=3D"color:black">Christian Schmutzer (cschmutz) <cschmut= [email protected]><br> <b>Date: </b>Tuesday, 3 December 2024 at 22:37<br> <b>To: </b>Eric Vyncke (evyncke) <[email protected]><br> <b>Cc: </b>Christian Schmutzer (cschmutz) <[email protected]>, The I= ESG <[email protected]>, [email protected] <draft-ietf-pals= [email protected]>, [email protected] <[email protected]>, pals@= ietf.org <[email protected]>, [email protected] <stewart.bryant= @gmail.com>, [email protected] <[email protected]><br> <b>Subject: </b>Re: =C9ric Vyncke's Discuss on draft-ietf-pals-ple-12: (wit= h DISCUSS and COMMENT)<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;mar= gin-bottom:12.0pt;margin-left:36.0pt"> <span lang=3D"EN-US" style=3D"font-size:11.0pt">Hi Eric,<br> <br> Thank you for your review. Please see my responses inline via [cs], mention= ed changes are incorporated in newly uploaded -13 version.<br> <br> Christian <br> <br> > On 29.11.2024, at 16:38, =C9ric Vyncke via Datatracker <noreply@iet= f.org> wrote:<br> > <br> > =C9ric Vyncke has entered the following ballot position for<br> > draft-ietf-pals-ple-12: Discuss<br> > <br> > When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s<br> > introductory paragraph, however.)<br> > <br> > <br> > Please refer to <a href=3D"https://www.ietf.org/about/groups/iesg/stat= ements/handling-ballot-positions/"> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions= /</a> <br> > for more information about how to handle DISCUSS and COMMENT positions= .<br> > <br> > <br> > The document, along with other ballot positions, can be found here:<br= > > <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-pals-ple/">http= s://datatracker.ietf.org/doc/draft-ietf-pals-ple/</a><br> > <br> > <br> > <br> > ----------------------------------------------------------------------= <br> > DISCUSS:<br> > ----------------------------------------------------------------------= <br> > <br> > <br> > # =C9ric Vyncke, INT AD, comments for draft-ietf-pals-ple-12<br> > CC @evyncke<br> > <br> > Thank you for the work put into this document.<br> > <br> > Please find below one blocking DISCUSS points (trivial to address), so= me<br> > non-blocking COMMENT points (but replies would be appreciated even if = only for<br> > my own education), and some nits.<br> > <br> > Special thanks to Stewart Bryant for the shepherd's detailed write-up = including<br> > the WG consensus *but it lacks* the justification of the intended stat= us.<br> > <br> > I hope that this review helps to improve the document,<br> > <br> > Regards,<br> > <br> > -=E9ric<br> > <br> > ## DISCUSS (blocking)<br> > <br> > As noted in <a href=3D"https://www.ietf.org/blog/handling-iesg-ballot-= positions/"> https://www.ietf.org/blog/handling-iesg-ballot-positions/</a>, a<br> > DISCUSS ballot is just a request to have a discussion on the following= topics:<br> > <br> > ### Section 2<br> > <br> > When using the BCP 14 template, please use the most recent one. I told= you that<br> > it was trivial to fix ;-)<br> <br> [cs] you surely got me there. I adjusted the section as follows <br> <br> The key words "MUST", "MUST NOT", "REQUIRED",= "SHALL", "SHALL NOT", "SHOULD", "SHOULD= NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY= ", and "OPTIONAL" in this document are to be interpreted as = described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.<br> <br> > ----------------------------------------------------------------------= <br> > COMMENT:<br> > ----------------------------------------------------------------------= <br> > <br> > <br> > ## COMMENTS (non-blocking)<br> > <br> > ### Added latency<br> > <br> > Should there be some guidance about the added latency due to the packe= tization<br> > (could be reduced with packet size) and jitter buffer size ?<br> <br> Good suggestion<br> <br> OLD<br> <br> All PLE implementations MUST be capable of supporting the default payload s= ize of 1024 bytes. <br> <br> NEW<br> <br> All PLE implementations MUST be capable of supporting the default payload s= ize of 1024 bytes. The payload size SHOULD be configurable to be able to ad= dress specifc packetization delay and overhead expectations.<br> <br> <br> I also added the following sentence to section 7.2.2:<br> <br> Considerations for choosing the pre-configured amount of payload required t= o be present for transitioning into the normal state:<br> * Typically set to 50% of the de-jitter buffer size to equally allow compen= sating for increasing and decreasing delay<br> * Choosing a compromise between the maximum amount of tolerable PDV and del= ay introduced to the emulated service<br> <br> <br> > ### Abstract & section 1<br> > <br> > s/This document describes/This document specifies/ in a PS ;-)<br> > <br> > Is `high-speed bit-streams` really part of this specification ? I.e., = this<br> > technique could also be used with really slow links.<br> <br> [cs] agree =93high=94 is relative. the term =93high=94 is used because PLE = is expected to be implemented for services at 100s of Mbps or Gbps speeds a= nd to avoid to immediately start with a reference to SAToP (RFC4533) which = is limited to low Mbps (E1, T1, E3 and T3) in the abstract.<br> <br> Is the reference to RFC4553 and not using the word =93high=94 a better opti= on? If we agree so, I can change in a future version<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US" = style=3D"font-size:11.0pt"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US" = style=3D"font-size:11.0pt">EV> I would suggest to do it as<br> EV> 1) this document can be used as well for lower speed<br> EV> 2) =93high=94 in ten years will probably look =93slow=94<o:p></o:p><= /span></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;mar= gin-bottom:12.0pt;margin-left:36.0pt"> <span lang=3D"EN-US" style=3D"font-size:11.0pt"><br> <br> > ### Section 1<br> > <br> > Suggest to expand PE at first use even if it is a knows acronym as it = is<br> > expanded later in the text.<br> <br> [cs] my bad, I overlooked this instance of PE and only expanded in followin= g paragraph. Fixed now<br> <br> > <br> > s/Ethernet connected/Ethernet-connected/ ?<br> > <br> > What is `Synchronous Ethernet`, honestly I do not know, hence an infor= mative<br> > reference is welcome.<br> <br> [cs] good catch. There is a informative reference later, I added one here n= ow as well<br> <br> > Should there be an informational reference to `Fibre Channel` ?<br> <br> [cs] There are various references to specific Fibre Channel interface rates= later in the document. I have added a reference to the T11 committee=92s w= ebsite for the reader to have a starting point if needed.<br> <br> > A graphic for the SONET/SDH explanations would add to the text (even i= f the<br> > text is clear as it is). Just a suggestion.<br> > <br> > `PDH` is not yet expanded at this point.<br> <br> [cs] fixed<br> <br> > ### Section 3.1<br> > <br> > Just a suggestion for the reader, keep this section but also expand th= e<br> > acronyms at first use (because then they are more understandable -- fe= w readers<br> > will read and understand a terminology section that only contains expa= nsions<br> > without explanations).<br> > <br> > ### Section 3.2<br> > <br> > s/The local oscillators C/The local clock C/ ?<br> > <br> > Is it clock or frequency in `frequency synchronization available`? Bec= ause the<br> > word frequency was never used before.<br> <br> [cs] clock synchronisation and frequency synchronisation are two terms that= mean the same thing. As the references G.8261.1 and G.8251 use the term fr= equency sync I reworded this paragraphs as follows<br> <br> OLD<br> ... for achieving frequency synchronization available.<br> <br> NEW<br> =85 for achieving clock synchronization, commonly also referred to as= frequency synchronization, available.<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US" = style=3D"font-size:11.0pt"><o:p> </o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US" = style=3D"font-size:11.0pt">EV> this is good indeed<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;mar= gin-bottom:12.0pt;margin-left:36.0pt"> <span lang=3D"EN-US" style=3D"font-size:11.0pt"><br> <br> > A reference (more than the expansion of section 3.1) for `BITS` will b= e welcome.<br> <br> [cs] reference now included<br> <br> > ### Section 5.1<br> > <br> > Isn't it obvious that C-SID can be used ? =3D> suggest removing thi= s sentence<br> > (feel free to ignore).<br> > <br> > Suggest to have a sub-section for the SRv6 behaviours.<br> <br> [cs] good suggestion. Done<br> <br> > s/The next header field of the SRH or last extension header/The next h= eader<br> > field of the SRH or *the* last extension header/<br> <br> [cs] done<br> <br> > <br> > s/The push of the SRH/The *insertion* of the SRH/ also add "per R= FC 8986".<br> <br> [cs] done<br> <br> > What is `pushed IPv6 header` ? If this is the SRH, then let's be clear= (and BTW<br> > IPv6 is not MPLS, there is no "push" ;-) ).<br> <br> [cs] we followed wording of RFC8986 section 5.3 and 5.4 here. I reworded to= not improperly call the IPv6 heade+ SRH just header<br> <br> OLD<br> =85 excluding the first SID in the SRH of the pushed IPv6 header. The first= SID is only placed in the destination address field of the pushed IPv6 hea= der.<br> <br> NEW<br> =85 excluding the first SID in the SRH. The first SID is only placed in the= destination IPv6 address field.<br> <br> Also replaced all appearances of push with add / insert in the part of the = document<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span lang=3D"EN-US" = style=3D"font-size:11.0pt">EV> thanks, the text is easier to read with I= Pv6 eyes ;-)<o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"mso-margin-top-alt:0cm;margin-right:0cm;mar= gin-bottom:12.0pt;margin-left:36.0pt"> <span lang=3D"EN-US" style=3D"font-size:11.0pt"><br> <br> > <br> > ### Section 7.2.1<br> > <br> > Suggest to make it clear that all packets are of the same size in `fix= ed size<br> > PLE payloads`<br> <br> [cs] reworded as follows<br> <br> OLD<br> Packetize the data received from the CE is into a fixed size PLE payloads<b= r> <br> NEW<br> Packetize the data received from the CE is into PLE payloads, all of the sa= me configured size<br> <br> > ### Section 10<br> > <br> > Suggest to add (e.g., via a reference) the URI of the IANA (sub)regist= ries.<br> > <br> > Also, there is no `Segment Routing Parameters`, only a `Segment Routin= g` one ;-)<br> <br> [cs] done<br> <br> > ## NITS (non-blocking / cosmetic)<br> > <br> > ### Use of SVG<br> > <br> > Suggest trying the "aasvg" tool to have nicer graphics in HT= ML/PDF rendering<br> > (worth a try).<br> <br> [cs] I will try with future drafts<br> <br> > ### ethernet<br> > <br> > Check that Ethernet is always capitalised.<br> <br> [cs] done<br> <br> > <br> > <br> > <o:p></o:p></span></p> </div> </div> </div> </div> </div> </body> </html> --_000_PH0PR11MB496696510D5EF615400FA514A9372PH0PR11MB4966namp_-- --===============5436810239625114983== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBhbHMtbGVhdmVAaWV0Zi5vcmcK --===============5436810239625114983==--