Is my side or is this hanging for everyone?
", "time": "2025-11-18T15:34:32.000Z"}, {"author": "Hannes Tschofenig", "text": "Works for me.
", "time": "2025-11-18T15:34:44.000Z"}, {"author": "Deb Cooley", "text": "I don't have an issue?
", "time": "2025-11-18T15:34:51.000Z"}, {"author": "Monty Wiseman", "text": "I'm going to re-join.
", "time": "2025-11-18T15:36:00.000Z"}, {"author": "Mike Ounsworth", "text": "I disagree that the current draft is \"Just use CMW\". I believe that description is wholly incorrect. You can absolutely just put your bits directly into the CSR Attribute without using a CMW wrapper.
", "time": "2025-11-18T15:40:09.000Z"}, {"author": "Hannes Tschofenig", "text": "I also have to disagree with MSJ here.
", "time": "2025-11-18T15:40:28.000Z"}, {"author": "Deb Cooley", "text": "patience
", "time": "2025-11-18T15:42:31.000Z"}, {"author": "Mike Ounsworth", "text": "Clarification: \"RATS Conceptual Message\" is an abstract philosophical term meaning, generically, Evidence, Endorsement, and Attestation Results. It DOES NOT mean the CMW wire format.
", "time": "2025-11-18T15:42:38.000Z"}, {"author": "Hannes Tschofenig", "text": "It is just the terminology the RATS group uses.
\nWhy invent new terminology?
", "time": "2025-11-18T15:43:13.000Z"}, {"author": "Mike Ounsworth", "text": "The intent of that abstract change was just to align terminology between LAMPS and RATS; not to change the semantics of the abstract.
", "time": "2025-11-18T15:43:44.000Z"}, {"author": "Deb Cooley", "text": "To be fair, I have had issues with the RATS terminology.
", "time": "2025-11-18T15:43:56.000Z"}, {"author": "Hannes Tschofenig", "text": "But that is what the IETF agreed to publish as an RFC.
\nThe communication patterns are also defined by RATS based on what is being done in the real world.
", "time": "2025-11-18T15:44:39.000Z"}, {"author": "Mike Ounsworth", "text": "I do too, but hey, they are the WG chartered to do this work; I don't think it's helpful for LAMPS to reject the output of the RATS WG.
", "time": "2025-11-18T15:44:40.000Z"}, {"author": "Hannes Tschofenig", "text": "FWIW the passport model is what we also use in OAuth.
", "time": "2025-11-18T15:47:09.000Z"}, {"author": "Hannes Tschofenig", "text": "(the draft is called OAuth client attestation)
", "time": "2025-11-18T15:47:36.000Z"}, {"author": "Deb Cooley", "text": "for sure, but PKIX (or Web PKI) classically doesn't work that way.
", "time": "2025-11-18T15:48:52.000Z"}, {"author": "Mike Ounsworth", "text": "Hint is also useful for WebAuthn.
", "time": "2025-11-18T15:49:41.000Z"}, {"author": "Mike Ounsworth", "text": "The problem it is solving is not unique to CMW.
", "time": "2025-11-18T15:49:52.000Z"}, {"author": "Hannes Tschofenig", "text": "The \"CMW folks\" -- just to be clear -- are people like Intel, Google, AMD, Nvidia, Arm, Oracle, ...
", "time": "2025-11-18T15:50:26.000Z"}, {"author": "Tim Hollebeek", "text": "Sorry, not impressed by logo clouds.
", "time": "2025-11-18T15:51:12.000Z"}, {"author": "Deb Cooley", "text": "I don't think the issue is whether there is a need. I think the issue is that there are two needs, and they are different.
", "time": "2025-11-18T15:51:12.000Z"}, {"author": "Tim Hollebeek", "text": "Those people are certainly capable of participating and making technical arguments.
", "time": "2025-11-18T15:51:48.000Z"}, {"author": "Hannes Tschofenig", "text": "But we had those people involved in the discussions. Those companies develop products in this field. Not irrelevant IMHO
", "time": "2025-11-18T15:52:07.000Z"}, {"author": "Deb Cooley", "text": "but those people are in rats, no?
", "time": "2025-11-18T15:52:23.000Z"}, {"author": "Deb Cooley", "text": "would make more sense to do the work there?
", "time": "2025-11-18T15:52:33.000Z"}, {"author": "Mike Ounsworth", "text": "I think Hannes' point is that the authors of the CSR-Attest draft are not \"the CMW people\". Distinct groups of peopel.
", "time": "2025-11-18T15:52:35.000Z"}, {"author": "Carl Wallace", "text": "Why is this hint any different than the old ContentHint in RFC 2634?
", "time": "2025-11-18T15:52:38.000Z"}, {"author": "Tim Hollebeek", "text": "I was reacting to \"are people like ...\". We don't give additional weight because you're a large company or represent one.
", "time": "2025-11-18T15:52:41.000Z"}, {"author": "Hannes Tschofenig", "text": "in RATS, in our design team calls, in the Confidential Computing Consortium
", "time": "2025-11-18T15:52:54.000Z"}, {"author": "Mike Ounsworth", "text": "Carl: ContentHint in RFC 2634
\nI didn't know about that. I'll make a note to go look.
I reacted because MSJ dismissed them as \"the CWM people\"
", "time": "2025-11-18T15:53:33.000Z"}, {"author": "Deb Cooley", "text": "(he meant 'the rats people'.)
", "time": "2025-11-18T15:53:56.000Z"}, {"author": "Deb Cooley", "text": "It is also worrying when in a rats meeting that people say HSMs are not legit hardware devices.
", "time": "2025-11-18T15:54:41.000Z"}, {"author": "Hannes Tschofenig", "text": "I do not agree with everyone in the RATS group - just to be clear.
", "time": "2025-11-18T15:55:13.000Z"}, {"author": "Deb Cooley", "text": "I'm not shocked at that
", "time": "2025-11-18T15:55:26.000Z"}, {"author": "Tim Hollebeek", "text": "That's fair --- no one agrees with everyone :)
", "time": "2025-11-18T15:55:29.000Z"}, {"author": "Hannes Tschofenig", "text": "FWIW the passport model is also used in the Privacypass WG
", "time": "2025-11-18T15:56:56.000Z"}, {"author": "Carl Wallace", "text": "Re: passport model, atestation results are way too underbaked here to my eye. EAR has promise.
", "time": "2025-11-18T15:57:48.000Z"}, {"author": "Deb Cooley", "text": "the 'passport model' is a classic IDM model. But PKIX hasn't classically used that model.
", "time": "2025-11-18T15:58:11.000Z"}, {"author": "Hannes Tschofenig", "text": "You have to start somewhere. This is not uncommon that not everything is standardized in a single specification
", "time": "2025-11-18T15:58:27.000Z"}, {"author": "Carl Wallace", "text": "stapled OCSP is PKIX
", "time": "2025-11-18T15:58:41.000Z"}, {"author": "Michael Richardson", "text": "Deb Cooley said:
\n\n\nthe 'passport model' is a classic IDM model. But PKIX hasn't classically used that model.
\n
Interesting point.
", "time": "2025-11-18T15:58:47.000Z"}, {"author": "Hannes Tschofenig", "text": "Carl is correct.
", "time": "2025-11-18T15:59:21.000Z"}, {"author": "Tim Hollebeek", "text": "I love when IETF is defining philosophical terms.
", "time": "2025-11-18T16:00:19.000Z"}, {"author": "Hannes Tschofenig", "text": "This is the CMW:
\nhttps://datatracker.ietf.org/doc/draft-ietf-rats-msg-wrap/
", "time": "2025-11-18T16:00:21.000Z"}, {"author": "Deb Cooley", "text": "I made rats define it in the draft Hannes listed.
", "time": "2025-11-18T16:00:34.000Z"}, {"author": "Mike Ounsworth", "text": "RATHOLE!
", "time": "2025-11-18T16:02:09.000Z"}, {"author": "Mike Ounsworth", "text": "I think this is the core point though: RATS and PKIX are different knowledge domains, and how much defining (and re-defining) is necessary to get a simple CSR doc out?
", "time": "2025-11-18T16:02:37.000Z"}, {"author": "Deb Cooley", "text": "And whether you need a single specification.
", "time": "2025-11-18T16:03:05.000Z"}, {"author": "Hannes Tschofenig", "text": "Definitely. The document management issue.
", "time": "2025-11-18T16:03:17.000Z"}, {"author": "Carl Wallace", "text": "This issue pre-dates CAB Forum code signing stuff by years
", "time": "2025-11-18T16:03:58.000Z"}, {"author": "Hannes Tschofenig", "text": "Agree. Nowadays, we have use cases for remote attestation all over the place
", "time": "2025-11-18T16:05:52.000Z"}, {"author": "Tim Hollebeek", "text": "I don't want to go down this rathole but if MSJ or the authors have thought about how this does / doesn't work with European WalletWorld [TM], I'd love to hear those perspectives some other time.
", "time": "2025-11-18T16:06:11.000Z"}, {"author": "Hannes Tschofenig", "text": "The answer to this question is in OAuth. The OAuth group decided not to use LAMPS because they hate X.509
", "time": "2025-11-18T16:06:57.000Z"}, {"author": "Hannes Tschofenig", "text": "I can give you the details.
", "time": "2025-11-18T16:07:15.000Z"}, {"author": "Deb Cooley", "text": "so rats should use oauth?
", "time": "2025-11-18T16:07:16.000Z"}, {"author": "Carl Wallace", "text": "So much inter WG hate:-)
", "time": "2025-11-18T16:07:20.000Z"}, {"author": "Hannes Tschofenig", "text": "The OAuth group does not like RATS either.
", "time": "2025-11-18T16:07:38.000Z"}, {"author": "Hannes Tschofenig", "text": "It is another group where the not-invented-here syndrom is very strong (already from the start of the group).
", "time": "2025-11-18T16:08:01.000Z"}, {"author": "Hannes Tschofenig", "text": "The \"verifier\" is a logical entity.
", "time": "2025-11-18T16:11:32.000Z"}, {"author": "Michael StJohns", "text": "@timh - could you send a reference to walletworld please?
", "time": "2025-11-18T16:11:32.000Z"}, {"author": "Michael Richardson", "text": "Evidence and/or Attestation Result, signed by an Endorsement Key that the Verifier believes represents a legit HSM.
", "time": "2025-11-18T16:11:36.000Z"}, {"author": "Carl Wallace", "text": "@hannes - tnx
", "time": "2025-11-18T16:12:42.000Z"}, {"author": "Tim Hollebeek", "text": "", "time": "2025-11-18T16:12:57.000Z"}, {"author": "Hannes Tschofenig", "text": "This is a development that keeps some part of the OAuth community busy
", "time": "2025-11-18T16:12:59.000Z"}, {"author": "Michael Richardson", "text": "Carl Wallace said:
\n\n\n\n
\n- and that is bound to the public key that is the subject of the CSR
\n
the key pair being spoken about is not the Endorsed HSM key.
", "time": "2025-11-18T16:13:04.000Z"}, {"author": "Tim Hollebeek", "text": "heh, two people using Google at the same time
", "time": "2025-11-18T16:13:07.000Z"}, {"author": "Deb Cooley", "text": "hannes might know it by heart.
", "time": "2025-11-18T16:13:38.000Z"}, {"author": "Hannes Tschofenig", "text": "Rifaat and I have regular conference calls with the European Commission on this topic because they are tracking the progress of our specifications.
", "time": "2025-11-18T16:13:41.000Z"}, {"author": "Michael StJohns", "text": "For the \"banana phone\" the \"attestation result\" is actually an \"attestation\" - triggered by the end entity, and involving a third party... in this case, its well defined
", "time": "2025-11-18T16:13:43.000Z"}, {"author": "Hannes Tschofenig", "text": "The blanket term \"attestation\" does not exist in RATS
", "time": "2025-11-18T16:14:11.000Z"}, {"author": "Hannes Tschofenig", "text": "I actually agree with them that that term has too much meaning associated and needs further description
", "time": "2025-11-18T16:14:28.000Z"}, {"author": "Michael StJohns", "text": "oops... EvidenceBundle -> AttestationResultsBundle
", "time": "2025-11-18T16:14:57.000Z"}, {"author": "Hannes Tschofenig", "text": "This link might also be interesting in the wallet discussion: https://eudi.dev/latest/
", "time": "2025-11-18T16:15:17.000Z"}, {"author": "Monty Wiseman", "text": "That's the role of the \"Attestation Key\" that signs the \"Evidence\"
", "time": "2025-11-18T16:18:35.000Z"}, {"author": "Michael StJohns", "text": "@carl - some EVIDENCE-STATEMENT definitions might not be IETF RFCs... idea was a dictionary vs a registry
", "time": "2025-11-18T16:20:37.000Z"}, {"author": "Carl Wallace", "text": "I understand that. None of the statements I work with are IETF RFCs. But a rule for binding needs to be someplace.
", "time": "2025-11-18T16:21:32.000Z"}, {"author": "Michael StJohns", "text": "I can talk to that during the QA - I did have a conversation with the IANA about creating a more general dictionary
", "time": "2025-11-18T16:22:07.000Z"}, {"author": "Tim Hollebeek", "text": "I agree with Carl, as a CA, if I can't implement a system from these specs that allows me to verify from an arbitrary compliant CSR that the associated key is in an HSM without additional coordination with the Attester, it has relatively little value as a standard.
", "time": "2025-11-18T16:22:27.000Z"}, {"author": "Tim Hollebeek", "text": "If I can do that, it's quite valuable.
", "time": "2025-11-18T16:22:51.000Z"}, {"author": "Mike Ounsworth", "text": "@Tim Are you saying that we can't standardize a CSR Attribute unless we also standardize all the APIs between every device manufacterer and every verifier?
", "time": "2025-11-18T16:24:03.000Z"}, {"author": "Mike Ounsworth", "text": "IE the RATS WG needs to conclude before we can publish this CSR doc?
", "time": "2025-11-18T16:24:36.000Z"}, {"author": "Carl Wallace", "text": "Many attestations are not RATS, so RATS has nothing to do with the point I was making.
", "time": "2025-11-18T16:25:05.000Z"}, {"author": "Tim Hollebeek", "text": "I'm saying when you have an interoperability standard, it should allow parties to interoperate. If there are unspecified bits that require pairwise interactions to resolve, you lose the value of standards.
", "time": "2025-11-18T16:25:21.000Z"}, {"author": "Michael StJohns", "text": "@deb - let me show you what I talked to IANA about related to this... later during the QA
", "time": "2025-11-18T16:26:21.000Z"}, {"author": "Michael StJohns", "text": "I think it will make things clearer
", "time": "2025-11-18T16:26:30.000Z"}, {"author": "Hannes Tschofenig", "text": "Creating an empty registry would work for me.
", "time": "2025-11-18T16:27:15.000Z"}, {"author": "Carl Wallace", "text": "FWIW in earlier versions of the draft we had other entries in the registry table:
\n\nThose all pointed to attestation technology developed by the Trusted Computing Group.
", "time": "2025-11-18T16:30:01.000Z"}, {"author": "Michael StJohns", "text": "three ways...
", "time": "2025-11-18T16:30:31.000Z"}, {"author": "Michael StJohns", "text": "not two
", "time": "2025-11-18T16:30:35.000Z"}, {"author": "Michael StJohns", "text": "four ways
", "time": "2025-11-18T16:31:03.000Z"}, {"author": "Michael StJohns", "text": "(But, even if you built a RP with a deep examination of the Evidence, the Evidence could be encrypted to the Verifier)
", "time": "2025-11-18T16:31:26.000Z"}, {"author": "Carl Wallace", "text": "so why include a port?
", "time": "2025-11-18T16:31:37.000Z"}, {"author": "Michael StJohns", "text": "A single number instead of an OID?
", "time": "2025-11-18T16:32:04.000Z"}, {"author": "Hannes Tschofenig", "text": "@Carl?
", "time": "2025-11-18T16:32:17.000Z"}, {"author": "Michael StJohns", "text": "Use the OID at the evidence-statement type
", "time": "2025-11-18T16:32:20.000Z"}, {"author": "Michael StJohns", "text": "4 is my slide \"Recommended Fix for Previous\"
", "time": "2025-11-18T16:33:56.000Z"}, {"author": "Michael Richardson", "text": "the URN, with a FQDN in it, is registration-free, and mostly self-documenting. An OID in an IANA registry can point at documentation. An OID from a PEN is registration-free/self-documenting. An OID from elsewhere might be much harder to figure out; this doesn't matter for \"approved\" Verifiers to which one has a trust/business relationship. When this matters is when things go wrong, not when they go right.
", "time": "2025-11-18T16:37:22.000Z"}, {"author": "Hannes Tschofenig", "text": "I am also fine with an URN, which was one of the proposal in the past
", "time": "2025-11-18T16:37:50.000Z"}, {"author": "Carl Wallace", "text": "There are type identifiers embedded in these payloads already, Why not those?
", "time": "2025-11-18T16:38:01.000Z"}, {"author": "Hannes Tschofenig", "text": "In which payloads?
", "time": "2025-11-18T16:38:14.000Z"}, {"author": "Carl Wallace", "text": "The attest statement
", "time": "2025-11-18T16:38:26.000Z"}, {"author": "Michael StJohns", "text": "I have a \"don't care\" with respect to how you define hints IFF either the hint is part of the lower structure, OR the 'hint' field type is set by the object identifier for the EvidenceStatement
", "time": "2025-11-18T16:38:29.000Z"}, {"author": "Hannes Tschofenig", "text": "@Carl: You mean in the Attestation Evidence? If so, that would require the RA/CA to understand the format
", "time": "2025-11-18T16:39:06.000Z"}, {"author": "Carl Wallace", "text": "The problem is the attest staement is layered and you are providing a hint about what is in the lower level (just like occured with CMS).
", "time": "2025-11-18T16:39:48.000Z"}, {"author": "Carl Wallace", "text": "It might be the CA needs to understand a type identifier it otherwise would not
", "time": "2025-11-18T16:40:22.000Z"}, {"author": "Tim Hollebeek", "text": "Again, the CABF discussions at this time are purely at the \"if attestations were available, we would consider using them\" level. It's impossible to actually interoperate with CABF Code Signing today because no requirements have been written yet.
", "time": "2025-11-18T16:42:15.000Z"}, {"author": "Tim Hollebeek", "text": "^^^ interoperable attestations
", "time": "2025-11-18T16:42:28.000Z"}, {"author": "Carl Wallace", "text": "*parser and verifier
", "time": "2025-11-18T16:42:53.000Z"}, {"author": "Hannes Tschofenig", "text": "The different Evidence Formats can be dealt with by the Verifiers
", "time": "2025-11-18T16:43:05.000Z"}, {"author": "Monty Wiseman", "text": "I cannot seem to change my mic device. As stated, we did implement the TPM 2 example. The link is on one of the slides.
", "time": "2025-11-18T16:43:24.000Z"}, {"author": "Carl Wallace", "text": "that does not change that parsing and verifying is important. i tend to doubt CA's will outsource all verification
", "time": "2025-11-18T16:43:46.000Z"}, {"author": "Tim Hollebeek", "text": "In the CABF world, CAs are largely not permitted to outsource verification.
", "time": "2025-11-18T16:44:20.000Z"}, {"author": "Hannes Tschofenig", "text": "Nothing in the draft says that you have to outsource
", "time": "2025-11-18T16:44:41.000Z"}, {"author": "Tim Hollebeek", "text": "Right, but the point is that well-specified verification is very important because CAs will have to implement it.
", "time": "2025-11-18T16:45:11.000Z"}, {"author": "Carl Wallace", "text": "right, but references to parsing are many and references to verification are relatively few. parsing is the easy part
", "time": "2025-11-18T16:45:17.000Z"}, {"author": "Mike Ounsworth", "text": "\"Right, but the point is that well-specified verification is very important because CAs will have to implement it.\"
\nI agree that this is a problem, and that requiring CAs to implement per-Device-Vendor parsers is not great, I believe that this problem is very much not within the LAMPS charter.
", "time": "2025-11-18T16:46:53.000Z"}, {"author": "Michael Richardson", "text": "Not sure I know what \"subordinate\" means here.
", "time": "2025-11-18T16:48:26.000Z"}, {"author": "Carl Wallace", "text": "per evidence type parsers is unavoidable (that horse has left the barn). per attestation result is not unavoidable
", "time": "2025-11-18T16:48:35.000Z"}, {"author": "Hannes Tschofenig", "text": "I agree.
", "time": "2025-11-18T16:48:53.000Z"}, {"author": "Mike Ounsworth", "text": "I believe I was talking about terminology, not technology, when I made the \"subordinate\" comment.
", "time": "2025-11-18T16:49:01.000Z"}, {"author": "Michael Richardson", "text": "Carl Wallace said:
\n\n\nper evidence type parsers is unavoidable (that horse has left the barn). per attestation result is not unavoidable
\n
For the Verifier, or the RP( the CA)?
", "time": "2025-11-18T16:49:02.000Z"}, {"author": "Hannes Tschofenig", "text": "The AR standardization looks promising.
", "time": "2025-11-18T16:49:20.000Z"}, {"author": "Tim Hollebeek", "text": "+1 Carl, that's all I want, something well-specified enough so I can tell which evidence parser I need
", "time": "2025-11-18T16:49:26.000Z"}, {"author": "Deb Cooley", "text": "@mike O: good.
", "time": "2025-11-18T16:49:29.000Z"}, {"author": "Carl Wallace", "text": "for the verifier (which in this case is the CA most likely)
", "time": "2025-11-18T16:49:29.000Z"}, {"author": "Michael Richardson", "text": "Carl Wallace said:
\n\n\nfor the verifier (which in this case is the CA most likely)
\n
Short term,yes for a very limited number of initial formats, but long term, very unlikely, I think.
", "time": "2025-11-18T16:50:18.000Z"}, {"author": "Hannes Tschofenig", "text": "@Tim: You do not need the hint if the RA/CA is colocated with the Verifier. You also do not need the hint if there is only a single Verifier.
", "time": "2025-11-18T16:51:04.000Z"}, {"author": "Mike Ounsworth", "text": "To MSJ: I strongly believe that if the TPM does not provide a way to serialize its data into a single byte string; that is not a problem for LAMPS to solve.
", "time": "2025-11-18T16:51:19.000Z"}, {"author": "Michael StJohns", "text": "@mike O... that's basically wrong.
", "time": "2025-11-18T16:52:00.000Z"}, {"author": "Steve Hanna", "text": "I will need to leave at the top of the hour. I think that I have the information that I need to work with Tim P and Carl on our recommendation.
", "time": "2025-11-18T16:52:03.000Z"}, {"author": "Hannes Tschofenig", "text": "The \"hint\" is not mandatory to implement. It is an optional parameter
", "time": "2025-11-18T16:52:03.000Z"}, {"author": "Carl Wallace", "text": "anythign solvable with attest statement + aux can be solved with different attest statement
", "time": "2025-11-18T16:52:22.000Z"}, {"author": "Tim Hollebeek", "text": "@Hannes why does the number of verifiers matter? It seems odd to me that the number that exist would modify their operation.
", "time": "2025-11-18T16:52:24.000Z"}, {"author": "Michael StJohns", "text": "@carl - yes, but then why does \"hint\" get preference?
", "time": "2025-11-18T16:52:45.000Z"}, {"author": "Hannes Tschofenig", "text": "Because the RA/CA needs to decide to which Verifier to send the Evidence
", "time": "2025-11-18T16:52:51.000Z"}, {"author": "Michael StJohns", "text": "same thing applies to cmw and webauthn
", "time": "2025-11-18T16:52:58.000Z"}, {"author": "Carl Wallace", "text": "+1 to what Tim just said
", "time": "2025-11-18T16:53:21.000Z"}, {"author": "Tim Hollebeek", "text": "ok I get what you're saying. Though with one verifier, you still have the multiplexing problem, it's just within the verifier instead.
", "time": "2025-11-18T16:53:22.000Z"}, {"author": "Carl Wallace", "text": "not everything needs to recap password and background
", "time": "2025-11-18T16:53:31.000Z"}, {"author": "Monty Wiseman", "text": "We are showing \"logical\" components so the different \"roles\" can be differentiated.
", "time": "2025-11-18T16:53:32.000Z"}, {"author": "Michael StJohns", "text": "@tim - yup
", "time": "2025-11-18T16:53:34.000Z"}, {"author": "Carl Wallace", "text": "@carl - the CSR CSP ought to tell you what it wants to accept... problem exists when you have the verifier between the two..
", "time": "2025-11-18T16:54:57.000Z"}, {"author": "Russ Housley", "text": "@ALL: Five minutes left
", "time": "2025-11-18T16:55:31.000Z"}, {"author": "Michael StJohns", "text": "because the verifier can indepedently decide what it will accept.
", "time": "2025-11-18T16:55:31.000Z"}, {"author": "Michael StJohns", "text": "@carl - do you have my most recent ID draft? see section 4 - bullet 5
", "time": "2025-11-18T16:56:52.000Z"}, {"author": "Michael Richardson", "text": "I agree with you Carl, EAR should merge with AR4SI. And I'd do that for a -bis. We did that for DHCPv6 (RFC8415). It was a very long document, very hard to review. Worth it at step two.
", "time": "2025-11-18T16:57:45.000Z"}, {"author": "Carl Wallace", "text": "@MSJ i had missed that bullet and thought the statement in the sec cons was the only reference. mea culpa.
", "time": "2025-11-18T16:58:53.000Z"}, {"author": "Hannes Tschofenig", "text": "I agree with Carl on the EAR and AR4SI. This is something the RATS group needs to decide
", "time": "2025-11-18T16:59:00.000Z"}, {"author": "Mike Ounsworth", "text": "Carl - in my slides I made the argument that it's useful for the RA to know at the top whether it's acting in the Background or Passport model, even if it can't parse the payload. Do you disagree with that?
", "time": "2025-11-18T16:59:14.000Z"}, {"author": "Hannes Tschofenig", "text": "Do we meet again?
", "time": "2025-11-18T16:59:38.000Z"}, {"author": "Carl Wallace", "text": "that's a type disambiguation question, evidence or AR
", "time": "2025-11-18T16:59:39.000Z"}, {"author": "Mike Ounsworth", "text": "Fair.
", "time": "2025-11-18T16:59:52.000Z"}, {"author": "Mike Ounsworth", "text": "You also get into weird parsing issues if you have a single list of stuff that mixes Evidence and ARs.
", "time": "2025-11-18T17:00:21.000Z"}, {"author": "Mike Ounsworth", "text": "Hence why we decided to make them separate lists.
", "time": "2025-11-18T17:00:41.000Z"}]