How best to refer to discovery and capabilities detection in BRSKI-AE

[DDvO]

Here is a suggestion. Update/extend the existing text:

4.2.1. Pledge - Registrar Discovery
The discovery is done as specified in [RFC8995].

as follows:

4.2.1. Pledge - Registrar Discovery

The pledge discovers the registrar basically as specified in [RFC8995].
The pledge may already know or simply assume that
the discovered registrar supports BRSKI-AE with the certificate enrolment protocol its wants to use.
In case the pledge receives an error response on its enrolment request,
it may take this as an indication that the registrar does not support this
and then may decide to try some other variant or terminate the bootstrapping.

At the time of writing this specification, an extension to BRSKI [TDB informative reference to BRSKI-discovery]
was under development that aims to allow include in the discovery of the registrar
an optional list of capabilities it has, namely the BRSKI variants it supports
such as BRSKI-AE and related parameters such as CMP as the enrolment protocol.
If and when this extension is available, the pledge can make use of it to determine
beforehand whether the registrar supports BRSKI-AE with the wanted enrolment protocol.
This will be helpful to gain in advance a clear picture of the capabilities of the
discovered registrars and to choose, as far as possible, a matching enrolment protocol.
This way, trial and error regarding the capabilities of the registrar is avoided.

[DDvO]

After feedback from Hendrik, slightly improved and partly simplified the above proposal:

The pledge discovers the registrar as specified in [RFC8995].
The pledge may simply assume that the registrar supports BRSKI-AE with the certificate enrolment protocol it wants to use.
In case the pledge receives an error response on its enrolment request,
it may take this as an indication that the registrar does not support BRSKI-AE or the used certificate enrolment protocol
and either try again using a different certificate enrolment protocol or terminate the bootstrapping.

Note: The discovery mechanism by BRSKI may be extended to provide information on capabilities of the registrar,
such as the certificate enrolment protocol(s) it supports. This needs to be specified a separate document;
at the time of writing this specification, it is being done in [TDB informative reference to BRSKI-discovery].

[DDvO]

After further feedback and discussion in this week's Design Team meeting, here is a further update:

4.2.1. Pledge - Registrar Discovery

The pledge discovers the registrar basically as specified in [RFC8995].
In an engineered environment, the pledge may simply assume that the discovered registrar
supports the BRSKI-AE variant of BRSKI with the certificate enrolment protocol it wants to use.

Note: In case the protocol is not supported by the registrar, this would be detected only after
the pledge sent its certificate enrolment request, on which it would receive an error (likely at HTTP level).
This late detection might be avoided in several ways.
The registrar might be able to determine by inspecting the IdevID used by the pledge in the voucher request which enrolment protocol the pledge is going to use and reject the voucher request if it does not support this protocol.
The pledge could also include in its voucher request an explicit indication which enrolment protocol it is going to use,
such that the registrar can safely reject the request if it does not support this protocol. This may be achieved by a simple optional extension of the voucher request structure with a key-value pair, where absence implies "EST" as the default protocol, and currently the only other defined value would be "CMP".

As a more general solution, the discovery mechanism by BRSKI may be extended to provide beforehand to the pledge explicit information on the capabilities of the registrar, such as the certificate enrolment protocol(s) it supports.
This needs to be specified a separate document; at the time of writing this specification, it is being done in [TDB informative reference to BRSKI-discovery].

[mcr]

I have a problem with the word "basically"... it seems that there is a variation so please just describe that variation.
The use of an error backoff is fine. There are three situations that we need to think about:

1. there are actually no compatible registrars on the network, and we need to communicate this impedence mismatch to a human.
2. there are actually compatible registrars, but the pledge hasn't discovered/tried the correct one yet. This is where the discovery process can matter. The key thing is to somehow keep the pledge from cycling through the non-compliant ones without ever getting to the correct one. The fact that multiple join proxies can lead to the same registrar is part of what causes the annoyance.
3. an attacker is presenting some set of registrars to the pledge in a way that keeps it from ever finding the compatible one. (This is the same as Terminology change for pledge-agent #2, but malicious intent)

It seems to me that there is a need to specify some behaviour for non-compatible registrars to report the presence of an incompatible pledge.

[DDvO]

Yep, "basically" is too vague.
Should have read: As long as no extended discovery mechanism is available that can provide information on the specific capabilities of a registrar

[DDvO]

Due to the above feedback and further internal discussion, here is a further update:

4.2.1. Pledge - Registrar Discovery

The pledge may discover a registrar as specified in [RFC8995].
This is the fallback strategy when no extended discovery mechanism is available that can provide information on the specific capabilities of a registrar.
This optimistic approach is sufficient in an engineered environment, where the pledge may simply assume that the registrar discovered this way supports the BRSKI-AE variant of BRSKI with the certificate enrolment protocol it wants to use.

As a more general solution, the discovery mechanism by BRSKI may be extended to provide beforehand to the pledge explicit information on the capabilities of the registrar, such as the certificate enrolment protocol(s) it supports.
This needs to be specified a separate document; at the time of writing this specification, it is being done in [TDB informative reference to BRSKI-discovery].

[DDvO]

@toerless and @mcr, are you fine with the updated and shrunk text?

[toerless]

I am sorry, but i can not endorse this text. It implies that a registrar that only supports CMP, but not EST would (forever) have to announce itself as if it was a registrar (according to RFC8995) that does support EST - to support CMP-only pledges with no support of better discovery. And continuously misdirecting EST pledges to such registrars.

We can muck around with various options, but i think they all make us add technology debt that we should rather avoid. For example:

Registrar could "MUST have option to disable such announcements". Still, as long as we do not mandate support for better discovery on pledges, we may need to have registrar announce the "wrong" information. ... I would really like to argue against that.

alternative technology debt:

To support pledges with only rfc8995 discovery mechanisms, registrars MUST support EST in addition to any alternative enrollment option. If two or more alternative enrollment options (beside EST), all registrars offering these discovery mechanisms MUST also support all the alternative enrollment options required by such pledges.
.. this seems like a big technology debt to get away from EST...

Is it worth to inherit this dept just to avoid a normative dependency against brski variation discovery ?

If the whole purpose of the discussion is to avoid a normative dependency, then maybe we could try to put discovery out of scope in the document. There is so much work in the IETF that is not a complete solution to a problem, but just a subset of it. Aka: some text like

• rfc8995 discovery can not be used because... (see above)
• discovery is out of scope of this document.
• deployments may consider {{brski-discovery}} as an option

This might be a way to avoid a normative reference (the out-of-scope). But not sure if it flies with iesg. But its a sane approach with the only risk being to get upgraded to normative dependency.

[toerless]

Ok, just talked to Alvaro Retana (Futurewei colleage and 8 year AD), and it should be fine to take the reference out of line of "normative" through appropriate resturcuting. We primarily must not have any normative requirements, not even a MAY against anything such as brski-discovery.

E.g.:

• lets move the discovery stuff to brski-discovery, and make those of -ae authors who worked on it co-author(s).
• write simple text such as the following:

Discovery of registrars that support a specific alternative enrollment option and/or proxies that supports proxying to such a registrar is out of scope of this document. Implementations of this work need to also support some mechanism to support this. See for example {{brski-discovery}}.

Note that RFC8995 discovery is insufficient for this, because registrars supporting alternative enrollment protocols may not want to support EST, and even if they do, RFC8995 discovery does not allow to indicate which particular alternative enrollment option is supported. Use of RFC8995 alone would thus lead to recurring attempts and failure connecting to registrars not supporting the pledge expected enrollment option. This is particularily undesirable when introducing non-EST capable registrar in the presence of EST-only (RFC8995) pledges. When proxies are used, these proxies will also not allow pledges to reach every registrar they discover (instead, they will select to connect only to one or a subset), potentially never allowing pledges to connect to the only registrar supporting the desired alternative enrollment option.

[DDvO]

Thank you @toerless for your comments.

The motivation for our above proposal is not only to avoid a normative reference to a document that would incur a considerable delay in publication of the BRSKI-AE RFC. Even more important to us authors is another issue: effort in implementation, deployment, and operation.
As long as it is clear from the context (e.g., in an engineered environment, which is mentioned in the proposed text) that the registrar supports the enrolment protocol(s) needed by the pledges that are able to discover it, everything just works without the need to implement and deploy any extension to the existing discovery.

Regarding the way how to allow making the reference to brski-discovery informative, your suggested solution to declare the discovery topic out of scope of the BRSKI-AE spec sounds good to me.
What do others think?

As mentioned in our design team meeting of last week, I also like your suggestion that the authors of specs describing BRSKI variations become co-authors of brski-discovery. To this end, I already started contributing to it a little, by the proposed tweaks to the paragraph defining/reserving identifiers of enrolment protocols: anima-wg/brski-discovery#2.
I hope that also all other (co-)authors of BRSKI-AE etc. are fine with becoming co-authors of brski-discovery?

[toerless]

The problem with the idea of "engineered environment" is that we usually have no good way to constrain deployment of the individual devices, pledges, registrar to such engineered environment. And as soon as they are deployed outsize of such an environment, they would cause all those incompatibility issues.

Forcing devices into an "engineered environment' would for example be by having devices (pledge, registrar) that only support some specific type of radio network, and thats always engineered. We can not expect it.

If we say for Registrars "MUST NOT use rfc8995 discovery unless known to be in an engineered environment", that alas only solves half the isue. I can not come up with a way to do the same for pledges. We can not expect configuration of a pledge pre-enrollment, and with just RFC8995 discovery, a pledge will react (undesirably) to existing RFC8995 deployments ;-((

I think we should just hurry up on making brski-discovery RFC a reality, as it solves these issues. To this end, i'll try to get slots in the other WGs with experts so that hopefully we can frontend validation of the concepts by outside experts (outside anima).

[DDvO]

We seem to agree that within engineered environments, there is no problem because
there, the operator of such an environment is responsible for which devices (registrar(s) or pledges) can enter it and can make sure that only compatible devices are deployed in the given environment.

If devices happen to get deployed in any other (unconstrained) environment, right that things become more difficult.

• I do not see that a pledge can do real harm in any environment - it just won't be able to get bootstrapped successfully if it cannot hook up with a registrar suitable for it. Even if it obtains a valid voucher and then fails to complete the certificate enrollment stage thereafter, already from the plain BRSKI perspective there must be a way of cleanly coping with this incompatibility error because there must be a way of copying with any kind of enrollment failure.
• Indeed incompatible registrars could do harm because they may get discovered by pledges that have other expectations on the enrollment protocol and thus block pledges from hooking up with a better suited registrar.
  To solve this, I think we could say basically what you suggested above:
  A new BRSKI-AE registrar that does not support EST (as a fallback for use with old pledges) MUST NOT use plain RFC 8995 discovery unless known to be in an engineered environment.

[DDvO]

@toerless and @mcr, what do you think about my last suggestion addressing the concerns raised by Toerless?
It boils down to extending my above text proposal with the sentence I mentioned at the end of my most recent response,
such that the full text becomes:

4.2.1. Pledge - Registrar Discovery

The pledge may discover a registrar as specified in [RFC8995].
This is the fallback strategy when no extended discovery mechanism is available that can provide information on the specific capabilities of a registrar.
This optimistic approach is sufficient in an engineered environment, where the pledge may simply assume that the registrar discovered this way supports the BRSKI-AE variant of BRSKI with the certificate enrolment protocol it wants to use.
If a new BRSKI-AE registrar that does not support EST (as a fallback for use with old pledges) and
is not known to be in an engineered environment, it MUST NOT use plain RFC 8995 discovery.

As a more general solution, the discovery mechanism by BRSKI may be extended to provide beforehand to the pledge explicit information on the capabilities of the registrar, such as the certificate enrolment protocol(s) it supports.
This needs to be specified a separate document; at the time of writing this specification, it is being done in [TDB informative reference to BRSKI-discovery].

[EskoDijk]

If a new BRSKI-AE registrar that does not support EST (as a fallback for use with old pledges)
is not known to be in an engineered environment. it MUST NOT use plain RFC 8995 discovery.

This sentence is quite complex - requires a lot of thinking to unravel the requirement;

• actor that does NOT support x;
• that is NOT known to be in y;
• must NOT use z.

That's a 3x negative. What's the real requirement :)

[toerless]

In the absence of better discovery mechanisms (such as {{...}}) that allow BRSKI-AE pledges to explicitly discover a BRSKI-AE registrar supporting the enrollment protocol required by the pledge, BRSKI-AE registrars supporting only CMP but not EST MAY use RFC8995 discovery through a configuration option that SHOULD be enabled only in engineered environments. Engineered environments are those where only pledges requiring CMP are deployed. Likewise pledges MAY rely on RFC8995 discovery to find a registrar.

If pledges supporting only CMP are and that use RFC8995 discovery are deployed in non-engineered environments, they may discover registrars not supporting CMP, but only EST and fail their enrollment when using them. To support operating in such an environment, the pledge MUST cycle through registrars that it discovers to finally find a CMP capable one and enroll via it.

CMP registrars configured to announce RFC8995 discovery MUST NOT consider it to be an error when the log for the pledge from the MASA indicates prior vouchers for the pledge to such EST registrar, but instead provide the voucher to the pledge and let it enroll.

[DDvO]

Thanks Esko for your comment.

That's a 3x negative. What's the real requirement :)

Right, the sentence is rather difficult. We can transform it to something logically equivalent with fewer negations, such as:

If a new BRSKI-AE registrar is not known to be in an engineered environment and uses plain RFC 8995 discovery,
it MUST support EST as a fallback for use with pledges not using BRSKI-AE.

@EskoDijk how do you like this?

@toerless would this be fine for you as well?
You mentioned in today's call that you also have further suggestions for a text regarding the pledge side.

[DDvO]

Ah, Toerless, after reloading the page, I noticed that you meanwhile already added new texts - thanks!

[DDvO]

@toerless I find your new texts very useful.
I've just simplified them a little and integrated them with my older (above) text proposal as follows.
Are you - and others - fine with this?

4.2.1. Pledge - Registrar Discovery

Pledges may discover registrars using the basic mechanism specified in [RFC8995], which does not provide information on specific capabilities of registrars.
This optimistic approach is sufficient in engineered environments where a pledge can simply assume that all registrars discovered this way support BRSKI-AE with the certificate enrollment protocol it wants to use.

As a more general solution, the BRSKI discovery mechanism can be extended to provide beforehand to the pledge explicit information on the capabilities of a registrar, such as the certificate enrollment protocol(s) it supports.
Defining such an extension is out of scope of this document. It is being done in [TDB informative reference to BRSKI-discovery].

In the absence of better discovery mechanisms, BRSKI-AE registrars supporting only CMP but not EST MAY use RFC 8995 discovery through a configuration option that SHOULD be enabled only in engineered environments where only pledges requiring CMP are deployed. In such environments, pledges MAY rely on RFC8995 discovery to find suitable registrars.

If a pledge that supports only CMP and uses RFC8995 discovery is deployed in a non-engineered environment, it might discover registrars that support only EST, und using them, it will fail its enrollment. In order to cope with such an environments, the pledge needs to cycle through registrars that it discovers to finally find a CMP capable one and enroll via it.
To support such a search strategy, CMP capable BRSKI-AE registrars that are configured to announce RFC 8995 discovery MUST NOT reject a pledge just because the log from the MASA indicates prior vouchers for this pledge from registrars that are not CMP capable.

[EskoDijk]

I'm assuming the goal is to leave out a new discovery mechanism from the AE-draft, and rely on the existing one. (Not entirely sure why we have this goal - it would be better to have a complete discovery solution, including Join Proxy definitions/considerations, as part of a new protocol such as BRSKI-CMP and published at the same time?)

If the discovery aspect is causing such problems, then I doubt we can publish an RFC saying "BRSKI-AE generalizes BRSKI to support new types of enrollment protocols" and at the same time say "discovery is done like in RFC 8995". This is only going to work if either

1. the Registrar (and so the domain owner and its IT services) by requirement supports ALL potential protocols
2. the environment is controlled such that only Pledges are added of the "type" that the Registrar supports.

If we don't choose one of these options we cannot go ahead claiming BRSKI-AE is generic. (We could make it specific: e.g. BRSKI-CMP but that would change the nature of this draft.) So we're forced to choose one of these two options if we want to go ahead.
Then, it seems we go for option 2 here? If so we can simplify the text quite a bit I think. See below for an example:

4.2.1. Pledge - Registrar Discovery

A pledge discovers a registrar using the basic mechanism specified in [RFC8995], which does not provide information to the pledge on specific capabilities of registrars.
This optimistic approach is sufficient in engineered environments where a pledge can simply assume that all registrars discovered this way support the variant of BRSKI with the certificate enrollment protocol it wants to use.

As a more general solution, the BRSKI discovery mechanism can be extended to provide beforehand to the pledge explicit information on the capabilities of a registrar, such as the certificate enrollment protocol(s) it supports.
Defining such an extension is out of scope of this document. Future work such as [TDB informative reference to BRSKI-discovery] may provide this.

A BRSKI-AE registrar MUST support basic registrar discovery as defined in RFC 8995, unless it implements such a future extension that would replace this basic mechanism.

[DDvO]

Thanks Esko for sharing your thoughts.

I'm assuming the goal is to leave out a new discovery mechanism from the AE-draft,

Yes.

and rely on the existing one.

Not in general, but in engineered environments.

(Not entirely sure why we have this goal - it would be better to have a complete discovery solution, including Join Proxy definitions/considerations, as part of a new protocol such as BRSKI-CMP and published at the same time?)

As I explained in our design team meetings and for instance three weeks before in a response to @toerless in this thread:

The motivation for our above proposal is not only to avoid a normative reference to a document that would incur a considerable delay in publication of the BRSKI-AE RFC. Even more important to us authors is another issue: effort in implementation, deployment, and operation.

In other words, would be nice to have the extended discovery mechanism, but it is not yet fully specified, and it will taken even longer until it will be implemented, and we cannot rely on it being available at all in all scenarios because it will take extra efforts and is not mandatory to implement.

If the discovery aspect is causing such problems, then I doubt we can publish an RFC saying "BRSKI-AE generalizes BRSKI to support new types of enrollment protocols" and at the same time say "discovery is done like in RFC 8995".

The idea is not to require to do discovery as before in RFC 8995, but to mention that

• a better option is being specified and may be available in the future
• for cases (or: as long as) this is not available, under certain conditions it is also okay to do without it,
  and the new texts by Toerless even provide solutions how to handle potential pitfalls.

[EskoDijk]

@DDvO if it's only about a discovery mechanism to discover "CMP capable registrar" it could be defined in a really simple way. Just same as RFC 8995 but add a string property "cmp" to the discovered data, and that's it. Or even simpler use a different service name with "cmp" in it. If it's about solving discovery generically, then I understand this could require more time and thought.

But my issue is that without discovery, isn't the solution incomplete? You have less implementation effort but not a working solution. And if you would re-use the same discovery but with a slightly different service name or an added parameter, the extra implementation effort would be near zero.

I'm not sure if we could standardize an incomplete solution that doesnt require discovery in a particular way? Or maybe we can and an implementer would just have to wait for the discovery part to become available?

[toerless]

Esko: RFCs are only in the rarest of cases complete solution documentations. Yes, ANIMA being in OPS, we do love to do that, but with more complex solutions i think we did learn that that often delays the progression of individual component work. Discovery/automation being ignored as part of specifying solutions is almost a proud tradition of the industry. My whole motivation of joining what later became the ANIMA effort more than 10 years ago is because of decades of deploying and developing protocol technologies that tthen turned out to be nerd-knob-hells. And resulted in an even worse hell called the "magic SDN controller that configured all the nerd knobs". In RFC8995 we did IMHO a fairly high-level job of discovery which IMHO a lot of handwaving. And that was because the focus of the document and all the technocal details of it (BRSKI) where already complex enough to find a lot more time and cycles to further detail discovery aspects. So, i do thnk that it is most prudent to finally get to discovery in BRSKI through a separate document so we can detail it for better interopable implementations, and in return, we would try to only provide feasible first-gen stub discovery into the existing/prior document. Cheers Toerless

[EskoDijk]

@toerless Ok for me to consider BRSKI-AE as a building block that can be further enhanced with (future/discovery) mechanisms.
I also opened issue #33 to determine what the intended scope is for the discovery of BRSKI-AE, since e.g. the BRSKI Join Proxy is only defined for GRASP and only defined for ACP context. I'm ok with the answer being here "same protocol, same scope".

But given the discussion in this issue, there is a desire to have a minimal, simple GRASP discovery solution that supports BRSKI+CMP, for the ACP context or maybe for another context too (non-ACP -> this could be discussed in #33 ).

Now the simplest thing I can think of is to re-use the existing RFC 8995 GRASP discovery and change the objective value so that "BRSKI+CMP" can be distinguished from "BRSKI" by a Pledge that knows about CMP.

For example the objective could look like this:

["AN_Proxy", 4, 1, ["cmp"] ]

we don't need a complete discovery solution that works for all cases, just a simple something to distinguish CMP vs EST. And since we don't propose yet something like the above here, I'm struggling to understand why. It's so simple, it uses the GRASP parameters like it was designed for, and it avoids introducing strange mandatory requirements involving "in engineered environments you MUST do X" or trial-and-error for the CMP-Pledge.

Note: using ["cmp"] instead of just "cmp" makes the approach more easily extendible in the future to whatever we decide in draft-discovery.

[EskoDijk]

PS as a side note, in constrained-voucher we do the same as I described above to distinguish the CoAP JP from a regular JP with the objective as follows:

["AN_Proxy", 4, 1, "DTLS"]

this could be easily changed to the below, to stay more in line with what I proposed here:

["AN_Proxy", 4, 1, ["estc"] ]

where estc refers to the EST-coaps protocol, that constrained-voucher uses for enrollment.

[DDvO]

Thanks Esko and Steffen for providing further suggestions on the above proposed text.
I've used them in a new update for the section content, performing also some further tweaks.
Since time is pressing with the submission cut-off on Monday, likely the following text will be the one in version 06:

Pledges may discover registrars using the basic mechanism specified in {{RFC8995}},
which does not provide information on specific capabilities of registrars.
This optimistic approach is sufficient in engineered environments
where a pledge can simply assume that all registrars discovered this way support
the variant of BRSKI-AE with the certificate enrollment protocol it wants to use.

As a more general solution, the BRSKI discovery mechanism can be extended
to provide beforehand to the pledge explicit information on the capabilities
of a registrar, such as the certificate enrollment protocol(s) it supports.
Defining such an extension is out of scope of this document.
Future work such as [TDB informative reference to BRSKI-discovery] may provide this.
This may be specifically helpful in non-engineered environments
where pledges cannot presume that all registrars have the capabilities they need.

In the absence of better discovery mechanisms,
BRSKI-AE registrars supporting only CMP but not EST
SHOULD be configured to allow for RFC 8995 discovery
only in engineered environments where only pledges requiring CMP are deployed.
This prevents them from being discovered by pledges that assume the use of EST.

In case a pledge that uses RFC 8995 discovery and supports BRSKI-AE with only CMP
gets deployed in a non-engineered environment,
it might at first discover registrars that do not support CMP (but only EST).
A possible strategy for the pledge in this case is to
cycle through the registrars it discovered until it has found
a registrar that it was able to use successfully for CMP-based enrollment.
To support such a search strategy, CMP capable BRSKI-AE registrars that are
configured to allow for RFC 8995 discovery MUST NOT reject a pledge
just because the log from the MASA indicates prior vouchers for this pledge
from registrars that are not CMP capable.

[mcr]

I don't feel like we are making progress here, so let's err on the side of under-specification rather than wrong-specification.

[EskoDijk]

I think it's ok to update the text to what David proposed; this can be used as a basis for discussion. Maybe also at the Prague meeting. There may be good reasons for 1:1 re-using the 8995 discovery here, without using the obvious solution of a new name or parameter to distinguish BRSKI-EST and BRSKI-CMP. These reasons I still need to learn about. And after discussion we may decide to remove some of the new requirements that are possibly 'wrong' or too complex.

Under-specification would be fine also in this case because as Toerless argued the discovery can be defined separately. But in this case the discovery text would need to be different.

[DDvO]

Yes, please let us have a preliminary text such as the above in the upcoming version as a concrete basis for discussion.
Good that we can soon discuss about this in person, at the IETF 118 in Prague.
Esko, wenn do you plan to arrive? Michael already on Friday evening, and Toerless on Saturday evening IIRC.

[EskoDijk]

I'm arriving Sunday evening late (will miss all the opening events unfortunately).

[DDvO]

After our very helpful (mostly) in-person side meeting on Monday last week,
here is the new text according to the solution we reached there
and with wording agreed among the authors:

4.2.1. Pledge - Registrar Discovery

Discovery as specified in BRSKI {{RFC8995, Section 4}} does not support
discovery of registrars with enhanced feature sets.
A pledge cannot find out in this way whether discovered registrars
support the certificate enrollment protocol it expects, such as CMP.

As a more general solution, the BRSKI discovery mechanism can be extended
to provide upfront information on the capabilities of registrars.
Future work such as {{I-D.eckert-anima-brski-discovery}} may provide this.

In the absence of such a generally applicable solution,
BRSKI-AE deployments may use their particular way of doing discovery.
{{brski-cmp-instance}} defines a minimalist approach that MAY be used for CMP.

In controlled environments where the specific BRSKI features
required by pledges and the features supported by the registrar(s)
are known and considered during engineering,
also the following optimistic approach MAY be followed.
Each pledge simply assumes that all registrars involved support
BRSKI-AE with the enrollment protocol(s) that it requires.

and a new paragraph at the end of Section

5.1. BRSKI-CMP: Instantiation to CMP:

For BRSKI-AE scenarios where a general solution (cf. {{discovery}})
for discovering registrars with CMP support is not available,
the following minimalist approach MAY be used.
Perform discovery as defined in BRSKI {{RFC8995, Section 4}}, but using
the service name "brski-registrar-cmp" instead of "brski-registrar".
Note that this approach does not support join proxies.

This part of the just uploaded new draft version 07.

[EskoDijk]

Notes for the record:

• the 5.1 reference to RFC 8995 Section 4 was changed to Appendix B, because it's about mDNS/DNS-SD discovery in particular and not GRASP discovery.
• discussion yesterday in the ANIMA design team call about the "controlled environments" paragraph. The proposal was to remove it. I didn't fully capture all the arguments (pros and cons of the paragraph) but if needed we can start a mail thread to list the arguments.