IETF 60 NEWTRK Working Group Minutes
New IETF Standards Track Discussion WG (newtrk)
Thursday, August 5 at 0900-1130
CHAIR: Scott Bradner <firstname.lastname@example.org>
MINUTES: These minutes were created by Scott combining notes taken by
Spencer Dawkins <email@example.com> with the session jabber
log Peter Saint-Andre.
Agenda Bashing: Chair
No agenda bashing took
WG status: Chair
The working group status is actually sort of muddled. Scott thought
that we were getting close to consensus on a two-step standards process
but mailing list consensus collapsed - we've only had about 15 posters
over the last month, only 8 in the past 2 weeks - hard to gauge
consensus with such a small sample size
We've officially missed our first milestone (in June), but we do have
a WG landscape draft (it's just not the one we're supposed to
Discussion of current proposals: David Black
Black/Carpenter ID draft-ietf-newtrk-proposals-00.txt
Larry Masinter - metrics should be correlated with our goals - most of
these metrics are timeliness, ignoring quality goals, for example
- outline various proposals without making recommendations
- tease out common and reusable ideas from various proposals
- identify pros and cons
- metrics for success? - improving interoperability, getting stuff
- faster, increase use of higher standards steps, make IETF more
Scott Lawrence - would like to see metric - reduce "conform to this ID"
Spencer Dawkins - metrics for success are hard, for failure easy
(Harald Alvestrand said this in ICAR)
Aaron Falk - move kind of review that we get from IESG earlier in the
Scott Bradner - i.e., less bounce-back from IESG to WG?
David Black - Less cross-area discusses?
Brian Carpenter - we're close to discussing ICAR metrics here
Bob Braden - standard quality may be inversely proportional to document
Eliot Lear - what does that mean in terms of what we're doing here?
Larry Masinter - concerned about metrics over which we have no control
eg., marketing references by marketing people e.g., if status of
document doesn't reflect status of protocol
John Loughney - how useful is this? Not all Internet drafts are the
same - WG drafts?
Brian Carpenter - Length of time for WG drafts to cycle from 00 to RFC.
Larry Masinter - things come into the IETF at varying levels of
maturity - harder to measure
John Klensin - need to be careful about success criteria metrics,
because they are easy to game - peer SDOs have already tripped over this
David Black - Rough consensus on the list that a standard is not
forever, no matter how many levels we use - we're never through
Scott Bradner - i.e., can cycle in grade, not just progression through
Keith Drage - IETF doesn't know how to incorporate errors and
extensions - when you stop changing a protocol, it's obsolete
Brian Carpenter - don't know how to handle trivial errors, either
Larry Masinter - Protocols change, documents don't (e.g., people post
changes at a website or in a research paper without coming back to the
Eliot Lear - some documents get old and crufty - stay tuned for details
Brian Carpenter - the words "old and crufty" are not in the current
draft, need to be added
Scott Lawrence - names of levels are at best ambiguous and at worst
misleading - having both "Internet Draft" and "Draft Standard" don't
work - we ought to fix the names if nothing else
Scott Bradner - related nit: we get IPR disclosures that say that 'X
will happen if protocol becomes an IETF Standard'
Larry Masinter - name changes are least important change - want to
encourage documents to be revised to match the protocols
Keith Drage - revision vs advancing in place is confusing - "moving to
next level" is problematic, need to be more rigorous
Scott Bradner - depends on the scope of changes
David Black - Proposals on the table -
Common ideas - snapshots, document what we've learned from
implementation and deployment, version numbers, better process
documentation and tracking
- clean up our act,
- go back to 2026 as written,
- prune levels to two,
- whack everything to one level,
- declare victory and don't change a thing (and document
differences between what we do and 2026)
Brian Carpenter - process documentation bleeding into shepherding, etc.
- need to coordinate
Aaron Falk - what happens in the working group and what happens to the
existing body of standards - need to think about both at the same time
- this could be disruptive
Keith Drage - what kind of tracking of "good" vs "bad" documents or
good vs. not so good, e.g., is tracking internal or external?
needs to be reflected by something on the cover of the document so can
be understood outside the IETF
Eliot Lear - I propose that we take "just revise 2026" off the table
John Klensin - note that defacto this means one standards level
David Black - so you want to take proposal 2 off the table? (room -
Larry Masinter - reality does match the written record, so first step
is to tell the truth about where we are today
Paul Hoffman - VPN consortium has to implement IETF specs - if we do
slash and burn, outside world will be very happy, levels confuse
vendors outside the IETF
Brian Carpenter - would those happy people want version numbers?
Paul Hoffman - absolutely - interoperability register, too
Kurt Zeilenga - not enough consistency in our current processes across
working groups to declare victory
Scott Bradner - process varies between areas, e.g., Routing Area has
Aaron Falk - snapshots could mean different things in different WGs
Larry Masinter - how well the proposals motivate individuals to write
true statements about the protocols
Keith Drage - interoperability register looks like a very good idea -
would anyone contribute?
Brian Carpenter - we didn't put pros and cons for version numbers in
the draft, and we need to
David Black - Questions: any major options missing? Do nothing?
Can we take this off the table? Without even documenting changes?
Harald Alvestrand - if we do nothing, we can stop now
Brian Carpenter - let's add a section on really doing nothing -
advantage of removing hypocrisy
David Black - Are descriptions accurate?
Brian Carpenter - I would like to see discussion of pros and cons on
Larry Masinter - pros and cons aren't right - will send text to the list
Paul Hoffman - for whom are we making changes? There are two audiences,
so could have two pros/cons lists
Brian Carpenter - want to refine pros and cons before we make choices
John Klensin - proposals overlap in funny ways -
Peter - decompose proposals into specific pieces? Maybe "yes" if we can
keep from screwing it up
Keith Drage - need reality check on proposal components to make
Spencer Dawkins - take stuff off the table if we can at this meeting
John Klensin - goodness as a criteria will fail - someone will like
anything, but people have to do the work, even though some things on
the list are evil - cost-benefit is harder and smarter
Larry Masinter - interoperability matrix doesn't evolve - too static -
make it part of another process
Aaron Falk - we've sidestepped comments on these proposals at this
Brian Carpenter - would like to see discussion on the list, because
this draft is a two-brain dump, not a WG document
Adding a layer of indirection to standards naming: Klensin
John Klensin - Two proposals, started off in different places, overlap
First some history - We adopted three document series for standards
track with one set of documents - BCPs and STDs exist only as an index,
and this creates problems that prevents much use of STDs
STDs should be real documents, which can be referenced and which can
capture changes over time
Two John proposals overlap a lot - difference is that John Loughney is
doing web pages and John Klensin is doing stuff in documents
We can't tell people to implement 2821 (PS) instead of 821 (full
Aaron Falk - if we are terrible writing AS docs, why would be good at
writing these new STD docs?
John Klensin - the question is how we document clearly and publicly
what the IETF was doing when, for example, 2821 can't replace 821,
except in protocol action notices.
Keith Drage - how will this help me from an external referencing point
of view? Problem is that we need to refer to things long before they
are full standards - proposal assigns STD numbers at Proposed
Standards. This might help with referencing something like TCP
Scott Bradner - actually TCP is now a poster child for this problem
Keith Drage - I'm more interested in things that are not yet standards,
such as SIP
John Klensin - Something I did not mention is that a standard
number goes on something the moment it goes to proposed. This doesn't
require changing the standards process. This makes it possible to say
things like "SIP is becoming like TCP and here is the list, but here is
what you need to pay attention to."
Bob Braden - we're creating a new namespace for standards, and this
makes a lot of sense (allows version numbers). RFC numbers are document
references, not standards references.
John Klensin - This is an attempt to separate documents registry issue
from the standards issue - two issues: (1) standards namespace (2)
boundaries of labels
Aaron Falk - there's a connection here with the PROTO team - need to
coordinate - trying to get WG chairs to write protocol piece of action
John Klensin - the proto team effort is probably an important component
John Loughney - I think John Klensin and I are attempting the same
thing how much do we capture and how do we do it? e.g., never clear how
updates and obsoletes work
Scott Bradner - need to say HOW a document updates another
Larry Masinter - working group splits the protocol into several
documents, and some of the critical details may be missing - need to
point to Informational, IDs, mailing list postings, etc. - and we need
examples to think about this more
Keith Drage - where are we headed, on document types? Is this a
bibliography, a document tree, a profile ... created when the IESG
approves a document? - these documents become a byproduct of IESG
John Klensin - this would become part of the process by which a
protocol action happens - errata are a procurement problem and a
lawyer problem - ASes were supposed to handle this, but they are rarely
used. "Must conform to STD 75 as of this date/version". And STDs have
abstracts, just like other documents have abstracts.
Scott Bradner - Another common experience is that a document has not
addressed a certain concept and would need to be addressed in a
revision, but there has no way to document those so that we remember to
address it when the
doc is revised
Bob Braden - John Klensin pointed out that errata on standards are
standards-track issues, so they've been pointing these to the IESG
Aaron Falk - don't we need version numbers if this is a
procurement-world concept - or at least dates and tracking history
John Klensin - conformance with STD doc as of a particular date
Eliot Lear - I like the idea, this is obvious in a web-based world,
draft is verbose (and will get longer with examples).
Larry Masinter - these documents need to be more prominent than RFCs -
RFCs contain pointers to current STD locator - what if the RFC gets
reused in more than one STD?
Bob Braden - it would be useful to separate namespace engineering from
mechanisms for publishing, so we can make progress - is SIP a standard,
or are there pieces? - need to be clearer about figuring out what goes
in a STD.
Scott Bradner - "standard 35, or standard SIP?" frequently our
standards are known by a colloquial name
John Loughney - what can we break out, in order to make progress? Make
a draft that's an example?
John Klensin - the proposals differ in maintenance models, but overlap
a lot. John Klensin concerns about web pages (as major mechanism) and
maintenance teams (which become self-preserving). My personal opinion
is that proposals
address same general space and main ideas are compatible. Repurposing
STDs does not change basic way in which we work, only how things are
documented -- may speed things up without more risk. Maintenance teams
and web pages are a poor standards technology, especially for
procurement -- bad experience in IETF and elsewhere with standing
interpretation and revision committees.
John Loughney - someone has to define what TCP is and produce these
documents. Don't care about how or where, and recognize procurement
issue. Understand concerns about maintenance teams, and know we have to
get the work done
John Klensin - it's worth fleshing out TCP, but not worth fleshing out
the full set of STDs (certainly not the full set of proposed
standards). Somebody has to decide it's important enough to tie
proposed standards together.
Peter - we do non-authoritative work with technical publishing
Keith Drage - if these are to be usable, these must carry a level of
authority -- same or greater than the STD document
Larry Masinter - what about application-level protocols - HTTP with
cookies, etc? HTML? A browser? what's the "STD"? - every document is
discrete until someone decides documents go together and does the work.
Bob Braden - don't call your new space STDs - need a new namespace.
Haven't been able to retrain people to use STD numbers - at least take
RFC numbers out of standards-track document - mistake to call new this
STD, perhaps ISN (Internet Standard Number) references.
Kurt Zeilenga - what about STD version compatibility? "standard as of a
certain date". We do this referring to standards from other SDOs now.
Scott Lawrence - need for non-normative references within the STD -
e.g., HTTP with cookies. - may be work that hasn't even happened yet.
This proposal slides toward taking over AS functionality as well.
Is defining the labeling a function of this working group? Labeling
problem spans all proposals. This proposal affects the importance of
other questions the working group is thinking about.
Keith Drage - this improves the external referencing issue a lot.
Scott Bradner - Sense of the room? Should this work should be done in
this working group?
Kurt Zeilenga - this seems orthogonal to defining what the standards
track should be
John Klensin - you are right, but that does not imply it is not good to
separate that work
Scott Bradner - if we have something like this which points to a set of
documents, then the importance of the levels is reduced
John Klensin - can even say "we have high confidence in this standard
except section 7 and there is an I-D that is working to address it" etc.
Scott Bradner - hum: should work of this ilk be done in the WG?
(strong hums for, no hums against)
John Klensin - can others help by providing real examples? (please?)
Cruft Removal: Lear/Alvestrand
Eliot Lear - Daytime, time, host access protocol, hello, SLIP, IP over
SMDS - these are all full standards. Draft standards and proposed
standards are just as bad. And some have serious security problems, etc.
Some fruit is low-hanging, some is more controversial.
Still used? Would you want someone to use the concepts again?
Is it safe to use?
John Loughney - it's currently much harder to remove things that are
dangerous (because another RFC is required) - but people reference RFC
numbers and don't know it's been deprecated.
John Klensin - this points out why the labeling discussion needs to be
part of this WG discussion
David Black - difference between "waste of time" and "hazardous
to your health"
Elliot Lear - How to remove? Ad hoc committee? Working group? w/IESG
approval? 2026 requires IETF last call.
Current proposal in ID
Also includes DS, PS, BCP.
Larry Masinter - these docs can be short and are not that hard to do
Bob Braden - Jon Postel said "standards are forever" - moving to
historic means "egregiously bad". Maybe this was the product of a
simpler time. Some of the oldest STDs were grandfathered as STDs in the
first place when the standards track was created.
Eliot Lear - "Historic" has come to mean "dangerous". But some of these
are not dangerous, just old and no longer in (wide) use. What if there
are a lot of historic documents?
John Klensin - do we need new levels for "bad" and "stupid"?
Elliot Lear - why do this at all? parts of the community are concerned
that once something passes to PS/DS/STD, it's there for a long time,
which leads the IESG to be overly careful about advancing things to
those levels. Let deployment experience dictate lifetime of a
standard. This discussion applies to standards-track document only.
Keith Drage - this movement takes effort - is moving worth the effort?
we might think it's dangerous, but someone might be using it in a
Scott Bradner - their use might not be as restricted as they think if
it is going over IP
Elliot Lear - The main benefit is to introduce a release valve.
Kurt Zeilenga - "informational" might be an appropriate demotion, too -
prevents standards-track normative references, forces people to
John Klensin - what about the forever-ago proposed standards we have
now? Automatically advanced? "Hasn't killed the Internet yet." If we
pass through killing, we should pass through advancing as well.
Scott Lawrence - Time is not as important as having an orderly process
to address these matters.
Elliot Lear - only reason for time perspective is that we can remove
the notion that proposed standards live forever
David Partain - I think spring cleaning in standards docs is a good
thing that will force us to learn some surprising things about our
process, but we need to do so in an open way
Harald Alvestrand - This is the most light-weight process we (Elliot
and me) can imagine for moving things to Historic. If we decide not to
do this because it's too much work, we should stop talking about making
things Historic - because it won't be done, we know that, and we should
stop fooling ourselves.
Elliot Lear - Harald and I would like to do this and any change to
Historic would happen only after IETF Last Call and IESG approval
Keith Drage - ETSI added historic - this is contentious - The Last Call
Elliot Lear - document why standard is thought to be old and crufty,
put through IETF Last Call, if possible incorporate dissenting opinion
Scott Bradner - involve authors if possible.
Scott Bradner - humm if think it's a good idea for WG to pursue?
(Sense of room is "yes")
Scott Bradner - Autoupgrade also? (Not a strong sense of the
room. Go to the list.)