Gen-ART LC review of draft-ietf-netmod-ip-cfg-09

[Peter Yee]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments you
may receive.

Document: draft-ietf-netmod-ip-cfg-09
Reviewer: Peter Yee
Review Date: May-03-2013
IETF LC End Date: May-03-2013
IESG Telechat date: May-16-2013

Summary: This draft is basically ready for publication as a Standards Track
RFC, but has nits that should be fixed before publication. [Ready with nits]

The abstract says it pretty well: This document defines a YANG data model
for management of IP implementations.

Major issues:

Minor issues:

Nits:

Page 7, bottom: The code copyright date says 2012.  Update it to 2013.

Page 10, in leaf phys-address, the description has an incorrect spelling of
"neighbor".

General: where a description of phys-address is given, in both cases it says
"The physical level address...".  It might be more correct to state "The
link layer address..." for most but not all cases.  

That's it.  Everything appears consistent within the limits of my
understanding of YANG.

-Peter Yee

Re: [IETF] Re: Balancing the Process (Was: Obsoleting SPF RRTYPE)

[Mark Andrews]

In message <86172038-8f62-4508-8199-be4c16906...@kumari.net>, Warren Kumari 
writes:
>
> On May 2, 2013, at 9:56 PM, Mark Andrews  wrote:
>
> >
> > In message <5182828c.3040...@isdg.net>, Hector Santos writes:
> >> Mr. Resnick,  for the record, I wasn't upset. Believe it or not, I was
> >> actually applying an suggestion posted last month or so here with the
> >> IETF diversity talks to help get a major WG issue resolved, one with a
> >> near surety of an appeal, resolved and addressed much faster and hence
> >> avoid a waste of time on the behalf of all.
> >>
> >> How appropo, that a topic of "balancing of process" as being
> considered.
> >>   It is one thing I believe the IETF needs and can be actually apply
> >> today. Yes, I don't agree with the negative tone taken in SPFBIS where
> >> in effect, an attempt to shut down communications and indirectly
> >> personally attack posters occurred and the advocates of the SPF RRTYPE
> >> removal (incidentally, a SPEC change which I believe was prohibited by
> >> the charter), basically blowing off advocates of a RFC4408 status quo.
> >> If you believe that was proper, I think we have a WG problem.
> >>
> >> Overall, I believe this (keep the migration path) is the proper
> >> compromise to resolve the issue, and I believe that this particular
> >> issue is industry-wide important to resolve with across the board
> >> engineering input. It *SHOULD NOT* be reserved only to the
> applications
> >> SPFBIS group especially when we know what the DNS community will say
> >> about this and has said so since MARID 2003 and again last year in
> IETF
> >> and DNSOPs. I was simply hoping to help "Balance the process" then as
> I
> >> was attempted to do again.  If I was in error for trying to get a
> >> serious issue resolve, then please accept my apology.
> >>
> >> Sincerely,
> >>
> >> Hector Santos
> >
> > One of the questions is how to deal with vendors that claim to ship
> > a product which is in compliance with the protcol when they are
> > not.
> >
> > The DNS protocol has a error code for when you do not understand a
> > query, FORMERR.  It also has a error code for when you do not
> > implement part of the protocol, NOTIMP.
> >
> > With RFC 103[45] you have three choices as a developer when you get
> > a query type you don't know about.
> >
> > 1. Treat it as a FORMERR.
> > 2. Treat it as a NOTIMP.
> > 3. Treat it as a opaque data.
> >
> > Now in my book it isn't a FORMERR as you can understand the question
> > even if you can't deal with it.  NOTIMP is a reasonable response
> > though I believe the intent in RFC 103[45] was to treat it as opaque
> > data query which is what RFC 3597 says to do.
> >
> > Nowhere in RFC 103[45] does it say DO NOT RESPOND to the query yet
> > we have DNS vendors that ship products that do just that and are
> > claiming that they conform to the protocol.
> >
> > For a example of a set of servers that does this see earthlink.net's
> > servers.
> >
> > Query for HINFO/earthlink.net at the authoritative servers for
> > earthlink.net (itchy.earthlink.net and scratchy.earthlink.net) and
> > you will not get a response.  A RFC 103[45] compliant server should
> > know about HINFO.  It should also be capable of returning a NOERROR
> > NODATA response for that query and it fact will if you ask for a
> > non-existent TXT record at a name it serves.
> >
> > How do we deal with sites?
> > How do we deal with vendors that ship such product?
>
> Unless the caffeine just hasn't sunk in yet, it works for me:
>
> wmbt-macbookair:Preferences wkumari$ dig HINFO earthlink.net
> @scratchy.earthlink.net
>
> ; <<>> DiG 9.8.3-P1 <<>> HINFO earthlink.net @scratchy.earthlink.net
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1906
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
>
> ;; QUESTION SECTION:
> ;earthlink.net.   IN  HINFO
>
> ;; AUTHORITY SECTION:
> earthlink.net.1800IN  SOA itchy.earthlink.net.
> hostmaster.earthlink.net. 2013042602 3600 300 2592000 1800
>
> ;; Query time: 51 msec
> ;; SERVER: 207.69.188.197#53(207.69.188.197)
> ;; WHEN: Fri May  3 12:59:50 2013
> ;; MSG SIZE  rcvd: 84
>
> So, maybe the way you fix such sites / deal with vendors that ship such
> products is you post to ietf@ietf.org and cc hostmaster@site?
>
> :-P
> W

Did you see the bounce that came back from hostmas...@earthlink.net?

You follow the link in that email and there is no where to report
the problem.  None of the options offered was really sensible though
I did open a chat window and report the problem.  I doubt it will
have much effect.

Whois doesn't help.  Same bouncing email address or one needs to
make a international phone call to report the problem.

And no it still doesn't work, below, from where I am in the world
not that ietf@ is the right place to diagnose this specific issue.

Earthl

RE: Effects on DNS can be severe &&& Re: call for ideas: tail-heavy IETF process

[Tony Hain]

S Moonesamy wrote:
> ...
> 
> >I have not followed this discussion, but my cursory read of the tracker
> >ticket shows the WG blew off the issue by claiming that historical
> >unsophisticated attacks can be easily thwarted, while completely
> >ignoring the case where the target domains exist. Aborting an
> >amplification attack on failures does not do anything about the case
> >where an attacker goes to the trouble to make sure all the quires will
> >return valid answers. Either the issue-tracker discussion is
> >inadequate, or this is exactly the kind of thing that adds excess delay
and
> workload to the IESG review process.
> 
> It seems that the above is related to Issue #24 [1].  I posted a rough
summary
> of the initial discussion [2].  I took a look at the IETF 83 minutes and I
found
> "DNS amplification attacks" [3] mentioned.  There was a message from
> Andrew Sullivan [4].
> 
> A working group may decide to blow off the issue if it wants.  The issue
can
> be listed in the write-up.

Yes it can, and they often do. The question in this case is more about the
way that was documented, and Douglas' effective call for a wider review of
the decision. It may simply be the wording in the issue tracker, but reading
that the effective message is: 
   "a security issue was raised, and a subset of the potential attack is
easily mitigated, therefore the WG is dropping it"
There may well be more to it, and I said I have not been following it. The
point is that 'outside reviewers' will not be immersed in past discussion,
so what and why should be clear. I purposefully tied this to the ongoing
IESG process discussion, because it is a prime example of why post-WG
discussions take longer than expected, and may result in changes. 

Tony

Re: Language editing

[joel jaeggli]

On 5/3/13 3:04 PM, Brian E Carpenter wrote:

On 04/05/2013 09:22, Yaron Sheffer wrote:

GEN-ART is a good example, but actual document editing is much more work
and arguably, less rewarding than a review. So I think this can only
succeed with professional (=paid) editors.

I think I disagree, if we can find the knack of effective crowd-sourcing.
We do after all have several hundred native English speakers active
in the IETF, which would mean each one would have to volunteer for
less than one draft per year and we'd be done.
Variously as an individual contributor, shepherd and chair I have asked 
for source text so that I could provide large copy edits which the 
authors could then apply at their leisure. I have also asked for 
volunteers to help with heavy edits. IMHO polishing a document for 
consumption is a very useful form of contribution, which doesn't 
necessarily require either deep technical background in the area or 
personal involvement in the draft.

I don't know how much experience you have with professional editors.
Apart from the RFC Editor crew, my experience has been "mixed". Somebody
a year or three ago (the last time we had this exact same discussion)
pointed out the differences between copy-editors and technical editors.
One difference is that the latter are much more expensive. Copy-editors
tend to be rule-driven; technical editors are supposed to understand
the material.
Most working group participants already have a deeper background in the 
area and familiarity with the jargon than a copy-editor.


 Brian

RE: Effects on DNS can be severe &&& Re: call for ideas: tail-heavy IETF process

[S Moonesamy]

Hi Tony,
At 14:11 03-05-2013, Tony Hain wrote:

See the thread about Re: call for ideas: tail-heavy IETF process for
discussion about wider review at an earlier point in the process. Also, just
because there is a discussion on issue-tracker does not mean the document is
'high quality'. If there is an explicit trade-off being made, the main
document needs to address that directly so subsequent reviewers and
implementers know what and why.


Yes.


I have not followed this discussion, but my cursory read of the tracker
ticket shows the WG blew off the issue by claiming that historical
unsophisticated attacks can be easily thwarted, while completely ignoring
the case where the target domains exist. Aborting an amplification attack on
failures does not do anything about the case where an attacker goes to the
trouble to make sure all the quires will return valid answers. Either the
issue-tracker discussion is inadequate, or this is exactly the kind of thing
that adds excess delay and workload to the IESG review process.


It seems that the above is related to Issue #24 [1].  I posted a 
rough summary of the initial discussion [2].  I took a look at the 
IETF 83 minutes and I found "DNS amplification attacks" [3] 
mentioned.  There was a message from Andrew Sullivan [4].


A working group may decide to blow off the issue if it wants.  The 
issue can be listed in the write-up.


Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/spfbis/current/msg00906.html
2. http://www.ietf.org/mail-archive/web/spfbis/current/msg00847.html
3. http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt
4. http://www.ietf.org/mail-archive/web/spfbis/current/msg00944.html 

Re: A note about draft-ietf-spfbis-4408bis

[Doug Barton]

Andrew (and Pete, since he raised a similar issue),

On 05/02/2013 12:50 PM, Andrew Sullivan wrote:

Doug,

No hat.

On Thu, May 02, 2013 at 12:22:03PM -0700, Doug Barton wrote:

Given that you can be 100% confident that the issue will be raised
during IETF LC, wouldn't it be better to hash it out in the WG (as
we have attempted to do)? Or is the WG's position, "we have no
intention of dealing with this unless we're forced to?"


We _have_ hashed this out in the WG.  As I have noted to you -- now on
three separate lists -- the problem is that we have an actual
interoperability bug in RFC 4408, and we need to fix it.  The WG
evaluated the various alternatives for how to solve that, and having
performed the evaluation the group came to the conclusion that, _in
this specific case_, deprecating RRTYPE 99 is the most reasonable
course of action.


I understand the conclusion the WG has come to, and I have a pretty good 
understanding as to why. At Pete's request I reviewed the threads 
related to this issue in the spfbis archive. I also understand that the 
WG (which you co-chaired, although I will accept your "no hat" statement 
above at face value) desperately wants this issue to go away.


The problem is that the WG came to a very bad conclusion. A conclusion 
that is not only bad for SPF, it's bad for the future of innovation in 
the DNS, contrary to 5507, and arguably contrary to the group's own 
charter.


I am not saying that the WG members (or chairs) should be given the 
wet-noodle treatment over having reached a bad decision, but what is 
cross-area review for if not to catch cases where the WG echo 
chamber/tunnel vision/what have you -- resulted in a bad outcome?


It would be different if the right solution were hard, or if I were the 
only one objecting. But neither is true.



I am not happy about this, but other analyses do not seem to be
supported by any facts,


I'm not sure what facts you're looking for beyond what I've already 
provided. But in no particular order:


1. "Deprecate SPF/99" is in violation of 5507
2. Numerous people smarter than I have pointed out detailed technical 
reasons why overloading TXT generally, and particularly at the zone 
apex, is a horrible idea.


Furthermore, 2 of us presented detailed analyses of the arguments raised 
in spfbis, and found them severely lacking. In summary, "We tried doing 
SPF/99 10 years ago and it didn't work, so we stopped." I (and others) 
have several times now offered detailed responses explaining that in a 
post-3597 world that shouldn't be an issue anymore. "There are still 
some firewalls or other middleboxes that don't handle DNS properly" is a 
truism, but as pointed out by myself and Mark Andrews the value of 
"some" has been reduced to the margins by IPv6 and DNSSEC. Both that 
issue, and the issue of updating provisioning systems are things that 
need to be dealt with, but they are going to be true for whatever 
advances we want to make in the DNS. As an organization we have stated 
that we're not willing to be held hostage to those issues (5507), a 
position with which I maintain full agreement and support.


Further-furthermore, after I suggested that the way forward is to query 
SPF/99 first, it came to light that 2 of the major implementations 
(Mail::SPF and libspf2) _already do that_. A fact that the WG seems to 
be conveniently ignoring.


Frankly at this point I'm wondering what the fuss is about.


nor by any argument that leads to the
conclusion that an arrangement we would all like better has any chance
of deployment.


If your argument here is, "The SPF literati have spoken, don't intend to 
change, and wish you to stop bothering them by pointing out that they've 
come to the wrong conclusion," I'm sure you can imagine my response. 
However, given that 2 of the major implementations _have already 
switched to doing what I suggested_, what we're really talking about 
here is winning over the hearts and minds of "the masses" who do this 
stuff, write up the docs, etc. Personally I can't think of a better way 
to continue that ball rolling than to publish an spfbis document that 
documents how to do v=spf1 the way it should have been done in the first 
place, and specifies that future versions of SPF will be SPF/99 only.


Doug

Re: Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]

[Bjoern Hoehrmann]

* Hector Santos wrote:
>May I suggest that the IETF produce a web site for gathering IETF 
>participants profiles and even resumes.  It can have a questionnaire to 
>extract the valuable information that will help maximize the IETF/IESG 
>efforts.  The "Business Information" (BI) can then be leveraged by ADs, 
>WGs (and other IETF/IESG leaders) to recruits/invite participants for 
>various projects, reviews, etc.  It will have many win-wins for all.  We 
>should consider there are as much, and perhaps even more IETF man-years 
>in people that never attended meetings but were active for many years, 
>nonetheless, in their various IETF protocol interest areas.
>
>The structure of this questionnaire will be important to be successful 
>and beneficial.

+1
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: Effects on DNS can be severe

[Douglas Otis]

On May 3, 2013, at 1:00 PM, Scott Kitterman  wrote:

> On Friday, May 03, 2013 12:46:52 PM Douglas Otis wrote:
>> On May 3, 2013, at 12:21 PM, Scott Kitterman  wrote:
>>> On Friday, May 03, 2013 12:04:53 PM Douglas Otis wrote:
>>> ...
>>> 
 Over many years at attempting to change the course of the SPF process,
 this
 effort appears to have been futile.
>>> 
>>> ...
>>> 
>>> It does seem a bit odd for you to claim you're being ignored when the
>>> largest change in SPF processing limits contained in 4408bis was your
>>> suggestion.  An alternate interpretation to consider is that the working
>>> group fully considered your inputs and incorporated those that were
>>> appropriate technically and in scope for the charter.
>> 
>> Dear Scott,
>> 
>> 
>> This was not directly part of the IETF process, as my input there was
>> ignored.
>> 
>> As I recall, removal of unlimited recursion occurred after a presentation
>> made in Boston to the Open Group.
> 
> I assume you are referring to some of the pre-IETF activities for SPF.  
> Recursion based processing limits don't appear in RFC 4408 (and also not in 
> 4408bis).
> 
>> As with unlimited recursion, the need for the macro functions are also
>> negligible while posing real risks. This is a serious security concern
>> still needing to be addressed.
> 
> This was discussed in the working group and tracked in the WG issue tracker:
> 
> http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24
> 
> The change mentioned in the ticket is a direct result of your input to spfbis 
> (referenced in the ticket).
> 
> As far as I can tell, this is just a case of "the working group came to a 
> different conclusion, so I'll whine about it on the main list".

Dear Scott,

While the recommendation may have helped, there is a trend of large websites 
publishing synthetic domains as an alternative to web cookies. This overcomes 
the suggested fix. A similar issue applies to SPF reverse namespace macro 
expansion consuming connection resources, especially in regard to IPv6.  In the 
end, the domain is still not authenticated, the number of transactions remain 
excessive and inhibit meaningful mitigation. Nothing justifies active content 
in DNS resource records distributed with email.  Macros are not needed and 
seldom if ever are used in this regard.  Simply put, SPF macros are not safe.  
DKIM as specified is not safe. Open IPv6 email can not be defended.  The IETF 
needs to seek better and fairer remedies.

Regards,
Douglas Otis

Gather Profiles/Resumes [was Re: call for ideas: tail-heavy IETF process]

[Hector Santos]

May I suggest that the IETF produce a web site for gathering IETF 
participants profiles and even resumes.  It can have a questionnaire to 
extract the valuable information that will help maximize the IETF/IESG 
efforts.  The "Business Information" (BI) can then be leveraged by ADs, 
WGs (and other IETF/IESG leaders) to recruits/invite participants for 
various projects, reviews, etc.  It will have many win-wins for all.  We 
should consider there are as much, and perhaps even more IETF man-years 
in people that never attended meetings but were active for many years, 
nonetheless, in their various IETF protocol interest areas.


The structure of this questionnaire will be important to be successful 
and beneficial.


Sincerely,

Hector Santos


On 5/3/2013 10:32 AM, Thomas Narten wrote:

"Adrian Farrel"  writes:


Well said, Thomas.



Two concrete suggestions:

1) have WGs do the managing role more proactively
2) mentor authors and others a bit more to encourage them how best to
operate



Which I suspect means...



0) have ADs manage/mentor the WG chairs more proactively.


Absolutely. But that is why the nomcom is supposed to select ADs that
have *management* capabilities as well as technical skills.


Almost certainly a case of "if I had less work to do I would have
more time to do the things that would reduce my workload."  :-)


Well, this is why you get paid the big bucks.

Not to put too fine a point on in, but ADs need to manage their time,
and they need to balance between the immediate and the long term. They
have to do *both*, and especially NOT neglect longer-term stuff that
will have real and signficant, but not immediate benefits.


WG chairs might like to comment, but I suspect that one lunchtime training
session every four months does not constitute proactive management.


This would help and could be part of a comprehensive approach. But ADs
also need to lay down expectations on WG chairs, and *grade* and
*evaluate* WG Chair performance. WG chairs also don't have
cycles... And ADs seem reluctant to step in and make management
changes that really often are needed to change the dynamices within
WGs that are not delivering...

Thomas

Re: Effects on DNS can be severe &&& Re: call for ideas: tail-heavy IETF process

[Scott Kitterman]

There's been a details review of his draft done when it was published, if you 
want something more coherent to read:

http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis

In the more than half decade since, the issue has been discussed and reviewed 
many times.  In the pre-IETF phase of SPF development the processing limits 
were very different and, in my opinion, inherently risky.  The changed 
processing limits is probably the most important technical difference between 
RFC 4408 and the pre-IETF drafts.  To the extent there is a significant 
problem, I think the changes in RFC 4408 substantially mitigated it and the 
4408bis draft goes a bit further.

We did have an extensive discussion about SPF macros and if they should be 
removed.  The conclusion of the working group was that given our charter and 
the facts available, they should not.  

Doug's claim not to have participated is not correct.  All you have to do is 
look at the mailing list archive.  It's true that he seems to have stopped at 
some point, but having submitted issues to a WG that were reviewed and that 
ultimately impacted the text in the draft is not at all not participating.

Finally, I don't think it's reasonable for a draft to document internally why 
various decisions were made.  It needs to document the results of the WG 
efforts.  4408bis is long enough already and all the working group discussions 
are documented for people who are interested.

Scott K

On Friday, May 03, 2013 02:11:28 PM Tony Hain wrote:
> Scott,
> 
> See the thread about Re: call for ideas: tail-heavy IETF process for
> discussion about wider review at an earlier point in the process. Also, just
> because there is a discussion on issue-tracker does not mean the document
> is 'high quality'. If there is an explicit trade-off being made, the main
> document needs to address that directly so subsequent reviewers and
> implementers know what and why.
> 
> I have not followed this discussion, but my cursory read of the tracker
> ticket shows the WG blew off the issue by claiming that historical
> unsophisticated attacks can be easily thwarted, while completely ignoring
> the case where the target domains exist. Aborting an amplification attack on
> failures does not do anything about the case where an attacker goes to the
> trouble to make sure all the quires will return valid answers. Either the
> issue-tracker discussion is inadequate, or this is exactly the kind of
> thing that adds excess delay and workload to the IESG review process.
> 
> FWIW: id-otis-spf is an incoherent collection of issues. I can see why a WG
> might have trouble parsing it, and come out with a different answer than
> what was expected. That said, wider review requires a simpler problem
> statement and understanding of what resources are being traded against
> others, and for security issues in particular, a comprehensive set of attack
> scenarios and mitigations.
> 
> Tony
> 
> > -Original Message-
> > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> > Scott Kitterman
> > Sent: Friday, May 03, 2013 1:00 PM
> > To: ietf@ietf.org
> > Subject: Re: Effects on DNS can be severe
> > 
> > On Friday, May 03, 2013 12:46:52 PM Douglas Otis wrote:
> > > On May 3, 2013, at 12:21 PM, Scott Kitterman 
> > 
> > wrote:
> > > > On Friday, May 03, 2013 12:04:53 PM Douglas Otis wrote:
> > > > ...
> > > > 
> > > >> Over many years at attempting to change the course of the SPF
> > > >> process, this effort appears to have been futile.
> > > > 
> > > > ...
> > > > 
> > > > It does seem a bit odd for you to claim you're being ignored when
> > > > the largest change in SPF processing limits contained in 4408bis was
> > > > your suggestion.  An alternate interpretation to consider is that
> > > > the working group fully considered your inputs and incorporated
> > > > those that were appropriate technically and in scope for the charter.
> > > 
> > > Dear Scott,
> > > 
> > > 
> > > This was not directly part of the IETF process, as my input there was
> > > ignored.
> > > 
> > > As I recall, removal of unlimited recursion occurred after a
> > > presentation made in Boston to the Open Group.
> > 
> > I assume you are referring to some of the pre-IETF activities for SPF.
> > Recursion based processing limits don't appear in RFC 4408 (and also not
> 
> in
> 
> > 4408bis).
> > 
> > > As with unlimited recursion, the need for the macro functions are also
> > > negligible while posing real risks. This is a serious security concern
> > > still needing to be addressed.
> > 
> > This was discussed in the working group and tracked in the WG issue
> 
> tracker:
> > http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24
> > 
> > The change mentioned in the ticket is a direct result of your input to
> 
> spfbis
> 
> > (referenced in the ticket).
> > 
> > As far as I can tell, this is just a case of "the working group came to a
> 
> different
> 
> > conclusion, so I'll whine about it on the 

Re: Language editing

[Brian E Carpenter]

On 04/05/2013 09:22, Yaron Sheffer wrote:
> GEN-ART is a good example, but actual document editing is much more work
> and arguably, less rewarding than a review. So I think this can only
> succeed with professional (=paid) editors.

I think I disagree, if we can find the knack of effective crowd-sourcing.
We do after all have several hundred native English speakers active
in the IETF, which would mean each one would have to volunteer for
less than one draft per year and we'd be done.

I don't know how much experience you have with professional editors.
Apart from the RFC Editor crew, my experience has been "mixed". Somebody
a year or three ago (the last time we had this exact same discussion)
pointed out the differences between copy-editors and technical editors.
One difference is that the latter are much more expensive. Copy-editors
tend to be rule-driven; technical editors are supposed to understand
the material.

Brian

Re: Language editing

[Doug Barton]

On 05/03/2013 02:22 PM, Yaron Sheffer wrote:

GEN-ART is a good example, but actual document editing is much more work
and arguably, less rewarding than a review. So I think this can only
succeed with professional (=paid) editors.


I'm not sure that's the right conclusion to draw.

In the past I have done extremely detailed copy editing for drafts that 
I was particularly excited about, and wanted to help become RFCs. In 
exactly 1 case that work was warmly received by the author. In all the 
other cases I was met with reactions anywhere from mild disinterest to 
open hostility. In the most extreme example I was told on the list that 
my efforts were not welcome, would not be incorporated into any future 
drafts, and that I should not be trying to do the RFC Editor's job for 
them. I was also accused in private of trying to make the author look 
stupid. As a result of the at best generally apathetic reaction I no 
longer bother doing that kind of detailed copy editing when I review 
drafts.


The conclusion I have drawn (based in part on my own limited experience, 
and in part in seeing the same thing played out in IETF LC) is that as a 
community we do not place sufficient value on high quality work at late 
stages in the process. This is unfortunate on several levels. First, 
while I have the highest respect for the quality of work that the RFC 
Editor does it's not realistic to expect them to catch everything. And 
even if we were willing to fund the next-highest level of 
review/editing, in the best case scenario that kind of work usually 
incurs additional delays due to having to go back and forth with the 
authors, WG, etc. But I think more importantly, by not engaging in a 
better class of refinement at the WG level we miss the opportunity to 
help bring everyone's skill set up to a higher level.


There is a serious caveat to this though, we do not want to generate a 
perception that "only perfect English text need apply." We should make 
clear that _initial_ versions of drafts can and should be submitted even 
if the prose isn't yet publishable. But we should also make clear that 
help will be provided to _get_ the text up to snuff, and we should value 
that goal as an institution.


Doug

Re: call for ideas: tail-heavy IETF process

[Barry Leiba]

> I would like to suggest that the IESG Review be done in public on the WG
> mailing list.I've been a WG co-chair for just over a year now, and
> I'm truly astounded by what happens behind the scenes.
>
> It's not the substance, it's the quantity, and the lack of WG view of
> it.   I think that this substantially and quite negatively contributes
> to the "fix it during IESG review", and therefore to the IESG workload.

Pete and I suggested this to the App chairs in Orlando (see here:
http://www.ietf.org/proceedings/86/slides/slides-86-appsawg-4.pdf ),
and we are currently trying it out with draft-ietf-core-coap, which is
scheduled for the 16 May IESG telechat (see
http://datatracker.ietf.org/doc/draft-ietf-core-coap/ and note that
I've set the "Send notices to" field to include the working group
mailing list).

It appears to be working very well, and I'd like to try it on more
documents in more working groups.  Perhaps some day it will be the
normal way to operate; we'll have to see.

Barry, Applications AD

Re: Language editing

[Yaron Sheffer]

GEN-ART is a good example, but actual document editing is much more work 
and arguably, less rewarding than a review. So I think this can only 
succeed with professional (=paid) editors.


Thanks,
Yaron



On 05/02/2013 02:40 PM, Yaron Sheffer wrote:

I suggest that we budget for a number of WG drafts per year (say,
20 IETF-wide) to go through professional, paid-for heavy-duty
editing


My experience is that unless the editors have some background in
protocols, this takes a surprising amount of effort, explaining it to
them and catching _their_ mistaken assumptions (which can be subtle).
  However,

On 05/02/13 19:13, Peter Saint-Andre allegedly wrote:

Instead of imposing even more work on the RFC Editor team, I
suggest that you find someone in the WG, in your company, in the
IETF community (etc.) to help with the language issues.


... then you have quality control issues, uncertainty who to turn to,
finding someone who not only appears to be good but actually is, etc.

So how about a pool of volunteer editors, aka GEN-AET, with developed
reputations?

Re: Last Call: Change the status of DKIM (RFC 6376) to Internet Standard

[Murray S. Kucherawy]

What he said, except that I don't run the perl thing.  :-)

+1.


On Fri, May 3, 2013 at 11:52 AM, John Levine  wrote:

> I use DKIM via two independent implementations, perl Mail::DKIM to
> sign outgoing mail, and C language opendkim to check incoming mail in
> the SMTP daemon.  It is a mature protocol and the implmentations
> interoperate with no problems I've ever seen.
>
> I support promoting 6376 to Internet Standard.
>
> Regards,
> John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. http://jl.ly
>
>

RE: Effects on DNS can be severe &&& Re: call for ideas: tail-heavy IETF process

[Tony Hain]

Scott, 

See the thread about Re: call for ideas: tail-heavy IETF process for
discussion about wider review at an earlier point in the process. Also, just
because there is a discussion on issue-tracker does not mean the document is
'high quality'. If there is an explicit trade-off being made, the main
document needs to address that directly so subsequent reviewers and
implementers know what and why.

I have not followed this discussion, but my cursory read of the tracker
ticket shows the WG blew off the issue by claiming that historical
unsophisticated attacks can be easily thwarted, while completely ignoring
the case where the target domains exist. Aborting an amplification attack on
failures does not do anything about the case where an attacker goes to the
trouble to make sure all the quires will return valid answers. Either the
issue-tracker discussion is inadequate, or this is exactly the kind of thing
that adds excess delay and workload to the IESG review process.

FWIW: id-otis-spf is an incoherent collection of issues. I can see why a WG
might have trouble parsing it, and come out with a different answer than
what was expected. That said, wider review requires a simpler problem
statement and understanding of what resources are being traded against
others, and for security issues in particular, a comprehensive set of attack
scenarios and mitigations. 

Tony


> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
> Scott Kitterman
> Sent: Friday, May 03, 2013 1:00 PM
> To: ietf@ietf.org
> Subject: Re: Effects on DNS can be severe
> 
> On Friday, May 03, 2013 12:46:52 PM Douglas Otis wrote:
> > On May 3, 2013, at 12:21 PM, Scott Kitterman 
> wrote:
> > > On Friday, May 03, 2013 12:04:53 PM Douglas Otis wrote:
> > > ...
> > >
> > >> Over many years at attempting to change the course of the SPF
> > >> process, this effort appears to have been futile.
> > >
> > > ...
> > >
> > > It does seem a bit odd for you to claim you're being ignored when
> > > the largest change in SPF processing limits contained in 4408bis was
> > > your suggestion.  An alternate interpretation to consider is that
> > > the working group fully considered your inputs and incorporated
> > > those that were appropriate technically and in scope for the charter.
> >
> > Dear Scott,
> >
> >
> > This was not directly part of the IETF process, as my input there was
> > ignored.
> >
> > As I recall, removal of unlimited recursion occurred after a
> > presentation made in Boston to the Open Group.
> 
> I assume you are referring to some of the pre-IETF activities for SPF.
> Recursion based processing limits don't appear in RFC 4408 (and also not
in
> 4408bis).
> 
> > As with unlimited recursion, the need for the macro functions are also
> > negligible while posing real risks. This is a serious security concern
> > still needing to be addressed.
> 
> This was discussed in the working group and tracked in the WG issue
tracker:
> 
> http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24
> 
> The change mentioned in the ticket is a direct result of your input to
spfbis
> (referenced in the ticket).
> 
> As far as I can tell, this is just a case of "the working group came to a
different
> conclusion, so I'll whine about it on the main list".
> 
> Scott K

Re: Effects on DNS can be severe

[Scott Kitterman]

On Friday, May 03, 2013 12:46:52 PM Douglas Otis wrote:
> On May 3, 2013, at 12:21 PM, Scott Kitterman  wrote:
> > On Friday, May 03, 2013 12:04:53 PM Douglas Otis wrote:
> > ...
> > 
> >> Over many years at attempting to change the course of the SPF process,
> >> this
> >> effort appears to have been futile.
> > 
> > ...
> > 
> > It does seem a bit odd for you to claim you're being ignored when the
> > largest change in SPF processing limits contained in 4408bis was your
> > suggestion.  An alternate interpretation to consider is that the working
> > group fully considered your inputs and incorporated those that were
> > appropriate technically and in scope for the charter.
> 
> Dear Scott,
> 
> 
> This was not directly part of the IETF process, as my input there was
> ignored.
> 
> As I recall, removal of unlimited recursion occurred after a presentation
> made in Boston to the Open Group.

I assume you are referring to some of the pre-IETF activities for SPF.  
Recursion based processing limits don't appear in RFC 4408 (and also not in 
4408bis).

> As with unlimited recursion, the need for the macro functions are also
> negligible while posing real risks. This is a serious security concern
> still needing to be addressed.

This was discussed in the working group and tracked in the WG issue tracker:

http://trac.tools.ietf.org/wg/spfbis/trac/ticket/24

The change mentioned in the ticket is a direct result of your input to spfbis 
(referenced in the ticket).

As far as I can tell, this is just a case of "the working group came to a 
different conclusion, so I'll whine about it on the main list".

Scott K

Re: Effects on DNS can be severe

[Douglas Otis]

On May 3, 2013, at 12:21 PM, Scott Kitterman  wrote:

> On Friday, May 03, 2013 12:04:53 PM Douglas Otis wrote:
> ...
>> Over many years at attempting to change the course of the SPF process, this
>> effort appears to have been futile.
> ...
> 
> It does seem a bit odd for you to claim you're being ignored when the largest 
> change in SPF processing limits contained in 4408bis was your suggestion.  An 
> alternate interpretation to consider is that the working group fully 
> considered your inputs and incorporated those that were appropriate 
> technically and in scope for the charter.

Dear Scott,


This was not directly part of the IETF process, as my input there was ignored.

As I recall, removal of unlimited recursion occurred after a presentation made 
in Boston to the Open Group.

As with unlimited recursion, the need for the macro functions are also 
negligible while posing real risks. This is a serious security concern still 
needing to be addressed.

Regards,
Douglas Otis

Re: call for ideas: tail-heavy IETF process

[Thomas Narten]

Pete Resnick  writes:

> On 5/3/13 7:59 AM, Thomas Narten wrote:

> > Like everyone, I wish things moved more quickly, but every attempt
> > I've ever seen that tries to speed things up ends up reducing the
> > quality or having some other undesirable side effect.
> >

> Can you talk a bit more about this, including some examples?

Sorry, what I had in mind here was what I'll call process
tweaks. Attempts at changing the process to speed reviews, dispense
with reviews, overlap reviews, etc.

No, our processes aren't perfect. But we have bigger problems that are
not due to process that we'd do better to focus on rather than trying
to tweak the process in (IMO) minor ways. We should focussing more on
*root* *causes* and what concrete, pragmatic steps can be taken to
mitigate them.

> I'm trying to reconcile the concern that we "end up reducing the 
> quality"

Again, I was thinking of proposals for process (or operational)
changes that attempt to shorten things by overlapping or removing
reviews or steps, trying to get the IESG to do less review (e.g., "ADs
should only review looking at topics that are defined by their area")
and otherwise focus on the *process* as being the problem.

> and  that we "NOT neglect longer-term stuff that will have real 
> and significant, but not immediate benefits." ADs have finite resources 
> and can't accomplish both immediate and longer-term stuff maximally all 
> of the time. My inclination would be to say, "If they are in conflict, 
> weight the longer-term over the immediate, even if that might result in 
> some reducing of quality on any single document." Am I over-reading your 
> earlier message to say that you think the weighting should go toward the 
> immediate?

You have it right. And I meant "longer-term stuff" in a general
sense. There are many topics that are not immediate, but could be
important long term.

Spend enough time on long term so that it is not neglected. You have
to do both. But you must also MUST do long term stuff.

> I think we agree that doing the longer-term stuff will end up 
> with increased quality over the long term, but doing more of the 
> longer-term stuff is sure to reduce the amount of time spent on 
> immediate, which means document reviews and therefore some short term 
> lowering of quality. Is that OK, or is that an example of the kind of 
> thing we've attempted that ends up with bad results?

It's easy to fall back to the comfort zone, which is doing the
bi-weekly document reviews and such. I.e., the day-to-day operational
stuff.

What's more important to the IETF? Spending time on one questionable
(but quite possibly irrelevant) document to make it better before it gets
published? Or getting the IETF as a whole to work better and more
efficiently and produce better product?

Thomas

Re: Effects on DNS can be severe

[Scott Kitterman]

On Friday, May 03, 2013 12:04:53 PM Douglas Otis wrote:
...
> Over many years at attempting to change the course of the SPF process, this
> effort appears to have been futile.
...

It does seem a bit odd for you to claim you're being ignored when the largest 
change in SPF processing limits contained in 4408bis was your suggestion.  An 
alternate interpretation to consider is that the working group fully 
considered your inputs and incorporated those that were appropriate 
technically and in scope for the charter.

Scott K

Effects on DNS can be severe

[Douglas Otis]

Dear ietf and dnsext,

I apologies for posting this ahead of the wg last call.

Over many years at attempting to change the course of the SPF process, this 
effort appears to have been futile.
It seems many even feel the present spfbis document represents current 
practices.  It does not, from the perspective of macros.
I have written an I-D that I fully expect SPF proponents will denounce and so I 
have left that wg alone.  

Here is a draft written in hopes of placing these concerns into a broader 
scope--
http://tools.ietf.org/html/draft-otis-ipv6-email-authent-00

Two references in this draft  did not carry over in the same manner as in the 
tcl script?  
Until remedied, here are the links missing in this i-d:

[I-D.otis-spf-dos-exploit]
http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01

[v6-BGP-Rpts]
http://bgp.potaroo.net/v6/as6447/

SPF can pose serious threats, that when confronted, few solutions are 
available.  I have been able to convince some of the larger providers of this 
concern, who in returned offered assurances the macro extensions in their SPF 
libraries are removed and in doing so have not seen any problems.

This is a serious effort at addressing a security concern, please read this 
draft from that perspective.

Regards,
Douglas Otis

RE: call for ideas: tail-heavy IETF process

[Tony Hain]

Pete Resnick wrote:
> Not disagreeing with your message, but a couple of clarifying points:
> 
> On 5/3/13 12:41 PM, Tony Hain wrote:
> 
> > I would agree with you that weighting longer term is the 'right
> > thing', but given that people wait for an RFC number to implement, and
> > then take the position that RFC (PS) == STD, you never get to the
> > longer term because the bar is set so high on the first hurdle that it
> > becomes impossible for people to justify the effort to go for the next
one.
> >
> 
> When Thomas said "longer-term", I took him to mean *all* of the things
that
> are longer time horizon, like management/mentoring of WGs and chairs,
> doing more early cross-area participation (including by ADs) in the design
of
> and work on protocols (not just review), etc. In particular, I didn't
understand
> him to mean longer-term as having anything to do with advancement on the
> standards track. I think the above longer-term goals are important. I
think
> movement along the standards track will be the outcome if we get to
> working well, but not a goal in-and-of itself.

I actually view all of the housekeeping activities as short term. Thomas
will have to state what he meant.

> 
> > In any case I don't see 60/40 as a tail-heavy process. If the WG time
> > were cut in half and the IESG/RFC-editor time stayed the same, maybe
> > it would be tail-heavy, but realistically more 'balanced'.
> >
> 
> I'll point you to Jari's excellent reminder that "time" is probably the
least of
> the heaviness on the tail end. What is tail heavy is the work
> investment: We do WG last call reviews, IETF-wide Last Call reviews,
> directorate reviews, IESG reviews, all at the end of the process. We spend
> scant little energy (of the wider IETF community and leadership) on early
> design reviews and protocol development early and in the middle of the
> document process. As Jari said, that model ends us up with late surprises,
> lack of transparency, etc., and probably uses much more energy overall
than
> if we invested it earlier in the process. Sure, this can translate to
delays, but
> that's only one (maybe minor) effect of being tail-heavy.

While I agree that it would appear to be a heavy workload, that is just
because it is concentrated enough to see. If you actually did all the work
across all the participants to review every document at every iteration,
nothing would get done. Even when the IETF was ~60 people creating a few
documents a year, reviews happened late, and changes were made. Yes earlier
comments from outside the WG will reduce overall surprise and workload, but
finding the right reviewers is tricky.

One could require that every BOF be presented to every Open Area meeting,
then required public comment from every other AD before being allowed to
form a WG. This would front load the review and raise general awareness
about what is being discussed. Unfortunately since that event and resulting
documents are half a decade apart, potential reviewers have long since
forgotten any concerns they might have had, and need to start fresh anyway.
For long standing WGs one could consider doing the same at every charter
change, but again, document movement within the WG needs to be faster for
any of that to matter. 

The only way I can see to reduce the time from BOF to RFC is to reduce the
public expectation on the quality of that initial document which will get
wide review and initial implementation.  We should be talking about ~ 3
years to get to STD, not the initial draft that gets review beyond the WG.
In practice what we have today is functionally STD at initial publication,
so there is a very concentrated effort at one point in time. If the process
to get from WG I-D to initial RFC was basically a sanity-check, the detailed
IESG and cross-area review could be spread out during implementation prior
to the update that removed the DRAFT: status. Realistically though, human
nature would take over and nothing would happen until the WG tried to take
that step and we would be having the same discussion about tail work load. 

Bottom line, we need a signal to other areas that a WG document is ready for
serious in depth review, and a document title change seems to be what people
are looking for. At the same time WGs need to do a better job of spreading
awareness earlier in the process to get comments from those that have
different perspectives, then actually listen to them during document
development. Surprise comes from being isolated, and/or shouting down voices
that later come back during review to highlight flaws. If the process to get
to DRAFT: status was less burdensome, documents would move more quickly and
less effort would have gone into the flawed document before it got seriously
reviewed. 

Tony

Re: Last Call: Change the status of DKIM (RFC 6376) to Internet Standard

[John Levine]

I use DKIM via two independent implementations, perl Mail::DKIM to
sign outgoing mail, and C language opendkim to check incoming mail in
the SMTP daemon.  It is a mature protocol and the implmentations
interoperate with no problems I've ever seen.

I support promoting 6376 to Internet Standard.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

Re: call for ideas: tail-heavy IETF process

[Pete Resnick]

Not disagreeing with your message, but a couple of clarifying points:

On 5/3/13 12:41 PM, Tony Hain wrote:


I would agree with you that weighting longer term is the 'right thing', but
given that people wait for an RFC number to implement, and then take the
position that RFC (PS) == STD, you never get to the longer term because the
bar is set so high on the first hurdle that it becomes impossible for people
to justify the effort to go for the next one.
   


When Thomas said "longer-term", I took him to mean *all* of the things 
that are longer time horizon, like management/mentoring of WGs and 
chairs, doing more early cross-area participation (including by ADs) in 
the design of and work on protocols (not just review), etc. In 
particular, I didn't understand him to mean longer-term as having 
anything to do with advancement on the standards track. I think the 
above longer-term goals are important. I think movement along the 
standards track will be the outcome if we get to working well, but not a 
goal in-and-of itself.



In any case I don't see 60/40 as a tail-heavy process. If the WG time were
cut in half and the IESG/RFC-editor time stayed the same, maybe it would be
tail-heavy, but realistically more 'balanced'.
   


I'll point you to Jari's excellent reminder that "time" is probably the 
least of the heaviness on the tail end. What is tail heavy is the work 
investment: We do WG last call reviews, IETF-wide Last Call reviews, 
directorate reviews, IESG reviews, all at the end of the process. We 
spend scant little energy (of the wider IETF community and leadership) 
on early design reviews and protocol development early and in the middle 
of the document process. As Jari said, that model ends us up with late 
surprises, lack of transparency, etc., and probably uses much more 
energy overall than if we invested it earlier in the process. Sure, this 
can translate to delays, but that's only one (maybe minor) effect of 
being tail-heavy.


pr

--
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478

Re: Language editing

[Dale R. Worley]

> From: Scott Brim 
> 
> My experience is that unless the editors have some background in
> protocols, this takes a surprising amount of effort, explaining it to
> them and catching _their_ mistaken assumptions (which can be subtle).

I'm told that the CCITT maintains a staff of technical writers.
Certainly, the *writing* in their standards is better.

Dale

Re: [spfbis] [dnsext] Obsoleting SPF RRTYPE

[Noel David Torres Taño]

On Jueves, 2 de mayo de 2013 15:53:09 Eliot Lear wrote:
> 3.  What can be done by the IETF to improve likelihood of adoption, and
> conversely what should we not bang our heads against?

Amend the Wikipedia article about SPF, where it states that it is TXT only?

-
A: Because it breaks the logical flow of discussion.
Q: Why is top posting bad?


signature.asc
Description: This is a digitally signed message part.

Re: call for ideas: tail-heavy IETF process

[Ralph Droms]

On May 3, 2013, at 8:59 AM 5/3/13, Thomas Narten  wrote:

> Just a few points...
> 
> Michael Richardson  writes:
> 
>> I'll repeat what has been said repeatedly in the newtrk and related
>> discussions.  The step from ID to "RFC" is too large because we are
>> essentially always aiming for "STD" rather than "PS".
> 
>> If we are unwilling to bring "RFC" back to a place were it does not
>> equal STD, then we need to create a new category of document which
>> amounts to "fully baked ID".  Things like IANA allocations could occur
>> at that point.
> 
>> In the days of dot-boom it was not unusual to see widespread
>> implementation very early in the ID process and even interop and
>> experimental deployment.   While this still occurs for quite a number of
>> things (and sometimes it's a problem that the ID can not be changed as a
>> result), there is an equal amount of "wait for the RFC to come out".
> 
> I suspect there is a bit of rose colored reminiscing of history.
> 
> The world has changed, significantly.
> 
> For example, there has been massive consolidation in industry. There
> simply are fewer entities doing implementations today. 15 years ago,
> it was common to see a half dozen or more implementations from
> different (often smaller) entities, even before a document got out of
> a WG. Nowadays, the cost of doing an implementation (for a company) is
> in some sense much higher, and business realities make companies
> *very* selective in what they implement and put into a product.

Adding a little detail - those implementations have to be prototypes, with the 
implementing entities willing to make changes in the code prior to shipping 
product. Once the code has been shipped to customers, there is a lot of 
resistance to making changes to the specification.  

> I suspect that the notion that if the IETF published documents more
> quickly industry would implement them more quickly/frequently is
> wishful thinking.
> 
> Michael Richardson  writes:
>> It's what Carsten said.
> 
>> 1) this idea is baked enough for cross-area review to make sense.
>> 2) the protocol is not going to change significantly, one could
>>   implement.
>> 3) any future changes need thus to take into account impact on
>>   existing implementations... BUT that doesn't mean that we can't
>>   change things.
> 
> Like it or not, 2 and 3 are contradictory. From an interoperability
> perspective, the difference between "not change significantly" and
> "change a lot" is irrelevant once you have deployments. Change (in the
> behavior or wire format) is change and breaks interoperability, no
> matter how big or small.

Right, so declaring a document a "fully baked ID" might have the perverse 
effect of freezing specifications at a point where there are still problems.

The key issues are the investment in an implementation, the cost of updating an 
implementation and, perhaps most importantly, the cost of making changes to 
code that has been shipped in products.

> 
> Hannes Tschofenig  writes:
> 
>> b) There is no interest to research where delay really happen.
> 
> I don't think that is true. Jari has pointed to his work. I think
> there is actually quite a lot of understanding of where the delays
> are. But fixing them is really really hard. Blaming the "tail end" or
> "the IESG" for the problems has always been the easy target. The
> reality (IMO) is that the place where improvements are needed is
> within the WG and on having authors be more responsive. But history
> suggests there are no easy fixes here.
> 
> Randy Bush  writes:
> 
>>> A basic question, then, is whether we think these absolute numbers and
>>> these proportions of time are reasonable and appropriate for the IETF
>>> to be/remain effective?
> 
>> seems pretty reasonable to me.  from personal experience, the iesg and
>> rfced add useful value.
> 
> +1

It would be interesting to understand the cost of that useful value, and 
whether the same useful value could be provided elsewhere at reduced cost.

"Cost" in this case can be tricky - the useful value in IESG review comes at 
the cost of asking the members of the IESG to invest 10s of hours per week in 
careful review of every document.  That time requirement contributes to the 
notion that being an AD is a full time job, which in return reduces the 
diversity of the pool of candidates willing to volunteer for an AD position.

So, there is useful value, but can we get that same value by distributing the 
load out to the larger community?

> 
> Like everyone, I wish things moved more quickly, but every attempt
> I've ever seen that tries to speed things up ends up reducing the
> quality or having some other undesirable side effect.
> 
> The bottom line is that getting a good spec requires iteration, and
> reviews from a broad set of parties. That is best done
> *sequentially*. And given the limited cycles the (volunteer) community
> as a whole has, you can't easily change these dynamics. We've seen
> many attempts t

RE: call for ideas: tail-heavy IETF process

[Tony Hain]

Pete Resnick wrote:
...
> On 5/3/13 7:59 AM, Thomas Narten wrote:
> 
> > Like everyone, I wish things moved more quickly, but every attempt
> > I've ever seen that tries to speed things up ends up reducing the
> > quality or having some other undesirable side effect.
> >
> 
> Can you talk a bit more about this, including some examples?
> 
> I'm trying to reconcile the concern that we "end up reducing the quality"
and
> that we "NOT neglect longer-term stuff that will have real and
significant, but
> not immediate benefits." ADs have finite resources and can't accomplish
> both immediate and longer-term stuff maximally all of the time. My
> inclination would be to say, "If they are in conflict, weight the
longer-term
> over the immediate, even if that might result in some reducing of quality
on
> any single document." Am I over-reading your earlier message to say that
> you think the weighting should go toward the immediate? I think we agree
> that doing the longer-term stuff will end up with increased quality over
the
> long term, but doing more of the longer-term stuff is sure to reduce the
> amount of time spent on immediate, which means document reviews and
> therefore some short term lowering of quality. Is that OK, or is that an
> example of the kind of thing we've attempted that ends up with bad
results?
> 

Pete,

I would agree with you that weighting longer term is the 'right thing', but
given that people wait for an RFC number to implement, and then take the
position that RFC (PS) == STD, you never get to the longer term because the
bar is set so high on the first hurdle that it becomes impossible for people
to justify the effort to go for the next one.



When the I-D series was introduced specifically to deal with the issue of
RFC == STD, we didn't get it right. In hind sight we should have done
something more like the IEEE does with 802.11, and explicitly put a big
DRAFT: in the title. Industry doesn't seem to get confused about DRAFT: N or
DRAFT: AC, and still deploys, then moves on with full standards. We could
still do that, and likely get motivation to move a DRAFT: to PS (remove the
DRAFT: from the title) by wider review and deployment. I realize this is
really doing nothing more than introducing an extra step in the process, but
in some ways it is more of a formalization of the expected behavior at the
first RFC step. One could go so far as to not remove DRAFT: until the spec
met DS, and move the default  from PS to DS at the same time as removing the
extra step from the process. One could really get crazy and just remove DS
from the list, because nobody understands what that one is for anyway, and
then when the DRAFT: gets removed from the title it is really the STD people
are expecting ... ;)

In any case I don't see 60/40 as a tail-heavy process. If the WG time were
cut in half and the IESG/RFC-editor time stayed the same, maybe it would be
tail-heavy, but realistically more 'balanced'.  At the end of the day, the
only way to reduce the time at IESG review is to have a document with clear
objectives up front that the document can be evaluated against, and for the
WG to put a quality document in their hands. Too often the WG takes so long
that the objectives drift, if they were even clearly stated up front, and
comments like "you have to have been involved in the mail thread" show up
during review. If something is not clear in the document, and it was cleared
up in a meeting or on the mail list, that clarification needs to get moved
into the document or subsequent reviewers / implementers will never get it,
and the result is delay and/or poor quality documents. 

Tony

Re: call for ideas: tail-heavy IETF process

[Michael Richardson]

> "Thomas" == Thomas Narten  writes:
Thomas> The current cycle too often seems to be more like "new
Thomas> version posted". Wait if anyone reviews. Some reviews
Thomas> eventually, maybe. Oh, IETF meeting coming, time for a
Thomas> revision. But with meeting approaching, there are a zillion
Thomas> docs and cycles are limited.  Rather haphazard, with too
Thomas> many documents effectively only being revised once per
Thomas> meeting cycle.

I would like to suggest that the IESG Review be done in public on the WG
mailing list.I've been a WG co-chair for just over a year now, and
I'm truly astounded by what happens behind the scenes.  

It's not the substance, it's the quantity, and the lack of WG view of
it.   I think that this substantially and quite negatively contributes
to the "fix it during IESG review", and therefore to the IESG workload.

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





pgpI0t3me2_sq.pgp
Description: PGP signature

Re: call for ideas: tail-heavy IETF process

[Thomas Narten]

Dave Crocker  writes:

> The issue with providing management assistance is to focus on
> managing the work.  That's an organizational orientation, not just a
> tracking thing.  It's about getting clarity of the work to be done
> and of getting folks to do the work of contributing, writing,
> reviewing, and debating in a timely manner, and achieving forward
> progress in a timely manner.

> Few working groups have enough detail to juggle to make this
> something that hinges on the tools.

Strongly agree here.

Let me expand further on "work plan" and  "project management".

It needs to be done on a per-document basis. I.e., Wouldn't it be nice
if every WG document was revised 3 times between meetings? I bet that
alone would change dynamics (assuming there were substantive
changes)...

But it extends to the WG as a whole.  WGs have a finite number of
cycles. There are always a small number of core players (whether
editor, reviewer, etc.), and if you spread their resources too thinly,
a WG starts having problems.

Few WGs acknowledge that and try to manage it. Managing it means:

1) identifying core documents that are priority, and minimizing
distractions that will take cycles away from the priority
deliverables.

2) It may mean making concious decisions not to work on some documente
*yet* in order to concentrate resources where it matters

3) it means tying the work plan directly back to the charter. If the
two aren't in sync, one or both need changing.

4) It means recognizing that there are real limits to how many
documents a WG can (credibly) work on at any one time. (Too many WGs
have lots of marginal documents that suck cycles away from the
critical ones.) How many WGs say "no" to marginal documents?

Thomas

Re: call for ideas: tail-heavy IETF process

[t . p .]

- Original Message -
From: "Ray Pelletier" 
To: 
Cc: "Thomas Narten" ; "IETF list" 
Sent: Friday, May 03, 2013 3:29 PM

On May 3, 2013, at 10:20 AM, "Adrian Farrel" 
wrote:

> Well said, Thomas.
>
>> Two concrete suggestions:
>>
>> 1) have WGs do the managing role more proactively

Provide WG Chairs the monitoring tools they need to be proactive -
Action Tracker, what do I need to do today data tracker  views.  Same
for AD.



Such as a list once a month, sent to the list of each active WG, of the
state change, if any, in the I-Ds which have been accepted by the WG as
work items, giving the date at which the last state change occurred.
State is not just the IESG type tracker state, but also a new revision
of the I-D.

I know how useful I find this from the WG Chairs who produce it already.

Tom Petch


Same for authors and their mentors, if any.

Ray


>> 2) mentor authors and others a bit more to encourage them how best to
>> operate
>
> Which I suspect means...
>
> 0) have ADs manage/mentor the WG chairs more proactively.
>
> Almost certainly a case of "if I had less work to do I would have more
time to
> do the things that would reduce my workload."  :-)
>
> WG chairs might like to comment, but I suspect that one lunchtime
training
> session every four months does not constitute proactive management.
>
> Adrian
>

Re: call for ideas: tail-heavy IETF process

[Thomas Narten]

Ray Pelletier  writes:

> Provide WG Chairs the monitoring tools they need to be proactive -
>  Action Tracker, what do I need to do today data tracker views.
>  Same for AD.

> Same for authors and their mentors, if any.

Tools may help in some cases (IESG, chairs), but the fundamental
problem is not tools. It's about work culture, setting proper
expectations (and communicating them to everyone), and having
accountability and followup to fix things when stuff isn't happening.

Thomas

Re: [IETF] Re: Balancing the Process (Was: Obsoleting SPF RRTYPE)

[Warren Kumari]

On May 2, 2013, at 9:56 PM, Mark Andrews  wrote:

> 
> In message <5182828c.3040...@isdg.net>, Hector Santos writes:
>> Mr. Resnick,  for the record, I wasn't upset. Believe it or not, I was 
>> actually applying an suggestion posted last month or so here with the 
>> IETF diversity talks to help get a major WG issue resolved, one with a 
>> near surety of an appeal, resolved and addressed much faster and hence 
>> avoid a waste of time on the behalf of all.
>> 
>> How appropo, that a topic of "balancing of process" as being considered. 
>>   It is one thing I believe the IETF needs and can be actually apply 
>> today. Yes, I don't agree with the negative tone taken in SPFBIS where 
>> in effect, an attempt to shut down communications and indirectly 
>> personally attack posters occurred and the advocates of the SPF RRTYPE 
>> removal (incidentally, a SPEC change which I believe was prohibited by 
>> the charter), basically blowing off advocates of a RFC4408 status quo. 
>> If you believe that was proper, I think we have a WG problem.
>> 
>> Overall, I believe this (keep the migration path) is the proper 
>> compromise to resolve the issue, and I believe that this particular 
>> issue is industry-wide important to resolve with across the board 
>> engineering input. It *SHOULD NOT* be reserved only to the applications 
>> SPFBIS group especially when we know what the DNS community will say 
>> about this and has said so since MARID 2003 and again last year in IETF 
>> and DNSOPs. I was simply hoping to help "Balance the process" then as I 
>> was attempted to do again.  If I was in error for trying to get a 
>> serious issue resolve, then please accept my apology.
>> 
>> Sincerely,
>> 
>> Hector Santos
> 
> One of the questions is how to deal with vendors that claim to ship
> a product which is in compliance with the protcol when they are
> not.
> 
> The DNS protocol has a error code for when you do not understand a
> query, FORMERR.  It also has a error code for when you do not
> implement part of the protocol, NOTIMP.
> 
> With RFC 103[45] you have three choices as a developer when you get
> a query type you don't know about.
> 
> 1. Treat it as a FORMERR.
> 2. Treat it as a NOTIMP.
> 3. Treat it as a opaque data.
> 
> Now in my book it isn't a FORMERR as you can understand the question
> even if you can't deal with it.  NOTIMP is a reasonable response
> though I believe the intent in RFC 103[45] was to treat it as opaque
> data query which is what RFC 3597 says to do.
> 
> Nowhere in RFC 103[45] does it say DO NOT RESPOND to the query yet
> we have DNS vendors that ship products that do just that and are
> claiming that they conform to the protocol.
> 
> For a example of a set of servers that does this see earthlink.net's
> servers.
> 
> Query for HINFO/earthlink.net at the authoritative servers for
> earthlink.net (itchy.earthlink.net and scratchy.earthlink.net) and
> you will not get a response.  A RFC 103[45] compliant server should
> know about HINFO.  It should also be capable of returning a NOERROR
> NODATA response for that query and it fact will if you ask for a
> non-existent TXT record at a name it serves.
> 
> How do we deal with sites?
> How do we deal with vendors that ship such product?

Unless the caffeine just hasn't sunk in yet, it works for me:

wmbt-macbookair:Preferences wkumari$ dig HINFO earthlink.net 
@scratchy.earthlink.net

; <<>> DiG 9.8.3-P1 <<>> HINFO earthlink.net @scratchy.earthlink.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1906
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;earthlink.net. IN  HINFO

;; AUTHORITY SECTION:
earthlink.net.  1800IN  SOA itchy.earthlink.net. 
hostmaster.earthlink.net. 2013042602 3600 300 2592000 1800

;; Query time: 51 msec
;; SERVER: 207.69.188.197#53(207.69.188.197)
;; WHEN: Fri May  3 12:59:50 2013
;; MSG SIZE  rcvd: 84

So, maybe the way you fix such sites / deal with vendors that ship such 
products is you post to ietf@ietf.org and cc hostmaster@site?

:-P
W


> 
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> 

--
Hope is not a strategy.
  --  Ben Treynor, Google

Re: call for ideas: tail-heavy IETF process

[Randy Bush]

> One possible step is to have WG Chairs be *managers*, like they are
> supposed to be.
> ...
> The current cycle too often seems to be more like "new version
> posted".  Wait if anyone reviews.  Some reviews eventually, maybe. Oh,
> IETF meeting coming, time for a revision.

with wg chairs taking multiple months to do the simplest of button
pushes, authors slow down so that they get the most out of that oh so
rare button push.

randy

Re: call for ideas: tail-heavy IETF process

[John Leslie]

Dave Crocker  wrote:
> On 5/3/2013 7:29 AM, Ray Pelletier wrote:
> 
>> Provide WG Chairs the monitoring tools they need to be proactive - Action 
>> Tracker, what do I need to do today data tracker  views.  Same for AD.
>>
>> Same for authors and their mentors, if any.
> 
> The IETF already provides pretty good tools.  They could always be 
> better, of course, but they almost certainly aren't essential.

   That much is probably true.

> The issue with providing management assistance is to focus on managing 
> the work.  That's an organizational orientation, not just a tracking 
> thing.  It's about getting clarity of the work to be done and of getting 
> folks to do the work of contributing, writing, reviewing, and debating 
> in a timely manner, and achieving forward progress in a timely manner.

   That much is true.

> Few working groups have enough detail to juggle to make this something 
> that hinges on the tools.

   That, alas, is not true.

   I subscribe to a number of WG lists where they find a issue tracker
_quite_ essential to their work. And to most folks, the issue tracker
output is more confusing than helpful: you're never quite sure which
issue number something belongs under.

   The lists I subscribe to have as work items drafts where nothing
happens until IETF-week deadlines (and sometimes not even then!).

   It seems _very_ likely that some automated tools to point out the
inactivity would help...

--
John Leslie 

RE: call for ideas: tail-heavy IETF process

[Adrian Farrel]

> >> 1) have WGs do the managing role more proactively
> 
> Provide WG Chairs the monitoring tools they need to be proactive - Action
> Tracker, what do I need to do today data tracker  views.  Same for AD.
> 
> Same for authors and their mentors, if any.

Wouldn't work for me. YMMV.

Adrian

Re: Language editing

[Ralph Droms]

On May 2, 2013, at 9:47 PM 5/2/13, Dave Crocker  wrote:

> On 5/2/2013 4:13 PM, Peter Saint-Andre wrote:
>> Instead of imposing even more work on the RFC Editor team, I suggest
>> that you find someone in the WG, in your company, in the IETF
>> community (etc.) to help with the language issues. I did this recently
>> with a document in one of the WGs where I'm active and it worked quite
>> well (especially if the document is under source control and you can
>> just send a patch).
> 
> 
> +1
> 
> This goes beyond the simple-but-expensive matter of having the work done by 
> the RFC Editor.
> 
> With every opportunity, we should move work to the people who want its result.

Dave, I agree with you and you make a very important point, that applies 
broadly to this conversation.

In particular, it should be the responsibility of the interested parties to 
engage community support, and it should be the responsibility of the community 
to put effort into producing a document that meets requirements of basic 
writing quality.

> 
> IETF work that is successful has community support.  The community wants it 
> and demonstrates this by working on it.  That can (and I think should) 
> include ensuring basic writing quality.

If you'll allow me to dive into process issues and solution engineering 
briefly, these writing quality issues should be caught well before the document 
reaches the IESG, in the abstract to ensure that the responsibility (and the 
work) in producing publishable documents rests with the people who want the 
document published, and pragmatically because a DISCUSS position of "returned 
for improvement in writing quality" is at the edge of what can be handled 
through routine processes.

> 
> If the community does not have enough interest in the work to write it well, 
> it has bigger problems that won't be remedied by more RFC Editor effort...

Yup.

> 
> d/

- Ralph

> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

Re: call for ideas: tail-heavy IETF process

[Pete Resnick]

On 5/3/13 9:32 AM, Thomas Narten wrote:


Not to put too fine a point on in, but ADs need to manage their time,
and they need to balance between the immediate and the long term. They
have to do *both*, and especially NOT neglect longer-term stuff that
will have real and signficant, but not immediate benefits.
   


Interesting. For the most part, I agree with the above. And I think we 
have been neglecting some of the longer-term stuff. But earlier:


On 5/3/13 7:59 AM, Thomas Narten wrote:


Like everyone, I wish things moved more quickly, but every attempt
I've ever seen that tries to speed things up ends up reducing the
quality or having some other undesirable side effect.
   


Can you talk a bit more about this, including some examples?

I'm trying to reconcile the concern that we "end up reducing the 
quality" and  that we "NOT neglect longer-term stuff that will have real 
and significant, but not immediate benefits." ADs have finite resources 
and can't accomplish both immediate and longer-term stuff maximally all 
of the time. My inclination would be to say, "If they are in conflict, 
weight the longer-term over the immediate, even if that might result in 
some reducing of quality on any single document." Am I over-reading your 
earlier message to say that you think the weighting should go toward the 
immediate? I think we agree that doing the longer-term stuff will end up 
with increased quality over the long term, but doing more of the 
longer-term stuff is sure to reduce the amount of time spent on 
immediate, which means document reviews and therefore some short term 
lowering of quality. Is that OK, or is that an example of the kind of 
thing we've attempted that ends up with bad results?


pr

--
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478

Re: call for ideas: tail-heavy IETF process

[Elwyn Davies]

On Fri, 2013-05-03 at 14:27 +0100, Stephen Farrell wrote:
> On 05/03/2013 01:59 PM, Thomas Narten wrote:
> > 
> > If you look at the delays documents encounter (both in WG and in IESG
> > review), the killer is long times between document revisions. Focus on
> > understanding the *why* behind that and what steps could be taken to
> > make improvements.
> 
> Good point. I guess the obvious answers are "not enough
> cycles" 
and not enough "concentrated cycles" - designing and documenting a
protocol in my experience requires a longish period of undisturbed
concentration by the person with the editing crayon, and responsive,
deep and immediate review by co-authors to generate fast turn round
reviews of versions.
Its hard enough keeping the in-brain implementation of the protocol
running accurately day-by-day.  If there are gaps of weeks rebooting the
implementation wastes precious concentrated time.  Probably putting a
few people with no other commitments in a isolated space generates
fastest results. Maybe we could get ISOC to provide a retreat space (or
one per continent) for protocol designers?
> and, for newer authors, uncertainty about how to
> get stuff done, but are there other less obvious answers?
> (Input here might really help the IESG discussion btw since
> in the nature of things, we're less likely to realise what
> newer or less frequent participants find problematic.)
One thing that might help:
We have directorates and review panels.  Can we distil any/more of their
wisdom into checklists/guidance for protocol writers?
Some is already there (not a complete list):
BCP 72 for security considerations 
BCP 41 on congestion control
BCP 61 on Strong Security Requirements
Some stuff in RFC 6385 for gen-art

[Some of this is getting a bit long in the tooth.]

So what do you ...
- think about when designing the security aspects/transport congestion
aspects/... of a new protocol?
- what triggers alarm bells/gold stars when you are reviewing the
general principles/security aspects/congestion/ABNF/state
machines/mib/xml/extensibility/ of a draft?

Regards,
Elwyn

> 
> S.

Re: call for ideas: tail-heavy IETF process

[Dave Crocker]

On 5/3/2013 7:29 AM, Ray Pelletier wrote:

Provide WG Chairs the monitoring tools they need to be proactive - Action 
Tracker, what do I need to do today data tracker  views.  Same for AD.

Same for authors and their mentors, if any.



Probably none of the above.

The IETF already provides pretty good tools.  They could always be 
better, of course, but they almost certainly aren't essential.


The issue with providing management assistance is to focus on managing 
the work.  That's an organizational orientation, not just a tracking 
thing.  It's about getting clarity of the work to be done and of getting 
folks to do the work of contributing, writing, reviewing, and debating 
in a timely manner, and achieving forward progress in a timely manner.


Few working groups have enough detail to juggle to make this something 
that hinges on the tools.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: call for ideas: tail-heavy IETF process

[Thomas Narten]

"Adrian Farrel"  writes:

> Well said, Thomas. 

> > Two concrete suggestions:
> > 
> > 1) have WGs do the managing role more proactively
> > 2) mentor authors and others a bit more to encourage them how best to
> > operate

> Which I suspect means...

> 0) have ADs manage/mentor the WG chairs more proactively.

Absolutely. But that is why the nomcom is supposed to select ADs that
have *management* capabilities as well as technical skills.

> Almost certainly a case of "if I had less work to do I would have
> more time to do the things that would reduce my workload."  :-)

Well, this is why you get paid the big bucks.

Not to put too fine a point on in, but ADs need to manage their time,
and they need to balance between the immediate and the long term. They
have to do *both*, and especially NOT neglect longer-term stuff that
will have real and signficant, but not immediate benefits.

> WG chairs might like to comment, but I suspect that one lunchtime training
> session every four months does not constitute proactive management.

This would help and could be part of a comprehensive approach. But ADs
also need to lay down expectations on WG chairs, and *grade* and
*evaluate* WG Chair performance. WG chairs also don't have
cycles... And ADs seem reluctant to step in and make management
changes that really often are needed to change the dynamices within
WGs that are not delivering...

Thomas

Re: call for ideas: tail-heavy IETF process

[Ray Pelletier]

On May 3, 2013, at 10:20 AM, "Adrian Farrel"  wrote:

> Well said, Thomas. 
> 
>> Two concrete suggestions:
>> 
>> 1) have WGs do the managing role more proactively

Provide WG Chairs the monitoring tools they need to be proactive - Action 
Tracker, what do I need to do today data tracker  views.  Same for AD. 

Same for authors and their mentors, if any. 

Ray


>> 2) mentor authors and others a bit more to encourage them how best to
>> operate
> 
> Which I suspect means...
> 
> 0) have ADs manage/mentor the WG chairs more proactively.
> 
> Almost certainly a case of "if I had less work to do I would have more time to
> do the things that would reduce my workload."  :-)
> 
> WG chairs might like to comment, but I suspect that one lunchtime training
> session every four months does not constitute proactive management.
> 
> Adrian
> 

RE: call for ideas: tail-heavy IETF process

[Adrian Farrel]

Well said, Thomas. 

> Two concrete suggestions:
> 
> 1) have WGs do the managing role more proactively
> 2) mentor authors and others a bit more to encourage them how best to
> operate

Which I suspect means...

0) have ADs manage/mentor the WG chairs more proactively.

Almost certainly a case of "if I had less work to do I would have more time to
do the things that would reduce my workload."  :-)

WG chairs might like to comment, but I suspect that one lunchtime training
session every four months does not constitute proactive management.

Adrian

Re: call for ideas: tail-heavy IETF process

[Thomas Narten]

> Good point. I guess the obvious answers are "not enough
> cycles" and, for newer authors, uncertainty about how to
> get stuff done, but are there other less obvious answers?
> (Input here might really help the IESG discussion btw since
> in the nature of things, we're less likely to realise what
> newer or less frequent participants find problematic.)

One possible step is to have WG Chairs be *managers*, like they are
supposed to be. That means the equivalent of having project plans. For
a given document, come up with a (reasonable, pragmatic, workable)
schedule for getting reviews, discussion, revision, repeat. And then
get committments from parties (authors, reviewers, etc.) to
deliver. And followup if they don't...

The current cycle too often seems to be more like "new version
posted". Wait if anyone reviews. Some reviews eventually, maybe. Oh,
IETF meeting coming, time for a revision. But with meeting
approaching, there are a zillion docs and cycles are limited.  Rather
haphazard, with too many documents effectively only being revised once
per meeting cycle.

WGs make the most progress when authors respond quickly (within days)
to reviews, and do so on the list discussing possible text
revisions. You get much quicker and substantive discussion that way
and it becomes clear whether folk are converging.

Contrast that with "ask for reviews". Wait a month or two. New
document appears that says "this reflects comments we got, go
read". Delays between review/response tend to feed upon
themselves. Folk forget context, etc., making it more of an effort to
go back and remember their reviews, etc.

Too much of WG activites are "best effort" where volunteers (who are
busy and may not actually have the experience to do things optimally)
are expected magically to just know how things are supposed to work
make progress. Reality is a bit different.

Two concrete suggestions:

1) have WGs do the managing role more proactively
2) mentor authors and others a bit more to encourage them how best to
operate

Thomas

Re: call for ideas: tail-heavy IETF process

[Stephen Farrell]

On 05/03/2013 01:59 PM, Thomas Narten wrote:
> 
> If you look at the delays documents encounter (both in WG and in IESG
> review), the killer is long times between document revisions. Focus on
> understanding the *why* behind that and what steps could be taken to
> make improvements.

Good point. I guess the obvious answers are "not enough
cycles" and, for newer authors, uncertainty about how to
get stuff done, but are there other less obvious answers?
(Input here might really help the IESG discussion btw since
in the nature of things, we're less likely to realise what
newer or less frequent participants find problematic.)

S.

Re: call for ideas: tail-heavy IETF process

[Thomas Narten]

Just a few points...

Michael Richardson  writes:

> I'll repeat what has been said repeatedly in the newtrk and related
> discussions.  The step from ID to "RFC" is too large because we are
> essentially always aiming for "STD" rather than "PS".

> If we are unwilling to bring "RFC" back to a place were it does not
> equal STD, then we need to create a new category of document which
> amounts to "fully baked ID".  Things like IANA allocations could occur
> at that point.

> In the days of dot-boom it was not unusual to see widespread
> implementation very early in the ID process and even interop and
> experimental deployment.   While this still occurs for quite a number of
> things (and sometimes it's a problem that the ID can not be changed as a
> result), there is an equal amount of "wait for the RFC to come out".

I suspect there is a bit of rose colored reminiscing of history.

The world has changed, significantly.

For example, there has been massive consolidation in industry. There
simply are fewer entities doing implementations today. 15 years ago,
it was common to see a half dozen or more implementations from
different (often smaller) entities, even before a document got out of
a WG. Nowadays, the cost of doing an implementation (for a company) is
in some sense much higher, and business realities make companies
*very* selective in what they implement and put into a product.

I suspect that the notion that if the IETF published documents more
quickly industry would implement them more quickly/frequently is
wishful thinking.

Michael Richardson  writes:
> It's what Carsten said.

> 1) this idea is baked enough for cross-area review to make sense.
> 2) the protocol is not going to change significantly, one could
>implement.
> 3) any future changes need thus to take into account impact on
>existing implementations... BUT that doesn't mean that we can't
>change things.

Like it or not, 2 and 3 are contradictory. From an interoperability
perspective, the difference between "not change significantly" and
"change a lot" is irrelevant once you have deployments. Change (in the
behavior or wire format) is change and breaks interoperability, no
matter how big or small.

Hannes Tschofenig  writes:

> b) There is no interest to research where delay really happen.

I don't think that is true. Jari has pointed to his work. I think
there is actually quite a lot of understanding of where the delays
are. But fixing them is really really hard. Blaming the "tail end" or
"the IESG" for the problems has always been the easy target. The
reality (IMO) is that the place where improvements are needed is
within the WG and on having authors be more responsive. But history
suggests there are no easy fixes here.

Randy Bush  writes:

> > A basic question, then, is whether we think these absolute numbers and
> > these proportions of time are reasonable and appropriate for the IETF
> > to be/remain effective?

> seems pretty reasonable to me.  from personal experience, the iesg and
> rfced add useful value.

+1

Like everyone, I wish things moved more quickly, but every attempt
I've ever seen that tries to speed things up ends up reducing the
quality or having some other undesirable side effect.

The bottom line is that getting a good spec requires iteration, and
reviews from a broad set of parties. That is best done
*sequentially*. And given the limited cycles the (volunteer) community
as a whole has, you can't easily change these dynamics. We've seen
many attempts to reduce the overall time by trying to overlap reviews
and steps, but that has the side effect of losing *sequential*
*iteration* (where each new review reviews the previous set of
additions/changes). IMO, overlapping steps is dangerous and leads to
poor quality.

> being in a many-year process of getting a technology through the
> saussage machine, it's the wg that feels to me to be the most
> inefficient part of the process.  i attribute this to email not being
> the best medium, and meetings being too short and too far between.  but
> that is purely subjective.

If you want to speed up the process, focus on how to *increase* the
amount of iteration you get (i.e., revised drafts) while at the same
time *reducing* the time between revised drafts.

If you look at the delays documents encounter (both in WG and in IESG
review), the killer is long times between document revisions. Focus on
understanding the *why* behind that and what steps could be taken to
make improvements.

And finally, a big reason the IESG review is where things happen is
that it *really* is the last time one has to verify that a document is
ready to go. With the limited cycles we all have, there will always be
a tendancy to not deal with a document until the point of "this is
your last chance". Nothing like a *real* deadline to motivate people
to finally deal with a document, before it's too late.

Thomas

Re: Language editing

[t . p .]

 Original Message -
From: "TZI" 
To: "t.p." 
Cc: "Peter Saint-Andre" ; "Marc Petit-Huguenin"
; "Yaron Sheffer" ; "ietf"

Sent: Friday, May 03, 2013 9:37 AM
Subject: Re: Language editing


> We really do need a tool, the like of which I was using 40 years ago
> when writing code, that allows patches to be applied independently

that's what pull requests (or gerrit) are about.

> and
> temporarily to see what it then looks like and if agreed that it looks
> good, incorporating them permanently into the source (XML).  Ideally
> such a tool would reverse engineer the amended text into XML patches
as
> well - text is so much easier to work with than XML (or any other
markup
> language).

try writing the draft in markdown and using Miek Gieben's or my tool
(kramdown-rfc2629) to convert into XML.

it is so much easier to collaborate in markdown...


Right, but the context is that after many years and several rounds of
editing, the I-D is ready for Last Call and someone who may not have
been previously involved in the editing goes through and proposes
enhancements for legibility.  It needs to be an available on the IETF
website tool and easy enough for many to use without much education.

Tom Petch

Grüße, Carsten

Re: call for ideas: tail-heavy IETF process

[Jouni Korhonen]

Jari,

This was an interesting (and a needed) writeup. I also want to share
my view as an IETF newbie who has had a chance to experience IETF
document process a few times. Sorry for chiming in late..

For the most part I got the feeling that we have the right tools and
a working process already in place. It is mostly about how we treat
the process and adjust our habits to it.

The thing I dislike is when you ship a camel into IESG and a horse
comes out.. and everybody is like "what happened?" ;-) My approach
would be simple. If a document gets x DISCUSSes out of y or even a
single DISCUSS would substantially change the technical solution of
the document, ship it back to the WG - always, no questions asked. The
document is not ready and we are wasting IESG's time. The technical
work belongs to the WG. Obviously this begs for a much higher
threshold for an AD to give a document a DISCUSS instead of a COMMENT.

Then about the habits. From my limited experience, folks are used to
the think "the document will anyway be reviewed, reworked and can be
finished in the IESG" and that occasionally shows. I want to believe
this habit changes if the document must be ready for real before
leaving the WG.

The cross area directorate reviews are great and should have even
more weight than they have today. And here is what I would like to
see to change slightly. The directorate & expert reviews should all
be done before sending the document out of the WG into the IESG.
Probably the IETF LC should also happen before sending the document
out of the WG.

My Z$0.02,
Jouni


On May 1, 2013, at 6:33 PM, Jari Arkko  wrote:

> I wrote a blog article about how we do a fairly significant amount of reviews 
> and changes in the late stages of the IETF process. Next week the IESG will 
> be having a retreat in Dublin, Ireland. As we brought this topic to our 
> agenda, Pete and I wanted to raise the issue here and call for feedback & 
> ideas for improving the situation with all of you.
> 
> http://www.ietf.org/blog/2013/05/balancing-the-process/
> 
> Jari
> 

Re: Language editing

[Scott Brim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/02/2013 02:40 PM, Yaron Sheffer wrote:
> I suggest that we budget for a number of WG drafts per year (say,
> 20 IETF-wide) to go through professional, paid-for heavy-duty
> editing

My experience is that unless the editors have some background in
protocols, this takes a surprising amount of effort, explaining it to
them and catching _their_ mistaken assumptions (which can be subtle).
 However,

On 05/02/13 19:13, Peter Saint-Andre allegedly wrote:
> Instead of imposing even more work on the RFC Editor team, I
> suggest that you find someone in the WG, in your company, in the
> IETF community (etc.) to help with the language issues.

... then you have quality control issues, uncertainty who to turn to,
finding someone who not only appears to be good but actually is, etc.

So how about a pool of volunteer editors, aka GEN-AET, with developed
reputations?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.13 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlGDmroACgkQF0TR2hENFASGtACfYHQB29sSh9CUxg9NfLLzGtuW
7DMAoJnyyfb3KVXJaCcnOERlMuHiXLtx
=YEaW
-END PGP SIGNATURE-

Re: Language editing

[Ted Lemon]

On May 3, 2013, at 4:24 AM, t.p.  wrote:
> We really do need a tool, the like of which I was using 40 years ago
> when writing code, that allows patches to be applied independently and
> temporarily to see what it then looks like and if agreed that it looks
> good, incorporating them permanently into the source (XML).  Ideally
> such a tool would reverse engineer the amended text into XML patches as
> well - text is so much easier to work with than XML (or any other markup
> language).

Actually, what I'd like to see is a change approval process, where I can go in 
and make the edits I want to the document, submit those, and then the document 
editors can just go down the list of changes approving them or not.   I guess 
that's not too different from what you said, but with a better UI.

Re: Language editing

[TZI]

> We really do need a tool, the like of which I was using 40 years ago
> when writing code, that allows patches to be applied independently

that's what pull requests (or gerrit) are about.

> and
> temporarily to see what it then looks like and if agreed that it looks
> good, incorporating them permanently into the source (XML).  Ideally
> such a tool would reverse engineer the amended text into XML patches as
> well - text is so much easier to work with than XML (or any other markup
> language).

try writing the draft in markdown and using Miek Gieben's or my tool 
(kramdown-rfc2629) to convert into XML.

it is so much easier to collaborate in markdown...

Grüße, Carsten

Re: Language editing

[t . p .]

- Original Message -
From: "Peter Saint-Andre" 
To: "Marc Petit-Huguenin" 
Cc: "Yaron Sheffer" ; 
Sent: Friday, May 03, 2013 12:13 AM
>
> On 5/2/13 4:03 PM, Marc Petit-Huguenin wrote:
> > On 05/02/2013 02:40 PM, Yaron Sheffer wrote:
> > An alternative would be to have the RFC-editor doing copyediting of
> > I-Ds for a fee.  Depending on the cost, I would use such service
> > for my I-Ds.  That would be good for everybody:  I would spend less
> > time trying to make my text legible and more making the protocol
> > described in it better.  And because the document would have been
> > copy-edited by the same people that will publish the RFC, that's
> > less work at the end.
>
> Instead of imposing even more work on the RFC Editor team, I suggest
> that you find someone in the WG, in your company, in the IETF
> community (etc.) to help with the language issues. I did this recently
> with a document in one of the WGs where I'm active and it worked quite
> well (especially if the document is under source control and you can
> just send a patch).

Ah, there's the rub.

I have done this on a number of occasions for a variety of people and
editing the text file of an I-D is almost trivial compared to then
incorporating the amendments, some agreed, some debated, some rejected,
into the XML, in doing so introducing the need for further amendments
(problem generates change generates problem generates ... the cycle
beloved of all software developers).

We really do need a tool, the like of which I was using 40 years ago
when writing code, that allows patches to be applied independently and
temporarily to see what it then looks like and if agreed that it looks
good, incorporating them permanently into the source (XML).  Ideally
such a tool would reverse engineer the amended text into XML patches as
well - text is so much easier to work with than XML (or any other markup
language).

Tom Petch

> Peter
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRgvMHAAoJEOoGpJErxa2p1WkP/Ao11JgbfdPk1+r5psycC4yW
> hc9qCTZeJEuXHHEG5mFLXyuEugkL1LKDjH7TAHql3o28iRYi1P+0LnR4l4Eg27u8
> Rfk8TrQ3pE0EHOiMhtX9b1G718iyQAR6bxjBJhR0Sc6f5Y2x4drqZQd4xwHggNCz
> uKp58+mrEizUBM3V6+JtCJAQj/mOv3HVbbSij8yWWYvJzuOP1nJ+rqEaI/0lBct5
> rkWrefJogtxRHIrwALKmV+BYV99MyDzmm4kwZj+rDzqy/epq77FkqvZUms9EkLZW
> HYLWE9RL/onV+XOLbjkSIvjqjCgKdaS1FpMH6zqYidNN491bLAQacyI0QS9d6dGw
> 9AbDMf1uTxWcfWyB4LrwFFVyA8ZVCWO+1d5up+LSRgfGR/u0WhbyiaJqN0JKy10t
> 0yJ30+4rwsYjtzsOWy1Zggn8bD4uXXdyjbw8X6Ze69A8ChBlIqticIf4mEd12qSO
> E6k8SqtsoX17QmEU8oa7RwNaIbQ59txVju0NHEDlYreBKdHeRrki1SuK5+VrOJAg
> yTqzNkpJskgwFukSfLBiX446c4luXkQ4XoSWT3NdkqxIq2ikpXh3WU2p0WgDTM+G
> EreYmGTQXP9YV2Ieb+nMsj1pNbD0gB5a8CpXWLe859IIu2ga1uCcxo99LqPymNJB
> hmkU2s1OJ2xuR1/d5Anx
> =JEpp
> -END PGP SIGNATURE-
>