Subject: [ippm] Alvaro Retana's No Objection on draft-ietf-ippm-stamp-option-tlv-07: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Tue, 14 Jul 2020 12:47:30 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-ippm-stamp-option-tlv-07: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Figures 1 and 2 are labeled "an example" -- but they are not examples.

(2) §3: "If the test session is not stopped, the Session-Sender, can, for
example, send a base STAMP packet [RFC8762]."  Just to make sure I understand:
if the Session-Reflector doesn't support this specification, then a packet with
or without an SSID will look the same to them, right?  If so, then there's no
need for the Session-Sender to change its packets -- may be worth a mention.

(3) §4: "the TLV is malformed, i.e., the Length field value of the fixed-size
TLV is not equal to the value defined for the particular type".  The Length can
also be incorrect for variable-size TLVs -- so perhaps change to "the TLV is
malformed, i.e., the Length field value is not valid for the particular type"

(4) §4: "MUST try to process"  "Do or do not. There is no try." - Yoda. ;-) 
Seriously...consider deleting this sentence as skipping the TLV should already
result in processing the next one, if present.

(5) The Reference column in tables 1/4/6/8 mixes references and assignment
policies.  The whole registry should reference this document...so the column
should really point at the assignment policies.

(6) Table 2: The new registry is being defined in this document, so you can go
ahead and assign values -- no need to wait for IANA.

(7) Nits:

s/SSID/the SSID/g

s/vendor's the Structure/vendor's Structure

s/extend STAMP/extend the STAMP

s/is Extra/is the Extra

s/one-octet-long Type field, and two-octet-long/a one-octet-long Type field,
and a two-octet-long

s/equals length/equals the length

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 15 Jul 2020 14:07:52 -0700

Hi Alvaro,
thank you for your review, question, and suggestions to improve the
document. Please find my answers below under the GIM>> tag.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/
GIM>> Removed "An example" in the caption to both figures.

> need for the Session-Sender to change its packets -- may be worth a
GIM>>  Would the update below be acceptable:
OLD TEXT:
   If the test session is not stopped,
   the Session-Sender, can, for example, send a base STAMP packet
   [RFC8762].
NEW TEXT:
   If the test session is not stopped,
   the Session-Sender, can, for example, send a base STAMP packet
   [RFC8762] or continue transmitting STAMP test packets with the SSID.

> malformed, i.e., the Length field value is not valid for the particular
GIM>> Thank you for the suggestion. Accepted.

> result in processing the next one, if present.
GIM>> Indeed, there is no medal for trying but only for winning.
There are two places the have "MUSTtry to process". Deleting the
sentence in the first case is simple as the preceding requires to skip
unknown TLV. The second sentence probably better to be re-worked:
OLD TEXT:
      The Session-Reflector MUST try to process the next TLV in
      the extended STAMP packet.
NEW TEXT:
      The Session-Reflector MUST skip the processing of the
      unrecognized TLV.
Would this change be acceptable?

> should really point at the assignment policies.
GIM>> Could the allocation policies be in the informative text prior to the
table, e.g., Table 1:
   All code
   points in the range 1 through 175 in this registry shall be allocated
   according to the "IETF Review" procedure as specified in [RFC8126].
   Code points in the range 176 through 239 in this registry shall be
   allocated according to the "First Come First Served" procedure as
   specified in [RFC8126].
Then the Reference column points to "This document" in all rows?

> ahead and assign values -- no need to wait for IANA.
GIM>> We discussed that with groups that are prototyping, and we're told
that that makes no difference for them.

> GIM>> Yes to all nits and many thanks for your help.

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 16 Jul 2020 08:09:10 -0700

Greg:

Hi!

I’m fine with all your answers.

With respect to the tables in the IANA section, I prefer to have the
policies in the table since that makes it clearer (at least to me).  But as
long as IANA is happy with the content and the actions I have no problem
with your proposal. :-)

Thanks!!

Alvaro.

On July 15, 2020 at 5:08:05 PM, Greg Mirsky ([email-masked]) wrote:

Hi Alvaro,

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 16 Jul 2020 08:40:30 -0700

Hi Alvaro,
thank you for your quick response and kind consideration of the proposed
updates. All are in the working version and will upload ones the gate opens.

Regards,
Greg

On Thu, Jul 16, 2020 at 8:09 AM Alvaro Retana <[email-masked]>
wrote:

> GIM>> Could the allocation policies be in the informative text prior to
> the table, e.g., Table 1:
>    All code