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

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?

Andrew Smith wrote:

> 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 protected] [mailto:[email protected]] On Behalf
> Of Fred Baker
> Sent: Thursday, August 29, 2002 6:35 PM
> To: Kwok Ho Chan
> Cc: [email protected]; [email protected]
> Subject: [Diffserv] Re: Fwd: RE: Fwd: Re: authors 48 hours: RFC
> 3289<draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>
> 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 protected]>
> >>To: "Brian E Carpenter" <[email protected]>, "Fred Baker"
> >><[email protected]>,
> >>    "Chan, Kwok-Ho [BL60:470:EXCH]"<[email protected]>
> >>Cc: <[email protected]>, <[email protected]>,
> >>    "Dan Grossman" <[email protected]>
> >>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 protected]
> >>X-SMTP-RCPT-TO: [email protected]
> >>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 protected]
> >>  NEW:
> >>    Andrew Smith
> >>    Harbour Networks
> >>    Jiuling Building
> >>    21 North Xisanhuan Ave.
> >>    Beijing, 100089, PRC
> >>
> >>    EMail: [email protected]
> >>
> >>
> >>
> >>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 protected]]
> >>Sent: Thursday, May 30, 2002 5:56 AM
> >>To: Fred Baker
> >>Cc: [email protected]; [email protected]; 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 protected], [email protected]
> >> > >Subject: Re: authors 48 hours: RFC 3289
> >> > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
> >> > >Cc: [email protected], [email protected], [email protected],
> >> > >         [email protected], [email protected]
> >> > >From: [email protected]
> >> > >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 protected]  Thu May 23 16:22:59 2002
> >> > >Date: Thu, 23 May 2002 23:22:45 GMT
> >> > >To: [email protected], [email protected]
> >> > >Subject: Re: authors 48 hours: RFC 3289
> >> > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
> >> > >Cc: [email protected], [email protected],
> >>[email protected],
> >> > >    [email protected], [email protected]
> >> > >From: [email protected]
> >> > >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 protected]  Tue May 21 09:25:15 2002
> >> > > > Date: Tue, 21 May 2002 16:24:54 GMT
> >> > > > To: [email protected], [email protected]
> >> > > > Subject: Re: authors 48 hours: RFC 3289
> >> > > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
> >> > > > Cc: [email protected], [email protected],
> >>[email protected],
> >> > > >    [email protected], [email protected]
> >> > > > From: [email protected]
> >> > > > 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 protected]  Mon May 13 11:51:19 2002
> >> > > > > Date: Mon, 13 May 2002 18:50:53 GMT
> >> > > > > To: [email protected], [email protected]
> >> > > > > Subject: Re: authors 48 hours: RFC 3289
> >> > > > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
> >> > > > > Cc: [email protected], [email protected],
> >> > > [email protected],
> >> > > > >    [email protected], [email protected]
> >> > > > > From: [email protected]
> >> > > > > 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 protected]  Fri May 10 01:03:56 2002
> >> > > > > > X-Sender: [email protected]
> >> > > > > > X-Mailer: QUALCOMM Windows Eudora Version 5.1
> >> > > > > > Date: Fri, 10 May 2002 16:03:24 +0800
> >> > > > > > To: [email protected]
> >> > > > > > From: Fred Baker <[email protected]>
> >> > > > > > Subject: Re: authors 48 hours: RFC 3289
> >> > > > > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
> >> > > > > > Cc: [email protected], [email protected],
> >> > > > > >    [email protected], [email protected],
> [email protected],
> >> > > > > >    [email protected]
> >> > > > > > Mime-Version: 1.0
> >> > > > > > X-AntiVirus: scanned by AMaViS 0.2.1
> >> > > > > >
> >> > > > > > At 10:37 PM 5/9/2002 +0000, [email protected]
> 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 protected]
> https://www1.ietf.org/mailman/listinfo/diffserv
> Archive:
> http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillis
> t.html
>
> _______________________________________________
> diffserv mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

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