Joel, The important piece of information is that this is a pseudowire endpoint. These days, most pseudowire endpoints seem to be Ethernet. But some aren't. There are still some legacy layer 2 pseudowires hanging around. So, since we can't enumerate every type of pseudowire endpoint, we might as well just call it a pseudowire endpoint and provide no further information about the type. Ron > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@xxxxxxxxxxxxxxx] > Sent: Monday, December 4, 2017 4:19 PM > To: Ron Bonica <rbonica@xxxxxxxxxxx>; gen-art@xxxxxxxx > Cc: draft-ietf-intarea-probe.all@xxxxxxxx; int-area@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: Genart telechat review of draft-ietf-intarea-probe-07 > > Thank you Ron. > > On the E-bit (or P-Bit), is the important goal that it is a virtual interface, that it > is pseudowire, or ? It might help there text indicating what a receiver might > do differently based on this bit being set or unset. > Having said that, Ethernet Pseudowire is at least a clearer distinction than just > "Ethernet". And as long as the bit has a clear definition, any disagreement > about what "should" be identified is clealry NOT a show stopper. > > Yours, > Joel > > On 12/4/17 4:13 PM, Ron Bonica wrote: > > Hi Joel, > > > > Thanks for the review. Responses inline...... > > > > Ron > > > > > >> -----Original Message----- > >> From: Joel Halpern [mailto:jmh@xxxxxxxxxxxxxxx] > >> Sent: Thursday, November 30, 2017 4:45 PM > >> To: gen-art@xxxxxxxx > >> Cc: draft-ietf-intarea-probe.all@xxxxxxxx; int-area@xxxxxxxx; > >> ietf@xxxxxxxx > >> Subject: Genart telechat review of draft-ietf-intarea-probe-07 > >> > >> Reviewer: Joel Halpern > >> Review result: Almost Ready > >> > >> I am the assigned Gen-ART reviewer for this draft. The General Area > >> Review Team (Gen-ART) reviews all IETF documents being processed by > >> the IESG for the IETF Chair. Please wait for direction from your > >> document shepherd or AD before posting a new version of the draft. > >> > >> For more information, please see the FAQ at > >> > >> <https://urldefense.proofpoint.com/v2/url?u=https- > >> > 3A__trac.ietf.org_trac_gen_wiki_GenArtfaq&d=DwICaQ&c=HAkYuh63rsuhr > >> 6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl- > >> > AWF2EfpHcAwrDThKP8&m=hKAAxSQXBFWxkxtwUUKzdYcvZ22_3zrp0OZhHK > >> V2AH4&s=X_Kje37D5HB_DdICxGgn_TkAqoXymCuJdJetUjwYPy4&e=>. > >> > >> Document: draft-ietf-intarea-probe-07 > >> Reviewer: Joel Halpern > >> Review Date: 2017-11-30 > >> IETF LC End Date: 2017-12-13 > >> IESG Telechat date: 2017-12-14 > >> > >> Summary: This document is almost ready for publication as a Proposed > >> Standard RFC. > >> > >> Major issues: > >> I can not determine from the text why two identification objects are > >> sometimes allowed, or how they are to be used. The texts seems > >> to indicate > >> that they can be somehow combined to identify a single probed > interface. > >> But I can not see how. > > > > [RB ] > > Good catch. > > > > At one time I thought that this was necessary because IPv6 link-local > addresses are not necessarily unique to the node. So, you might need to > probe by IP address and something else (e.g., ifName). However, ifName is > unique to the node. So, one instance of the interface identification object is > enough. > > > > I will remove that sentence. > > > > > >> > >> Minor issues: > >> In section 2.1 in describing the usage when the probed interface is > >> identified by name or ifindex, the text refers to MIBII, RFC 2863. I > would > >> expect to see it refer instead (or at least preferentially) to RFC 7223, > >> the YANG model for the Interface stack. > > > > [RB ] > > Fair enough. I will make that change in the next version. > > > >> > >> The E bit in the Extended ICMP Echo reply seems a bit odd. Shall we try > to > >> encode all the possible interface types in this field? Shall we try to > >> distinguish Ethernet directly over fiber from Ethernet over ...? What > >> about an emulated Ethernet interface (pseudowire, etc.) I do not > >> understand why this is here, and fear it is ambiguous. > > [RB ] > > Looking back, I described that badly. This bit is set if the interface is a > pseudowire endpoint and it is running Ethernet. > > > > Maybe I should call it the P-bit for Pseudowire endpoint. We don't need to > specify what type of pseudowire it is. > > > > What do you think? > > > >> > >> Nits/editorial comments: > >> I find the description of the node containing the proxy interface as > being > >> "the probed node" as being somewhat odd, as it is not the node > containing > >> the probed interface. I would have expected it to be called "the proxy > >> node"? > > [RB ] > > > > Fair enough. I can make that change in the next revision. > > > >> > >> Very nitpicky: In section 4, the step reading "If the Code Field is equal > >> to No Error (0) and the L-bit is clear, set the A-Bit." probably ought to > >> say "otherwise, clear the A-bit." > >> > > [RB ] > > Fair enough. I can make that change in the next revision. > > > >