Subject: Re: [netext] WGLC for I-D: draft-ietf-netext-pmip6-qos

From: "Charles E. Perkins" <[email-masked]>
Date: Sat, 01 Feb 2014 18:55:14 -0800

Hello folks,

I didn't have time for a complete review, but I did make
the following notes.

==================================================

Suggestion: use Kb/sec or at least bytes/sec as the units.
With 802.11ac, we are already over the limit of what 32 bits can
measure for transmission rates measured in bits/sec.

Terminology should be alphabetized.

The term "sub-options" is never used.

Should use abbreviations LMA and MAG most of the time
after introducing them and citing RFC 5213.  5213 uses them
most of the time, why not this document?

What about Quality of Service Attribute types 12 through 254
in section 4.2?

In section 4.2.5.  Allocation and Retention Priority,
it is not clear why Priority-Level, Preemption-Capability,
and Preemption-Vulnerability are defined to take up 64
bits, when all the values that have been defined would
easily fit within less than half of the Reserved field.
Perhaps some justification is indicated for this design.

Worse yet, there is absolutely no hint to the implementer
about how the features are to be used.  If there is some
other document available for this purpose, it should be
cited.  Otherwise, some additional description is required
in this document.

In section 4.2.10.  QoS Traffic Selector,
the format of the Traffic Selector is *NOT* opaque.
It follows the specifications cited in the previous
paragraph, right??

=============================================================

I made a few editorial improvements, which can be seen as shown in
the attached file. Sorry, for some reason I can't get rfcdiff to work
right now.

Regards,
Charlie P.

On 1/30/2014 1:24 AM, Ryuji Wakikawa wrote:
> Raj,
>
> I don’t see any issue in this version.
> The draft is ready for publication.
>
> thanks
> ryuji
>
> 2014/01/23 午前8:33、Basavaraj Patil <[email-masked]> のメール：
>
>> Hello,
>>
>> This is the WG last call for the I-D: Quality of Service Option for
>> Proxy Mobile IPv6 <draft-ietf-netext-pmip6-qos-10.txt>
>>
>> Abstract
>>
>>     This specification defines a new mobility option, the Quality of
>>     Service (QoS) option, for Proxy Mobile IPv6.  This option can be used
>>     by the local mobility anchor and the mobile access gateway for
>>     negotiating Quality of Service parameters for a mobile node's IP
>>     flows.  The negotiated QoS parameters can be used for QoS policing
>>     and marking of packets to enforce QoS differentiation on the path
>>     between the local mobility anchor and the mobile access gateway.
>>     Furthermore, making QoS parameters available on the mobile access
>>     gateway enables mapping of these parameters to QoS rules that are
>>     specific to the access technology and allows those rules to be
>>     enforced on the access network using access technology specific
>>     approaches.
>>
>> The I-D is intended for publication as a proposed standard.
>> The deadline for receiving reviews, comments, feedback is February 7th,
>> 2014.
>>
>> Please send your review comments to the mailing list, chairs or,
>> authors.
>>
>> -Chairs
>>
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

-- 
Regards,
Charlie P.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 3 Feb 2014 14:52:47 +0000

Hi Charlie,

Thanks for the review and for the proposed changes to the text. Very much
appreciated.

We (Authors) have discussed your comments and here is our response to your
comments.

>I didn't have time for a complete review, but I did make

This is a reasonable suggestion. We had a discussion on this with Georgios
before.
With 32-bit number we can represent up to 4Gb and we thought we are
covered for any of the current access technologies that are supported
today including 802.11ac.
Also, given that this is also aligned with 3GPP, we chose to keep the
units as "bps".

>Terminology should be alphabetized.

Ok.

>The term "sub-options" is never used.

Will fix it.

>most of the time, why not this document?

When we were writing RFC5213/RFC5844, we looked at RFC3344 and RFC3775
carefully and followed the same conventions. That pretty much continued
and all the PMIP specs followed the same conventions. I do agree, this
makes the doc lengthy, but keeps it consistent. If you are not too keen on
this, we prefer to keep this consistent with the other specs.

>What about Quality of Service Attribute types 12 through 254

Thanks. Will add an explicit note that those values are Reserved.

>Perhaps some justification is indicated for this design.

OK. We got the same review comment earlier from one other reviewer. We
will change the format to the following.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |   Reserved    |   PL  |PC |PV |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

PL: Priority Level 1-15 (4bits)
PC: Pre-emption Capability 0/1 (2 bits; 1 bit is a spare as in GTP format)
PV: Pre-emption Vulnerability 0/1 (same as the above)

>cited.  Otherwise, some additional description is required

Ack. Will craft some text.

>It follows the specifications cited in the previous

Ok. Will fix it.

Ack. Will implement those changes.

Thanks for the review. This really helps.

Regards
Sri

>> I donâ€™t see any issue in this version.
>> 2014/01/23 åˆå‰8:33ã€Basavaraj Patil <[email-masked]>
>>ã®ãƒ¡ãƒ¼ãƒ«ï¼š
>>
>>> Hello,
>>>