[hpke] Mohamed Boucadair's Block on charter-ietf-hpke-00-01: (with BLOCK and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
charter-ietf-hpke-00-01: Block

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.)



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



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

Hi all,

I have some meta question that I'd like to discuss first as I lack background.

# Other CFRG Specs

The following is indicated as the main motivation for this "upgrade":

CURRENT:
  Informational document on the IRTF stream, however, has caused some confusion
  as to its usability, especially with other standards organizations

Picking randomly other specifications produced by CFRG (e.g.,
https://datatracker.ietf.org/doc/rfc7748/referencedby/) that spec is
normatively cited by many RFCs/etc. RFC7748 is cited normatively by SDOs such
as 3GPP in TS 33.501.

Why the status confusion is a concern for the HPKE and it isn't for other CFRG
RFCs? Also, what are the other SDOs for which this is posing problem? Did we
explained the operation mode of CFRG to those SDOs?

Based on which criteria we will be deciding in the future that is OK to "leave"
an CFRG RFC as informational while another is worth to be stamped with IETF PS?

# CFRG Coordination?

Do we foresee any? or we think that interested participants will be part if
HPKE?

At least for an outsider, this looks strange that we are touching an CFRG spec
but not explicitly mentioning how we plan to handle that.


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

# Shared experience, installed base, and operational considerations

CURRENT:
   with targeted changes based on experience with its use

and

CURRENT:
  is not widely used

Do we intend to seek for that "experience with it use" or we do already have a
list of candidate items?

For item that the WG may "decide to remove functionality", are we also planning
to include some operational guidance (migration, etc.).

I see that the charter includes the following as a means to minimize the impact
on existing deployments. I would prefer if we highlight that motivation here,
not artificially imposing a means that may be influenced by other charter items
(e.g., adjust "based on experience with its use").

CURRENT:
  The Standards Track and Informational versions must have identical behavior
  for any functionality that they both specify.

# More Ops matters

Are there plans to also look at means to ease/help troubleshooting and
diagnostic when such schemes are used?

# Specification Simplification/Split

Does the WG intends/excludes that the test vectors will be offloaded and be
handled separately from the base spec?

# nits

##

CURRENT:
  TLS Encrypted ClientHello [draft-ietf-tls-esni]

Not sure it is useful to have draft references in a charter.

##

OLD:  And there are currently no
NEW:  Also, there are currently no

## Redundant with milestones

CURRENT:
  Deliverables:
   1. HPKE specification to the IESG as Proposed Standard (yesterday)
   2. New post-quantum and post-quantum/traditional hybrid cipher suites for
   HPKE to the IESG as Proposed Standard (the day before that)

I suggest to remove those.