[16NG] Re: Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2]

Thanks Raj for taking into account my comments.

Basavaraj Patil wrote:
> Comments by Bruno Sousa:
>
>   
>> Here is my contribution to the draft-ietf-16ng-ipv6-over-ipv6cs-04,
>> many of the issues I'm pointing come from the previous version of this
>> draft.
>>
>> 1) Typos (besides the ones pointed by Junghoon Jee)
>> - inclide (page 5) --> include
>> - service specific or service-specific (page 5 and others) I think we
>> should be coherent.
>> - enacapsulated (page 7) --> encapsulated
>> - specfic (page 7, section 4.1) --> specific
>> - sucesful (page 10, section 6.2 and page 17 appendix C) -->
>> successful
>>     
>
> Could not find this typo.
>   
Strange, but better that way!
>   
>> - succesfull (page 10, section 6.2) --> successful
>> - Hader (page 11, section 6.3) --> Header
>>
>>     
>
> Fixed the rest of the typos.
>
>   
>> 2) Terminology (section 3 and section 5).
>> I'm questioning myself why only the definition of the ASN?
>> For instance, important terms, used through out the memo are IPv6 link,
>> L2 link.
>> I think these ones should also be clarified from the beginning.
>>     
>
> The intent is to use common terminology and ASN is the only term that
> is specific to this document. The rest of the terms are intended to be
> included in the next rev of the 16NG PS I-D. The terminology proposed
> for inclusion in the PS I-D is in the email:
> http://www1.ietf.org/mail-archive/web/16ng/current/msg00291.html
>   
Ok. I'm clarified!
>   
>> I agree with the term ASN here, nevertheless it does not appear cited on
>> the document,
>> with the exception of the appendixes A and C.
>> I think it is important to refer it on the section 5,
>> the generic network architecture, when talking on the access network.
>>     
>
> If you were to look back to rev 2 of this I-D, you will see the WiMAX
> specifics being a part of the normative part of the I-D. However based
> on the WG objectives and the goal for this I-D, it was decided that
> the draft would be applicable to a generic 802.16 network and not just
> WiMAX. Hence the WiMAX specific parts are now in an appendix. Maybe I
> could even move the term ASN to the appendix.
> Adding WiMAX specific text in the main body of the I-D is not an
> option. 
>   
I agree with you. It's better to have the draft applied to a generic .16 
network, then a WiMAX network.
Probably the idea to move the term ASN to the appendix is not a bad 
idea. Since it comes from WiMAX spec.
>   
>> 3) IPv6 link (section 6)
>> " A link is bounded by routers that decrement TTL."
>> If we are talking about IPv6, shouldn't we refer Hop Limit instead of TTL?!
>>
>>     
>
> Yes, I agree. Fixed it.
>
>   
>> 4) IPv6 link in 802.16
>> "
>>   In 802.16, there exists an L2 Transport Connection between an MS and
>>   a BS which is used to transport user data, i.e IPv6 packets in this
>>   case.  A Transport Connection is represented by a CID (Connection
>>   Identifier) and multiple Transport Connections can exist between an
>>   MS and BS.
>> "
>> I think the first sentence is somehow contradictory with the rest of the
>> paragraph.
>> It is possible to have more then one transport connection between MS and BS.
>> These transport connections are defined on the MAC layer (L2),
>> so why refer "there exists an L2 Transport Connection?!"
>>
>> (If my thoughts are correct) I propose to change the first sentence to:
>>
>>  In 802.16, the Transport Connection between an MS and a BS is used
>>  to transport user data, i.e. IPv6 packets in this case.
>>     
>
> Agreed. Incorporated the proposed sentence.
>
>   
>> 5) Maximum transmission unit in 802.16 (section 6.3)
>>
>> "
>>   The 802.16 MAC header is a 6 byte header followed by the payload and
>>   a 4 byte CRC which covers the whole PDU (Protocol Data Unit).  The
>>   length of the PDU is indicated by the Len parameter in the Generic
>>   MAC HDR. 
>> "
>> As reading, we may think that the payload and the CRC are always present
>> on the MAC frames.
>> They are not included in all messages. So I suggest to rewrite this,
>> starting with:
>>
>>  The 802.16 MAC PDU (Protocol Data Unit) is composed by
>>  a 6 byte header followed by an optional payload and
>>  an optional CRC covering the header and the payload.
>>
>>     
>
> Okay... I changed the text in the I-D as proposed.
>
>   
>> This introduction has also the propose to clarify the covering of the
>> CRC (header + payload)
>> and not the whole PDU (since this one can include the CRC).
>>
>>
>> 6) IPv6 prefix assignment (section 7)
>> I suggest to add a reference to the RFC2461, to clarify where the
>> on-link flag is defined:
>>
>> The prefixes are advertised with the on-link (L-bit) flag set as
>> specified in RFC2461.
>>     
>
> Okay. Done.
>
>   
>> This section starts with:
>> "
>>  Each MS can be considered to be on a separate subnet as a result of
>> the point-to-point connection.
>> "
>> In the middle there is a sentence:
>> "
>>  Each MS MUST be considered to be on a separate subnet as a result of
>> the point-to-point connection.
>> "
>> Shouldn't here we have a consensus also?
>> (probably this is an issue related with RFC2119) So can or MUST?!
>> And the sentences aren't repeating themselves in the same section?
>>
>>     
>
> Agree. Fixed it.
>
>   
>> 7) Appendix D
>> This section introduces the SDU size proposed by the WiMAX forum.
>> I just want to point that there is no a relation with the SDU and
>> the IPv6 payload spoken along the document.
>> Shouldn't this be clarified?!
>>     
>
> I dont think that is necessary. Within the main body of the text it is
> clear what the MAX IPv6 payload size can be. And in the appendix, the
> I-D is making a recomendation that the MAX MTU be 1400 bytes by
> default but obviously can be anything between 1280 and 1500.
>   
Ok. I agree with you.

Kindly,
Bruno Sousa