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

[Basavaraj Patil <[e-mail]>]

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.

> - 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

>
>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. 

>
>
>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.

Thanks for reviewing and your comments on the I-D.

-Raj

>
>
>Kindly,
>Bruno Sousa
>


_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng