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
- [16NG] Fw: I-D ACTION:draft-madanapalli-16ng-ipv4… Daniel Park
- Re: [16NG] Fw: I-D ACTION:draft-madanapalli-16ng-… Bruno Miguel Sousa
- RE: [16NG] Fw: I-DACTION:draft-madanapalli-16ng-i… Narvaez, Paolo (Paolo)
- Re: [16NG] Fw: I-D ACTION:draft-madanapalli-16ng-… Syam Madanapalli
- Re: [16NG] Fw: I-DACTION:draft-madanapalli-16ng-i… Syam Madanapalli