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

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Thank you for the comments Adam, please see further below:

On 1/22/19, 19:25, "Adam Roach" <[e-mail]> wrote:

    Adam Roach has entered the following ballot position for
    draft-ietf-mile-xmpp-grid-09: Yes
    
    ----------------------------------------------------------------------
    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?
[NCW] In the implementations (of subscribers) we have seen, they typically are looking for
Schemas they already understand.  That is, when it does the capability discovery, it is looking to match namespaces it knows about and ignores the ones it doesn't.
    
    §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.
        [NCW] Thanks for pointing this out. We added the following sentence in Section 9 -
        The means to achieve end-to-end encryption is beyond the scope of this document.