Independent Stream Open Meeting (ISOPEN)

IETF-120, Vancouver
Friday 26th July, 9.30am - 11.30am
Regency C/D

• Materials
• Minutes and notes
• Chat room

• Recording

• Chairs: Mark Nottingham mnot@mnot.net,
  Adrian Farrel adrian@olddog.co.uk

• Note-taker: Sue Hares
• Independent Stream Editor: Eliot Lear
  rfc-ise@rfc-editor.org

Administrivia and purpose of meeting

Mark Nottingham: Note well described.

Adrian Farrel: Please behave

Mark Nottingham: This is a one-off meeting. Review of agenda

No comments on agenda bashing

Introduction to Independent Submissions

Russ Housley and Eliot Lear

Chat notes that Joyce Reynolds name was missing from some slides. An
updated version of the slides failed to be picked up by Meetecho.

David Schinazi: I missed the SAAG session. Can you summarize it?

Eliot Lear: It was a healthy discussion, but lengthy - so I will let the
Security AD describe it.

Deb Cooley: We will publish a summary. It was a healthy discussion and
we received a lot of feedback.

Paul Wolters: I just want to point we are not trying tp prevent people
from using various cryptos. We simply believe that can get codepoints
without RFC numbers.

Peter Liu: Yesterday, we raised this question in SEC and it was routed
here. For some national design cryptos, what are the reviews or
endorsement or open procedures we should go through prior to turning to
the IETF (for standardization).

Eliot Lear: Let's defer that question for a while.

Mark Nottingham: Can we hold this discussion until we complete the
slides.

Questions about the presentation

Liang Xia: In the cryptographic page, there are SM2 and SM3 of the
DNSSEC is on hold right now because it is not implemented worldwide.
However, there seems to be interest. In this case, how do we proceed?

Eliot Lear: That is correct. There's actually nothing written. You are
correct to call out this particular case. What has been concerned is
that I ha asked fro at least an implementation as a DNSSEC extension.
I'm not rejecting the drat. I just want to see more implementation
interest.

Liang Xia: I just wanted

Mark Nottingham: The slide on the screen is missing some text (should
be: No stream is an island.)

Paul Hoffman: You said correctly that there is a rule that ISE streams
cannot create IANA registries.

Eliot Lear: In general.

Paul Hoffman: IANA can create registries.

Eliot Lear: There is an RFC governing the creation of registries.
(should be added here)

Paul Hoffman: You state encryption and crypto algorithms; Please clarify
what exactly you are meaning. Is it the algorithms, or the mechanisms.

Mark Nottingham: (missed comment)

Paul Hoffman: I am not disagreeing. I think it fine.

Eliot Lear: I'm only going to answer your question with an example. IF
someone stated "here's the SM2 and SM3 descriptions"

Mark Nottingham: Will the RFC editor board stand up. (add list and link
to notes. )

Eliot Lear: The editorial board serves at the pleasure of the ISE.

Community feedback and open discussion

Peter Liu: so continuing questions about the review process.
Understanding the ISE does not have the capacity to really review the
crypto primitive. (This was also discussed in the sec session.) Will
there be some reviews by outside crypto organization like SP or Orkland?
We would like an endorsement before going to the IAC.

Eliot Lear: I have experts on the crypto, but I will be looking to SAAG
to set direction for this discussion.

Peter Liu: If we need competition or open publication, let us know.

Jim Fenton: I would like to challenge the statement that the ISE is not
an end run and doesn't publish standards. Some RFCs from the ISE look
like documents that have gone through the IETF consensus process, often
containing normative keywords, but the ISE documents have not. This
waters down the value of the "RFC" prefix.

Adrian Farrel: Is the focus whether the standard should look less like
standards, or is it just the existence of the document?

Jim Fenton: It is the RFC prefix on the document number. Maybe it should
be replaced with ISE or something (i.e., ISE xxxx)

Martin Thomson: I'm not a cryptographer. I'm here to talk about the
structure of the system. I heard Eliot use the word "I" quite a number
of times in his presentation. We have relied for 30+ years on
exceptional individuals fulfilling this function. As an organization, we
should do away with the reliance on individuals. We can have a long
discussion on the availability of websites and GitHub pages and various
other things for publishing dissenting opinions. But we do need the
scape valve.

Adrian Farrel: Do you have suggestions for what we could do instead?

Martin Thomson: That's the hard part. I would like to hear what other
people have to say. My thoughts are not complete.

Richard Barnes: I'm in offline mode. I will start where Martin left off.
I think the first step is to get the procedures described by Eliot into
documents. Based on capturing this information, we should go through and
write nors for these process. I would like to endorse the prior two
speakers heartily. Also thank Russ Housley for overview, I found your
slides interesting on why one needs an RFC for all of those things in
contrast with all the other ways of publishing. We have to take the
purposes in mind together with the costs and the confusion. I think you
risk confusion about the goals and opportunities and if you take them
all into account you end up with a very narrow set of things that need
to be RFCs. What is the niche in the modern world?

Liang Xia: I think we are generally talk about the same thing. About the
cryptographic, no matter if it is national, we do not have a way to
define and publish it. It is really good to consider if there is a good
way (or policy) on how to publish the standard. Some times, we need a
ISE document. My suggest is that perhaps we can create a registration
process for the new cryptographics (not just a registry).

Lars Eggert: The previous speakers (Martin and Jim) is what I was going
to say. There is a very narrow class of document where the IS is the
sort of outlet for what there isn't any other outlet. But there is a
narrow area of work, and there a few examples where confusion between
the streams (IETF and ISE) is desired. I'm wondering if there is another
example. I found there is a large fraction of the IESG mindshare time
that is needed for the fuzzy area between the ISE and IETF, and if we
could eliminate that it would help the IESG.

Harald: The problem with the IESG mind share occupied by ISE was the
cause of me writing the first document on the IESG review of IS
submission in 2004. The RFC series contains a lot of things which should
never be referenced (Historic, April Fools, Bad Ideas, Experimental).
The problem of things in the series that should not be referenced is not
significantly changed by the IS stream. The RFC has so many good
documents, that people forget that it also contains bad things. We need
more bad RFCs.

Stephen Farrell: I'm happy to help (with bad RFCs). Harald said most of
what I wanted to say I also do not think there is as problem with the
current set-up. The IETF stream has just as much of a problem with
people misunderstanding the status of documents. We do depend on
individuals - which is better than the "bait-switch" of companies.

David Schinazi: I want to talk about the purpose or benefit of
publishing docs on the IS stream.

1. We already covered alternate viewpoints. Better served by something
   else these days unlike when the ISE Stream was created
2. Interoperability is not served by immutable RFCs. Once published,
   you can't fix any bugs. Example of Http3 launched without RFC
3. We have an IETF policy on IANA registries which was we have change
   control in the expert review. There are a couple of registries that
   have RFC control. IETF has largely moved away from that to expert
   review etc. This historical reason is no longer required. I think
   there a couple of registries that still have "RFC Required" but
   those should be fixed.
4. Cryptography is a domain where more isn't always better. A small
   number of well peer-reviewed solutions is better than a large buffet
   of options that have been reviewed less. We should leave that
   responsibility to the IETF. If we fix the IANA registries we don't
   need to publish RFCs.

Based on these four points, I have a proposal. I think that the IS
stream should be reduced to April Fools RFCs. As an IAB member, we could
update RFCs that update the ISE model. I am happy to help the IAB to
update those documents.

Andrew Campling: Pushing back politely on suggestion to make terms of
reference tighter and not rely on the person: I think that ambiguity in
this role is actually a feature and not a bug. It would be a mistake to
be overly prescriptive as exactly how it operates. It is a good thing to
have an outlet with some flexibility around it. Don't change this
flexibility. To the comment in the chat about "the RFC brand". Brand
change is hard. Be careful.

Adrian Farrel: Jumping in before Kathleen. We heard a little bit from
IAB members, but one of the big purposes of this meeting is to get
information for the IAB. The IAB members should give us specific
question.

Kathleen Moriarty: We need the release valve. I agree with Harald and
Stephen - there are a lot of RFCs that are bad. So the quality of the
RFC stream is not something we have control over. I also think that the
IAB and IRTF streams need to be considered in concert with the IS stream
with regard to additional labels or removing a label.

Ted Hardie: I think one valuable output from this would be documenting
the ISE process in a way that would allow anybody in the community to
understand where the failure modes are. I think once we have that we
coud have the conversation on whether the failures modes are bad for
specific types of things in the IS series. After a careful review, we
can determine what changes need to be made in the complex system. As
David Schinazi, if the consequence of the failure mode is we don't get
funny things once per year - is a different failure mode than we do not
feedback on why people thought the IETF RFC consensus could have been
done different. For example, the write-up of Fred Baker writing up the
way that Cisco did a particular protocol. It was not sufficient for an
IETF Consensus document, but it helped the community know how things
worked and it contributed to the dialog.

Martin Thomson: Yeah, there are so many things to cover here. Harald's
point on bad RFCs: I agree there are a lot of bad RFCs for various
reasons. But there is a difference between consensus that something is a
bad idea and lack of consensus that it is a good idea. One of the things
I've observed is the consent degree that Microsoft in early 2000s had a
great set of document that differed from the IETF standards. These
Microsoft documents were precise and well written and all hosted by
Microsoft on the Web. The release valve is a lot larger - the size of
the Internet. The question of bad RFCs is better recognised by changes
in the IETF (not here). At lot of people put effort into documents only
to find that they don't have consensus and then they look to the IS
stream. The ISE's queue reads like a litany of the failures of the IETF.

Adrian Farrel: So thank you for drawing the line between what is the
Independent Stream doing and what the IETF Stream is doing. It is really
hard to have this conversation without the overlap. I think I heard that
things coming from the IETF stream have consensus. Maybe without getting
into a discussion of all the IETF stuff, there is some fixing to be done
there that would make it clearer where to draw lines.

Jay Daley - IED: A big part of the role of the LLC and the Secretariat
is developing content and other things to help people understand the
IETF in the broadest sense. Until recently the IETF web site had almost
nothing about the Independent Stream. That has now got something on it,
but there is still very little information about this out there. That
makes most of the Independent Stream something only for IETF insiders.
The problem is that if it becomes well-known it will not scale.

Richard Barnes: I wanted to pick up on a thread that Martin raised and
tie it back to this thread of confusion. The confusion is not between
good documents and bad documents. The confusion is between things that
have a broad consensus and things that are whatever Eliot decides to
publish. Not to say Eliot doesn't have process and he is doing a good
job. I would like to tie that to the question of whether national
cryptographic algorithms are published. National governments surely have
a way to publish elsewhere. Here is a case where there is a clear
conflict in branding and unknown (misunderstood) process.

Wes Hardaker: As an IAB member, we need to know what the community wants
in the Independent stream. When is it the right time for the relief
valve. When is the bad time for the relief valve. We want to put the
characteristics of "good relief valve" documents and "bad relief valve"
document. This brings me to the cryptographic discussion. The IAB
sometimes gets early warning about when we need to change our processes
- to get specific things (like the big code point table). The ISE can
give us an indication of when we need to make changes to not need the
ISE so much. Summary: When should the IETF process change.

Bron Gondwana: I'm trying to work out what the properties of the ISE
that make it worth publishing there because anyone can put anything up
on the Internet. The value is editorial process. The editorial team does
a better job of creating a quality publication that I can write myself.
Prior-art relevance. You have a central place for archival. Most web
pages from 20 years ago are no longer referencable. There are IANA
registies that we must have will not go away if a published document
disappears. But the RFC brand seems to pretend that the document has
IETF approval. We take that away and a lot of the arguments go away. We
get all the benefits without the disadvantage of putting an IETF label
on it. It needs to have a different name that is not "RFC".

Eliot Lear: I'm still trying to listen to get feedback on how Eliot can
do his job better. I want to make a few comments on how the streams work
in relation to other streams (to give clarity).

• Sometimes the streams are looking to the independent stream so they
  an document things without having to go through the consensus
  process And a good example of that type of document is the
  informational document like scion that have been published.
• Documentation of a new Email headers and extension is a place were
  the effort to create a document is smaller within the ISE than
  creating a WG (or AD sponsored document).

Just some food for thought.

Colin Perkins: People keep talking about the role of the Independent
stream as an escape value. Few RFCs on the Independent stream critique
what the IETF is doing. I see RFCs publishing where the IETF has no
consensus to publish it, but not critique in IETF publication. I think
the latter would be a good use, but the former is not a good use.

Paul Wolters: An example I was involved in was TLS/DNSsec chain
document. It wasn't that the TLS WG was against it, was just that we
didn't want to spend more time on it; there were two parties that did
not agree.

Pete Resnick: There are two competing things:

1. Value of the ISE Colin was talking about
2. The marking value of the RFC series

It sounds like we are focused on the "marketing value of the RFC". This
may not be the right forum for that discussion. I hope the value is in
the IETF not in the RFC label.

Liang Xia: What is our next step? Do we have a plan to document our
policy or process?

Deb Cooley: [no hats, no employer] If you shun national crypto, you
would almost be devoid of crypto. Think about the fairness of allowing
some national crypt and not others. The publication of crypto is a good
use of the Independent Stream. Vendors are not interested in
implementing I-Ds. People want RFCs due to the stability.

David Schinazi: First to respond to Deb, I think we've been using the
term national crypto as a shorthand. We shouldn't be. The term should
really be "not widely peer reviewed crypto. Feedback to Eliot - publish
fewer RFCs. Point 2, we've been talking about kind of marketing value of
RFCs. When an RFC is published, I have been able go get code in
open-source implementations.

Eliot Lear: One point of information RFC4846 says ISE will use the
preponderance of reviews I receive on a document. Send me reviews saying
"I don't think this should be published" etc.

David Schinazi: As IAB member : please do that and please cc the IAB. On
areas of new work the IETF should consider: interesting, but no the
ISE's job.

Suresh Krishnan: I looked at this on the IESG. I suggested we should
drop the RFC label. The response I got was "the IETF does not own the
RFC brand"

Eliot Lear: The RFC does not belong to the ISE either.

Suresh Krishnan: On the RFC publication I asked that RFC7974 not be
published, but it got published. What are the rules? Give us some
visibility into your queue.

Eliot Lear: Please look at the datatracker for the stream ISE and see
all the documents. There are also states in the document. I use "I" more
than I should. The reviewers do most of the work.

Suresh Krishnan: I appreciate that Eliot is doing a good job in getting
reviews from many people. Need to evaluate whether more reviews
compromises the independence of the stream.

Nicola Rustignoli: I am one of the authors on SCION document. I want to
echo what Eliot says. The Independent Stream publication allowed us to
get valuable feedback on a protocol developed outside the IETF. We're a
bit in between research and IETF. This is important to document as what
has been done. Without the ISE we might have had to go "somewhere else".

Nick Sullivan: CFRG co-chair. There are no CFRG or IETF or ISE RFCs that
define national crypto primitive, whether US or otherwise. I do not see
why we should start now. WG themselves set their own rules for code
points which involve having a stable document. I recall that 22519 came
through CFRG before going to FIPS and being made part of national
government standards. The pressure for publication of crypto primitives
as RFCs that have already gone through national organizations is
misguided.

Stuart Card: In our work for drone remote ID protocol group (DRIP), we
had to coordinate with lots of other SDOs in the aviation communities.
They want to hear about RFCs not drafts. Our own documents say don't
cite drafts. So it is a brand. The vast majority of 8 billion humans
have never heard of an RFC and don't care. In networking only vague
notion. I would like to suggest that we have lots of other tagging
mechanism (BCP, standards, and others) that we have not used well.

Peter Koch: I think we are having three discussion:

1. national crypto, (little to do with ISE)
2. is gate keeping function for all streams working the way it was
   envisaged (solution not with ISE but with predefined policies) only
   two points made

Bron Gondwana: People who differentiate between ISE RFC and IETF
Consensus RFC are only in this room. Those who can should protect that
brand.

Richard Barnes: What I've heard today is that there are lots of
constraints and considerations that are not written down. So the lack of
these considerations create confusion about the publication process of
the ISE. I would happy to contribute to the process of writing
down/refining the constraints and considerations.

Wrap up and next steps

Adrian: Thank you to the room for being civilized. Can I call on Tommy
to say what he has heard from an IAB perspective, and what the next
steps are, and where this can be discussed further.

Tommy Pauly (IAB chair): Certainly we at a high level, there is a
diversity of opinions and perspectives and experience. And I think
that's very good to hear all of that come together here. Many of the key
items that people are bringing up seem to be about the relationship
between the ISE and the IETF, and how perceptions of the work being
done, and how work transfers between the two different bodies. As for
some concrete next steps, I think we want to look at the notes before
proposing the next steps. Please email other thoughts to the IAB or the
ISE. I did hear reoccurring themes: How the RFC brand is perceived.
Seems to be one of the underlying tensions in discussion regarding what
happens.

Mark Nottingham: Thank you Tommy. And just on that last point, it's
apparent that there are some kind of higher-level issues here about the
RFC series and one can think of those as policy issues. We happen to
have a group that is in charge of policy for the RFC series. And the
chairs of that group are in the room. Pete and Russ. Can you suggest
what the steps might be for that group.

Pete Resnick: It is in scope to discuss a lot of these issues in RSWG.

Russ Housley: Building on what Pete said, one of the RSWG is asked to do
is to distinguish between operational things and policy things. We are
only on the policy side. But part of the struggle in the working group
is to determine where the gray area is between those two.

Eliot Lear: Big action for me: People want to have a little more
visibility/comments into the ISE process. Two things already done:

1. Working with Robert Sparks to make the reviews are tagged as public
   and and open.
2. I can document the process a little more. How it works today is
   different from how it might work in the future.

Adrian: I wonder if people could send you feedback on which RFCs they
which hadn't been published and how bad they think it was.

Eliot: Yes. Which ones have caused harm and which helped.

Mark Nottingham: The home for the discussion on Crypto is in the
security area.

Eliot Lear: I will try to process the documents that come through. I
will put a big statement in crypto documents to say "use at your own
risk."