Subject: Tricky cross-area topics

From: Adam Roach <[email-masked]>
Date: Thu, 3 Oct 2019 14:29:03 -0500

Working group chairs --

In an attempt to reduce the number of "late surprises" with documents 
found during IESG review -- that is, showstopping issues with uses of 
technology that can sometimes require non-trivial reworking of protocol 
mechanisms -- the IESG has gathered together a list of topics that 
frequently trip up document authors and occasionally entire working groups.

The hope is that Working Group Chairs can keep an eye on these topics as 
new work starts up in their working groups, so that appropriate experts 
can be looped in early in the process, thereby avoiding late surprises 
during IETF last call and IESG evaluation.

The high-level list lives at 
<https://trac.ietf.org/trac/iesg/wiki/ExpertTopics>. The intent is that 
this should be fairly easy to scan to see whether a document under 
consideration for adoption touches on any of the related technologies. 
Each area also has its own slightly more detailed page, linked from this 
list, that goes into the technology areas in a bit more depth; but the 
intention here is that anyone using a listed technology should reach out 
to a directorate, expert, or area director in the related area for guidance.

Please feel free to share this list with your respective working groups 
however you see most fit.

Thanks!

/a

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 3 Oct 2019 16:16:03 -0400

Adam,

On Thu, Oct 03, 2019 at 02:29:03PM -0500, Adam Roach wrote:
> <https://trac.ietf.org/trac/iesg/wiki/ExpertTopics>. The intent is
> that this should be fairly easy to scan to see whether a document
> under consideration for adoption touches on any of the related
> technologies. Each area also has its own slightly more detailed
> page, linked from this list, that goes into the technology areas in
> a bit more depth; but the intention here is that anyone using a
> listed technology should reach out to a directorate, expert, or area
> director in the related area for guidance.

One I'd suggest adding is transport security considerations for routing.
This one comes up regularly. 

-- Jeff (and Deborah would appreciate it if I found the several days to do
the writeup on it)

---

From: Russ Housley <[email-masked]>
Date: Thu, 3 Oct 2019 18:16:52 -0400

In security, you probably want to ask whether manual key management is proposed.  See RFC 4107.

Russ

> On Oct 3, 2019, at 3:29 PM, Adam Roach <[email-masked]> wrote:
> 
> Working group chairs --
> 
> In an attempt to reduce the number of "late surprises" with documents found during IESG review -- that is, showstopping issues with uses of technology that can sometimes require non-trivial reworking of protocol mechanisms -- the IESG has gathered together a list of topics that frequently trip up document authors and occasionally entire working groups.
> 
> The hope is that Working Group Chairs can keep an eye on these topics as new work starts up in their working groups, so that appropriate experts can be looped in early in the process, thereby avoiding late surprises during IETF last call and IESG evaluation.
> 
> The high-level list lives at <https://trac.ietf.org/trac/iesg/wiki/ExpertTopics>. The intent is that this should be fairly easy to scan to see whether a document under consideration for adoption touches on any of the related technologies. Each area also has its own slightly more detailed page, linked from this list, that goes into the technology areas in a bit more depth; but the intention here is that anyone using a listed technology should reach out to a directorate, expert, or area director in the related area for guidance.
> 
> Please feel free to share this list with your respective working groups however you see most fit.
> 
> Thanks!
> 
> /a
>

---

From: Dave Thaler <[email-masked]>
Date: Thu, 3 Oct 2019 23:25:39 +0000

In INT, under the Protocol Tunneling list of questions, you want to ask whether a tunnel type is being registered (the common issue being "no, we didn't think of that").

-----Original Message-----
From: WGChairs <[email-masked]> On Behalf Of Russ Housley
Sent: Thursday, October 3, 2019 3:17 PM
To: Adam Roach <[email-masked]>
Cc: IETF WG Chairs <[email-masked]>
Subject: Re: Tricky cross-area topics

Russ

> The high-level list lives at <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fiesg%2Fwiki%2FExpertTopics&amp;data=02%7C01%7Cdthaler%40microsoft.com%7Ca0c1fb15598e4baae05008d7484f6cbe%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637057378278079494&amp;sdata=4sC5Pm1q%2FaoPN99%2Fi%2B8bUYCPjxIDkGTxWNP4Ew4qm1w%3D&amp;reserved=0>. The intent is that this should be fairly easy to scan to see whether a document under consideration for adoption touches on any of the related technologies. Each area also has its own slightly more detailed page, linked from this list, that goes into the technology areas in a bit more depth; but the intention here is that anyone using a listed technology should reach out to a directorate, expert, or area director in the related area for guidance.
>

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 4 Oct 2019 08:28:01 -0400

> The hope is that Working Group Chairs can keep an eye on these topics as new work starts up in their working groups, so that appropriate experts can be looped in early in the process, thereby avoid…

I like this idea a lot, thanks IESG.

> The high-level list lives at <https://trac.ietf.org/trac/iesg/wiki/ExpertTopics>. The intent is that this should be fairly easy to scan to see whether a document under consideration for adoption to…

Please add "special use names" to the bullet on DNS. The classic case is the year-long nightmare around “.home” in RFC 7788.

I wrote a draft (and then have lately failed to update it from comments, but will before Singapore) suggesting some guidelines for IETF WGs to use in picking special use names, or finding alternatives, if it appears that a protocol “needs” a hard-coded domain name. There are some dragons, particularly if people want “a TLD” for their protocol.

Suzanne

---

From: Warren Kumari <[email-masked]>
Date: Fri, 4 Oct 2019 10:38:18 -0400

> Please add "special use names" to the bullet on DNS. The classic case is the year-long nightmare around “.home” in RFC 7788.

Yup -- that's actually mentioned in the "For a more complete
discussion of these topics, please see
https://trac.ietf.org/trac/ops/wiki/WikiStart" link, but the summary
was overly terse - I just expanded it with "special use names".

Thanks!
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Jim Schaad <[email-masked]>
Date: Fri, 4 Oct 2019 10:27:57 -0700

Things that are missing in my opinion:

ART:

Application Layer Security: Is missing COSE, and CMS 

Expanded:  When application layer security is specified for a protocol, issues that must be addressed include:
 1) Matching of entities and keys:  Who is doing the matching?  What needs to be done for naming?  How is matching revoked or timed out?
 2) Supported algorithms and what the migration path should be.
 3) Algorithm and capability negotiation:  What do we both support and how do we find out?  The issues are different between online and store and forward.
4) What security properties are needed, two common ones are confidentiality and data origination.  (Note data origination is not the same as integrity.)

Security area does not discuss any store and forward issues.  Examples are CMS, X509, and so forth.

-----Original Message-----
From: WGChairs <[email-masked]> On Behalf Of Adam Roach
Sent: Thursday, October 3, 2019 12:29 PM
To: IETF WG Chairs <[email-masked]>
Subject: Tricky cross-area topics

Working group chairs --

The high-level list lives at
<https://trac.ietf.org/trac/iesg/wiki/ExpertTopics>. The intent is that this should be fairly easy to scan to see whether a document under consideration for adoption touches on any of the related technologies. 
Each area also has its own slightly more detailed page, linked from this list, that goes into the technology areas in a bit more depth; but the intention here is that anyone using a listed technology should reach out to a directorate, expert, or area director in the related area for guidance.

Thanks!

/a

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Sat, 5 Oct 2019 07:40:04 +0000

Thank you Dave for your review. Can you check whether https://trac.ietf.org/trac/int/wiki/IntAreaIssues is OK for you ? Esp the reference to IANA

Regards

-éric

On 04/10/2019, 01:26, "WGChairs on behalf of Dave Thaler" <[email-masked] on behalf of dthaler=[email-masked]> wrote:

    -----Original Message-----
    From: WGChairs <[email-masked]> On Behalf Of Russ Housley
    Sent: Thursday, October 3, 2019 3:17 PM
    To: Adam Roach <[email-masked]>
    Cc: IETF WG Chairs <[email-masked]>
    Subject: Re: Tricky cross-area topics

    Russ

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 6 Oct 2019 11:12:03 +1100

Random thought -- we make WGs jump through a minor formal hoop -- the shepherd writeup -- before going to IETF LC, to make sure they've done everything the need to and save later work.

It might be good to start doing something similar when they *start* a new document, to make sure they take things like this into account. Otherwise, I suspect this wiki page is going to get... dusty.

Cheers,

> On 4 Oct 2019, at 10:28 pm, Suzanne Woolf <[email-masked]> wrote:
> 
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 Oct 2019 12:43:51 +0200

Mark Nottingham <[email-masked]> wrote:
    > Random thought -- we make WGs jump through a minor formal hoop -- the
    > shepherd writeup -- before going to IETF LC, to make sure they've done
    > everything the need to and save later work.

    > It might be good to start doing something similar when they *start* a
    > new document, to make sure they take things like this into
    > account. Otherwise, I suspect this wiki page is going to get... dusty.

The trend is supposed to now be that shepherds are assigned when the document
is adopted.  That is so that they can watch to how the consensus is formed.
That write-up can't be finished until the WGLC, but it should be started when
the document is adopted.

So I'm agreeing with you: we should go through this list earlier.  But I
think that it can be done as part of the shepherd process.  I suggest that
the write up template include the top-level overview (area list + links) from
this document.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 6 Oct 2019 13:57:10 +0000

I have never heard, nor been told that.

I have also heard and been told that the WG chairs, perhaps with observation by the AD at a meeting, decide consensus.
 
Where did you get this?   Is it written down in any guidance for WG chairs?

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 Oct 2019 16:23:40 +0200

> I have never heard, nor been told that.

It could be that I've made this up, or that it's just something I've been
doing.  But, I don't think that I'm alone in this delusion.  I know that it's
not widespread.  Nor is the practice of trying to have people who are not the
WG chair be shepherds.

A reason I give for doing this is because it trains people up a bit to be
able to become WG chairs.  And it gives the WG chairs (and AD) a bit like an
idea if the person would make a good chair.... and lord needs we need more WG
chairs (and more diverse of them), because... only WG chairs can become ADs.
[an unwritten rule enforced by IAB]

    > I have also heard and been told that the WG chairs, perhaps with
    > observation by the AD at a meeting, decide consensus.

Yes, WG chairs should be trying to judge consensus at meetings, and on
mailing lists.  The shepherd's job is to observe and report whether this
process worked well or not.
 
    > Where did you get this?  Is it written down in any guidance for WG

Sorry, I don't know.  I could wander around the WG chair pages and look again.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 6 Oct 2019 10:37:08 -0400

Michael, you seem to be mixing several things.
Using the shepherding job to help train folks is something I have seen 
discussed in several places, anbd tried to do.
Appointing shepherds early is practiced by some working groups and not 
others.

But in no case that I know of is the shepherd's job to report whether 
the WG process worked well.  the shepherd report does include whether 
the consensus was rough, clear, ...  But that is NOT a report on whether 
the process worked well.

Yours,
Joel

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 Oct 2019 18:08:28 +0200

Joel M. Halpern <[email-masked]> wrote:
    > the consensus was rough, clear, ...  But that is NOT a report on
    > whether the process worked well.

My words were poor.
I mean what you said!

The point, though being, that the Shepherd is not determining consensus, but
just reporting on the flavour of it.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 Oct 2019 18:09:05 +0200

Joel M. Halpern <[email-masked]> wrote:
    > Michael, you seem to be mixing several things.  Using the shepherding
    > job to help train folks is something I have seen discussed in several
    > places, anbd tried to do.

Have we codified it all yet? I don't think so.

    > Appointing shepherds early is practiced by
    > some working groups and not others.

okay, so it's a practice I'd like to spread.

---

From: Warren Kumari <[email-masked]>
Date: Sun, 6 Oct 2019 13:44:38 -0400

> Have we codified it all yet? I don't think so.

I don’t think we really need to codify it - I think it's just in the common
lore category.

As an AD, I've found that non-chair shepherd write ups are variable in
terms of quality, but generally better than chair done ones -- but whatever
the case, having the write up done by a participant is my preference as it
provides people a chance to see doing things like chairing isn't scary,
 takes some load off the chairs, and also provides an extra view point.

W
apologies for typos - typing one handed on phone as I'm sitting in urgent
care - I cut my thumb open... :-(

> okay, so it's a practice I'd like to spread.
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Oct 2019 08:44:05 +0200

Warren Kumari <[email-masked]> wrote:
    >> 
    >> Joel M. Halpern <[email-masked]> wrote: > Michael, you seem to be
    >> mixing several things.  Using the shepherding > job to help train
    >> folks is something I have seen discussed in several > places, anbd
    >> tried to do.
    >> 

    > I don’t think we really need to codify it - I think it's just in the
    > common lore category.

I'd like it to move up to "obscurely written lore" category; perhaps with a
discussion about pro/con....

    > terms of quality, but generally better than chair done ones -- but
    > whatever the case, having the write up done by a participant is my
    > preference as it provides people a chance to see doing things like
    > chairing isn't scary, takes some load off the chairs, and also provides
    > an extra view point.

That's pretty much my reasoning.

    > W apologies for typos - typing one handed on phone as I'm sitting in
    > urgent care - I cut my thumb open... :-(

And that's the reason to make sure you have three or four fingers (thumbs) on
two hands initialized for fingerprint unlock of phones :-)