[ippm] Alvaro Retana's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)

[Alvaro Retana via Datatracker <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-ippm-rfc8321bis-02: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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

§7 ("Results of the Alternate Marking Experiment") makes several
recommendations about the use of one or two flag bits:

      One flag: packet loss measurement SHOULD be done as described in
      Section 3.1, while delay measurement MAY be done according to the
      single-marking method described in Section 3.2.1.  Mean delay
      (Section 3.2.1.1) is NOT RECOMMENDED since it implies more
      computational load.

      Two flags: packet loss measurement SHOULD be done as described in
      Section 3.1, while delay measurement SHOULD be done according to
      double-marking method Section 3.2.2.  In this case single-marking
      MAY also be used in combination with double-marking and the two
      approaches provide slightly different pieces of information that
      can be combined to have a more robust data set.

These recommendations are good, as they are the result of experimentation.
However, they don't provide any deployment or operational guidelines of when
is it ok to follow them and when it isn't.  For example, for the one flag case,
when it is ok to not measure packet loss as described in §3.1?  Why is the use
of that mechanism only recommended and not required?

I have the same questions for all the recommendations and optional indications
in the text above.  To clear this DISCUSS I expect deployment or operational
recommendations that can be used as implementation/deployment guidance.


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

(1) I support Roman's DISCUSS position, and have a related question to this
text in §7.1 (Controlled Domain requirement):

   For security reasons, the Alternate Marking Method is RECOMMENDED
   only for controlled domains.

When is it ok to use the Alternate Marking Method in any other deployment? 
IOW, given the definition of a controlled domain earlier in this section, why
is its use only recommended and not required?

[I am not including this point as a DISCUSS because I expect it to be solved
when Roman's concern is addressed.]

(2) §7 says that a deployment "SHOULD also take into account how to handle and
recognize marked and unmarked traffic".   I don't see any interoperability need
to use an rfc2199 keyword.  IOW, s/SHOULD/should