[newtrk] My notes from Newtrk

["Spencer Dawkins" <[e-mail]>]

Please send corrections to Scott!

Thanks,

Spencer

New IETF Standards Track Discussion (newtrk) WG

Thursday, March 10 at 1530-1745
===============================

CHAIR: Scott Bradner <[e-mail]> 
SCRIBE: Spencer Dawkins <[e-mail]>

AGENDA

intro & status - chair 

  a.. One week away from end of WGLC on ISD document
  b.. Did not WGLC cruft yet, will discuss moving forward here
  c.. We are not worrying about the number of stages in the standards process, because if we do ISD, we won't care about status of individual RFCs
discussion of ISD proposal  - John Klensin
background reading:
draft-ietf-newtrk-repurposing-isd-01.txt
draft-ietf-newtrk-sample-isd-00.txt
draft-ietf-newtrk-sd-00.txt
draft-ietf-newtrk-sample-isd-stdproc-00.txt

  a.. We went though a number of issues with the ISD document at the last meeting, the current ISD draft captures all the discussion John could capture
  b.. Not getting comments that require document changes - are there questions? Comments? Are we ready to go?
  c.. Don't want ISDs to contain IETF process BCPs, so proposed SD series ("Standing Document") - need to decide what we want to do about this, not obviously within our chartered scope
  d.. We need a DTD for these documents, if we're going to keep them in XML. The IESG needs to wade in here, because they care more than we can care about the details - if this is the plan, we need to start punting to the IESG now
  e.. Brian Carpenter - what are you punting? Not designing DTDs, surely? Defining what they should do? That's basically the problem. What sections, what they should contain, etc. We've gotten individual feedback from IESG members that isn't consistent
  f.. Brian blamed his predecessor
  g.. Eliot Lear - we're supposed to decrease the work of the IESG, not increase it. We need a liaison, and it needs to not be Brian. We need to ask "are we keeping the right information?" Let's get this feedback before doing the detailed work.
  h.. John Klensin - if we need arbitrary IESG decisions, it would be more efficient to let the IESG make them on their own
  i.. Harald Alvestrand - the IESG tends to defer complicated questions. We can probably ask "do you agree that X is true and Y is false?" Be as specific as possible. Don't ask them to think. About what they really want.
  j.. Brian Carpenter - Let's conspire on questions with binary answers, sometime in the next two weeks.
  k.. John Klensin - we don't want to cycle for very many more months without feedback.
  l.. Dan Connally - XML DTD for what sort of document?
  m.. John Klensin, standing on one leg - we've discovered that a small number of categories about unlinked RFCs isn't useful and linking with STDs is too late. We've done a lot of iterations, but that's the waterfront. We're looking for a real document series, not a bunch of RFCs. The ISDs contain prose about the referred-to RFCs. 

  n.. Eliot Lear - did not find serial number in the current draft. What about maturity level of ISD versus maturity level of RFCs referenced?
  o.. Scott Bradner - would like to postpone this discussion.
  p.. Bob Braden - what do we need to do before passing to the IESG? Granularity is a real problem and needs to be addressed in the ISD draft. Taxonomy of the problem space, or some part of the problem space, is needed.
  q.. John Klensin - conclusion of WG is that we can't get a unified theory. We can do examples.
  r.. Bob Braden - I'm asking for running code.
  s.. John Klensin - check the example documents - there's no way to answer this question in general.
  t.. Eliot Lear - Bob is asking for some more specific use cases
  u.. Spencer Dawkins - use cases are not easy - and don't need to be serialized with this discussion. It would be good to figure out how many ISDs SIP is, but don't wait on this - the SIP chairs think this will be hard.

  v.. Scott - Any objections to moving this forward?
  w.. Bob Braden - is this a BCP? Scott believes so. Bob - Experimental? John Klensin - we don't have process experiments except for July14th RFC. This could be a process experiment, but John is concerned about "going back" if we decide NOT to go forward.
  x.. Scott - IESG would be mandating that WG chairs "do the right thing" - going back will be funky.
  y.. Brian Carpenter - using Experimental doesn't feel right - BCP doesn't feel a lot better, there are problems with the labels. Informational? No level of approval, and people don't read Last Calls for Informational carefully. We'll propose BCP and can go to Historic if we have to.
  z.. Eliot Lear - Backing out is difficult because the other label is STD - this won't multiplex well with ISDs. Maturity levels still need help?
  aa.. John Klensin - we cycled with no helpful input last time - we can solve this fast or tell the IESG to figure it out, those are the options.
  ab.. Scott Bradner - we can have "soft" labels - "has been implemented", etc.
  ac.. John Klensin - if ISDs have the lowest maturity level referenced that solves one problem.
  ad.. Scott - but this means all ISDs will be Proposed Standard, and that's the problem we have now. We have running code that maturity levels aren't used anyway.

  ae.. Brian Carpenter - actually like not having mathematical relationships based on maturity levels.
  af.. Harald Alvestrand - ISDs talking about maturity levels makes sense, having maturity levels doesn't.
  ag.. John Klensin - does this document queue up behind decisions about maturity levels? We hope not.
  ah.. Eliot - Maturity statements make more sense than maturity levels.
  ai.. Melinda Shore - this is a boffo idea, totally support it, one caveat - we need relatively uniform descriptions
  aj.. Does anyone think ISDs should wait for maturity levels?
  ak.. Eliot Lear - if the purpose is to ask the IESG if we're doing the right thing, we don't have to wait, but if we're nailing things in stone, we need to have some clue.
  al.. John Klensin - should I just take maturity level of ISD out of the draft?
  am.. Eliot Lear - did we also agree that we would provide descriptive text? But this is about the referred-to RFCs, not about the ISD. Would like to see applicability.
  an.. We will forward request for processing with one change after WGLC finishes. This will be a normal request for publication, but we expect feedback from the IESG. If they say "yes", they say "yes".

  ao.. Harald Alvestrand - will request for processing include a DTD? We don't have one now, so the answer is no.
  ap.. Dan Connally - is the reason there isn't a DTD because it's hard, or no one knows how, or ...
  aq.. John Klensin - we don't need a DTD until the IESG knows what they want, at least not more than a skeleton.
  ar.. John Klensin - we also need to scrub explicit placeholders, including the cruft work. 

  as.. Bob Braden - is it the expectation that when this is adopted, RFCs will no longer have maturity levels? Scott - we'll stay with the current mechanism for pragmatic reasons, until we get a better offer - we'll just say "standards track".
John went through the rest of the placeholders...

  a.. IESG can put anything in an ISD they feel to be helpful, right? Seems to be "yes". We've discovered that we need a place to store accumulated experience, that's what we're trying to accommodate. 

  b.. Bob Braden - we have a lot of experience about our inability to foretell the future - IESG has a freeform field to extend this mechanism, and that's a good thing.
  c.. Eliot Lear - there's a difference between having a freeform field and having a freeform document.
  d.. Harald Alvestrand - I thought it was obvious that the working group was going for a DTD when they chose XML, so I can start writing text when this is approved

report and discussion on the anti-cruft effort - Eliot Lear
background reading: 
draft-ietf-newtrk-cruft-00.txt

  a.. We've been running a cruft experiment since the last IETF
  b.. There is cruft out there - we covered this last time. We created a list of all PSes numbered under 2000 and discussed them on a mailing list, asking for anyone to provide any reason why it wasn't cruft. There was barely even a laugh test. We did outreach to find other people, and we're asking again here.
  c.. We have 57 documents on the current cruft list, out of 119 that we started with.
  d.. Cruft classes - PEM, Whois++. Token Ring, Appletalk, Novell, X.400, X.25, plus MIBs for cruft.
  e.. Pat Thaler - IEEE does five-year reviews, and Token Ring recently passed in IEEE - this is good enough for us.
  f.. Telnet docs were removed from the cruft list.
  g.. Pekka Savola - we don't have a clear idea what "making something Historic" means - some people think if a protocol is even in use somewhere in the universe, we shouldn't declare it cruft.
  h.. Scott Bradner - if the criteria is that "cruft" isn't what we would recommend today, should MIBs be on the list if there's no alternative MIB? Obsoleted isn't the same thing as Historic... There are three reasons things became Historic - replaced, obsolete, or a really bad idea - this doesn't help at all.
  i.. Other positive output - some documents will be revised, etc.
  j.. How to do more outreach?
  k.. Should a draft detailing what is cruft be Informational or a request to the IESG to remove these documents? Or words for ISDs?
  l.. Spencer Dawkins - is 57 a big enough number? I thought we had more cruft than this - others? Also - please don't produce a bunch of ISDs about cruft- that's the last thing we need to move ISDs forward!
  m.. Melinda Shore - 57 isn't that bad - we don't want to throw out too much.
  n.. Pekka Savola - the IETF Announce list would be enough outreach.
  o.. Bob Braden - OSI protocols were on the list, and X.400 probably didn't die...
  p.. Melinda Shore - we can do more outreach, Bob is right, and the question of how to filter stuff out is a hard one - we can get input from others
  q.. John Klensin - ITU is considering bringing back X.400 distinguished names to solve the DNS problem...
  r.. Brian Carpenter - IBM's office I visit has only token ring, we do need to be careful.
  s.. Scott Bradner - a MIB is different from a protocol - the MIB will be in use as long as a device is on the net.
  t.. Pekka Savola - is there any problem with non-cruft referencing cruft? There aren't "normative references" in these older documents. What about Informational? that would get rid of a lot of more...
  u.. Harald Alvestrand - the reason to obsolete X.400 documents in the IETF isn't because no one uses it, it's because no one cares what we said anymore.
  v.. Pekka Savola - criteria could be "no one has energy to revise this document"
  w.. Eliot Lear - we could also go look at Draft Standards, but we are supposed to be thinking about the process of going to Draft Standards anyway. I'm planning to spend another month looking for authors and doing outreach. If you have contacts/e-mail addresses for someone who's interested, please send them to me.
  x.. Plan for going forward?
  y.. Pekka Savola - any assumptions about Informational RFC versus actual request for action? 

  z.. Fun exercise and move on? Publish the list? Request moving documents to Historic? Last two options got about equal support in the room, we'll take this to the list.
  aa.. Brian Carpenter - the second option needs justifying
  ab.. Melinda Shore - eventually this needs to go to the IESG, but it's not ready yet.
  ac.. Doug Otis - we have a massive RFC Index and it's hard to figure out most recent document - can we have a cruft-free index, at least?
  ad.. Bob Braden - I don't think we should just forget about this, but ISD will make this irrelevant, so put your energy there, unless the document is harmful to the Internet.
  ae.. John Klensin - I'm concerned that we do as little as possible to add work to the IESG - ISDs will make these documents irrelevant - I should remove the ISD text pointing to cruft, right? Scott - right, and we can move discussion about alternatives into an opinion.
  af.. Melinda Shore - there's another step that needs to happen before we go to the IESG - we have to do a Last Call to move to Historic anyway. The mechanism to identify cruft can use some refinement.
  ag.. Eliot Lear - I agree that the number of documents that can be crufted being only 57 means the document classification is actually being maintained. We can wait on the ISDs and come back to this if we have to.
  ah.. Pat Thaler - I'd rather have choice 1 than choice 2. Publishing another RFC that calls Proposed Standards cruft will be invisible and people will continue to use them.
  ai.. Harald Alvestrand - if we don't declare these documents Historic, we should abandon the concept of Historic. Declaring something cruft by not issuing an ISD is pretty obscure.
  aj.. Eric Grey - Just making documents Historic doesn't make them go away. The advantage is that this does raise the visibility of the document's status. 

  ak.. Scott Bradner - we've used Historic to tag really bad ideas - don't lose this.
  al.. John Klensin - what path are we going down? I thought we would issue a 57-document ISD and bail all of them out.
  am.. Harald Alvestrand - that would work for me.
  an.. There is no support for abandoning the crufting work, we're still going forward.
wrapup - chair 

  a.. Where to go next? We could have ISD draft and cruft done by Paris.
  b.. Look at the labeling of RFCs? Maturity level, and tagging non-IETF documents. ISDs could make RFC maturity levels irrelevent. 

  c.. Bob Braden - confused - I thought the label on the RFC reflected the standards process - is this changing?
  d.. Scott - RFC maturity levels can wait until we're sure we need to do the work on this at all. We are going to have to revise the standards process eventually, but we can wait to see which way we need to revise it.
  e.. Bob Braden - If you have a standard and want to extend it, is another RFC added to the ISD? Or a new ISD might reference the old one, or... what's the process for deciding what ISD an RFC goes into when a standard changes? RFC Editor needs more guidance here.
  f.. Brian Carpenter - I agree and want to say it differently - this is how we direct someone to the real SMTP specification instead of the full standard one. We can freewheel here for a bit before redoing RFC 2026.
  g.. Clear way to identify non-IETF RFCs? If we have ISDs, and we are extremely clear what a standard is (an ISD), this probably doesn't matter.
  h.. Bob Braden - Not All RFCs Are Standards - actually, "NO RFCs are standards" - correct.
  i.. Defer this work, too? No objection in the room. All our objectives are deferred, and we won't meet in Paris.