Subject: [Diffserv] Re: Fwd: RE: Fwd: Re: authors 48 hours: RFC 3289<draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE

From: Fred Baker <[email-masked]>
Date: Thu, 29 Aug 2002 18:35:23 -0700

At 07:45 PM 8/29/2002 -0400, Kwok Ho Chan wrote:
>Fred:
>Are you referring to the attached E-Mail?

yes. I would like all comments edited into the new document to have at 
least been seen by the working group. I don't think we'll get a lot of 
commentary, but people should have the opportunity.

>-- Kwok --
>
>>From: "Andrew Smith" <[email-masked]>
>>To: "Brian E Carpenter" <[email-masked]>, "Fred Baker" 
>><[email-masked]>,
>>    "Chan, Kwok-Ho [BL60:470:EXCH]"<[email-masked]>
>>Cc: <[email-masked]>, <[email-masked]>,
>>    "Dan Grossman" <[email-masked]>
>>Subject: RE: Fwd: Re: authors 48 hours: RFC 
>>3289<draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>>Date: Thu, 30 May 2002 12:20:51 -0700
>>X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
>>Importance: Normal
>>X-SMTP-HELO: falcon.mail.pas.earthlink.net
>>X-SMTP-MAIL-FROM: [email-masked]
>>X-SMTP-RCPT-TO: [email-masked]
>>X-SMTP-PEER-INFO: falcon.mail.pas.earthlink.net [207.217.120.74]
>>
>>I just found out about the "48 hours" today: most of these comments are
>>probably (way) too late but there are some editorial things buried in here
>>that might be helpful at this late stage:
>>
>>Please change my contact info:
>>         OLD:
>>
>>                                                        A. Smith
>>                                                        Allegro Networks
>>         NEW:
>>                                                        A. Smith
>>                                                        Harbour Networks
>>
>>11. Authors' Addresses
>>
>>OLD:
>>    Andrew Smith
>>    Allegro Networks
>>    6399 San Ignacio Ave
>>    San Jose, CA 95119
>>
>>    EMail: [email-masked]
>>  NEW:
>>    Andrew Smith
>>    Harbour Networks
>>    Jiuling Building
>>    21 North Xisanhuan Ave.
>>    Beijing, 100089, PRC
>>
>>    EMail: [email-masked]
>>
>>
>>
>>3.5.3.  diffServMinRateTable - The Minimum Rate Table: The description (both
>>here and in the comments in the MIB module and in the DESCRIPTION clauses)
>>is unclear on when the Rate and when the Priority parameters are to be used
>>and what is their combined effect:
>>
>>    "When the output rate of a queue or scheduler must be given a minimum
>>    rate or a priority, this is done using the diffServMinRateTable.
>>    Rates may be expressed as absolute rates, or as a fraction of
>>    ifSpeed, and imply the use of a rate-based scheduler such as WFQ or
>>    WRR.  The use of a priority implies the use of a Priority Scheduler.
>>    Only one of the Absolute or Relative rates needs to be set; the other
>>    takes the relevant value as a result.  Excess capacity is distributed
>>    proportionally among the inputs to a scheduler using the assured
>>    rate.  More complex functionality may be described by augmenting this
>>    MIB."
>>
>>I thought that the type of scheduler was implied by diffServSchedulerMethod,
>>not by "use of a priority".  And if you're doing strict priority scheduling,
>>neither of Absolute or Relative rates needs to be set, right? Text above
>>seems to imply otherwise. See also below.
>>
>>3.5.5 There's no reference to figure 4. Perhaps it should be from the
>>paragraph at the bottom of p18?
>>
>>3.5.5 Is there a way to keep this set of diagrams closer to (in-line with)
>>the text describing them, or at least, on the same page? I know it wastes
>>paper/bytes but would add to clarity.
>>
>>3.5.5 I find some of this relatively new text confusing (this is the first
>>time I've seen it so tell me if I'm too late with the following comments).
>>Specifically:
>>
>>    "For representing a Strict Priority scheduler, each scheduler input is
>>    assigned a priority with respect to all the other inputs feeding the
>>    same scheduler, with default values for the other parameters.
>>    Higher-priority traffic that is not being delayed for shaping will be
>>    serviced before a lower-priority input.  An example is found in
>>    Figure 2."
>>
>>Clearer (or, at least, more accurate) is:
>>
>>    "For representing a Strict Priority scheduler, the
>>diffServSchedulerMethod is set to diffServSchedulerPriority and the
>>prededing queue or scheduler feeding this scheduler input is assigned a
>>priority in its associated diffServMinRateEntry with respect to all the
>>other inputs feeding the same scheduler (the value of the other parameters
>>in this entry are irrelevant). Traffic from higher-priority inputs to this
>>scheduler will be serviced before that from lower-priority inputs. An
>>example is found in Figure 2."
>>
>>Figures 3, 4 and 5: suggest you use more specific labels in some of the
>>boxes to remove confusion:
>>- figure 3, replace "Rate" with "MaxRate" in each box;
>>- figure 4, put something in the empty boxes e.g. "n/a" or leave them out.
>>Replace "Shaping Rate" with "MaxRate" - we have no parameter called shaping
>>rate.
>>
>>3.5.5: suggest you lose the NOTE and its text, just above figure 4, or at
>>least join it up with the following paragraph.
>>
>>3.5.5: last paragraph should be part of 3.6 really. And glue Figure 6 to
>>this paragraph for clarity.
>>
>>3.6: change "four AF classes" to "four AF classes, each with 3 levels of
>>drop precedence or 'colours'". We must be clear that this is just an example
>>of an AF implementation that chooses to do 4 classes, each with 3 colours.
>>
>>3.6: Suggest you use the same example scenario for figures 6 and 7 - it's
>>confusing to use different example scenarios. Figure 7 introduces a new kind
>>of "hybrid" notation for the first time (we've always gone left-to-right
>>before, not top-to-bottom - I preferred the former for clarity): I suggest
>>it needs some words to explain the notation (rhetorical questions: what do
>>the lines imply when they don't have arrowheads? what are the 2 or 3
>>different lines exiting from the meters? These are all deducible from the
>>following text but it's made harder work due to the new notation. BTW,
>>there's an arrow missing out of the back/bottom/right Action box.
>>
>>3.6: suggest you add the "everything else" case that you discuss in the text
>>to figure 7.
>>
>>3.6.: there's no reference to figure 7 in the text.
>>
>>3.6 and 3.7: actually, I'm not sure why these sections are here in this
>>document - a few years ago, we took out similar "tutorial" material and put
>>it in the Model draft. There's nothing in these sections that is specific to
>>the MIB. The right thing to have in this document is the "translation" of an
>>example like this into the structures and linkages used by the MIB but these
>>sections do not help with this. We had such material in draft-09 and it has
>>disappeared (I'm not saying 3.6 and 3.7 aren't useful material but it just
>>does not belong in this document) - I think this is a backward step.
>>
>>Anyhow, I'm probably too late to the party with most of these comments - I
>>should have reviewed it when the IESG last call was in progress (I didn't
>>realise so much had changed since -09 which was the last version that I
>>reviewed properly).
>>
>>Andrew
>>
>>
>>
>>
>>-----Original Message-----
>>From: Brian E Carpenter [mailto:[email-masked]]
>>Sent: Thursday, May 30, 2002 5:56 AM
>>To: Fred Baker
>>Cc: [email-masked]; [email-masked]; Andrew Smith;
>>Kwok Ho Chan
>>Subject: Re: Fwd: Re: authors 48 hours: RFC
>>3289<draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>>
>>
>>OK, in view of Kwok's response we can give it another day or say, but
>>then...
>>
>>    Brian
>>
>>Fred Baker wrote:
>> >
>> > You may need to make an executive decision here. Andrew and Kwok are AWOL.
>> >
>> > >Date: Wed, 29 May 2002 19:50:58 GMT
>> > >To: [email-masked], [email-masked]
>> > >Subject: Re: authors 48 hours: RFC 3289
>> > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>> > >Cc: [email-masked], [email-masked], [email-masked],
>> > >         [email-masked], [email-masked]
>> > >From: [email-masked]
>> > >X-Sun-Charset: US-ASCII
>> > >
>> > >Kwok Ho and Andrew,
>> > >
>> > >We still have not heard from you regarding this document.  Please let
>> > >us know if there are any corrections required.
>> > >
>> > >We are waiting to hear from you.
>> > >
>> > >RFC Editor
>> > >
>> > >
>> > >----- Begin Included Message -----
>> > >
>> > > >From [email-masked]  Thu May 23 16:22:59 2002
>> > >Date: Thu, 23 May 2002 23:22:45 GMT
>> > >To: [email-masked], [email-masked]
>> > >Subject: Re: authors 48 hours: RFC 3289
>> > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>> > >Cc: [email-masked], [email-masked],
>>[email-masked],
>> > >    [email-masked], [email-masked]
>> > >From: [email-masked]
>> > >X-Sun-Charset: US-ASCII
>> > >X-AntiVirus: scanned by AMaViS 0.2.1
>> > >Content-Length: 3636
>> > >
>> > >Kwok Ho and Andrew,
>> > >
>> > >Please let us know if the document is ready to be published.
>> > >
>> > >We are awaiting your reply.
>> > >
>> > >Thank you.
>> > >
>> > >RFC Editor
>> > >
>> > >
>> > > > From [email-masked]  Tue May 21 09:25:15 2002
>> > > > Date: Tue, 21 May 2002 16:24:54 GMT
>> > > > To: [email-masked], [email-masked]
>> > > > Subject: Re: authors 48 hours: RFC 3289
>> > > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>> > > > Cc: [email-masked], [email-masked],
>>[email-masked],
>> > > >    [email-masked], [email-masked]
>> > > > From: [email-masked]
>> > > > X-Sun-Charset: US-ASCII
>> > > > X-AntiVirus: scanned by AMaViS 0.2.1
>> > > > Content-Length: 2866
>> > > >
>> > > > Authors,
>> > > >
>> > > > We have not heard any further from you regarding this document.  We
>> > > > would appreciate a confirmation that the document is ready to be
>> > > > published as it now appears at:
>> > > >
>> > > >    ftp://ftp.isi.edu/in-notes/authors/rfc3289.txt
>> > > >
>> > > > We will wait to hear from you before continuing on.
>> > > >
>> > > > Thank you.
>> > > >
>> > > > RFC Editor
>> > > >
>> > > >
>> > > > > From [email-masked]  Mon May 13 11:51:19 2002
>> > > > > Date: Mon, 13 May 2002 18:50:53 GMT
>> > > > > To: [email-masked], [email-masked]
>> > > > > Subject: Re: authors 48 hours: RFC 3289
>> > > > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>> > > > > Cc: [email-masked], [email-masked],
>> > > [email-masked],
>> > > > >    [email-masked], [email-masked]
>> > > > > From: [email-masked]
>> > > > > X-Sun-Charset: US-ASCII
>> > > > > X-AntiVirus: scanned by AMaViS 0.2.1
>> > > > > Content-Length: 1984
>> > > > >
>> > > > > Fred,
>> > > > >
>> > > > > Thank you for bringing this to our attention.  It now parses
>> > > > > successfully.
>> > > > >
>> > > > > We have updated your contact information in the authors address
>> > > > > section, as well as within the mib.
>> > > > >
>> > > > > Please let us know if there are any further corrections required.
>>We
>> > > > > will wait to hear from you.
>> > > > >
>> > > > > Thank you.
>> > > > >
>> > > > > RFC editor
>> > > > >
>> > > > >
>> > > > > > From [email-masked]  Fri May 10 01:03:56 2002
>> > > > > > X-Sender: [email-masked]
>> > > > > > X-Mailer: QUALCOMM Windows Eudora Version 5.1
>> > > > > > Date: Fri, 10 May 2002 16:03:24 +0800
>> > > > > > To: [email-masked]
>> > > > > > From: Fred Baker <[email-masked]>
>> > > > > > Subject: Re: authors 48 hours: RFC 3289
>> > > > > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>> > > > > > Cc: [email-masked], [email-masked],
>> > > > > >    [email-masked], [email-masked], [email-masked],
>> > > > > >    [email-masked]
>> > > > > > Mime-Version: 1.0
>> > > > > > X-AntiVirus: scanned by AMaViS 0.2.1
>> > > > > >
>> > > > > > At 10:37 PM 5/9/2002 +0000, [email-masked] wrote:
>> > > > > > >FYI:
>> > > > > > >
>> > > > > > >W: f(rfc3289.mi2), (42,1) Textual convention "Dscp" defined but
>> > > not used
>> > > > > > >W: f(rfc3289.mi2), (52,1) Textual convention "DscpOrAny" defined
>>but
>> > > > > > >not used
>> > > > > >
>> > > > > > these two warnings come up because the TCs are in a separate MIB
>> > > Module
>> > > > > > from the main mib, and are imported into it. They are fine.
>> > > > > >
>> > > > > > My contact information has changed slightly; I have a new physical
>> > > address.
>> > > > > >
>> > > > > >
>>/=====================================================================/
>> > > > > >   |     Fred Baker                 |        1121 Via Del Rey
>>|
>> > > > > >   |     Cisco Fellow               |        Santa Barbara,
>>California |
>> > > > > >   +--------------------------------+        93117 USA
>>|
>> > > > > >   | Nothing will ever be attempted,| phone: +1-805-681-0115
>>|
>> > > > > >   | if all possible objections must| fax:   +1-413-473-2403
>>|
>> > > > > >   | be first overcome.             |
>>|
>> > > > > >   |     Dr. Johnson, Rasselas, 1759|
>>|
>> > > > > >
>>/=====================================================================/
>> > > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> > >----- End Included Message -----
>

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: "Andrew Smith" <[email-masked]>
Date: Thu, 29 Aug 2002 19:41:56 -0700

I'm not convinced that now is the right time to be updating this MIB
and/or the RFC that includes it. Some of Tom Irwin's first set of
comments fix errors but some (and all of his second set of comments) are
clarifications, as were most of mine from May 3th 2002 (below). If we
must, then I'd suggest just fixing the syntax errors in the MIB module.
But don't things like this usually wait for a "natural" refresh cycle
e.g. an attempt to move an RFC to Draft standard? I'd hate to
destabilise anyone's plans to implement the current RFC. We've got
published/archived fixes on the record so I don't see the urgency to
update (other than tidiness). And it's quite likely that we'd be able to
remove 20 pages or more with the benefit of another year or so more
implementation experience.

Just my thoughts - I don't have any significant stake in any current
implementation plans so it really ought to be up to others to say what
they want done.

Andrew Smith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fred Baker
Sent: Thursday, August 29, 2002 6:35 PM
To: Kwok Ho Chan
Cc: [email-masked]; [email-masked]
Subject: [Diffserv] Re: Fwd: RE: Fwd: Re: authors 48 hours: RFC
3289<draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE

>>                                                        Allegro
Networks
>>                                                        Harbour
Networks

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive:
http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillis
t.html

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Aug 2002 08:17:23 +0200

We have 2 choices:

1. Republish the RFC now (as Proposed Standard)
2. Simply list the errata on the RFC Editor's errata page. 

We'll certainly take guidance from the WG as to which is
better, so if you have an opinion please give it now.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Dan Grossman <[email-masked]>
Date: Fri, 30 Aug 2002 09:56:24 -0400

Why don't we do with the MIB what we did with RFC 2474, 2475, 2597 and 2598:  start a draft
(can a concluded WG have a WG draft?) that captures clarifications to the MIB?

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Aug 2002 19:08:53 -0700

At 07:41 PM 8/29/2002 -0700, Andrew Smith wrote:
>e.g. an attempt to move an RFC to Draft standard?

there is at least one thing whihc actually needs correction - a range on a 
variable.