Thank you for the review. I'm happy to hear that the document has improved significantly since 2013.
Still, a number of smaller editorial issues. Authors - have you seen these? Jari On Mar 21, 2014, at 8:04 PM, Elwyn Davies <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-opsawg-oam-overview-14.txt > Reviewer: Elwyn Davies > Review Date: 21 March 2014 > IETF LC End Date: Jan 2013 > IESG Telechat date: 27 March 2014 > > Summary: > Ready with nits and a couple of very minor issues. > I was pleased that this version of the document seems to have been > greatly improved since -08 which I reviewed previously in Jan 2013, and > the scope is now quite clear. Thanks for the work that has been done! > > Major issues: > None. > > Minor issues: > General: I wondered about the wisdom of using more or less mnemonic > tags for the multitude of references but on reflection the mnemonic > value is probably worthwhile. I toyed with the idea of adding the RFC > number next to the reference in the text on first occurrence so that > people don't have to keep skipping off to the references, but in the end > this is probably a silly idea. > > s2.2.9, Discussion: The added complexity of P2MP is called out but > nothing is said about MP2MP, which I think would be even more tricky. > Would it be useful to say something also about MP2MP? [*Are* there any > tools for this case?] > > s4.4.1, para 6: There seems to be possibly a minor contradiction between > the statements: > >> LSP Ping is easily extensible to >> include additional information needed to support new functionality, >> by use of Type-Length-Value (TLV) constructs. > > and > >> The usage of TLVs is >> typically not easy to perform in hardware, and is thus typically >> handled by the control plane. > > What is the implication of adding a new TLV as regards hardware and > performance? Does the second statement mean that either the hardware > will throw away messages with unknown, new TLVs, complain about such > messages or have poor performance? If so, the "easily" in the first > statement is possibly "easily but impractically". A little explanation > is probably needed (or maybe this is just too complex to explain here). > Maybe reducing all this to "LSP Ping is extensible using additional TLVs > but there may be hardware issues (see RFC...)." > > Nits/editorial comments: > General: s/i.e./i.e.,/, s/e.g./e.g.,/ (a couple of missing cases) > > General: It would be helpful to use non-breaking hyphens in MPLS-TP and > all references if possible. > > s1.2, first bullet: s/Standard development/Standards development/ > > s1.3: It would be useful to put a forward reference to the terminology > section 2.1 to cover the various acronyms and abbreviations in Table 1. > > s3, 2nd bullet: s/also allows to detect/also allows detection of/ It > might also be appropriate to be a bit less definite about localization - > add in 'attempts' or 'tries' maybe? > > s3, Delay Measurement: Maybe mention 'jitter' as an alternative for > delay variation. > > s4.3.3, 2nd bullet: s/a failure is detected/a failure is reported/ > > s4.3.3, last para: s/i.e. no failures are detected,/i.e., when no > failures have been detected,/ > > s4.3.3, last para: "...negotiated transmission time" Do you mean > "transmission rate" as mentioned in the previous para? If not it might > be good to make it clear that this isn't a typo. > > s4.4.1, para 4 (after 2nd bullet): s/and also Maximum Transmission Unit > (MTU) problems/and also identify Maximum Transmission Unit (MTU) > problems/ > > s4.4.1, para 5: s/the MPLS faults/MPLS faults/ > > s4.5.1, 2nd bullet: >> and there is a need to >> differentiate OAM packets from data plane ones. > This is slightly confusing - the congruence requirement makes all the > packets (OAM and user) to be data plane packets. How about: > >> and there is a need to >> differentiate OAM packets from ordinary user packets in the data plane. > > > s4.5.1, Maintencance Intermediate Point section: >> A MIP in MPLS-TP identifies OAM packets destined >> to it by the value of the TTL field in the OAM packet. > This is not terribly helpful: Either a reference to where to find out > what TTL value is needed or some explanation of the required value would > be a good idea. > > s4.5.1, Up and Down MEPs: > The term "bridge interface" is IEEE/MPLS-TP jargon and needs defining. > Might be also worth a note that, unlike prior usage of up/down, this has > nothing to do with defects (or layabout parliamentarians in > Brussels). ;-) > > s4.5.3: Please add a reference for PWE3 ACH and VCCV and a pointer to a > document where "PW control word" is defined (preferably with section > numbers. > > s4.5.4.6: s/if there a return path exists/if a return path exists/ > > s4.7.3, last para: s/Server accepts the modes./Server accepts the mode./ > > s4.7.3, last para: I think there is a bit of interaction missing: (i) > server tells Session-sender to start sending; (ii) if Control-client > stops the session, it tells server and server tells Session-sender; > (iii) when session is finished Session-sender reports to Server which > recovers data from Session-receiver (or controls Fetch client?) > > s5.1, Traceroute: Should this mention the Paris traceroute? > > s5.1, OWAMP/TWAMP: For consistency should probably reference RFCs. > > s5.3: s/in as much accuracy/with as much accuracy/ > > > > > > > > > > > > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
