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

From: Erik Kline via Datatracker <[email-masked]>
Date: Mon, 13 Jul 2020 23:25:34 -0700

Erik Kline 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:
----------------------------------------------------------------------

[ general ]

* Please clarify whether the Length is in network byte order or not for all
  multibyte fields.  A single statement, perhaps around 2.0 or something,
  declaring the convention would suffice (assuming all multibyte integers
  share the same encoding).

* Should there be an IANA registry for the access ID field as well?

[ sections 4.2,4.3 ]

* I think the L-bit error case guidance may not conform to the guidance
  in section 4(.0)?  Specifically, 4(.0) says if the Length field is funky
  the copy the rest of the packet into the reponse and set L=1 (yes?).
  Whereas, 4.2,3 says it MUST zero out the fields (rather than just copy
  the remainder of the packet).  I may have misunderstood something,
  though.

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

[ section 4 ]

* "that vendor's the" -> "that vendor's"

[ section 4.2 ]

* I know links with EUI64 addresses ("8 byte MACs") aren't especially
  popular but is some affordance for other link-layer identifiers
  desirable?

  Since it's a value chosen by the source I don't suppose it really
  matters all that much...

[ section 4.3 ]

* Add definitions or references for T2 and T3?

[ section 4.5 ]

* Under what conditions might R_RxC != R_TxC?  Does R_TxC factor in ICMP
  errors received that might be attributable to responses sent in this
  session?

[ section 4.8 ]

* I assume that the A bit setting by the reflector is the same behaviour
  if the HAMC should appear anywhere other than the last TLV?  If so,
  perhaps a brief clarifying statement.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 14 Jul 2020 19:24:31 -0700

Hi Erik,
thank you for your review, questions, and comments. Please find my answers
and notes in-lined below under the GIM>> tag.

Regards,
Greg

> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-option-tlv/
GIM>> Would the following new text in Section 4 be acceptable:
NEW TEXT:
   All multibyte fields in the defined in this specification TLVs are
   in network byte order.

> * Should there be an IANA registry for the access ID field as well?
GIM>> 3GPP defines the values for PMF's access ID in TS23501. From 3GPP
POV, there are only two types of access networks - 3GPP and Non-3GPP.

>   the remainder of the packet).  I may have misunderstood something,
GIM>> I agree that text in 4.2 and 4.3 is unnecessary. I propose the
following change in the text:
Section 4.2
OLD TEXT
   If the Length field's value is invalid, the Session-
   Reflector MUST zero all fields and MUST NOT return any information to
   the Session-Sender.  The Session-Reflector MUST ignore all other
   fields of the received Location TLV.
NEW TEXT:
   If the Length field's value is invalid, the Session-
   Reflector follows the procedure defined in Section 4 for a malformed
   TLV.
and in Section 4.3
OLD TEXT:
   If the value of the Length field is invalid, the
   Session-Reflector MUST zero all fields and MUST NOT return any
   information to the Session-Sender.
NEW TEXT:
   If the Length field's value is invalid, the Session-
   Reflector follows the procedure defined in Section 4 for a malformed
   TLV.

GIM>> Thank you. Done.

>   Since it's a value chosen by the source I don't suppose it really
GIM>> Information in Location TLV is filled by the Session-Reflector from
the received test packet. The Source MAC field reflects the penultimate to
the Session-Reflector Layer 2 node. Eric Vinke pointed out that IEEE
802.15.4 uses 16 or 64-bit addresses. I think that it is unlikely that
STAMP will be used in networks based on IEEE 802.15.4. But, AFAIK, EUI-64
is the method to auto-configure host by transforming its 48-bit-long MAC
into IPv6 address. Here's one of the explanations I've found:
EUI-64 (Extended Unique Identifier) is a method we can use to automatically
configure IPv6 host addresses. An IPv6 device will use the MAC address of
its interface to generate a unique 64-bit interface ID. However, a MAC
address is 48 bit and the interface ID is 64 bit.

> * Add definitions or references for T2 and T3?
GIM>> Are you referring to Table 2 and Table 3? Could you please clarify or
give an example of a kind of update you expect?

>   errors received that might be attributable to responses sent in this
GIM>> Direct loss measurement enable uni-directional measurements. Thus,
the Session-Sender can calculate packet loss in the forward direction
(far-end packet loss) by S_TxC - R_RxC. The packet loss in the reverse
direction (near-end packet loss) R_TxC - S_RxC (taken when the reflected
packet is received). Packet considered as "in-profile" may include ICMP and
other OAM packets.

>   perhaps a brief clarifying statement.
GIM>>  Yes, you are correct. I propose the following update:
   The HMAC TLV MUST follow all
   TLVs included in a STAMP test packet, except for the Extra Padding
   TLV.  If the HMAC TLV appears in any other position in a STAMP
   extended test packet, then the situation MUST be processed as HMAC
   verification failure, as defined in this section, further below.
Does it make it clearer?