Subject: Re: [Dime] AD review of draft-ietf-dime-qos-attributes-11.txt

From: Mark Jones <[email-masked]>
Date: Tue, 2 Jun 2009 15:50:33 -0400

Hi Dan

Thanks for the detailed review. Comments inline. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Romascanu, Dan (Dan)
> Sent: May 26, 2009 10:00 AM
> To: [email-masked]
> Subject: [Dime] AD review of draft-ietf-dime-qos-attributes-11.txt
> 
> Please find below my AD review of 
> draft-ietf-dime-qos-attributes-11.txt
> 
> T are Technical comments, E are editorial. 
> 
> I believe that the document is in reasonable shape. Function of the
> responses to the review we may decide to do a revised ID or send it to
> IETF Last Call and consider the comments below as IETF LC comments. 
>  
> Thanks and Regards,
> 
> Dan
> 
> 
> 
> 
> T1. IP-Address in 4.15 and 4.16 should not include also a type AVP?
> (IPv4 and IPv6) As written the specification and examples seem to deal
> with IPv4 only. SO I miss something? 
> 

The draft is indeed intended to deal with IPv4 and IPv6. The IP-Address AVPs in the draft are of Diameter type Address and so already contain an Address-Type indicator.

> T2. Was this specification sent for review to IEEE 802.1? I 
> believe that
> it should - maybe during the IETF Last Call, especially because of the
> VLAN and priority AVPs semantics. For example one of the questions to
> ask is about the usage of the values 0 and 4095 for VLAN-IDs. These
> usually have special semantics in IEEE 802.1 headers and I 
> would suggest
> that we get expert assessment about their usage in filters. 
> 

We sought out an IEEE 802.1 expert contributor (Max Reigel) and he wrote the VLAN sections in the draft. The VLAN sections have also been reviewed by the WiMAX folks who are reusing the Classifier. However, we did not formally request a review by IEEE 802.1.

> T3. In Section 5.1 
> 
>       0: drop
>       1: shape
>       2: police
>       2: mark
> 
> Should be 3: mark I guess
> 

Agreed. This will be resolved in the next revision.

> T4. Why is not the list of actions in 5.7 (Excess-Traffic-Action)
> consistent with the list of actions in 5.1? 
> 

The coauthors are validating an approach to simplify the Action AVPs and improve consistency/readability. We will communicate a proposal shortly but do not expect these to impact any other sections of the draft.

> 
> E1. In section 3.3 the last sentence in the paragraph ('The lower the
> numerical value of Rule-Precedence AVP, the higher the rule
> precedence.') should come second in the paragraph. 
> 

Agreed. This will be resolved in the next revision.

> E2. Under fig.1 the text speaks about one Unmanaged Terminal, 
> while the
> figure represents multiple Unmanaged Terminals. 
> 

Agreed. This will be resolved in the next revision.

> E3. Section 4.1.4 s/both direction/both directions/
> 

Agreed. This will be resolved in the next revision.

> E4. The term ETH priority in 4.1.8.23, 4.1.8.24, and 4.1.8.25 is
> slightly mis-leading. There is no such thing as Ethernet 
> Priority, on an
> Ethernet there is no priority, and tagged packets are 
> prioritized in the
> routers or switches. I suggest to drop ETH from the names and to use
> either 8021 or nothing. 
> 

Agreed. We will drop the ETH- prefix in the next revision.

> E5. in Section 5.3 - Private Enterprise Number (PEN) is a 
> preferred term
> to SMI Network Management Private Enterprise Code
> 

"SMI Network Management Private Enterprise Code" was the term used in the Diameter Base RFC3588 (and bis) so we used it here for consistency. We can replace it in the next revision if the current preference is "Private Enterprise Number (PEN)".

> E6. The registry policies in the IANA considerations section should be
> expressed in terms and with reference to RFC 5226. 
> 

Agreed. The next version of the draft will add RFC5226 as a reference and replace:
    "A specification is required to add a new value to the registry."
With:
   "The definition of new values is subject to the Specification Required policy [RFC5226]."

Thanks
Mark

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 3 Jun 2009 14:47:19 +0200

Thanks, these are fine. Excepting T4 all other edits seem pretty
straight forward. I would suggest to revise the ID as soon as possible
and then send it to IETF Last Call. 

Regards,

Dan

> From: Mark Jones [mailto:[email-masked]] 
> Sent: Tuesday, June 02, 2009 10:51 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: RE: AD review of draft-ietf-dime-qos-attributes-11.txt
> 
> Hi Dan
> 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Romascanu, Dan (Dan)
> The draft is indeed intended to deal with IPv4 and IPv6. The 
> IP-Address AVPs in the draft are of Diameter type Address and 
> so already contain an Address-Type indicator.
> 
> > T2. Was this specification sent for review to IEEE 802.1? I believe 
> > that it should - maybe during the IETF Last Call, 
> especially because 
> > of the VLAN and priority AVPs semantics. For example one of the 
> > questions to ask is about the usage of the values 0 and 4095 for 
> > VLAN-IDs. These usually have special semantics in IEEE 
> 802.1 headers 
> > and I would suggest that we get expert assessment about 
> their usage in 
> > filters.
> > 
> 
> We sought out an IEEE 802.1 expert contributor (Max Reigel) 
> and he wrote the VLAN sections in the draft. The VLAN 
> sections have also been reviewed by the WiMAX folks who are 
> reusing the Classifier. However, we did not formally request 
> a review by IEEE 802.1.
> 
> > T3. In Section 5.1
> > 
> >       0: drop
> >       1: shape
> >       2: police
> >       2: mark
> > 
> The coauthors are validating an approach to simplify the 
> Action AVPs and improve consistency/readability. We will 
> communicate a proposal shortly but do not expect these to 
> impact any other sections of the draft.
> 
> > 
> > E2. Under fig.1 the text speaks about one Unmanaged Terminal, while 
> > the figure represents multiple Unmanaged Terminals.
> > 
> 
> Priority, on 
> > an Ethernet there is no priority, and tagged packets are 
> prioritized 
> > in the routers or switches. I suggest to drop ETH from the 
> names and 
> > to use either 8021 or nothing.
> > 
> 
> > E5. in Section 5.3 - Private Enterprise Number (PEN) is a preferred 
> > term to SMI Network Management Private Enterprise Code
> > 
> 
> "SMI Network Management Private Enterprise Code" was the term 
> used in the Diameter Base RFC3588 (and bis) so we used it 
> here for consistency. We can replace it in the next revision 
> if the current preference is "Private Enterprise Number (PEN)".
> 
>    "The definition of new values is subject to the 
> Specification Required policy [RFC5226]."
> 
> 
> Thanks
> Mark
>

---

From: Mark Jones <[email-masked]>
Date: Fri, 5 Jun 2009 15:06:19 -0400

Hi Dan,

The I-D has been revised and uploaded as draft-ietf-dime-qos-attributes-12. Comment T4 has been resolved as you suggested (Action and Excess-Treatment-Action AVPs have been combined in the QoS-Action AVP).

Regards
Mark

> From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
> Sent: June 3, 2009 8:47 AM
> To: Mark Jones; [email-masked]
> preferred

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 7 Jun 2009 15:13:28 +0200

Thanks, Mark. I am sending this to IETF Last Call. 

Dan

> Sent: Friday, June 05, 2009 10:06 PM
> The I-D has been revised and uploaded as 
> draft-ietf-dime-qos-attributes-12. Comment T4 has been 
> resolved as you suggested (Action and Excess-Treatment-Action 
> AVPs have been combined in the QoS-Action AVP).
> 
> Regards
> Mark
> 
> > > IP-Address AVPs in the draft are of Diameter type Address and so 
> > > already contain an Address-Type indicator.
> > > 
> > > We sought out an IEEE 802.1 expert contributor (Max 
> Reigel) and he 
> > > wrote the VLAN sections in the draft. The VLAN sections have also 
> > > been reviewed by the WiMAX folks who are reusing the Classifier. 
> > > However, we did not formally request a review by IEEE 802.1.
> > > 
> > > > T3. In Section 5.1
> > > > 
> > > >       0: drop
> > > >       1: shape
> > > >       2: police
> > > >       2: mark
> > > > 
> Action AVPs 
> > > and improve consistency/readability. We will communicate 
> a proposal 
> > > shortly but do not expect these to impact any other 
> sections of the 
> > > draft.
> > > 
> > > > 
> > > "SMI Network Management Private Enterprise Code" was the 
> term used 
> > > in the Diameter Base RFC3588 (and bis) so we used it here for 
> > > consistency. We can replace it in the next revision if 
> the current 
> > > preference is "Private Enterprise Number (PEN)".
> > >