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
