[mile] Adam Roach's Yes on draft-ietf-mile-xmpp-grid-09: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-mile-xmpp-grid-09: Yes

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-mile-xmpp-grid/



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

Thanks for such a well-written and clear document. I particularly liked the
extensive and methodical security analysis. I have two substantive comments
about the mechanism that I'd like to have a conversation about prior to moving
towards publication. I am balloting "yes" in anticipation of coming to an
understanding around these two topics.

---------------------------------------------------------------------------

§6:

>  (The payload in the foregoing example is from [RFC7970]; payloads for
>  additional use cases can be found in [RFC8274].)

This format appears to be only exemplary, rather than a requirement of the
mechanism. At the same time, these formats appear to be oriented toward
automatic processing. The presence of a schema indication in the top-level
element of the report does at least allow distinction between different report
formats, but that doesn't allow software to handle a schema that it doesn't
otherwise understand. How does a subscriber know which topics have schema
that they can handle?

---------------------------------------------------------------------------

§9:

>  Another consideration for deployers is to enable end-to-end
>  encryption to ensure the data is protected from the data layer to
>  data layer and thus protect it from the transport layer.

It's not clear what implementors are expected to do with this recommendation.
Options presumably include RFC 3923, XEP-0380, XEP-0373, XEP-0364, XEP-0027, or
maybe something I'm not aware of. I note that the XEPs I mention are
Historical, Obsolete, Experimental, and Deferred, none of which seem appropriate
for use. And it's my understanding that XMPP implementors are... to put it very
mildly, not enthusiastic about RFC 3923.

If I've missed an appropriate mechanism, please cite it as an example of how the
recommendation can be implemented. If not, please add text indicating that a
means for end-to-end encryption is a matter for future study.