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

["Andrew Smith" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
Of Fred Baker
Sent: Thursday, August 29, 2002 6:35 PM
To: Kwok Ho Chan
Cc: [e-mail]; [e-mail]
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" <[e-mail]>
>>To: "Brian E Carpenter" <[e-mail]>om>, "Fred Baker" 
>><[e-mail]>isco.com>,
>>    "Chan, Kwok-Ho [BL60:470:EXCH]"<[e-mail]>
>>Cc: <[e-mail]>om>, <[e-mail]>rg>,
>>    "Dan Grossman" <[e-mail]>
>>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: [e-mail]
>>X-SMTP-RCPT-TO: [e-mail]
>>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: [e-mail]
>>  NEW:
>>    Andrew Smith
>>    Harbour Networks
>>    Jiuling Building
>>    21 North Xisanhuan Ave.
>>    Beijing, 100089, PRC
>>
>>    EMail: [e-mail]
>>
>>
>>
>>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:[e-mail]]
>>Sent: Thursday, May 30, 2002 5:56 AM
>>To: Fred Baker
>>Cc: [e-mail]; [e-mail]; 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: [e-mail], [e-mail]
>> > >Subject: Re: authors 48 hours: RFC 3289
>> > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>> > >Cc: [e-mail], [e-mail], [e-mail],
>> > >         [e-mail], [e-mail]
>> > >From: [e-mail]
>> > >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 [e-mail]  Thu May 23 16:22:59 2002
>> > >Date: Thu, 23 May 2002 23:22:45 GMT
>> > >To: [e-mail], [e-mail]
>> > >Subject: Re: authors 48 hours: RFC 3289
>> > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>> > >Cc: [e-mail], [e-mail],
>>[e-mail],
>> > >    [e-mail], [e-mail]
>> > >From: [e-mail]
>> > >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 [e-mail]  Tue May 21 09:25:15 2002
>> > > > Date: Tue, 21 May 2002 16:24:54 GMT
>> > > > To: [e-mail], [e-mail]
>> > > > Subject: Re: authors 48 hours: RFC 3289
>> > > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>> > > > Cc: [e-mail], [e-mail],
>>[e-mail],
>> > > >    [e-mail], [e-mail]
>> > > > From: [e-mail]
>> > > > 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 [e-mail]  Mon May 13 11:51:19 2002
>> > > > > Date: Mon, 13 May 2002 18:50:53 GMT
>> > > > > To: [e-mail], [e-mail]
>> > > > > Subject: Re: authors 48 hours: RFC 3289
>> > > > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>> > > > > Cc: [e-mail], [e-mail],
>> > > [e-mail],
>> > > > >    [e-mail], [e-mail]
>> > > > > From: [e-mail]
>> > > > > 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 [e-mail]  Fri May 10 01:03:56 2002
>> > > > > > X-Sender: [e-mail]
>> > > > > > X-Mailer: QUALCOMM Windows Eudora Version 5.1
>> > > > > > Date: Fri, 10 May 2002 16:03:24 +0800
>> > > > > > To: [e-mail]
>> > > > > > From: Fred Baker <[e-mail]>
>> > > > > > Subject: Re: authors 48 hours: RFC 3289
>> > > > > >   <draft-ietf-diffserv-mib-16.txt> NOW AVAILABLE
>> > > > > > Cc: [e-mail], [e-mail],
>> > > > > >    [e-mail], [e-mail],
[e-mail],
>> > > > > >    [e-mail]
>> > > > > > Mime-Version: 1.0
>> > > > > > X-AntiVirus: scanned by AMaViS 0.2.1
>> > > > > >
>> > > > > > At 10:37 PM 5/9/2002 +0000, [e-mail]
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: [phone]
>>|
>> > > > > >   | if all possible objections must| fax:   [phone]
>>|
>> > > > > >   | be first overcome.             |
>>|
>> > > > > >   |     Dr. Johnson, Rasselas, 1759|
>>|
>> > > > > >
>>/=====================================================================
/
>> > > > > >
>> > > > >
>> > > >
>> > >
>> > >
>> > >----- End Included Message -----
>

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


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