[Add] ADD State of Things Observations

["Deen, Glenn" <[e-mail]>]

Disclaimer:  I’ve discussed the following with my co-chair and our AD for a sanity check, but if in the end if you don’t like it please send the hate mail to me as David and Barry are both innocent.

---

ADD State of Things Observations

Wearing my ADD co-chair hat, I’ve been thinking about the discussion had during the Sept 10th [1] and Sept 15 [2] Interims, and the subsequent list thread “My single use case” [3]  and the current draft-box-add-requirements [4] and it seems that there may be emerging two classes of Discovery situations that the group is discussing that are based on the complexity of the environment that the client is in.

 I’ll expand on what I mean by complexity father down in this note, but for now the two classes are:

(1) Low-complexity environments.  – this would include the case that started the “My single use case” thread

(2) High-complexity environments – this would include the RFC1918 situations,  networks with more advanced technical controls, networks/devices with applied policy controls.


Complexity
--------------

I call this differentiation Complexity because at the heart of the discussions it seems that it is the number different factors which need to be satisfied that emerges in the discussions and that these factors aren't simply classified in to distinct buckets that can be individually satisfied without consideration of other factors in other buckets.

Throughout various drafts, threads, and discussions the group has had a variety of operational and technical factors raised from a variety of situations.

Some factors have been operating in RFC1918 networks with CPE devices that use stub-resolvers;    Other factors have been concerns about network or device configuration requirements set by secured networks or devices; While other factors have considered the desire to be able to group associated resolvers together either by being operated by the same org, or by having the same policy set, or by same behavior set; Others have been how to operate in captive portal environments; .... and the list goes on.

This list can of course can contain complexities from the threat level of the environment or the device itself that could be considered.

The presence of such a wide variety of factors increases the complexity that a discovery mechanism needs to operating in, and in turn the complexity of the discovery mechanism itself.

Complexity is not a fixed thing - it is a spectrum of levels from very simple environments, to  more complex environments such as the  RFC1918/CPE situation, through to tightly managed situations, and even to very secured networks/devices.


Where we seem to be at
---------------------------------

That has led to a bifurcation that is well captured when you take into account the discussing in the "My single use case" thread, and the different breakdown of situations listed in draft-box-add-requirements.     The group has members with interest in working of discovery in difference levels of complexity.

We also have a couple of deployed, but not necessarily scalable,  approaches being used today by Firefox, Chrome, Microsoft, and Apple that currently are could be classified as simplistic versions of how you approach the discovery problem in the least-possible complex environments.    A good example of this is documented in draft-rescorla-doh-cdisco [5].

Recognizing that the complexity is a spectrum ranging from low-complexity, to mid-tired, to high-complexity it occurs to me that a path ahead maybe to recognize this aspect and instead of fighting it - incorporate it into the WG group's approach, and not to try to have one answer that works everywhere.

To that end I'd like to propose the following:

(1) To the authors of Draft-box-add-requirements:

Draft-box-add-requirements details different environments, but it does so from a perspective of listing each environment and the requirement that is then needed.   Based on comments at the Sept 10th Interim, some participants took it to a an attempt to create an aggregated list of requirements that any ADD Discovery solution would need to satisfy, with of course the entirely reasonable reaction from many that such a list of MUST requirements would be boiling the ocean and would potentially ignore that the lower handing fruit of the very low complexity environments.    I don' think that it was the intent of the draft authors to create an all-encompassing list of MUST requirements.

To that end, I would like to suggest to the draft-add-box-requirements authors (and anyone who'd like to help them) to update the draft with the technical feedback they received from the Sept 10 Interim, and to attempt to restructure the document and its requirements around the ideas of complexity of the discovery environment, and the second idea that while the document captures requirements that exist in a variety of increasingly complex environments. These higher complex requirements don't all need to be addressed in the output of ADD for ADD meet the needs of the environments with the highest demand.

The resulting new document would start with looking at low complexity environments and work up to higher complexity environments, with the requirements not being a set list of must-meet requirements, but instead a capturing for reference the spectrum of discovery situations that exist in the deployment land scape, with a recognition that there may be discovery methods which only work in the lower complexity ranges.  It would also attempt to document the environmental complexities as it identifies requirements.

(2) To the working group/other document authors

If we view the landscape of discovery mechanisms as working within particular ranges of complexity,  can we begin to recognize that aspect in the various draft approaches that have been put forward ?

This would in practical terms end up with proposals that are specifically targeted at different levels of complexity. A discovery mechanism proposal would identify and declare the level of complexity and any specific environmental complexities that it is intended to operate in as part of the draft.

I'm not suggesting that the ADD group try to produce distinct and unique discovery approaches for every possible environment.  Practically speaking there seems to be a few - perhaps as little as 2 or 3 - specific levels of complexity that group participants have brought up repeatedly over time.    If we accept that a single solution may not fit all situations, then the group can perhaps organically focus its work around the  simple low-complexity case,  and around 1 or 2 other specific complexities.     After all the output of ADD is entirely dependent on the group's participants coming together to work on the aspects that they rate as important to put their effort into.

Of course it would be nice if there was some commonality in how things work, and hopefully that is something that can come about by having the work commonly done in the same group, but it seems that recognizing that there are different levels of complexity that need solutions can be an important step.

(3) Form tiger/design teams to work on this

There’s already a number of good proposals that cover discovery from a couple of different approaches, and we’ve heard from many of them in WG sessions.   With those ideas as seeds, and with the discussions the group has had now would be a good point to create design teams to work together and come back with proposals for the different complexity situations.    For a start I would propose a group that will focus on the low-complexity environment and second group that would focus on the RFC1918/CPE Stub resolver environment.  If there is a third one it likely would be set-policy/enterprise discovery, which could over a broad variety of environments beyond enterprise.


It's up to the ADD group members
--------------------------------------------

In the end the ADD group will go in the direction the group participants want it to go in.   So please share your thoughts on the above approaches to the ADD mailing list. Is this a workable approach?


Regards
Glenn  Deen, ADD co-chair



----
References:

[1] https://datatracker.ietf.org/doc/minutes-interim-2020-add-01-202009101300/
[2] https://datatracker.ietf.org/doc/minutes-interim-2020-add-02-202009151300/
[3] https://mailarchive.ietf.org/arch/msg/add/IiYpAQ0ujdp0mlUzi1YB2cYYMT8/
[4] https://datatracker.ietf.org/doc/draft-box-add-requirements/
[5] https://datatracker.ietf.org/doc/draft-rescorla-doh-cdisco/