[newtrk] oops - I forgot to send teh draft notes to the newtrk session

[[e-mail] (Scott Bradner)]

I seem to have forgotten to send a copy of these notes to the list
(they were done a while ago) - comments by thursday please

Scott

-----
New IETF Standards Track Discussion (newtrk) WG

Wednesday, November 10 at 1300-1500
===================================

CHAIR: Scott Bradner <[e-mail]>

minutes based on notes by Spencer Dawkins 

AGENDA

I -   Welcome & Agenda Bash   - chair            5

II -  Cruft
      should we decruft - chair                 10
      decrufting details - Lear/Alvestrand      25
III - Labeling Standards - Klensin/Loughney     45
IV -  Naming RFCs - Rosenberg/Mankin            20

I - Welcome & Agenda Bash
	 There were no changes to the prepublished agenda.

II - Cruft
Scott Bradner: Note that our working group charter says that we need to
decide if we want to pursue a decrufting effort this month.

Elliot Lear: presentation on de-crufting idea:
RFC 2026 requires that a periodic review and/or timeout of standards
track RFCs. (Although this rarely happens.)  He feels that the IESG
looks at standards-track documents harder than it might because proposed
standard RFCs seem to live forever. He proposes an alternative - require
specific positive justification for a standard to continue being
considered a standard.
Questions from Elliot: How many levels (types) of cruft are there? And
are multiple levels significant? Historic? Deprecated? Abandoned? Note
Margaret's comment that this isn't saving the IESG any time, go look at
something else, please. There's a lot of work we need to do on roadmaps
and ISDs - that's for sure
"Valuable in a diminishing market" - it's not just cruft, it's antique
analysis We need to think about stalled stuff versus new stuff ("no new
cruft")
"Historic" is an ambiguous designation - no one cares or active warning
sign? or something else? Good to review documents, but lots of
controversy any time we try to look at a specific document. Maybe not
binary/categorization - maybe document-by-document

Scott Bradner: Does this work matter if we do ISDs?

Elliot Lear: Maybe we can start decrufting before we start doing ISDs?
Go forward as experiment and consider results at Paris IETF - do an
Internet draft with a list of documents and a short statement about
"why"

Scott Bradner: Sense of room - Should we consider a cleanup process with
self-organizing group working on the draft? Sense of room is "yes."
Scott: OK we'll proceed. We'll delay the charter milestone for the
decruft process document itself until we see results.

Volunteers? Talk to Elliot in the hallway...

II - labeling standards
John Klensin: Current standard designations are not useful, we don't
have stable references for most IETF protocols (RFCs, sure, but not
protocols!) Propose "Internet Standards Documentation" This idea seemed
to have buy-in in San Diego - we'll look at examples today, WGLC after
update? Note that if we do ISDs, it's not clear we should continue with
updates to "the Standards Track" The last working group milestone still
needs to be updating our process BCPs - we still need to say what we do,
and do what we say we do. Will this really take until the end of 2005?
Some of us hope not!

Some questions 
A/ Do ISDs have their own maturity levels? Would ISDs explicitly call
out the maturity level of documents that it points to? But our maturity
levels are way underused now. ISDs text may take over maturity levels,
obsoletes, updates, metadata, etc. Major value of ISD is collecting
things, maturity levels don't matter as much as the collection feature.
We may have "implied maturity levels" by pointing to interoperability
reports, etc. You'll need a process for drafting, reviewing (this
question matters but we'll talk about it later).

Sense of room is that ISDs would not have maturity levels.

B/ Are ISDs only for STD-level RFCs?
Are ISDs required for every PS? Who is motivated to produce and maintain
them? Somebody better be, if ISDs become the way we refer to our
standards!

Sense of the room is that we can produce ISDs for documents at entry to
the standards track.

C/ Is this part of normally producing a document? Format has to be dead
simple because everybody has to produce one. At least the MINIMUM needs
to be dead simple. How does last call work when you have multiple
unrelated efforts updating the same ISD? Knowing that would be a huge
step forward, and a far better use of IESG time than other things IESG
spend time on.
Do ISDs get Last Called? 

Sense of room is "yes". But we need to make sure we don't end up with
two or three times the number of last calls! Don't think we will, but
need to watch for this. Can update maturity levels more easily because
they can just be a statement in an updated ISD, instead of a whole new
RFC.

D/ Normative and Informative sections of ISDs?
We've given warnings of potential changes in RFC text today - and the
warnings live forever, right or wrong.
"If an ISD contains non-normative references, they shall be clearly
identified".
Q - Is this Host Requirements for one protocol? Scary - slippery slope!
Q - Remember the poor non-IETF purchasing guy reading these things!
Q Should we include commentary about what was done and why? 
A - Don't require this, but don't make it impossible, either!
Q - "Normative" is overloaded? Rat-hole!
Q - how would we do an ISD for "the web"?
Q - Make normative references to non-IETF documents? (ASCII s an
example)

Sense of the room was that an ISD could include both Normative &
Informative references.

E/ Confirmed errata?  Currently goes for expert review or IESG review,
or replaces with new RFC. Trying to make "trivial yet normative changes"
- at least they are last called... extreme example is typos, but we've
  had the wrong range of testing addresses before, which changed meaning
Q - Rethinking errata is good, but it's a side issue - we're trying to
define what defines a standard.
Q - We should be defining the minimum framework for ISDs here, not every
possible thing in an ISD at this stage of the game. We won't figure that
out here, anyway.
Q - Making profound changes to the way we define standards should be
done incrementally - don't go for the end zone now.
Q - Stuckees for significant ISDs won't do them more than once - don't
keep changing the rules and keep going back to the stuckees.
Q - Like the flexibility of ISDs - we won't even fix full standard
errors because there's no energy to do so. There's no energy to revisit
security considerations. This makes our lives better.

Sense of the room question "Can an ISD make changes to text of
underlying documents?" Sense of the room is "yes, half, no, a few"

F/ It's OK to make a normative reference to ASCII with a specific
version number, etc? We can say "or a later version", or "use this
version only"? 
Q - Needs to be specific and "long-lived", same as current RFC-Editor
practice. 

John will bring the remaining questions to the list.

Sense of the room is "yes, with no no's".

III - Naming RFCs
Jonathan Rosenberg: Industry usage of "RFCs" is disconnected from our
usage - they think RFCs are "the document series of the IETF".

In response to a question, Bob Braden said that 5-6 percent of recent
RFCs are from "outside the IETF,"

Jonathan Rosenberg: Very difficult to differentiate these RFCs, MGCP as
example - big industry protocol, lots of extensions, but we didn't
produce it! We were trapped by MGCP and Megaco being in the same
document series. Now even the ITU thinks that MGCP is an IETF standard,
even without any security considerations.
Proposal strawman - RFCs require IETF process, other documents are
called something else.

Q - RFCs have wisdom, but not all the wisdom.
Q - Sue people who call MGCP an IESG standard?
Q  RFCs predate IETF - can't undo history.
Q - Need ISDs and enforcement to fix this.
A - ISDs help and aren't enough.
Q - Current policies allow MGCP to live forever. This is a de facto
standard, and we can't stop this. 
Q - The Internet Draft tries to fix three different problems with one
solution. 
Q - Fixing people being confused about our standards takes more than
this draft.
Q - If a working group fails and a draft has value, the RFC Editor
SHOULD be able to publish the drafts.
Q - This is a complex problem, this draft just scratches the surface...
Q - What about April 1st series of RFCs? Include an MGCP April 1st
document in the apparent series?

Allison Mankin: Can't wipe out RFCs PLUS REFERENCES. The brand is shot.
There's no way to get back. RFCs aren't a strong brand, but marketing is
a strong consideration...

Q - People don't implement because it's an RFC, they implement to solve
problems. Changing the labels won't matter.
Q - It's not marketing, it's about procurement.

Allison Mankin: It's really hard to make an RFC sound like it DIDN'T
come from a working group! We need to institutionalize the way we deal
with these problems.

Scott Bradner: Need more discussion on this draft - keep it in the
charter, keep active on the mailing list.


.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html