Re: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

I will attempt to answer each substantive comment in a separate email,
as I want to show the work in the form of a diff, and it will be too
confusing to do it all at once.  The tinyurl that I posted for
Eric should remain valid as a cumulative diff as I push stuff to github, as
rfcdiff will calculate again each time.

Roman Danyliw via Datatracker <[e-mail]> wrote:
    > I support Eric’s Discuss position. Also a big thanks to Christian
    > Huitema’s thorough SECDIR reviews and the associated improvements made
    > as a result.  I have a few more items:

Could you specifically comment on Eric's comment about domainID being
a SHA-1 Hash of the PublicKeyInfo

    > (1) Section 5.7.  The format of a pledge status telemetry message seems
    > underspecified.

Fair enough.
In the interop testing that has occured online and in-person since November,
we have actually not gotten to this point yet.

    > ** what are all of the fields (e.g., version appears in the example but
    > no the text)

added version and text about how a registrar should behave when it sees a
version larger than it understands.

    > ** what are the field formats (e.g., the format of the status field is
    > inferred from the unlabeled example

    > ** which fields are mandatory?

    > ** Per the JSON snippet, is that normative is some way in describing
    > the format?

    > ** Also, how does a server receiving the telemetry messages behave when
    > receiving unexpected JSON attributes?

I have made these changes:
https://github.com/anima-wg/anima-bootstrap/commit/dd17db4f1c39b2332e6f49877a0a0fccd1dd5a6f

diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml
index 610150d..9aa2a2a 100644
--- a/dtbootstrap-anima-keyinfra.xml
+++ b/dtbootstrap-anima-keyinfra.xml
@@ -2101,41 +2101,69 @@ locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]></artwork>
         status.</t>

         <t>To indicate pledge status regarding the voucher, the pledge
-        MUST post a status message.</t>
+        MUST post a status message to the Registrar.</t>

         <t>The posted data media type: application/json</t>

         <t>The client HTTP POSTs the following to the server at the EST well
-        known URI "/voucher_status". The Status field indicates if the voucher
-        was acceptable. If it was not acceptable the Reason string indicates
-        why. In the failure case this message may be sent to an
-        unauthenticated, potentially malicious registrar and therefore the
-        Reason string SHOULD NOT provide information beneficial to an
-        attacker. The operational benefit of this telemetry information is
-        balanced against the operational costs of not recording that an
-        voucher was ignored by a client the registrar expected to continue
-        joining the domain.</t>
+        known URI "/voucher_status".</t>
+
+        <t>
+          The format and semantics described below are for version 1.
+          A version field is included to permit significant changes to this
+          feedback in the future.  A Registrar that receives a status
+          message with a version larger than it knows about SHOULD log the
+          contents and alert a human.
+        </t>
+
+        <t>The Status field indicates if the voucher was acceptable.
+        Boolean values are acceptable.
+        </t>
+
+        <t>
+          If the voucher was not acceptable the Reason string indicates
+          why. In the failure case this message may be sent to an
+          unauthenticated, potentially malicious registrar and therefore the
+          Reason string SHOULD NOT provide information beneficial to an
+          attacker. The operational benefit of this telemetry information is
+          balanced against the operational costs of not recording that an
+          voucher was ignored by a client the registrar expected to continue
+          joining the domain.
+        </t>

-        <t><figure>
-            <artwork><![CDATA[{
-  "version":"1",
-  "Status":FALSE /* TRUE=Success, FALSE=Fail"
-  "Reason":"Informative human readable message"
-  "reason-context": { additional JSON }
-}]]></artwork>
-          </figure>The server SHOULD respond with an HTTP 200 but MAY simply
-        fail with an HTTP 404 error. The client ignores any response. Within
-        the server logs the server SHOULD capture this telemetry
-        information.</t>
         <t>
           The reason-context attribute is an arbitrary JSON object (literal
           value or hash of values) which provides additional information
           specific to this pledge.  The contents of this field are not
           subject to standardization.
         </t>
+
+        <t>
+          The version, and status fields MUST be present.
+          The Reason field SHOULD be present whenever the status field
+          is negative.  The Reason-Context field is optional.
+        </t>
+        <t>
+          The keys to this JSON hash are case-insensitive.
+        </t>
+
+        <t><figure>
+            <artwork><![CDATA[{
+  "version":"1",
+  "status":FALSE /* TRUE=Success, FALSE=Fail"
+  "reason":"Informative human readable message"
+  "reason-context": { additional JSON }
+}]]></artwork>
+          </figure>
+          The server SHOULD respond with an HTTP 200 but MAY simply
+          fail with an HTTP 404 error. The client ignores any response. Within
+          the server logs the server SHOULD capture this telemetry
+          information.
+        </t>
         <t>
           Additional standard JSON fields in this POST MAY be added, see
-          <xref target="pledgestatustelemetryregistry" />.
+          <xref target="pledgestatustelemetryregistry" />.  A server that
+          sees unknown fields should log them, but otherwise ignore them.
         </t>
       </section>


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-