Re: [16NG] Fw: I-D ACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt

Bruno Miguel Sousa <bmsousa@dei.uc.pt> Fri, 09 February 2007 11:39 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFU64-0002LQ-MN; Fri, 09 Feb 2007 06:39:20 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFU63-0002LJ-51 for 16ng@ietf.org; Fri, 09 Feb 2007 06:39:19 -0500
Received: from smtp2.dei.uc.pt ([193.137.203.231] helo=smtp.dei.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFU61-0001Qz-M9 for 16ng@ietf.org; Fri, 09 Feb 2007 06:39:19 -0500
Received: from [10.3.1.109] (din-cisuc109.dei.uc.pt [10.3.1.109]) (authenticated bits=0) by smtp.dei.uc.pt (8.13.8/8.13.8) with ESMTP id l19BaSiO021601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Feb 2007 11:36:31 GMT
Message-ID: <45CC5CBB.4040103@dei.uc.pt>
Date: Fri, 09 Feb 2007 11:36:27 +0000
From: Bruno Miguel Sousa <bmsousa@dei.uc.pt>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: 16ng@ietf.org
Subject: Re: [16NG] Fw: I-D ACTION:draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt
References: <004f01c74bdf$92a69790$8046fea9@your655e9d6f61>
In-Reply-To: <004f01c74bdf$92a69790$8046fea9@your655e9d6f61>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information
X-FCTUC-DEI-SIC-MailScanner: Found to be clean
X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-51.8, required 3, autolearn=not spam, ALL_TRUSTED -1.80, L_SMTP_AUTH -50.00)
X-FCTUC-DEI-SIC-MailScanner-From: bmsousa@dei.uc.pt
X-Spam-Status: No
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Cc:
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Errors-To: 16ng-bounces@ietf.org

Dears


Here is my contribution to this draft.

General comments:

I think the text is well written and easy to understand.
The overall operations of IPv4 (address assignment, multicast, ...)
are presented in the document.


Specific comments:

1)
The  sentences in the abstract:
"
   access.  IEEE has specified several service specific convergence
   sublayers (CS) for 802.16 which are used by upper layer protocols.
   The ATM CS and Packet CS are the two main service-specific
   convergence sublayers and these are a part of the 802.16 MAC which
   the upper layers interface to. 
"
I suggest to rewrite since 802.16 defines two service specific 
convergence sublayers.
The term several does not seem correct imho. The sentences present some 
repetition
when referring to upper layers. My suggestion:

IEEE has specified the service specific convergence sublayers (CS)
in the 802.16 MAC to be used by upper layer protocols.
The ATM CS and the Packet CS represent the two main
service specific convergence sublayers for 802.16.

2)
Some minor corrections.
"
   Unit (MTU) and address assignment procedures for transmitting _IPv4_
   packets over IP Convergence Sublayer (IPCS) of IEEE 802.16.  This
"

"
   be sent to MSs before they acquire IP addresses.  The figure below
   illustrates the network _architecture_.
"

IPv4 and not IPv6
"
   _IPv4_ packets are transmitted in Generic 802.16 MAC frames as shown in
   the following figure.
"

remove: is
"
   must be established.  This connection _is_ consists of 802.16 MAC
   transport connection between MS and BS and an L2 tunnel between BS
   and AR. 
"

remove being
"
   connection to the AR.  BS reconstructs the payload header if the PHS
   is in use before _being_ the packet is tunneled to the AR. 
"


3)
Section Maximum Transmission Unit
The value of 2038 is justified in the text.
In my opinion it is important to add references to justify the values 
1920 and 576.

For instance for the 576 value I would add a reference to the RFC 1122
to present the effective MTU to receive.



Kindly,
Bruno Sousa


Daniel Park wrote:
> IPv4CS document is now available at:
> http://www.ietf.org/internet-drafts/draft-madanapalli-16ng-ipv4-over-802-dot-16-ipcs-00.txt
>
> Daniel (Soohong Daniel Park)
> Mobile Convergence Laboratory, SAMSUNG Electronics.
>
> _______________________________________________
> 16NG mailing list
> 16NG@ietf.org
> https://www1.ietf.org/mailman/listinfo/16ng
>
>   


_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng