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

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Mon, 13 Jul 2020 00:54:41 -0700

Murray Kucherawy 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:
----------------------------------------------------------------------

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:

* "Detected error events MUST be logged.  Note that rate of logging MUST be
controlled." -- This seems to be incomplete.  Logged where?  If you're going to
make this mandatory, shouldn't you discuss log retention requirements, details
of what's to be logged, logging security, and things of that nature?

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: Mon, 13 Jul 2020 19:42:15 -0700

Hi Murray,
thank you for your review and comments. I hope it would be acceptable to
address in this thread comments listed below and work on the DISCUSS in the
other thread.
Please find my answers and notes below tagged GIM>>.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/
GIM>> Agreed and removed.

> SHOULD?  When might one legitimately deviate from this requirement?
GIM>> I agree that it reads strangely. The main reason for SHOULD was that
an implementor might choose to support only TLVs, not SSID (too weird?).
Such implementation, in regard to SSID, will be indistinguishable from the
base STAMP as defined in RFC 8762. And the document explains the
interworking between the Session-Sender that uses SSID and the
Session-Reflector that is not. But if you don't see such case worthy of
consideration, will be glad to s/SHOULD/MUST/.

> of what's to be logged, logging security, and things of that nature?
GIM>> Yes, it is definitely an overkilling requirement. Would the following
text change be acceptable:
OLD TEXT:
   Detected error events MUST be logged.  Note that rate of logging MUST
   be controlled.
NEW TEXT:
   An operator MUST be notified of the error.  Detected error events MAY
   be logged.  Note that the rate of logging MUST be controlled.

> TLV Flags, Type, and Length." -- When might I deviate from that advice, as
GIM>> I agree, there is no exception. Hence s/SHOULD NOT/MUST NOT/. Also,
I've noticed similar use of the normative language in Section 4.2. The
proposed change is applied to that section as well.

> sure, but I'm curious about what "in-profile" might mean.  Would it be
GIM>> Usually, "in-profile" is another way to say "data flow". The
"in-profile" term is used, for example, in CFM/Y.1731 specification that
supports the ETH-DM. These specifications describe in detail which OAM
packets are considered "in-profile" and which must not be accounted for.
Perhaps establishing the equivalency between in-profile and data flow in
the first sentence be useful:
NEW TEXT:
   The Direct Measurement TLV enables collection of the number of in-
   profile packets, i.e., packets that form a specific data flow, that
   had been transmitted and received by the Session-Sender and Session-
   Reflector, respectively.

> * Same question for "access network".
GIM>> This reflects 3GPP's view of networking. The access network is a
network outside the 5G Core Network. From the 3GPP PoV it could be Non-3GPP
access, e.g., fixed broadband network, WiFi, or DOCSIS, or 3GPP, e.g., 5G
New Radio.

> * "... excluding when ..." -- suggest instead "excluding the case where"
GIM>> Thank you. Done.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 13 Jul 2020 20:23:26 -0700

> Please find my answers and notes below tagged GIM>>.

Sure.

> consideration, will be glad to s/SHOULD/MUST/.

I don't have much of an opinion on "too weird".  I find that use of
SHOULD/SHOULD NOT is often made more effective by presenting an example of
reasoning why one would choose not to do what it says.  Absent any such
guidance, or a description of what you give up if you don't comply, it
starts to feel like a MAY, because it doesn't seem to actually matter.  Or
in the alternative, as you said below on another point, it actually
shouldn't be a choice, so it deserves elevation to MUST.

> GIM>> Yes, it is definitely an overkilling requirement. Would the
> following text change be acceptable:
> OLD TEXT:

Compliance language is used to indicate key implementation points, where
interoperability among independent implementations is a concern or critical
security matters come into play.  I can't make out which of those is going
on here.  It doesn't seem to be either one.  For example: If I don't notify
the operator of the error, what breaks?  Or is this actually an API issue?
And why is the logging rate worth bringing up with a MUST?  Isn't that
really a local matter?  Also: MUST be notified, but how?

>    had been transmitted and received by the Session-Sender and Session-

That's much more helpful, yes.

Thanks!

-MSK

---

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

Hi Murray,
thank you for clarifications, most helpful. Please find my new notes below
under GIM2>> tag, Attached, please find the diff to the working version
that highlights all applied updates. I hope that I am making progress in
addressing your comments.

Regards,
Greg

On Mon, Jul 13, 2020 at 8:23 PM Murray S. Kucherawy <[email-masked]>
wrote:

>> GIM>> I agree that it reads strangely. The main reason for SHOULD was
>> that an implementor might choose to support only TLVs, not SSID (too
>> weird?). Such implementation, in regard to SSID, will be indistinguishable
>> from the base STAMP as defined in RFC 8762. And the document explains the
GIM2>> Changed to MUST

> really a local matter?  Also: MUST be notified, but how?
GIM2>> I see your point now. I agree that this is an internal behavior.
Will leave it to an implementor's choice and remove the text related to
logging from the document altogether.