Re: Language editing

[ned+ietf]

> Mark Andrews  wrote:
> >
> > Apples mail client is broken [IPv6:2001:df9::4015:1430:8367:2073:5d0]
> > is not legal according to both RFC 5321 and RFC 2821 which is all
> > that applies here.

>I was until today unaware how strong the feelings are on this
> "one-or-more" vs. "two-or-more" issue. I do not expect to change
> anybody's mind. :^(

>But I do object to calling that EHLO string "not legal".

It's syntactically illegal according to the ABNF in RFC 5321 itself, which
specifically states:

 IPv6-comp  = [IPv6-hex *5(":" IPv6-hex)] "::"
  [IPv6-hex *5(":" IPv6-hex)]
; The "::" represents at least 2 16-bit groups of
  ; zeros.  No more than 6 groups in addition to the
  ; "::" may be present.

>The 5321 reference names RFC 4291 as the source of address syntax
> (even if it gives BNF which says "two or more" if you delve deeply
> enough).

It may be the source, but the formal syntax specified in the document at hand
has to be the definitive one.

>RFC 4921 is clear about saying "one or more". The Errata posted
> against it claiming it should say "two or more" have been rejected.
> It is silly to argue under these conditions that Apple's EHLO string
> is "not legal".

No, what's silly is your argument that the ABNF in the actual specification of
how mail clients and servers are supposed to behave isn't the definitive
definition.

>BTW, RFC 5321 still contains the language about
> " if the verification fails, the server MUST NOT refuse to accept a
> " message on that basis.

And that language appears in the context of checking that the IP literal
in the HELO/EHLO actually corresponds to the IP address of the client. It
has nothing to do with syntactic validity.

> so IMHO enforcing any particular interpretation of what an IPv6
> address literal should look like is double-plus-ungood.

Then you should be arguing for a change in RFC 5321, because it is *very*
clear that this usage is not allowed.

Ned

Re: Language editing

[Mark Andrews]

You missed the point RFC 5321 SMTP clients have to operate
with RFC 2821 SMTP servers when sending address literal in
the HELO/EHLO.  Code doesn't magically get updated when the
spec is updated.  It takes years for changes to trickle
through.  The code has to be written, then it has to be
deployed.

[The who SPF issue is about a WG that is too impatient to
 wait for the updated code, that has been written, to be
 deployed.  That will happen as OS's get update / replaced.]

While RFC 4291 relaxed the address syntax, RFC 5321 didn't
because to do so would break interoperability.

RFC 5321's address literals are a subset of RFC 4291's
permittable address formats.  So there is nothing wrong
with referencing RFC 4291.

Mark

In message <20130507012924.GX23227@verdi>, John Leslie writes:
> Mark Andrews  wrote:
> > 
> > Apples mail client is broken [IPv6:2001:df9::4015:1430:8367:2073:5d0]
> > is not legal according to both RFC 5321 and RFC 2821 which is all
> > that applies here.
> 
>I was until today unaware how strong the feelings are on this
> "one-or-more" vs. "two-or-more" issue. I do not expect to change
> anybody's mind. :^(
> 
>But I do object to calling that EHLO string "not legal".
> 
>The 5321 reference names RFC 4291 as the source of address syntax
> (even if it gives BNF which says "two or more" if you delve deeply
> enough).
> 
>RFC 4921 is clear about saying "one or more". The Errata posted
> against it claiming it should say "two or more" have been rejected.
> It is silly to argue under these conditions that Apple's EHLO string
> is "not legal".
> 
>BTW, RFC 5321 still contains the language about
> " if the verification fails, the server MUST NOT refuse to accept a
> " message on that basis.
> 
> so IMHO enforcing any particular interpretation of what an IPv6
> address literal should look like is double-plus-ungood.
> 
> 
> 
>To the casual observer, it looks as if RFC 4291 relaxed a previous
> "two or more" requirement, but there are folks who don't want to
> accept that relaxing.
> 
>One can accept the idea that this relaxing has failed, yet still
> observe "liberal in what you accept" as trumping it. I truly wish the
> folks in the "two or more" camp would do so!
> 
> --
> John Leslie 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: IETF Diversity Question on Berlin Registration?

[CJ Aronson]

I was getting ready to send a note that basically said I give up when I saw
this post from Randy. Thanks Randy.

Then a friend posted this TED talk and it landed in my facebook feed.   It
gives me hope that there are a few men out there who might get the issue.
 I personally would love to see the IETF consult someone like this speaker.


http://www.upworthy.com/a-ted-talk-that-might-turn-every-man-who-watches-it-into-a-feminist-its-pretty-fantastic-7?g=2

I have found this whole thread discouraging and I felt the need to say
something.  This TED talk pretty much sums it up.

Thanks!

---Cathy


On Tue, Apr 30, 2013 at 2:41 PM, Randy Bush  wrote:

> you don't need a weatherman to know which way the wind blows.
> -- bob dylan
>
> we do not need measurements to know the ietf is embarrassingly
> non-diverse.  it is derived from and embedded in an embarrassingly
> non-diverse culture.
>
> we need to do what we can to remedy this.  progress not perfection is
> our goal.
>
> measurement may be useful to see if we are having effect and/or what
> things have effect (meeting locales, size of cookies, ...).
>
> we should be asking the minorities and those struggling to particiate
> what we can do to help.
>
> randy
>

Re: Language editing

[John Leslie]

Mark Andrews  wrote:
> 
> Apples mail client is broken [IPv6:2001:df9::4015:1430:8367:2073:5d0]
> is not legal according to both RFC 5321 and RFC 2821 which is all
> that applies here.

   I was until today unaware how strong the feelings are on this
"one-or-more" vs. "two-or-more" issue. I do not expect to change
anybody's mind. :^(

   But I do object to calling that EHLO string "not legal".

   The 5321 reference names RFC 4291 as the source of address syntax
(even if it gives BNF which says "two or more" if you delve deeply
enough).

   RFC 4921 is clear about saying "one or more". The Errata posted
against it claiming it should say "two or more" have been rejected.
It is silly to argue under these conditions that Apple's EHLO string
is "not legal".

   BTW, RFC 5321 still contains the language about
" if the verification fails, the server MUST NOT refuse to accept a
" message on that basis.

so IMHO enforcing any particular interpretation of what an IPv6
address literal should look like is double-plus-ungood.



   To the casual observer, it looks as if RFC 4291 relaxed a previous
"two or more" requirement, but there are folks who don't want to
accept that relaxing.

   One can accept the idea that this relaxing has failed, yet still
observe "liberal in what you accept" as trumping it. I truly wish the
folks in the "two or more" camp would do so!

--
John Leslie 

Re: Language editing

[Mark Andrews]

In message <51881140.5070...@gmail.com>, Brian E Carpenter writes:
> On 07/05/2013 02:10, l.w...@surrey.ac.uk wrote:
> > http://labs.apnic.net/blabs/?p=309
> > 
> > an excellent detective story on badly-written, poorly edited, standards 
> > track RFCs leading to interop pro
> blems. Enjoy.
> 
> I don't that is quite right. The problem in this case is not to do
> with linguistic quality. It's due to a lack of formal verification
> among a set of interacting and cross-area RFCs. (And the problem
> is wider, because there are two distinct places in IETF standards
> where ABNF for the text representation of IPv6 addresses can be
> found.) This is a case where no amount of language editing would
> have helped. Actually I used it a couple of months ago in a
> discussion with some experts on formal verification, and they rather
> liked it as a poster child for the need for formal methods in SDOs.
> 
> Brian


Apples mail client is broken [IPv6:2001:df9::4015:1430:8367:2073:5d0]
is not legal according to both RFC 5321 and RFC 2821 which is all
that applies here.  RFC 2821 was consistent with RFC 2373 and the
SMTP literal spec has remained frozen since then which you want
when you are trying to promote long term interoperability.

Now one could update RFC 5321 to accept the above :: instead of a
single :0: but you could never legally send it.

Note for IPv4 [070.0.0.0] is 70.0.0.0 not 56.0.0.0 despite the fact
that many system will take 070.0.0.0 and send to 56.0.0.0. 

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

Re: call for ideas: tail-heavy IETF process

[John C Klensin]

--On Monday, May 06, 2013 00:26 -0700 Bill McQuillan
 wrote:

> 
> On Sun, 2013-05-05, John C Klensin wrote:
> 
>> Finally, there are a few things that we used to do, that were
>> helpful, and that were abandoned due to industry evolution and
>> changes in priorities.  The original idea of a Proposed
>> Standard as a fairly rough specification that would be used
>> for study and evaluation on the basis of implementation
>> experience, not a spec from which products were built, is one
>> that has been mentioned (although not quite in that way).   
> 
> FWIW, this leads me to the thought that the IETF may have a 
> terminology problem. The word "standard" is used too soon in
> the  maturity levels of RFCs.
> 
> I think that our skills are primarily in producing "protocols"
> rather than "standards". Perhaps it would have been better if
> the names of the maturity levels were something like:
> 
>   Proposed Protocol
>   Test Version 1 Protocol
>   Test Version 2 protocol
>.
>.
>.
>   Standard Protocol
> 
> Only using the word "standard" when it was determined to be 
> stable and recommended for wide usage.

Not the first time this has been proposed.  Or even only the
fourth or fifth.  That doesn't necessarily make it a bad idea,
just one the community has not been willing to adopt.

   john

Re: call for ideas: tail-heavy IETF process

[John C Klensin]

--On Monday, May 06, 2013 04:35 -0400 Olaf Kolkman
 wrote:

> Personally I hope that RFC 6410 has the effect that we, as a
> community, get serious about promoting our proposed standards,
> or obsolete them. 
> 
> I wonder how many standards got promoted after 6410 was
> published.

According to my rough count (well, not that rough), the number
of RFCs numbered above 6410 that represent full Standards is
zero.  I note that DKIM is now in Last Call for promotion
without revision; if it succeeds, it would be the first.  

RFC 6410 was published in October 2011.  Between, e.g., October
2009 and May 2011, seven documents were published as Internet
Standards (RFCs 5652, 5730 - 5734, and 6152).  Because of the
five documents in the EPP series, that is not quite as large a
count as one would expect but even if one counts that as only
three, three is larger than zero.

That is definitely not a comparison on which I'd want to make
any statistical assertions, but it suggests that 6410 has not
been an overwhelming success is promoting documents.

john

Detective story (was: Language editing)

[SM]

At 13:23 06-05-2013, Brian E Carpenter wrote:

I don't that is quite right. The problem in this case is not to do
with linguistic quality. It's due to a lack of formal verification


Quoting from the detective story:

  "At [censored] we have changed our mail server configuration in the past few
   months, and are now using a mail server from [censored] namely the
   [censored] Server."

There isn't any mention of whether the mail server was tested.

  "Seemingly at random my efforts to send mail just fail."

There would likely be an error code with text providing an 
explanation.  I would probably follow a different debugging 
path.  Anyway, the session showed:


  "EHLO [IPv6:2001:df9::4015:1430:8367:2073:5d0]
   501 5.5.4 Invalid domain name"

This is where I go and read RFC 6409 and I find that:

  "The MSA SHOULD log message errors, especially apparent
   misconfigurations of client software."

And then follow up with RFC 5321 where I find a mention of address 
literals.  I go and read RFC 4291 which is a Draft Standard.  I see 
an update in RFC 5952 which is a Proposed Standard.  As I was told 
that the Internet runs on Proposed Standards that update must be 
right.  I see the following:


  "The recommendation in this section SHOULD be followed by systems
   when generating an address to be represented as text, but all
   implementations MUST accept and be able to handle any legitimate
   [RFC4291] format."

Back to the detective story:

  "The writing if RFC5952 is incredibly sloppy for a Proposed Standard"

I look at the write-up:

 "The 6MAN working group reviewed and discussed this document several
  times. There is a strong consensus to move this forward."

 "This document has been reviewed by key members of the 6MAN working
  group and the chairs."

I look at the IESG evaluation and I see:

 "Language & grammar are rough."

Between you and me, these Area Directors are trouble-makers.  :-)

I verify compliance (2010), RFC 2821, RFC 4409; there isn't any 
mention of the IPv6 specifications mentioned in the detective story.


There are people out there who have to fix problems like this.  There 
are people out there who have to read those specifications and figure 
out where is the head and where is the tail.


Regards,
-sm 

Re: Language editing

[John C Klensin]

--On Tuesday, May 07, 2013 08:23 +1200 Brian E Carpenter
 wrote:

> On 07/05/2013 02:10, l.w...@surrey.ac.uk wrote:
>> http://labs.apnic.net/blabs/?p=309
>> 
>> an excellent detective story on badly-written, poorly edited,
>> standards track RFCs leading to interop problems. Enjoy.
> 
> I don't that is quite right. The problem in this case is not
> to do with linguistic quality. It's due to a lack of formal
> verification among a set of interacting and cross-area RFCs.
> (And the problem is wider, because there are two distinct
> places in IETF standards where ABNF for the text
> representation of IPv6 addresses can be found.) This is a case
> where no amount of language editing would have helped.
> Actually I used it a couple of months ago in a discussion with
> some experts on formal verification, and they rather liked it
> as a poster child for the need for formal methods in SDOs.

And that is another oddity and perhaps another lesson.  The
robustness principle was formulated, not just as a general good
idea, but because of the understanding that there was little or
no aspiration in pre-IETF specifications to get every T crossed
and I dotted.   That level of precision is required for formal
verification (about which there are other problems) or formal
testing and certification (about which there are a different set
of other problems).  Not only was Jon aware that we often didn't
go into that level of detail, but there was a case to be made
that we didn't want to because it took too much time to get
after the documents right after the design and specification
were done (please reread that a few times).

Maybe things have changed, but, if one actually believes the
robustness principle, then, in the case Geoff cites, Exchange is
simply non-conforming -- not because the spec prohibits
rejecting on the basis of a fine distinction about IPv6 formats,
but because doing so is unnecessary, inconsistent with the
robustness principle, and, arguably, plain silly.

And that is the other thing we lost when "Proposed Standard"
went from "spec that might contain some problems, lack of
clarity, and less than wonderful writing as long as there were
no known technical defects" to "better get it right because it
is probably the last chance and people are going to build and
ship products on the basis of what it says".

We now have expectations consistent with specs that can be
formally verified and/or tested and that people will interpret
narrowly and a procedural model designed for specs that are much
less formal and complete.

john


   john

RE: call for ideas: tail-heavy IETF process

[SM]

At 07:20 03-05-2013, Adrian Farrel wrote:

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


One lunch every four months does not look like proactive management. :-)

At 11:34 03-05-2013, Andy Bierman wrote:

WG Chairs meeting with I-D editors once every 4 months isn't so great either.


Yes.


If the total time has gone up 100 days, and the IESG time has gone down
100 days, then clearly the WG process is the main problem.


Yes.

I posted a message over a year ago ( 
http://www.ietf.org/mail-archive/web/urn/current/msg01653.html ).  I 
looked at the WG status page a few minutes ago.  The WG did not 
publish any document.  I looked at the mailing list archive.  There's 
hasn't been a lot of activity.



The WG Chairs need more training on how to avoid the "slow tweak mode"
problem. The ADs need to manage their WG chairs so this doesn't happen.


The choice is whether to shut down the working group or not.  It was 
suggested (other thread) that WG Chairs have to find at least X 
reviewers [1].  I doubt that anyone is going to pay these reviewers 
[2].  This raises the question of whether the people who showed 
interest in starting the work were a bunch of cheerleaders. :-)


The current mode of operation is:

  (i)   The IESG will fix that

  (ii)  The RFC Editor will fix that

  (iii) More tools will fix that

There isn't any hurdle to try reviews by Senior IETF Reviewers 
(SIRS).  As an experiment the SIRS could commit to post public 
reviews of every draft going through a Working Group Last Call (WGLC) 
until the end of the year.  I assume that a report of the experiment 
will be provided after that so that the IETF community can assess for 
itself whether the experiment was a success.


Regards,
-sm

1. http://www.asterix.com/galerie/smailix/images/i11c.gif
2. http://www.asterix.com/galerie/smailix/images/i8c.gif 

Re: Language editing

[Brian E Carpenter]

On 07/05/2013 02:10, l.w...@surrey.ac.uk wrote:
> http://labs.apnic.net/blabs/?p=309
> 
> an excellent detective story on badly-written, poorly edited, standards track 
> RFCs leading to interop problems. Enjoy.

I don't that is quite right. The problem in this case is not to do
with linguistic quality. It's due to a lack of formal verification
among a set of interacting and cross-area RFCs. (And the problem
is wider, because there are two distinct places in IETF standards
where ABNF for the text representation of IPv6 addresses can be
found.) This is a case where no amount of language editing would
have helped. Actually I used it a couple of months ago in a
discussion with some experts on formal verification, and they rather
liked it as a poster child for the need for formal methods in SDOs.

Brian

Re: Language editing

[Dale R. Worley]

> From: 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.

In a sense you're right; if we could find sufficient members who are
good at editing technical English and motivate them to do so, then the
problem would be solved.  However, I don't see any of those conditions
becoming true.  As an organization, we don't place much value on
making the *words* of a document clear and correct, and neither do our
employers.  And relatively few engineers can write high-quality
English specifications.

More subtly, our process works against us, because we use technical
contributors as the document editors.  Improving writing is a matter
of zillions of relatively small changes, which is inefficient to do if
the person weilding the pen isn't the person who is working out the
corrections to the majority of the sentences in the document.

Dale

Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

[Tim Chown]

On 30 Apr 2013, at 16:43, joel jaeggli  wrote:

> On 4/30/13 8:33 AM, Robert Sparks wrote:
>> On 4/2/13 4:58 AM, Brian E Carpenter wrote:
>>> Just picking a couple of points for further comment:
>>> 
>>> On 02/04/2013 08:46, Liubing (Leo) wrote:
 
 [Bing] draft-chown-v6ops-renumber-thinkabout is an important input for the 
 gap analysis. Although the draft is expired, most of the content are still 
 valid.
 draft-chown is a more comprehensive analysis, while the gap draft is 
 focusing on gaps in enterprise renumbering. So it might not easy to 
 abstract several points as important from draft-chown to this draft. We 
 actually encourage people to read it.
>>> Robert is right, though, sending people to a long-expired draft is a bad 
>>> idea.
> I'm not sure I see that as worse than referring to Wikipedia, an expired 
> draft has the property that it's not going to change. I have no problem with 
> the idea that it would be an informative reference.   but yes it's a bit much 
> to say go read this.
>>> Of course we have to acknowledge it, but maybe we should pull some of its 
>>> text
>>> into an Appendix.
>>> 
>>> Tim Chown, any opinion?
>> The most recent version (and the one slated for the next telechat) still has 
>> this long-expired draft referenced.


Hi,

The old renumbering "thinkabout" draft came out of experiments on IPv6 
renumbering we did in 6NET some 10 (yikes!) years ago, for both enterprise and 
ISP networks. I think most of what was written is still applicable.  Brian 
borrowed a fair deal of it for RFC 5887.  I stopped work on it as there was 
little/no interest in the problem in v6ops at the time (or whatever v6ops was 
called back then). We produced technical 6NET reports separately, and did some 
follow-up work with Cisco separately.

Personally I don't mind if the principles are mentioned without the explicit 
reference - an ack in the Acknowledgements is adequate. 

It would be interesting to review the "thinkabout" draft to see how much still 
holds true.  Glancing at it, sections like "Application and Service-Oriented 
Issues" are still very much relevant. I guess Stig and I could consider 
advancing it along the Independent Submission path, or look for publication to 
an appropriate journal.  Life is short :)

Tim

Re: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

[Robert Sparks]

Looks good to me. Thanks!
RjS

On 5/6/13 3:02 AM, mohamed.boucad...@orange.com wrote:


Dear Robert,

I updated the document to cover the comments you raised. You can check 
the diff available at: 
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-triggered-reconfigure-06


Cheers,

Med

*De :*dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] *De la 
part de* Robert Sparks

*Envoyé :* vendredi 26 avril 2013 17:42
*À :* dh...@ietf.org; ietf@ietf.org; General Area Review Team; 
draft-ietf-dhc-triggered-reconfig...@tools.ietf.org

*Objet :* [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

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-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, 
described in

  the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section 
6.3.

I could be wrong, but If I'm right, this paragraph:

When retransmission is required, the relay may decide to correct the 
content of RECONFIGURE-REQUEST message it issues (e.g., update the 
Client Identifier list).  This decision is local to the relay (e.g., 
it may be based on observed events such as one or more clients were 
reconfigured on their own).



introduces a race-condition that could lead to an erroneous state. If 
a relay's first message included client A, then the retransmission 
included clients A and B, but that retransmission crosses with a 
success RECONFIGURE-REPLY to the request that only included client A, 
the relay will think it succeeded in asking A and B to be reconfigured.


Minor issues:

This sentence:

Furthermore, means to recover state in failure events must be 
supported, but are not discussed in this document.


places a requirement on a relay (even though it's not using a 2119 
MUST). Is there some other document that defines this requirement that 
you can reference? If not, the requirement should be discussed in this 
document. Alternatively, you could change the sentence to talk about 
the consequences of not having a proprietary means for recovering state.


Nits/editorial comments:

RE: Language editing

[l.wood]

http://labs.apnic.net/blabs/?p=309

an excellent detective story on badly-written, poorly edited, standards track 
RFCs leading to interop problems. Enjoy.

Lloyd Wood
http://sat-net.com/L.Wood/

Technical writer and editor, native English speaker, IELTS score of 9.0, 
vaguely appalled by this discussion.



From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of John C Klensin 
[john-i...@jck.com]
Sent: 05 May 2013 19:32
To: Brian E Carpenter; Yaron Sheffer
Cc: ietf@ietf.org
Subject: Re: Language editing

--On Saturday, May 04, 2013 10:04 +1200 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.

And what we have found more times than I care to think about --
and I've found even more times than that when trying to read
undergraduate papers -- is that "native English speaker" does
not imply "ability to write good, clear, coherent technical
English".  In addition, the IETF includes a reasonable number of
people whose first language is not English but whose ability to
write high-quality technical documents in English generally
exceeds that of our typical native speaker.   So my first
concern is that we not start making plans based on the
population of native speakers -- if we are going to find
volunteers to pretend to be technical editors, or assess the
population of such people, we had better base our assumptions on
the right set of skills.

> 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.

To be a little more precise, technical editors are supposed to
understand the nature of technical documents, to have good
intuitions about what is clear and precise and what isn't, and
so on.  Specific subject-matter expertise is yet another layer
of requirement and something we would be unlikely to find far
outside the relevant WG or Area.  I think the distinction
between copy editors and technical editors is very significant
(and I might have been the one who made the comment to which you
refer).  But one should not confuse that distinction with the
observation that there are probably as large a proportion of
poor editors who can't deal with material that requires some
skill (in either subcategory) in the world as there are poor
engineers who can't competently handle actual systems design
issues.

Having shepherded (and kicked, clawed, and dragged) a number of
documents through the system in the last few years that were
written by people whose engineering and protocol design skills
far exceeded their [English] technical writing skills, I'm less
optimistic about volunteer editing than several others seem to
be.  If a WG has surplus people with good technical editing
skills to pair with authors who may be better about the
technical details or tracking the WG discussions and getting
them into to document, then that is great.  But I have certainly
worked in or chaired WGs when there are no such people to spare
or who will volunteer.  In addition, it is really hard for
someone who cares enough about the subject matter of the WG to
be able to edit or translate a draft into good, clear, technical
English without injecting their own opinions about areas where
the original I-D may be unclear -- perhaps it is even harder
than writing the document with careful attention to WG consensus.

My guess is that we are going to need a mixed strategy that
involves volunteer (and adequately skilled) editors where we can
find them, professional technical editors where necessary (and a
good model for how they get paid), and oversight of the whole
process by the RFC Editor as well as relevant WG Chairs, ADs,
and the IESG.  We are also going to need to be much more clear
about what level of quality we, as a community (not just the
IESG), want and will insist on before a document goes into Last
Call.

I've always hoped that the standard could be "absolutely clear
about what is being specified, but everything else can be fixed
by the RFC Editor after approval".  But that requirement is more
easily stated that interpreted and used: I've seen text in
documents that I thought were that good nit-picked by the IESG
and edited by

RE: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

[mohamed.boucadair]

Dear Robert,

I updated the document to cover the comments you raised. You can check the diff 
available at: 
http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-triggered-reconfigure-06

Cheers,
Med

De : dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] De la part de 
Robert Sparks
Envoyé : vendredi 26 avril 2013 17:42
À : dh...@ietf.org; ietf@ietf.org; General Area Review Team; 
draft-ietf-dhc-triggered-reconfig...@tools.ietf.org
Objet : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

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-dhc-triggered-reconfigure-05
Reviewer:  Robert Sparks
Review Date: April 26, 2013
IETF LC End Date: May 6, 2013
IESG Telechat date: May 16, 2013

Summary: This draft is on the right track but has open issues, described in
  the review.

Major issues:

Overall, this document is solid, but I think there is a bug in section 6.3.
I could be wrong, but If I'm right, this paragraph:
When retransmission is required, the relay may decide to correct the content of 
RECONFIGURE-REQUEST message it issues (e.g., update the Client Identifier 
list).  This decision is local to the relay (e.g., it may be based on observed 
events such as one or more clients were reconfigured on their own).

introduces a race-condition that could lead to an erroneous state. If a relay's 
first message included client A, then the retransmission included clients A and 
B, but that retransmission crosses with a success RECONFIGURE-REPLY to the 
request that only included client A, the relay will think it succeeded in 
asking A and B to be reconfigured.

Minor issues:

This sentence:
Furthermore, means to recover state in failure events must be supported, but 
are not discussed in this document.
places a requirement on a relay (even though it's not using a 2119 MUST). Is 
there some other document that defines this requirement that you can reference? 
If not, the requirement should be discussed in this document. Alternatively, 
you could change the sentence to talk about the consequences of not having a 
proprietary means for recovering state.

Nits/editorial comments:

Re: call for ideas: tail-heavy IETF process

[Andy Bierman]

..

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

It works on down the line too.
WG Chairs meeting with I-D editors once every 4 months isn't so great
either.

If the total time has gone up 100 days, and the IESG time has gone down
100 days, then clearly the WG process is the main problem.

I'd like to see some stats on average delta between revisions of an I-D,
with some metric for the number of changes per revision.  I suspect
it would show way too many drafts that have a few edits once every
4 months. (One of mine right now even ;-)

The WG Chairs need more training on how to avoid the "slow tweak mode"
problem. The ADs need to manage their WG chairs so this doesn't happen.


Adrian
>
>
Andy

Re: call for ideas: tail-heavy IETF process

[Olaf Kolkman]

On May 5, 2013, at 7:54 AM, Hannes Tschofenig  wrote:

> On 05/05/2013 01:37 PM, Benoit Claise wrote:
>> On 2/05/2013 18:17, Carsten Bormann wrote:
>>> On May 2, 2013, at 07:21, "Eggert, Lars"  wrote:
>>> 
 Yeah, all kinds of issues, but if we created a new thing here in
 between WGLC and PS, the broader industry would never understand.
>>> That is a matter of naming and marketing ("candidate RFC"?).
>> There is already some misconception between I-RFC and Standards Tracks RFC.
>> I don't believe that adding a new name/category would help: instead it
>> would add to the confusion.
>> 
>> Regards, Benoit
> 
> Interesting that you mention this.
> 
> A note from a recent experience: Together with Olaf we are participating in a 
> European Multistakeholder Platform for ICT standardization, see 
> http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:C:2011:349:0004:0006:EN:PDF
> 
> The aim of this group is to find out how to reference IETF RFC (and standards 
> from other organizations, like the W3C) since the European Commission seems 
> to be unable to just reference standards beyond a small set of organizations 
> (such as ETSI).
> 
> As you can imagine, the different types of RFCs are not that easy to 
> understand for those who do not participate actively in the IETF. Getting 
> others to understand the different streams, the various document types and 
> different standards is already difficult and maybe there is room for 
> simplification here.

FWIW.

I think the difference between Informational and Standards track is fairly 
easily explained (in that context), having all the information in the headers 
and boilerplates helps. Where things become difficult is at the point where the 
maintenance of our standards need to be explained and questions about 
progression on the standards ladder get asked. 

Personally I hope that RFC 6410 has the effect that we, as a community, get 
serious about promoting our proposed standards, or obsolete them. 

I wonder how many standards got promoted after 6410 was published.

--Olaf

Re: call for ideas: tail-heavy IETF process

[Bill McQuillan]

On Sun, 2013-05-05, John C Klensin wrote:

> Finally, there are a few things that we used to do, that were
> helpful, and that were abandoned due to industry evolution and
> changes in priorities.  The original idea of a Proposed Standard
> as a fairly rough specification that would be used for study and
> evaluation on the basis of implementation experience, not a spec
> from which products were built, is one that has been mentioned
> (although not quite in that way).   

FWIW, this leads me to the thought that the IETF may have a 
terminology problem. The word "standard" is used too soon in the 
maturity levels of RFCs.

I think that our skills are primarily in producing "protocols"
rather than "standards". Perhaps it would have been better if the
names of the maturity levels were something like:

  Proposed Protocol
  Test Version 1 Protocol
  Test Version 2 protocol
   .
   .
   .
  Standard Protocol

Only using the word "standard" when it was determined to be 
stable and recommended for wide usage.

Anyway, my 2 cents.

-- 
Bill McQuillan