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

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 19 May 2013 20:00:04 +0000

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.

---

From: GangChen <[email-masked]>
Date: Thu, 23 May 2013 14:29:28 +0800

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.

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?

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.

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

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.

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)

5)section 2.10

One typo maybe there. "me" should be corrected.

These options me be useful for cellular
                      ^^
6)section 2.11

DNS server address can also be provisioned through PCO option. Should
it be mentioned in this section?

Best Regards

Gang

2013/5/20, Fred Baker (fred) <[email-masked]>:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 23 May 2013 10:15:45 +0300

Hi Gang,

Thanks for the review. See my initial comments inline.

> helpful if the draft can clarify the usages of NS/NA to a mobile

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?

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

> assign a proper section number.

Ok. I'll give this a though.

> "advertised/configured/assigned" to avoid the ambiguity with DHCP-PD

Right. This was already agreed after Ales' review.

> handset seems like a mobile station, which is comprised of MT and TE.

Ok. I'll draft something around this.

> guess we may could align the statement(even that not have normative

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.

> These options me be useful for cellular

Ack.

> 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

---

From: GangChen <[email-masked]>
Date: Thu, 23 May 2013 16:10:04 +0800

> confirmation from the upper layers. I do not see how this leads to possible

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