Subject: Gen-ART Review of draft-ietf-forces-mib-07

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 1 Sep 2008 09:07:03 -0500

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ietf-forces-mib-07
Reviewer: Spencer Dawkins
Review Date: 2008-09-01
IETF LC End Date: 2008-09-08
IESG Telechat date: (not known)

Summary: This document is very close to ready for publication as a Proposed 
Standard. I have two technical comments below, but both are minor issues 
that could resolved in AUTH48 if you think they have merit.

Comments:

OBTW, idnits 2.08.11 runs cleanly (one spurious warning about [RFCzzzz]).

3.  Introduction

   More specifically, the information in the ForCES MIB module relative
   to associations that are up includes:

Spencer (clarity): I'd suggest s/associations/associations between Control 
Elements and Forwarding Elements/, unless that's wrong (and if it is, I'd 
still suggest "between X and Y", whatever X and Y are). Later uses of 
"association" would be fine, of course, this is just providing initial 
context.

Spencer (clarity): I'd suggest s/up/in the UP state/, or at least 
all-caps-ing UP so it looks like a state.

4.  ForCES MIB Overview

   The MIB module contains the latest ForCES protocol version supported
   by the CE (forcesLatestProtocolVersionSupported).  Note that the CE
   must also allow interaction with FEs supporting earlier versions.

Spencer (clarity): I'd suggest s/CE/Control Element (CE)/ (and same for FE, 
ID, etc.) The reader can figure stuff like this out, but spelling it out for 
the reader is just too easy.

   o  Number of other ForCES messages sent from the CE
      (forcesAssociationOtherMsgSent) and received by the CE
      (forcesAssociationOtherMsgReceived) since the association entered
      the UP state.  Only messages other than Heartbeat, Association
      Setup, Association Setup Response, and Association Teardown are
      counted.

Spencer (technical): I think I know what you're saying here, but you're not 
counting "other" messages (because you exclude some of the "other" messages. 
The point is that you didn't get into the table with Association 
Setup/Association Setup Response, and you leave the table immediately after 
Association Teardown, so you don't have to count these messages, isn't it? 
:-(

If it's not too late to change this to "OperationalMsg" or something 
similar, I'd suggest that, for clarity. If it is too late to change this ...

   Finally, the MIB module defines the following notifications:

   o  Whenever an association enters the UP state, a notification
      (forcesAssociationEntryUp) is issued containing the version of the
      ForCES protocol running.  Note that as CE ID and FE ID are
      indexes, they appear in the OID of the ForCES-protocol running-

Spencer (technical): this is intended as a question, because I don't know 
MIB practices, but it looks to me like CE ID and FE ID are concatenated into 
ONE index, so they aren't "indexes" - right? I'm looking at the INDEX for 
"ForcesAssociationEntry".

The rest of the document is pretty clear about this, so I'd suggest "CE ID 
and FE ID are concatenated to form the table index", or something similar, 
unless I don't understand (it happens).

      version object.  Optionally, a notification
      (forcesAssociationEntryUpStats) can instead be issued with all
      associated information for this association, except
      forcesAssociationTimeDown. 

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Bob Braden <[email-masked]>
Date: Tue, 02 Sep 2008 09:16:51 -0700

>that could resolved in AUTH48 if you think they have merit.

An aside: The purpose of AUTH48 state is not (should not be) to resolve 
even minor issues.  Ideally, no issues should arise in AUTH48, but the 
world is not a perfect place.  But let's not get in the habit of sweeping 
minor changes to the every end of the publication process.  The revision 
process is pretty cheap.

Bob Braden

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Sep 2008 11:06:06 -0700

>minor changes to the every end of the publication process.  The revision

A big +1 to that. It is becoming increasingly common to hear 
reviewers and ADs say "please fix that in AUTH48" instead of "please 
turn in a new draft with these small number of changes". Because 
tools.ietf.org makes reading Internet Draft diffs so easy, there is 
really no good reason to not have the input to the RFC Editor be a 
known-clean document.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Sep 2008 14:28:05 -0500

OK...

> minor changes to the every end of the publication process.  The revision 

Agreed. I've been seeing a lot of Gen-ART reviewers, including myself, who 
say "could be resolved in AUTH48" as a unit of size, but I can see how 
reasonable people assume that it's a suggestion of tactics :-)

Thanks for the opportunity to break old habits when they become even less 
reasonable.

Spencer

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Sep 2008 16:48:43 -0400

--On Tuesday, 02 September, 2008 14:28 -0500 Spencer Dawkins
<[email-masked]> wrote:

>>> Standard. I have two technical comments below, but both are
>>> minor issues that could resolved in AUTH48 if you think they
>>> have merit.
>> 
>> An aside: The purpose of AUTH48 state is not (should not be)
>> to resolve  even minor issues.  Ideally, no issues should
>> arise in AUTH48, but the  world is not a perfect place.  But
>> let's not get in the habit of sweeping  minor changes to the
>> every end of the publication process.  The revision  process
>> is pretty cheap.
> 
> Agreed. I've been seeing a lot of Gen-ART reviewers, including
> myself, who  say "could be resolved in AUTH48" as a unit of
> size, but I can see how  reasonable people assume that it's a
> suggestion of tactics :-)
> 
> Thanks for the opportunity to break old habits when they
> become even less  reasonable.

Spencer, 

It occurs to me that people may have been saying "could be
resolved in AUTH48" when they really meant "could be resolved in
an RFC Editor note".   While, like Paul, I tend to prefer that
the RFC Editor get clean copy, there is a huge difference
between "IESG makes a note to the RFC Editor about a desired
editorial fix" or "IESG makes a note to the Author/Editor about
a desired editorial fix so it can be incorporated into the clean
copy that goes to the RFC Editor" and anything having to do with
AUTH48.  The former two are pre-editing and allow opportunities
for discussion of any proposed changes that appear to be
unreasonable.  Requesting that changes be made at AUTH48 time is
just, IMO, an opportunity for mistakes and/or abuse.

   john

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 2 Sep 2008 17:00:07 -0400

On Tue, 02 Sep 2008 16:48:43 -0400

> just, IMO, an opportunity for mistakes and/or abuse.

Personally, I don't even like RFC Editor notes for things that can and
should be corrected by the author.  As both an author and an AD, I much
preferred clean new copies.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 2 Sep 2008 16:08:29 -0500

To John and Steve,

>> an RFC Editor note".

I would not be a bit surprised if I meant that ;-)

> preferred clean new copies.

My own AD feels the same way, for reasonable reasons.

I do note that spinning revisions also activates all the review team 
reviewers to figure out what's changed since (in this case) 07. It's worth 
noting that although the ID submission tool has made submitting a 08 version 
very cheap, it's not free...

Thanks.

Spencer

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Sep 2008 23:15:17 +0200

Steven M. Bellovin wrote:
> ...
> ...

Absolutely.

The more edits need to be done in AUTH48, the more likely it is that 
something goes wrong and isn't noticed in time.

Also, things that may look "editorial" to some may be seen as 
"substantive" by others, in which case they really should have been 
reviewed before publication.

BR, Julian

---

From: John C Klensin <[email-masked]>
Date: Tue, 02 Sep 2008 17:56:50 -0400

--On Tuesday, 02 September, 2008 16:08 -0500 Spencer Dawkins
<[email-masked]> wrote:

>>> resolved in AUTH48" when they really meant "could be
>>> resolved in an RFC Editor note".
> 
>> Personally, I don't even like RFC Editor notes for things
>> that can and should be corrected by the author.  As both an
>> author and an AD, I much preferred clean new copies.
> 
> I do note that spinning revisions also activates all the
> review team reviewers to figure out what's changed since (in
> this case) 07. It's worth noting that although the ID
> submission tool has made submitting a 08 version very cheap,
> it's not free...

And that is why I've come to prefer the following sequence of
events:

	(i) Presumably-final draft goes to Last Call and
	Reviewers.
	
	(ii) Possible new draft, with changes clearly
	identified, as the result of Last Call (and Reviewer)
	comments.
	
	(iii) IESG review, which might produce a draft note,
	historically known as an RFC Editor note, along with
	approval.  If the IESG returns the document to the
	authors or WG instead, restart at (i) with a new draft.
	
	(iv) If that note is acceptable to the authors/ editors/
	WG/ etc., generation of a document that incorporates the
	changes.  That version is, or is not, posted at the
	discretion of the RFC Editor and/or WG Chair and/or AD.

In other words, the document editor prepares a clean draft with
the RFC Editor note(s) incorporated, rather than expecting the
RFC Editor to do so.  If a draft is posted at (ii), it implies
that significant changes have occurred and may trigger the
re-review to which Spencer refers.  The IESG approval at (iii)
is considered final and the document at (iv) simply an editorial
matter of splicing the changes in.  If that latter document is
posted at all, it is with the understanding that additional
substantive comments, or even post-IESG fine-tuning, are
inherently disruptive and time-consuming and that they should
not be accepted unless they raise new, very significant,
showstopper-level issues.  Otherwise, we would never finish
anything.

     john

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 3 Sep 2008 11:55:35 +0200

Essentially, this note is another me too.

> showstopper-level issues.  Otherwise, we would never finish

Personally I would like to see that whatever document enters into the  
RFC-Production function (to use the terminology from the RFC Editor  
model[*]) has a clean copy in the repository. That allows for a very  
clean interface between the streams and the RFC-producer. So, I would  
argue that the result of (iv) is always posted.

I can imagine that the posting of an I-D may cause Pavlovian reactions  
but maybe there are means by which one can prevent folk to mistake the  
posting of such I-D as another request for review.

--Olaf

[*] For those for who this terminology is new see: http://www.iab.org/documents/resources/RFC-Editor-Model.html
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: <[email-masked]>
Date: Wed, 3 Sep 2008 15:03:20 +0300

Olaf Kolkman rote:

> Personally I would like to see that whatever document enters into
> the RFC-Production function (to use the terminology from the RFC
> Editor model[*]) has a clean copy in the repository. That allows for
> a very clean interface between the streams and the RFC-producer. So,
> I would argue that the result of (iv) is always posted.

Based on my (quite short) experience as AD so far, it seems document
authors vary greatly in how fast they can update the document and
submit it (once the text has been agreed).

I've seen this done in less than 10 minutes (sometimes before the
IESG telechat ended). I've seen cases where it has taken several 
months. In cases where the time is measured in weeks (relatively
common) or months (fortunately rare), just sending the RFC Editor 
note (and not waiting for updated clean copy) saves time, especially 
considering that the RFC Editor processes documents quite fast
nowadays.

(I do agree that having a clean copy would be nice, though.)

Best regards,
Pasi

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 3 Sep 2008 14:09:19 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Wednesday, September 03, 2008 3:03 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Gen-ART Review of draft-ietf-forces-mib-07
> 
> Olaf Kolkman rote:
> 
> Based on my (quite short) experience as AD so far, it seems 
> document authors vary greatly in how fast they can update the 
> document and submit it (once the text has been agreed).
> 
> I've seen this done in less than 10 minutes (sometimes before 
> the IESG telechat ended). I've seen cases where it has taken 
> several months. In cases where the time is measured in weeks 
> (relatively
> common) or months (fortunately rare), just sending the RFC 
> Editor note (and not waiting for updated clean copy) saves 
> time, especially considering that the RFC Editor processes 
> documents quite fast nowadays.
> 

I agree with Pasi here. For a moderate or minor quantity of edits
editing the notes to the RFC editor after all parties agreed on the
changes is fast, efficient, and our under control - thus saving time in
the majority of cases with minimal efforts. 

Yes, having a clean copy is better. We live however in an imperfect
world. 

Dan

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Sep 2008 14:09:19 +0200

> considering that the RFC Editor processes documents quite fast

I'm tempted to say that if it takes the authors months to update the 
document with the suggested change, then, well, a publication delay of 
several months is what they deserve :-).

BR, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Sep 2008 06:58:14 -0700

>several months is what they deserve :-).

+1

Given that the great majority of documents in the "authors are too 
slow to post a new draft" state are WG items, a two-line note from 
the AD to the WG upbraiding the authors for not turning in the new 
draft should get a quick result. Better still, the original note that 
was asking for a new draft with minor edits can be Cc'd to the WG as 
well.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 3 Sep 2008 10:02:54 -0500

Hi, Robert,

Thanks for the quick response on all the comments - to be explicit, version 8 addresses all my comments, except for one question (below).

It actually could be OK to retain the OtherMsg name and definition, if there is a reason to do so (one reason might be "deployed systems use this name and definition"). What I was saying was that it violates the Principle of Least Astonishment - you could also clearly define "3" as "2", but implementers would still think "3" was "3" when scanning quickly.

:-)

This is an IETF Last Call review comment, so other reviewers can tell you "Spencer is worried about nothing", and Gen-ART comments are never blocking unless an AD includes them in a DISCUSS.

I'll trust that you guys will do the right thing, which might or might not be to make a change.

Thanks for hearing me out. 

Spencer
  > Association Teardown, so you don't have to count these messages, isn't it? 

  I agree, but I'd rather keep this explicit. As for "OtherMsg" vs "OperationalMsg": I'd rather keep it as is, given that we define what are these "other" messages.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 03 Sep 2008 08:21:55 -0700

> several months is what they deserve :-).

The only problem with this comment is that some readers might think the smiley 
means you (and Paul) weren't being completely serious.

It is always tempting to look for a way to have the administrative 
infrastructure make things easier.  In fact, as I re-read that sentence, I'm 
struck by how silly it might seem to want anything else.

The problem is that "easier" often isn't, when it entails adding mechanism to 
the infrastructure.  (Hmmmm. I seem to recall learning that concern about 
user-vs-infrastructure from the design of Internet technology...)

Let's have the tools and processes help where they have to, and where things are 
strictly mechanical, but let's not have them remove basic responsibility from 
those who produce the content. For one thing, we want to avoid making it too 
easy to have no one paying complete attention to the changes in the document.

In the spirit of the general goal to move as much work as plausible down to the 
working group, the authors should make the required changes, before the document 
is passed to the RFC Editor.  Give the RFC Editor a completely clean version.

If it takes months, then that is a measure of the working group's motivation to 
get the document published...

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Sep 2008 17:49:18 +0200

Dave CROCKER wrote:
> The only problem with this comment is that some readers might think the 
> smiley means you (and Paul) weren't being completely serious.
> ...

Ack.

So for the record: I was totally serious.

BR, Julian

---

From: Robert Haas <[email-masked]>
Date: Wed, 3 Sep 2008 10:49:43 +0200

Spencer, thanks for the comments. See below for the details. I reissued a 
draft with the editorial changes:

http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-08.txt

Regards,
-Robert

"Spencer Dawkins" <[email-masked]> wrote on 09/01/2008 04:07:03 
PM:
> 
> Gen-ART Review of draft-ietf-forces-mib-07
> 
> Spencer Dawkins 
> 
> to:
> 
> ietf
> 
> 09/01/2008 04:10 PM
> 
> Cc:
> 
> "Ross Callon", "General Area Review Team", rha, "Patrick Droz", 
> "Jamal Hadi Salim"
> 

> all-caps-ing UP so it looks like a state.

I made the suggested changes.

> the reader is just too easy.

I made the suggested changes.

> Association Teardown, so you don't have to count these messages, isn't 
it? 

I agree, but I'd rather keep this explicit. As for "OtherMsg" vs 
"OperationalMsg": I'd rather keep it as is, given that we define what are 
these "other" messages.

> unless I don't understand (it happens).

Your interpretation is correct, I changed the text as you suggested.

---

From: "Tom.Petch" <[email-masked]>
Date: Wed, 3 Sep 2008 18:33:59 +0200

----- Original Message -----
From: "Olaf Kolkman" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, September 03, 2008 11:55 AM
Subject: Re: Gen-ART Review of draft-ietf-forces-mib-07

> posting of such I-D as another request for review.

I have certainly had that Pavlovian reaction, especially when the new I-D has
appeared after a gap of weeks or months and I have forgotten what state the I-D
is in.  The solution lies in the hands of the document shepherd, to drop a note
to the mailing list explaining what the new I-D is for.  Some are good at it,
getting the e-mail out before the I-D announcement hits the list; others are
not.

More sophisticatedly, the announcement could flag that this I-D has now passed
from the WG to the AD, IESG etc. and that suggested enhancements are no longer
welcome.

Tom Petch

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 4 Sep 2008 11:34:15 -0500

OK, I waited 24 hours, but...

Dave Crocker, Charlie Perkins and I, and Scott Bradner independently, 
proposed

Working Group Snapshots (WGS) in 
http://www.watersprings.org/pub/id/draft-dawkins-pstmt-twostage-01.txt

Stable SnapShots (SSS), in 
http://www.watersprings.org/pub/id/draft-bradner-ietf-stds-trk-01.txt

either of which could be used to express exactly the attribute Tom is 
suggesting ("this I-D has now passed from the WG to the AD, IESG etc. and 
that suggested enhancements are no longer welcome"), and could be used to 
express other attributes as well ("the working group considers this I-D to 
be stable enough to implement, so we'll have implementation experience and 
won't be requesting publication of a paper design").

For extra credit, we could implement these with no 2026/2418 changes, if 
changing 2026/2418 is as impossible as it looks - neither BCP says we CAN'T 
do WGS/SSS.

Not all the process proposals of the 2003-2005 era were useless, IMO...

Spencer

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 04 Sep 2008 09:58:21 -0700

> Not all the process proposals of the 2003-2005 era were useless, IMO...

The issue was never really about potential utility.  There were a heck of a lot 
of very good and pragmatic proposals then.

The issue has always been about getting consensus to make specific changes, 
rather than having them die the death of a thousand claimed imperfections.

If the community truly wants changes, there will be changes.

d/
-- 

   Dave Crocker

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 9 Sep 2008 09:50:19 -0500

Hi, Robert,

I would report this as "ready for publication as Proposed Standard"...

Thanks,

Spencer

----- Original Message ----- 
From: Robert Haas
To: Spencer Dawkins
Cc: Patrick Droz ; General Area Review Team ; Jamal Hadi Salim ; 
[email-masked] ; Ross Callon
Sent: Tuesday, September 09, 2008 8:47 AM
Subject: Re: Gen-ART Review of draft-ietf-forces-mib-07

Hi Spencer,
I released a new version of the draft to change to ZeroBasedCounters and 
took the opportunity to rename the counters as you suggested. Now they are 
called *Oper* instead of *Other*:
http://www.ietf.org/internet-drafts/draft-ietf-forces-mib-09.txt
Regards,
-Robert

"Spencer Dawkins" <[email-masked]> wrote on 09/03/2008 05:02:54 
PM:

> [image removed]
>
> Re: Gen-ART Review of draft-ietf-forces-mib-07
>
> Spencer Dawkins
>
> to:
>
> Robert Haas
>
> 09/03/2008 05:06 PM
>
> Cc:
>
> "Patrick Droz", "General Area Review Team", "Jamal Hadi Salim",
> ietf, "Ross Callon"
>
> Hi, Robert,
>
> Thanks for the quick response on all the comments -  to be explicit,
> version 8 addresses all my comments, except for one question  (below).
>
> It actually could be OK to retain the OtherMsg name  and definition,
> if there is a reason to do so (one reason might be "deployed
> systems use this name and definition"). What I was saying was that
> it violates  the Principle of Least Astonishment - you could also
> clearly define "3" as "2",  but implementers would still think "3"
> was "3" when scanning  quickly.
>
> :-)
>
> This is an IETF Last Call review comment, so other  reviewers can
> tell you "Spencer is worried about nothing", and Gen-ART comments
> are never blocking unless an AD includes them in a DISCUSS.
>
> "OperationalMsg": I'd rather keep it as is, given that we define
> what are these "other" messages.

---

From: Robert Haas <[email-masked]>
Date: Tue, 9 Sep 2008 15:47:00 +0200

Hi Spencer,