Subject: [Gen-art] 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. 

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

---

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
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

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: "Ross Callon" <[email-masked]>
Date: Tue, 2 Sep 2008 23:47:38 -0400

I think that Spencer has already been sufficiently beat up about this,
but...  I would suggest that these minor issues be fixed before the
document is approved. The cleanest approach  (particularly if there are
any other IETF last call comments)is probably to fix it before I put the
document in front of the IESG. 

Thanks, Ross

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: 01 September 2008 10:07
To: [email-masked]
Cc: Ross Callon; General Area Review Team; [email-masked]; Patrick
Droz; Jamal Hadi Salim
Subject: Gen-ART Review of draft-ietf-forces-mib-07

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

Comments:

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

3.  Introduction

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.

4.  ForCES MIB Overview

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.

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

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

---

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"
> 
Proposed 

[RFCzzzz]).
Control 
I'd 
> all-caps-ing UP so it looks like a state.

I made the suggested changes.

FE, 
for 
> the reader is just too easy.

I made the suggested changes.

not 
messages. 
after 
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.

...
know 
into 
for 
ID 
similar, 
> unless I don't understand (it happens).

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 03 Sep 2008 06:54:28 -0400

I had a discussion with Robert yesterday and he is going to be
submitting a new version. I also sent a private note to Spencer to
that effect

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 03 Sep 2008 08:01:28 -0400

Sorry - a little too hasty in my response. I just saw that Robert's
already posted a revised version.

cheers,
jamal

---

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: Robert Haas <[email-masked]>
Date: Tue, 9 Sep 2008 15:47:00 +0200

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: "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,