Hi Greg, Thanks for addressing my comments quickly. Your proposed changes sound good to me.
Cheers Suresh On 10/21/2015 04:38 PM, Gregory Mirsky wrote: > Hi Suresh, > thank you for the most careful review and very helpful comments. Please find > my answers in-line and tagged by GIM>>. > > Regards, > Greg > > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krish...@ericsson.com] > Sent: Tuesday, October 20, 2015 8:13 PM > To: draft-ietf-ippm-type-p-monitor....@ietf.org; General Area Review Team > Subject: Gen-ART Telechat review of draft-ietf-ippm-type-p-monitor-02.txt > > 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-ippm-type-p-monitor-02.txt > Reviewer: Suresh Krishnan > Review Date: 2015/10/20 > IESG Telechat date: 2015/10/22 > > Summary: The draft is almost ready for publication as a Proposed Standard but > I do have some comments that you may wish to address. > > Minor > ===== > > * MBZ is not expanded. I understand this should expand to "Must Be Zero" and > it MUST be set to zero by senders and MUST be ignored by receivers. It makes > sense to add this to the terminology section or before first use. > GIM>> MBZ is used only in figures that reflect updates to formats defined in > RFC 5357. None of fields defined in RFC 5357 referenced in this proposal and > their identification in the figures is the same as in RFC 5357. I think it > may be confusing to those familiar with RFC 5357 to see "Must Be Zero" > instead of MBZ in figures. > > * Please cite as references RFC2474 for the DSCP field and RFC3168 for ECN. > GIM>> Thank you, will add references and send diff for review. > > * Section 2.2.1: > > "the first six bits of the Differentiated Service field" > > Not sure if this "first" qualification is required as RFC2474 defines the > DSCP field to be *exactly* 6 bits long. I have a similar issue with the word > "following" in the definition of the ECN field as they are two separate > fields. > GIM>> Al suggested re-wording that, in my view, makes it clear and > unambiguous: > o the six (least-significant) bits of the Differentiated Service > field MUST be copied from received Session-Sender test packet into > Sender DSCP (S-DSCP) field; > > * Section 2.2.2: Figure 4 seems to be incomplete and it has no mention of > either DSCP or ECN. Is this correct? Probably would also explain where the 28 > byte padding requirement comes from. > GIM>> Figure 4 reflects impact of DSCP and ECM Monitoring on test packet > transmitted by a Session-Sender that supports RFC 6038. RFC 6038 states that > in order to support Symmetrical Size and/or Reflects Octets modes > Session-Sender must append at least 27 octet-long Packet Padding. Because the > DSCP and ECM Monitoring extension requires Session-Reflector to copy > additional octet, the minimal size of Packet Padding to support RFC 6038 must > be 28 octets. > > Editorial > ========= > > * Section 2.2.1 > > s/MUST extracts/MUST extract/ > GIM>> Done. > > Thanks > Suresh > > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
