Subject: [ippm] Murray Kucherawy's Discuss on draft-ietf-ippm-stamp-option-tlv-07: (with DISCUSS and COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Mon, 13 Jul 2020 10:08:38 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-ippm-stamp-option-tlv-07: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 4 says: "Detected error events MUST be logged.  Note that rate of
logging MUST be controlled."

This seems to be incomplete.  Why is it a MUST?  It doesn't seem to have
anything to do with interoperability; if I don't log, nothing breaks.  If it's
MUST for security reasons, other questions arise: Logged where?  What data
specifically needs to be logged?  How long should they be retained?  Do any
privacy concerns arise?  Do the logs need to be protected at rest? etc.

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

I'll open with my usual complaint about having more than five authors, which is
the recommended maximum.

Abstract:

* "... in addition to ones supported by the STAMP base specification." -- I
think you could remove this clause; it's enough to say you're defining
extension(s).

Section 3:

* "An implementation of the STAMP Session-Reflector that supports this
specification SHOULD identify a STAMP Session using the SSID in combination
with elements of the usual 4-tuple for the session." -- Why is this only a
SHOULD?  When might one legitimately deviate from this requirement?

Section 4.3:

* "The Session-Sender SHOULD NOT fill any information fields except for STAMP
TLV Flags, Type, and Length." -- When might I deviate from that advice, as
SHOULD NOT allows?

Section 4.5:

* "The definition of "in-profile packet" is outside the scope of this document
and is left to the test operators to determine." -- This isn't my domain, to be
sure, but I'm curious about what "in-profile" might mean.  Would it be possible
to include an example?

Section 4.6:

* Same question for "access network".

Section 4.8:

* "... excluding when ..." -- suggest instead "excluding the case where"

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 14 Jul 2020 09:10:08 -0700

Hi Murray,
I've reviewed your DISCUSS and the COMMENTS. Please correct me if I
misunderstood it, but comparing with your earlier record in the
datatracker, it appears that you have raised the severity of one of the
COMMENTS to the DISCUSS. Other than that, they are the same as ones I'm
working on addressing. Is my understanding correct?

Regards,
Greg

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 14 Jul 2020 13:25:41 -0700

Hi Greg,

Yes, that's correct, though I added one point supporting the original
comment.  But it's all related.

-MSK