Re: [mile] Feedback on draft-ietf-mile-xmpp-grid-09

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

 Hi Florian,

As we (the authors) are still addressing IESG comments, we are welcoming yours as well.

Thank you for the review!  Please see further comments below:



On 1/24/19, 8:45 AM, "Florian Schmaus" <[e-mail]> wrote:



    I know I am late to the party, probably too late, but I had the chance

    to take at least a short look at the I-D (which has been on my TODO list

    for months). Here are my remarks with my XMPP goggles on, I hope they

    are still helpful.



    Section 6: The first reference should point to XEP-0060 not XEP-0030.

[NCW] Thanks for catching that. We will fix this in the next revision of the document.





    XMPP-Grid uses XEP-0060 (and XEP-0030) at its core. There are two size

    limitations you may want to consider:

    1. XEP-0060, unfortunately, does not specify a maximum PubSub node name

    length. If your XMPP-Grid use case allows it, then you may want to

    specify a maximum node name size. If you do so, then implementations

    claiming compatibility with XMPP-Grid are required to support this

    maximum node name size. I believe this would improve interoperability.

[NCW] XMPP-Grid uses the XMPP XEPs and IODEF  as they are defined. Neither one imposes a maximum node name; as the topics shared may vary in size (which IODEF also does not limit), I am not sure we can impose one here as that would limit IODEF as well.  Perhaps it is something we can raise to the IODEF community as well.



    2. Requesting all topics using XEP-0030 could potentially return a huge

    result set. It could become so large, that it exceeds the maximum stanza

    size limit of an involved party. In XMPP we have XEP-0059 "Result Set

    Management" to split (large) result sets into smaller ones.

    Unfortunately using XEP-0030 with XEP-0059 is underspecified (AFAIKT).

    Nevertheless, if you anticipate a large number of topics, then you may

    want to hint towards the problematic and XEP-0059 as a potential solution.

[NCW] In general, consumers that we run across have a small limited number of

topics of interest (especially in the threat/security sharing domain). But you raise a good point.

We will add the  following sentence in the document -

Implementations should take caution if their deployments allow for a large number of topics.

The Result Set Management as defined in XEP-0059, SHOULD be used to

allow the requesting entity to explicitly request Service Discovery result sets to be returned

in pages or limited size if the discovery results are larger in size.



    XEP-0059 is also the XMPP-ish mitigation against the type of resource

    exhaustion attacks mentioned in § 8.3.5. Referencing XEP-0059 in this

    section appears sensible.

  [NCW] Good suggestion. We will add the following sentence in the document -

Platforms could use <xref target='XEP-0059'/> to restrict the size of the result sets the

Controller returns in search or subscription results or topics' service discovery.



    As others already pointed out, I also wondered why the I-D requires

    exclusive usage of SASL EXTERNAL and SASL SCRAM, as opposed to making

    those two only MTI. Changing one "MUST" into a weaker keyword probably

    fixes that.



    If SCRAM-SHA1 is MTI (+1), then shouldn't RFC 5802 be a normative

    reference and not an informative one?

[NCW] That is a fair point.  The intent is to achieve interoperability, so it should be MTI; we will change it to implementations MUST support at least one of the two.



    Best wishes

     Florian