Script updating archive at 2024-12-03T01:18:40Z. [ci skip]

archive.json

@@ -1,6 +1,6 @@
 {
   "magic": "E!vIA5L86J2I",
-  "timestamp": "2024-12-01T01:28:06.109641+00:00",
+  "timestamp": "2024-12-03T01:17:54.798014+00:00",
   "repo": "ietf-wg-ppm/draft-ietf-ppm-dap",
   "labels": [
     {
@@ -157,6 +157,11 @@
       "name": "interim-2024-10-24",
       "description": "",
       "color": "FD7F89"
+    },
+    {
+      "name": "draft-14",
+      "description": "",
+      "color": "879C68"
     }
   ],
   "issues": [
@@ -78061,10 +78066,13 @@
       "author": "branlwyd",
       "authorAssociation": "COLLABORATOR",
       "assignees": [],
-      "labels": [],
+      "labels": [
+        "bug",
+        "draft-14"
+      ],
       "body": "Specifically:\r\n * Settle on 202 Accepted for the Helper's response code to aggregation continuation requests. Previously, the Leader Continuation section suggested 202 Accepted while the Helper Continuation section suggested 200 OK. Either code is fine by me, but we need to make the specification consistent.\r\n * Add maximum-value indicators to the aggregation & collection status messages. This is an editorial change: indicating the maximum value is optional per RFC 8446's presentation language, but doing so makes the specification clearer & is consistent with all other enumerated values defined in the specification.",
       "createdAt": "2024-11-27T00:11:27Z",
-      "updatedAt": "2024-11-27T00:11:44Z",
+      "updatedAt": "2024-12-02T22:41:36Z",
       "baseRepository": "ietf-wg-ppm/draft-ietf-ppm-dap",
       "baseRefName": "main",
       "baseRefOid": "f4cb8ea45d1e824eac29fc866c960a9cdcd91320",
@@ -78076,7 +78084,121 @@
       "mergedBy": null,
       "mergeCommit": null,
       "comments": [],
-      "reviews": []
+      "reviews": [
+        {
+          "id": "PRR_kwDOFEJYQs6TTv3i",
+          "commit": {
+            "abbreviatedOid": "4c5e09a"
+          },
+          "author": "tgeoghegan",
+          "authorAssociation": "COLLABORATOR",
+          "state": "APPROVED",
+          "body": "",
+          "createdAt": "2024-12-01T13:43:37Z",
+          "updatedAt": "2024-12-01T13:43:37Z",
+          "comments": []
+        },
+        {
+          "id": "PRR_kwDOFEJYQs6Tb9cT",
+          "commit": {
+            "abbreviatedOid": "4c5e09a"
+          },
+          "author": "cjpatton",
+          "authorAssociation": "COLLABORATOR",
+          "state": "APPROVED",
+          "body": "",
+          "createdAt": "2024-12-02T18:42:12Z",
+          "updatedAt": "2024-12-02T18:42:16Z",
+          "comments": [
+            {
+              "originalPosition": 15,
+              "body": "This looks like a bug fix. What do you want to do for interop? Should we cut a new draft so folks can implement this? Or are we OK with implementing 200 OK here?",
+              "createdAt": "2024-12-02T18:42:12Z",
+              "updatedAt": "2024-12-02T18:42:16Z"
+            }
+          ]
+        },
+        {
+          "id": "PRR_kwDOFEJYQs6Tdtkx",
+          "commit": {
+            "abbreviatedOid": "4c5e09a"
+          },
+          "author": "branlwyd",
+          "authorAssociation": "COLLABORATOR",
+          "state": "COMMENTED",
+          "body": "",
+          "createdAt": "2024-12-02T22:05:40Z",
+          "updatedAt": "2024-12-02T22:05:40Z",
+          "comments": [
+            {
+              "originalPosition": 15,
+              "body": "This is indeed a bugfix (or, well, it resolves an ambiguity in the spec).\r\n\r\nI think we should eventually cut a bugfix draft w/ this and any other small fixes we find during implementation. For DAP-13 interop testing we can handshake on the appropriate status; this PR switches to 202 everywhere, and that's what I'm currently implementing in Janus, but I don't have a strong opinion either way on the correct status to use -- I'd be happy enough with just about anything as long as we're consistent.",
+              "createdAt": "2024-12-02T22:05:40Z",
+              "updatedAt": "2024-12-02T22:05:40Z"
+            }
+          ]
+        },
+        {
+          "id": "PRR_kwDOFEJYQs6TdyZz",
+          "commit": {
+            "abbreviatedOid": "4c5e09a"
+          },
+          "author": "cjpatton",
+          "authorAssociation": "COLLABORATOR",
+          "state": "COMMENTED",
+          "body": "",
+          "createdAt": "2024-12-02T22:20:16Z",
+          "updatedAt": "2024-12-02T22:20:16Z",
+          "comments": [
+            {
+              "originalPosition": 15,
+              "body": "It would be nice to avoid cutting a draft if we can avoid it. If you think the intent is clear enough, then I think we should treat this as non-breaking. My suggestion would be to merge, update the change log, cut a draft, and inform the mailing list.",
+              "createdAt": "2024-12-02T22:20:16Z",
+              "updatedAt": "2024-12-02T22:20:16Z"
+            }
+          ]
+        },
+        {
+          "id": "PRR_kwDOFEJYQs6Tdyqv",
+          "commit": {
+            "abbreviatedOid": "4c5e09a"
+          },
+          "author": "cjpatton",
+          "authorAssociation": "COLLABORATOR",
+          "state": "COMMENTED",
+          "body": "",
+          "createdAt": "2024-12-02T22:21:06Z",
+          "updatedAt": "2024-12-02T22:21:06Z",
+          "comments": [
+            {
+              "originalPosition": 15,
+              "body": "We could also wait to see if more changes are needed after we've all wrapped up our implementations. I don't think we've caught any bugs in daphne yet.",
+              "createdAt": "2024-12-02T22:21:06Z",
+              "updatedAt": "2024-12-02T22:21:07Z"
+            }
+          ]
+        },
+        {
+          "id": "PRR_kwDOFEJYQs6Td65_",
+          "commit": {
+            "abbreviatedOid": "4c5e09a"
+          },
+          "author": "branlwyd",
+          "authorAssociation": "COLLABORATOR",
+          "state": "COMMENTED",
+          "body": "",
+          "createdAt": "2024-12-02T22:39:50Z",
+          "updatedAt": "2024-12-02T22:39:50Z",
+          "comments": [
+            {
+              "originalPosition": 15,
+              "body": "IMO, let's wait until we think our implementations are finished. Then we'll be in a better position to decide if we need to cut a new draft or just inform folks. In any case, I'll wait a few days to let anyone object & then merge this; heads-up that this specifies 202 Accepted as the correct response code for a Helper receiving an aggregation continuation request.\r\n\r\nI don't think the intent is clear, however; the text currently says that Helper aggregation continuation requests should result in a 202 Accepted in one place, and a 200 OK in another. I think this is something that should be cleaned up before RFC, one way or another.",
+              "createdAt": "2024-12-02T22:39:50Z",
+              "updatedAt": "2024-12-02T22:48:44Z"
+            }
+          ]
+        }
+      ]
     }
   ]
 }