Subject: Working across WGs versus charter fetishes

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Apr 2015 12:36:16 -0400

In theory the purpose of having the IETF meet as it does is to
encourage people in different areas to work together.

So why is it that whenever I propose designing something for WG A in a
fashion that allows it to be used by working group B along the road
that there is a constant chorus of 'out of scope'?

If we are going to work together then it has to be possible for
someone in the S/MIME world to say in their WG 'hey, OpenPGP has
already done it this way, why not copy'. Equally it should be possible
for someone in IPSEC to say 'hey, the TLS folk have won, why not work
on a common approach to key exchange'.

Instead anyone suggesting that we try to do things in a consistent way
across IETF have to keep explaining why an approach that allows for
consistency across WGs should be considered.

I think people need to think very carefully before entering into
discussions if the only input they have is to shoot down a use case.

If there are two proposals on the table and no clear way to choose
between them, the way to address the issue is to look for more use
cases that can serve as a tie breaker.

The point of working group focus is to get work done. Litigating the
question of whether a use case has standing is invariably a waste of
time. None of us can fully anticipate the uses for which a technology
will be put and the most successful IETF protocols are precisely the
ones that have supported such uses.

Just because a use case is on the table does not mean that there is an
obligation to address it.

The point of a charter is to focus a working group on a set of
deliverables. A charter should never become an obstacle to working
across working groups or across areas.

In the particular case that has set me off this time, the issue is
whether a not-yet WG would spin up yet another IANA registry for its
own exclusive use or make use of the MIME Content-Type registry.

Of course if you narrow the scope of the problem to one WG and nothing
outside its scope, there is 'nothing to choose' between the two
approaches. A new registry will serve just as well as the existing one
(besides creating more work) because the advantages of using
Content-Type have been ruled out of scope. But it doesn't bring any
advantage either.

One of the things we seem to lack in IETF is some sort of friction
when it comes to creating new registries. JOSE has just created a new
set of crypto registries instead of re-using the PEM set and there are
a half dozen other crypto registries besides. We seem to re-invent the
MIME content-type registry repeatedly. And quite why .well-known, URI
and SRV should be separate is a mystery to me.

In general, the way to get interoperation between protocols and avoid
silos is for people to use existing registries whenever possible.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 28 Apr 2015 17:03:29 +0000

> silos is for people to use existing registries whenever possible.

Sounds reasonable at first blush.  Perhaps this (more generally
unnecessary "siloization") is something sponsoring ADs and the IESG
might keep an eye on?

-- 
	Viktor.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Apr 2015 13:13:35 -0400

> unnecessary "siloization") is something sponsoring ADs and the IESG

I think it is something the IAB should push for.

Now I don't want to hold up the JOSE docs over this. But I do have a
fix for the crypto algorithm fiasco. Basically IETF should choose
exactly one mandatory algorithm for each purpose and exactly one
backup. And at this point the sets are pretty obvious and undisputed:

Mandatory: AES / SHA-2 / HMAC-SHA2 / RSA-2048 / DH
Backup: [Blank] / SHA-3 / [Blank] / [Crfg curves here] /  [Crfg curves here]

These and legacy code points would be the only ones for which new
entries are created. to use any other algorithm, one would have to use
an OID expressed in text or binary format as appropriate. There would
then be one draft per protocol explaining how to use such identifiers
in that protocol if that was desired.

This would kick all crypto algorithm discussions other than for
mandatory/recommended status out of IETF scope permanently. Anyone who
wants to can use any crypto they like but the only crypto anyone can
claim IETF endorsement for is the very limited set that has been
subject to IETF review.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Apr 2015 08:40:49 +1200

> that there is a constant chorus of 'out of scope'?

Maybe they didn't read RFC 1958:

   3.2 If there are several ways of doing the same thing, choose one.
   If a previous design, in the Internet context or elsewhere, has
   successfully solved the same problem, choose the same solution unless
   there is a good technical reason not to.  Duplication of the same
   protocol functionality should be avoided as far as possible, without
   of course using this argument to reject improvements.

       Brian

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 29 Apr 2015 06:55:50 +0200

On Tue, Apr 28, 2015 at 6:36 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

> that there is a constant chorus of 'out of scope'?
Thanks for your participation in joining work for the best of IETF. I know
there are people that prefer to separate issues for other purposes. So we
should discuss this issue including IESG.

I agree that it is very is to say out of scope, but the difficulty is to
confirm/convince with clear reason that it is out of scope. In technology
things are getting very very integrated, so it can be out of scope to make
things simple. On the other hand, the problem is due to work-management, or
in the hand of the ADs of those two WGs (WG-A and WG-B). However, if the AD
say it is out of scope that means it should be true. Furthermore, the
question must be answered by the IESG, or we can say why not having
cross-WG issues/discussion-list that we distinguish where we SHOULD
separate work and/or where we MUST join work. Usually the main job of
directors/IESG is to solve this problem of separate-works or inconsistency
in IETF works.

AB