Re: [v6ops] draft-ietf-v6ops-rfc3316bis WGLC

[GangChen <[e-mail]>]

2013/5/23, Jouni Korhonen <[e-mail]>:
>
> Hi Gang,
>
> Thanks for the review. See my initial comments inline.
>
> On May 23, 2013, at 9:29 AM, GangChen <[e-mail]> wrote:
>
>> wg,
>>
>> The draft contains useful discussions to help shaping IPv6 profile on
>> mobile phone. I support WGLC. The below comments are only for
>> discussion/consult/clarification.
>>
>> 1) section 2.2 Neighbor Discovery
>>
>> Once we discuss NS/NA, I'm struggling with the usage of those two
>> messages. The draft has very good description about notes on
>> point-to-point interface. The texts teach me that neighbor discovery
>> and NUD may be unnecessary, beacause the mobile phone doesn't rely on
>> NS/NA to discover neighbor and NUD is desirable to be achieved through
>> uppper layer guarantee. In some degree, audience may have impressions
>> mobile phones can eliminate NS/NA to reduce additional signalling. I'm
>> not sure if we could give those recommendations. Otherwise, it maybe
>> helpful if the draft can clarify the usages of NS/NA to a mobile
>> phone.
>
> So you want even more NS/NA text? What else needs to be added? So far we
> got the following:
>
>  o no address resolution.. due no link-layer addresses
>  o cellular host must support NUD (which then includes both
>    upper layer mechanisms and the unicast NS/NA one)
>  o DAD is not needed (and can be turned off using RFC4861 configuration
>    mechanisms) but causes no harm either if done.
>
> You can skip periodic unicast NS/NA NUD whenever you get the reachability
> confirmation from the upper layers. I do not see how this leads to possible
> elimination of NS/NA?

I don't see the necessity to eliminate NS/NS messages as well.
Whereas, it may desirable to mitigate the messages transmission on the
air. The draft may clarify:
1. no address resolution(already in the section)
2. no DAD(shift the texts to the section)
3. restrain periodic NUD if there is upper-layer indication available
(clarify the point in the section)

BRs

Gang

>> In regard to NUD using upper layer protocol, I have observed some apps
>> normally do keepalive/beacon message to fresh the link. Could those
>> messages be a tool to maintain NUD?
>
> Yes.. assuming the upper layer traffic is there all the time and
> bidirectional. That does not justify removal of explicit NUD using
> unicast NS/NA.
>
>> 2) I guess both section 2.3 and 2.4 cover SLACC. Reading the contents,
>> I feel section 2.4 seems a sub-section of 2.3. It may be good to
>> assign a proper section number.
>
> Ok. I'll give this a though.
>
>> In section 2.4, there is texts "as each delegated prefix is unique".
>> May I suggest to reword "delegated" to
>> "advertised/configured/assigned" to avoid the ambiguity with DHCP-PD
>
> Right. This was already agreed after Ales' review.
>
>> 3) section 2.5
>> It described the case of split mobile station. I guess it may help if
>> the draft adds a example for MT. USB dongle can be a MT.You may add
>> "(MT, e.g., a USB dongle)", like you did for TE. That also reminds me
>> "a mobile phone handset" used in the section of Abbreviations. Should
>> it be proper to use a USB dongle for the example. A mobile phone
>> handset seems like a mobile station, which is comprised of MT and TE.
>
> Ok. I'll draft something around this.
>
>>
>> 4)section 2.7
>>
>> If i remember coorectly, 3GPP label Privacy Extensions as the level of
>> "MAY". This section use "should" and "may" in the same paragraph. I
>> guess we may could align the statement(even that not have normative
>> meaning)
>
> Right. 3GPP has both "may" and "can" for privacy extensions, depending
> on the specification (i.e. 23401 say may use mechanism defined in 23221,
> which then says can use rfc4941). OK to lower the requirement language
> here.
>
>> 5)section 2.10
>>
>> One typo maybe there. "me" should be corrected.
>>
>> These options me be useful for cellular
>>                      ^^
>
> Ack.
>
>> 6)section 2.11
>>
>> DNS server address can also be provisioned through PCO option. Should
>> it be mentioned in this section?
>
> We say that the host may learn the DNS server address by lower layer
> means.. the IP stack has no idea of PCOs and we have on purpose kept
> the term PCO out of the document.
>
> Thanks.
>
> - Jouni
>
>
>
>>
>> Best Regards
>>
>> Gang
>>
>>
>> 2013/5/20, Fred Baker (fred) <[e-mail]>:
>>> The working group last call for this draft-ietf-v6ops-rfc3316bis
>>> announced
>>> last week continues for another week. Please feel free to comment on it.
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>