Subject: [Policy] RE: FW: [Diffserv] Informal WG last call for draft-ietf-diffserv -new-terms-06.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 14 Nov 2001 17:13:51 +0100

Thanks Andrea for the detailed review
And I see we have a discussion going with some agrrements
comiung out already. Looks like we may expect one more 
revision.

Bert 

> -----Original Message-----
> From: Dan Grossman [mailto:[email-masked]]
> Sent: Wednesday, November 14, 2001 5:09 PM
> To: Andrea Westerinen
> Cc: Diffserv@Ietf. Org; Policy@Ietf. Org; Bert Wijnen (Bert)
> Subject: Re: FW: [Diffserv] Informal WG last call for
> draft-ietf-diffserv-new-terms-06.txt 
> 
> 
> Andrea,
> Thanks for the careful review.
> > Dan, I was asked to do a review of the "new-terms" draft 
> wrt PolTerm.  In
> > general, there is good correspondence, but I have a few 
> minor comments.
> > 
> > 1. In Section 2, in the second paragraph, it would be 
> helpful to reference
> > the Policy Terminology RFC XXX 
> (draft-ietf-policy-terminology-04.txt,
> > waiting in the editor's queue) explicitly, since that supports your
> > conclusions of SLAs being of a contractual nature.
> 
> Agreed.
> 
> > 
> > 2. The SLS definition in "new-terms" is a bit different 
> (more restrictive)
> > than the definition in PolTerm.  The PolTerm definition 
> tries to straddle
> > the contractual versus service/conditioning aspects of an 
> SLS.  PolTerm
> > states that an SLS ...
> >         Specifies handling of customer's traffic by a network
> >         provider. It is negotiated between a customer and the
> >         provider, and (for example) in a DiffServ environment,
> >         defines parameters such as specific Code Points and the
> >         Per-Hop-Behavior, profile characteristics and treatment of
> >         the traffic for those Code Points. An SLS is a specific SLA
> >         (a negotiated agreement) and its SLOs (the individual
> >         metrics and operational data to enforce) to guarantee
> >         quality of service for network traffic.
> > It might be valuable to mention that the "new-terms" 
> definition further
> > restricts that specified in PolTerm, for the DiffServ environment.
> 
> I'd be hesitant to alter the Diffserv definition, since this 
> was subject of a 
> great deal of working group debate.  However, some words to 
> the effect that 
> you suggest would be appropriate.
> > 
> > 3. In the last paragraph of Section 2, where you quote from 
> the PolTerm RFC,
> > could you make this a normative reference?
> 
> Ok. I'd lost track of the Polterm draft, and frankly forgot 
> to check the RFC 
> Editors queue for its status.  The way this was done 
> reflected a concern that 
> this draft would get hung up behind the Polterm draft 
> indefinitely.  Since the 
> Polterm draft is ahead, it makes perfect sense to make the 
> Polterm RFC 
> normative.
> 
> > 
> > 4. In the last sentence of Section 2, you say "Therefore, 
> the relationship
> > between an SLS and a service provisioning policy is that 
> the latter is, in
> > part, the set of rules that define the parameters and range 
> of values that
> > may be in the former."  Would it be reasonable to say "... 
> define and manage
> > to the parameters and range of values ..."?  The word 
> "define" seems too
> > restrictive.
> >
> I'm having problems parsing your proposed sentence.   How can 
> a set of rules 
> "manage to" parameters and and a range of values?  
> 
> > And, a few nits:
> > 5. There are several weird quotation marks in the Status (``work in
> > progress'' and ``1id-abstracts.txt'').
> There's some wierd character mappings in my HPUX workstation. 
>  I'll move it 
> back to a windows platform and spot clean when this goes to 
> the RFC editor.
> 
> > 
> > 6. In Section 6, there are a few typos...
> > 'Hence the imperitive was"SHOULD" rather than "SHALL"' - should be
> > "imperative" and needs a space after "was"
> oops... 
> 
> > 'An egress DS-node at the edge of one DS-domain forwards 
> packets an ingress
> > DS-node at the edge of another DS domain.' - needs a "to" 
> after "forwards
> > packets"
> 
> well spotted.
> > 
> > 7. Is there a reason for the last paragraph of Section 8 to 
> look different
> > than the previous RFC summaries?  The grammar is written to 
> correspond, but
> > the missing ":" makes the paragraph difficult to read.
> 
> Will look into, thanks.
> > 
> > Thanks for considering these.
> 
> Thanks again for the review.  
> > Andrea
> > 
> Dan
> 

_______________________________________________
Policy mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/policy