[dns-at-ietf] Re: Discussion: big groups vs small, focused groups

[Petr Špaček <[e-mail]>]

On 06. 11. 25 7:03, Wes Hardaker wrote:
> Petr Špaček <[e-mail]> writes:
>> Can we try do BCPs @ DNS-OARC for couple years and see how it goes?
> 
> [disclaimer: I'm a big fan of DNS-OARC generally, but the questions
> below are really how to make this potentially work if this is the
> direction chosen]
> 
> 1. DNS-OARC doesn't yet have a publication stream at all, aside from a
> blog, which can certainly be remedied by creating one.  Certainly it
> fits within their current description under the "Information Sharing"
> category.

Sure. On this mailing list we are discussing how to change things, so 
let's assume we are actually allowed to change things for a moment.


 > My recollection is that occasionally (very rare) do have> "membership 
only" meeting slot; how would those potentially affect a
> published BCP if they were related as that differs from the always-open
> model of the IETF?

Fair question!

I remember one member-only session over last ~ 8 years, namely on topic 
of TsuName vulnerability and how to remediate it at registry/operator 
level before it goes public - with the intention to limit potential damage.

Please note that member-only session at in-person meeting is NOT the 
only non-public thing which is going on. DNS-OARC is routinely used to 
coordinate vulnerability response (= agree on possible fixes and 
publication date) among implementers before vulnerabilities are 
disclosed to public. This happens several times a year.

Funnily enough, a secret cabal group, coordinated via DNS-OARC secret 
channels, meet yesterday (in person in IETF hallway) to discuss what to 
do with yet another protocol-induced vulnerability which was reported 
recently. Blowing the information into an open mailing list before fixes 
are ready to go public would not exactly fulfill the purpose of 
responsible disclosure.

Now to the question of "How would those potentially affect a published BCP":
It means that - perhaps - timely information can be published/BCP 
updated in reaction to protocol vulnerabilities. With the speed of IETF 
process, we can _start_ the process when fixes go public, and then in a 
year have document. Maybe.

As an example, latest versions of BIND stopped accepting RFC 9471 
section 2.3. Glue for Cyclic Sibling Domain Name Servers to counter 
specific cache poisoning attack. Code fix was published like two weeks 
back. What would be your time estimate for updating RFC 9471 to say 
"this is not gonna work, don't even try that"?


> 2. If DNS BCPs were to be written at DNS-OARC, then we may have to
> reference external publications from our IETF streams at times.  This
> already happens so seems possible.  But do you foresee any complications,
> especially if we have cases of timing dependencies, or, worse, circular
> dependencies that are handled right now through internal clustering?

Sounds like rhetorical question, but I will respond anyway.

I'm software developer. I do foresee problems with circular dependencies 
in general. I also know they are routinely handled by cooperating 
parties. Let's assume cooperating parties.


> 3. How do we ensure enough IETF folk are participating in the external
> body (which is membership driven though has open lists)?  Or do you feel
> that operators are the ones to write BCP and thus protocol experts
> aren't as needed?  (that wasn't intend to be as leading of a question as
> it came out, but I'll leave it anyway)

It is a very leading question indeed.

If I look at active participants of dns-operations list, and participant 
list of DNS-OARC, and faces in dnsop, I already see a significant overlap.

Paperwork aside, DNS-OARC and IETF participation possibilities are the 
same in practical terms. Anyone can participant on mailing list, and 
attending in-person is paid.

Membership is really a red herring here as it has nothing to do either 
with mailing list or in-person meeting attendance.


Having said that all that, the main argument is this:
Current IETF's operational advice related to DNS (that is to say, also 
informational documents which tell operators what to do and so on) 
suffer from being ignored (see my previous e-mail, I'm not going to 
repeat the same examples). That tells me that - I guess - protocol 
designers might be over-represented in the process and at the same time 
the process does not take into account operational realities when 
formulating recommendations.


> 4. How do we ensure DNS-OARC publications are widely recognized as
> authoritative?  This is really a problem for all new bodies to widely
> publicize their intent to create new authoritative streams, and isn't
> really specific to OARC.

I think you answered your own question.

Best time to do this would be 20 years ago. Second best time is now.

Also, given my answer to the previous question, it seems to me you are 
overestimating weight _operators_ actually give to documents which come 
out of IETF. And BCPs without being recognized are piece of paper.

If we assume cooperating parties for a moment, as opposed to turf wars, 
we can publish a RFC which say 'hey, these folks know what they are 
doing, look over there for DNS BCP style documents' if we wanted to help 
to get this started :-)


> [5. I actually had one more but now I've forgotten it...]
> Naturally, right after I hit send I remembered it:
> 
> 5. Why is the DNS special such that DNS BCPs should be published in an
> external organization, but other protocol BCPs will be published in the
> IETF?  How do we handle the public redirection of only a specific subset
> of IETF protocols?

See previous two answers for context. DNS @ IETF have proven track 
record of ignored advice (and also unimplemented protocol documents, but 
that's a different topic). For me that is clear signal the current 
approach is disfunctional.

We know what they say about doing the same thing over and over and 
expecting different result. Let's not do that.
-- 
Petr Špaček