Subject: SLAAC/DHCPv6 addr-conf operational gaps

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 26 Feb 2013 07:14:27 +0000

Hi, 6man & v6ops

We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.

As we know there are several flags in RA messages regarding with the host configuration behavior, which are A (Autonomous) flag, M (Managed) flag, and O (Otherconfig) flag.
For some reason, the host behavior of interpreting the flags is ambiguous in the standard (mainly RFC4862). I presented a draft discussing M flag behavior in 6man @ietf84, and there were some feedbacks arguing the same issue. This draft analyzed all the three flags, and provided test result of current implementations, it showed the behavior of different mainstream desktop OSes have varied. The ambiguous and variation might cause operational problems, such as renumbering (used to discuss in 6renum WG and been documented in the WG drafts), cold start problem, and management gaps .etc.

Your review and comments would be appreciated very much. 

All the best,
Bing

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, February 25, 2013 5:52 PM
> To: Liubing (Leo)
> Cc: [email-masked]
> Subject: New Version Notification for
> draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> 
> 
> A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> has been successfully submitted by Bing Liu and posted to the
> IETF repository.
> 
> Filename:	 draft-liu-bonica-dhcpv6-slaac-problem
> Revision:	 01
> Title:		 DHCPv6/SLAAC Address Configuration Interaction Problem
> Statement
> Creation date:	 2013-02-25
> Group:		 Individual Submission
> Number of pages: 12
> URL:
> http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-problem-
> 01.txt
> Status:
> http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem
> Htmlized:
> http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-liu-bonica-dhcpv6-slaac-problem-01
> 
> Abstract:
>    This document analyzes the host behavior of DHCPv6/SLAAC interaction
>    issue. It reviews the standard definition of the host behaviors and
>    provides the test results of current mainstream implementations. Some
>    potential operational gaps of the interaction are also described.
> 
> 
> 
> 
> The IETF Secretariat

---

From: Arturo Servin <[email-masked]>
Date: Tue, 26 Feb 2013 17:28:36 +0800

Dear authors,

	Very interesting document and very valuable to document the current
behavior of the A, M and O flags (that have caused some headaches to
some including myself when troubleshooting IPv6).

	I see that has been submitted as "Proposed Standard" but I failed to
find what you are proposing.

	Would it better to be submitted as "Informational" and then look how to
indicate the correct behavior of the flags? or just as "Informational"?

Regards.
as

On 26/02/2013 15:14, Liubing (Leo) wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 26 Feb 2013 09:53:02 +0000

Hi, Arturo and all

That was my mistake. I derived this draft from a template and forgot to change it. 
It should be "Informational", thanks for finding this bug.

B.R.
Bing

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Arturo Servin
> Sent: Tuesday, February 26, 2013 5:29 PM
> To: [email-masked]
> Subject: Re: SLAAC/DHCPv6 addr-conf operational gaps
> 
> Dear authors,
> 
> > As we know there are several flags in RA messages regarding with the host
> configuration behavior, which are A (Autonomous) flag, M (Managed) flag,
> and O (Otherconfig) flag.
> > For some reason, the host behavior of interpreting the flags is ambiguous
> in the standard (mainly RFC4862). I presented a draft discussing M flag
> behavior in 6man @ietf84, and there were some feedbacks arguing the same
> issue. This draft analyzed all the three flags, and provided test result of
> current implementations, it showed the behavior of different mainstream
> desktop OSes have varied. The ambiguous and variation might cause
> operational problems, such as renumbering (used to discuss in 6renum WG
> and been documented in the WG drafts), cold start problem, and
> management gaps .etc.
> >

---

From: Arturo Servin <[email-masked]>
Date: Tue, 26 Feb 2013 18:09:50 +0800

Good.

	Regarding a possible next step. Are you guys planning to propose a
"correct" behavior of the flags? It may be worth to try.

Regards,
as

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 26 Feb 2013 08:28:22 -0500

Bing,

I as able to review the draft and agree this needs to be documented and
discussed.  I have had many frustrating nights dealing with my multiple
OSs at home and figuring out what behaviour I was trying to expect when
changing the upstream router's settings (M/O/A).

I think the problem space discussion within the draft should be enough to
have a preliminary discussion in the WG.  I know there have been issues in
the past with various opinions on what the M/O bits (for example) should
or should not be used for - or how authoritative they should be.

If the groups can agree that there is in fact a problem, then I would
agree with Arturo that we can have a constructive follow-up
draft/discussion on the corrective action.

Lets get past step 1 and agree there is an issue (or not); then go down
the more sensitive path of agreeing to the corrective action.

Thanks for putting this together.

Regards,

Victor Kuarsingh

On 2013-02-26 2:14 AM, "Liubing (Leo)" <[email-masked]> wrote:

>issue. This draft analyzed all the three flags, and provided test result
>of current implementations, it showed the behavior of different
>mainstream desktop OSes have varied. The ambiguous and variation might
>cause operational problems, such as renumbering (used to discuss in
>6renum WG and been documented in the WG drafts), cold start problem, and
>management gaps .etc.
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 26 Feb 2013 18:02:04 +0000

This is interesting. Thanks for doing these tests and submitting the results.

When testing the switching behavior, I'm curious for the " SLAAC-only host receiving A=0&M=1 " case as to what you set the Preferred Lifetime to, when you set A=0. I'm guessing Preferred Lifetime > 0?
Since RFC 4862 states "A preferred address becomes deprecated when its preferred lifetime expires", I would only have expected a host to deprecate a SLAAC-obtained address if the RA message set Preferred Lifetime to zero. It sounds like the case where the RA is changed from A=1 and Preferred Lifetime > 0 to A=0 and Preferred Lifetime > 0 is ambiguous. I'm not quite sure what the use case is for separating the A flag and Preferred Lifetime settings. Did you also run the test by changing to A=0 and Preferred Lifetime = 0? I would hope that there would be consistent behavior in that case.

For the "DHCPv6-only host receiving A=1&M=0" case, I'm curious as to whether you also tried sending a DHCPv6 Reconfigure message and forcing the host to release the DHCPv6-assigned address; and send A=1&M=0 in an RA directly after sending the Reconfigure. I'm not sure what the use case is for trying to force the release or deprecation of a DHCPv6 address via flags in an RA message. Once a host has a DHCPv6 address, I would have expected its subsequent behavior relating to that address and that DHCPv6 server to be governed by RFC 3315. The Linux/MAC behavior appears consistent with what I would have expected. The Windows 7 does not. I'm unaware of even a "hint" that suggests RA flags have a role in governing DHCPv6 behavior once RFC 3315 is in play.
Barbara

> Liubing (Leo)
> Sent: Tuesday, February 26, 2013 2:14 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: SLAAC/DHCPv6 addr-conf operational gaps
> 
> Hi, 6man & v6ops
> 
> For some reason, the host behavior of interpreting the flags is ambiguous in
> the standard (mainly RFC4862). I presented a draft discussing M flag behavior
> in 6man @ietf84, and there were some feedbacks arguing the same issue.
> This draft analyzed all the three flags, and provided test result of current
> implementations, it showed the behavior of different mainstream desktop
> OSes have varied. The ambiguous and variation might cause operational
> problems, such as renumbering (used to discuss in 6renum WG and been
> documented in the WG drafts), cold start problem, and management gaps
> .etc.
> 
> > has been successfully submitted by Bing Liu and posted to the IETF
> > repository.
> >

---

From: Mark Smith <[email-masked]>
Date: Tue, 26 Feb 2013 12:34:33 -0800 (PST)

Hi,

I've had a quick read though, I'll try to do a thorough one in the next week or so.

Thanks for writing this, I've been thinking about doing something similar over the last few months since, IIRC, I heard about Windows 7 invalidating IPv6 addresses learned via DHCPv6 when SLAAC was enabled and DHCPv6 was disabled on a link.

A few thoughts I've had which may be useful -

Firstly, I came to realise that the mistake being made by Windows 7 was the assumption that the aging of the assigned IPv6 addresses was tightly coupled to the DHCPv6 session state, meaning that if DHCPv6 went away, so would the assigned addresses. This is generally the way DHCPv4 has worked. However, in IPv6/DHCPv6, it seems the address lifetime values in the IA_NA are not coupled to the T1 and T2 times, so if DHCPv6 goes away (perhaps because the M bit was switched off in a latter RA), the configured IPv6 addresses should be left to age out as per their preferred and valid lifetimes.

The other thing I noticed was that the M RA flag and the PIO A flags aren't mutually exclusive - I couldn't find any text in RFC4861 that says if the M bit is switched on, the PIO A flags must be switched off and vice-versa. So that suggests that the DHCPv6 and SLAAC can co-exist, and I think that is quite reasonable if you're transitioning a link from DHCPv6 to SLAAC address configuration or vice-versa.

Thinking about it more, I came realise that DHCPv6 and SLAAC are _address configuration_ methods, but are not address aging methods - IPv6 takes care of address aging via it's preferred and valid aging mechanisms, regardless of the address configuration method. Static assignment is also just an address configuration method, although typically the addresses don't age out, but only because they're normally set to infinity. Perhaps in the future there might be other address configuration methods.

I didn't seem to be able to find an RFC that made it clear that address configuration and address aging are quite separate, so perhaps this ID could be the one.

Regarding this text:

'For the host behavior, there is an explicit rule in the SLAAC specification [RFC4862]: "If the Autonomous flag is not set, silently ignore the Prefix Information option."'

I think RFC5942, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes." updates that advice, as the PIO option is used to indicates which prefix/range of addresses are on-link, via the PIO O bit, even if the PIO A bit is switched off.

Best regards,
Mark.

>________________________________
> From: Liubing (Leo) <[email-masked]>
>To: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, 26 February 2013 6:14 PM

---

From: Karl Auer <[email-masked]>
Date: Wed, 27 Feb 2013 08:20:10 +1100

> We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.

Some time ago I wrote quite a long reply on this list about it. I've
changed my mind on a few points, and here's my current thinking, for
what it's worth. I think an update to the relevant RFCs (4861?) should
be written that makes the following unambiguous statements about the
flags.

1: The O and M flags are independent of each other.

The O flag implies nothing about address configuration, and the M flag
implies nothing about whether ancillary information is available.
However, DHCPv6 itself will supply ancillary information along with
address information, so a host doing stateful DHCPv6 SHOULD accept and
use the information returned with addresses rather than do additional,
separate stateless DHCPv6 queries. If a host accepts the ancillary
information in response to a stateful DHCPv6 query, then the valid and
preferred lifetimes of the ancillary data MUST be set to those of the
received address(es).

2: A valid RA can have both the O and the M flags set.

3: The M flag, if set, means that a DHCPv6 service is available for
stateful automatic address configuration by the hosts on the link. The
presence of a set M flag makes no statement about whether hosts should
use the service. The absence of a set M flag makes no statement about
whether a DHCPv6 service is available.

A host SHOULD perform stateful DHCPv6 address configuration if it sees a
set M flag in an RA. However, it SHOULD NOT do so if it already has one
or more addresses on the receiving interface that were acquired via
stateful DHCPv6.

A host MAY attempt to obtain addresses via DHCPv6 without seeing an RA
at all. Rationale: The host may be in a network containing a DHCPv6
server, but no router.

A host MAY attempt to obtain addresses via DHCPv6 even if it sees an RA
with no M flag set. Rationale: There may be multiple routers on a link,
not all of which are advertising an M flag.

4: The O flag, if set, means that a stateless DHCPv6 service is
available. The presence of a set O flag makes no statement about whether
hosts should use the service. The absence of a set O flag makes no
statement about whether a DHCPv6 service is available.

A host SHOULD perform a stateless DHCPv6 query when it sees a set O flag
in an RA. However, it SHOULD NOT do so if it has already acquired
information via stateless DHCPv6 and the preferred lifetime of that
information has not yet expired.

A host MAY attempt stateless DHCPv6 without seeing an RA at all.
Rationale: The host may be in a network containing a DHCPv6 server, but
no router.

A host MAY attempt stateless DHCPv6 even if it sees an RA with no O flag
set. Rationale: There may be multiple routers on a link, not all of
which are advertising an O flag.

5: Once configured, a DHCPv6 address SHOULD NOT be deconfigured until
its valid lifetime has expired.

Also, an address MUST NOT be deconfigured solely because an RA is seen
with no set M flag. However, a host MAY reduce the valid lifetime of an
address to two hours if an RA is seen with no set M flag. Rationale:
There may be multiple routers in a network, not all of which are
advertising a set M flag. Deconfiguring an address based solely on an RA
with no set M flag could result in an address "flap", where one RA
causes the address to be configured, the next causes it to be
deconfigured. Furthermore, the "contract" between the DHCPv6 server and
the host has stipulated that the host may use the address for the extent
of the stated valid lifetime. Reducing the valid lifetime to no less
than two hours prevents a trivial denial of service attack while
permitting an administrator to renumber more quickly if necessary.

6: Information obtained via stateless DHCPv6 SHOULD be considered valid
until the valid lifetime of the address(es) to which it pertains expires
OR the valid lifetime of the ancillary information expires OR until
another successful stateless DHCP query is performed for the relevant
address(es), whichever comes first.

Also, information obtained via stateless DHCPv6 MUST NOT be discarded
solely because an RA is seen with no set O flag. Rationale: There may be
multiple routers in a network, not all of which are advertising a set O
flag. Discarding information based on an RA with no set O flag could
result in the information "flapping", where one RA causes the
information to be obtained, the next causes it to be discarded.
Furthermore, the "contract" between the DHCPv6 server and the host has
stipulated that the host may use the information for the extent of the
stated valid lifetime.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 27 Feb 2013 03:07:02 +0000

Hi, Victor & Arturo

Thanks for the comments.
We do plan to write a draft of subsequence solution. But as Victor said, step 1 is to see if the groups agree there are problems. So hope more people could feed back on this.

Many thanks.

B.R.
Bing

> From: Victor Kuarsingh [mailto:[email-masked]]
> Sent: Tuesday, February 26, 2013 9:28 PM
> To: Liubing (Leo); [email-masked]; [email-masked]
> Cc: [email-masked]
> >>http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-proble
> m
> >>-
> >> 01.txt
> >> Status:

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 27 Feb 2013 03:36:30 +0000

This has been a historic issue. Although there was discussions several times, the specification still remain ambiguous. The differences in OS implementations are good proof that we need to do something in IETF.

This document has well described the current standard status and reality operational issues. However, for me, this document fails to suggest what we may do to fix this issue, neither in the gap section or as conclusion. It is clear that part of RFC4862 needs to be updated to make the configuration behavior clear and consistent. For that, this document fails to give a feasible proposal. Maybe, the authors has saved that for another follow up standard track document.

Best regards,

Sheng

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Liubing (Leo)
>Sent: Tuesday, February 26, 2013 3:14 PM
>Subject: [renum] SLAAC/DHCPv6 addr-conf operational gaps
>
>Hi, 6man & v6ops
>
>documented in the WG drafts), cold start problem, and management
>gaps .etc.
>
>_______________________________________________
>renum mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/renum

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 27 Feb 2013 04:01:19 +0000

Hi, Barbara

Thanks for your comments. Please see replies inline.

> From: STARK, BARBARA H [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2013 2:02 AM
> Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
> 
> When testing the switching behavior, I'm curious for the " SLAAC-only host
> receiving A=0&M=1 " case as to what you set the Preferred Lifetime to,
> when you set A=0. I'm guessing Preferred Lifetime > 0?

[Bing] Yes, we just leave the Preferred Lifetime as default, it should be > 0

> Since RFC 4862 states "A preferred address becomes deprecated when its
> preferred lifetime expires", I would only have expected a host to deprecate a
> SLAAC-obtained address if the RA message set Preferred Lifetime to zero. It
> sounds like the case where the RA is changed from A=1 and Preferred
> Lifetime > 0 to A=0 and Preferred Lifetime > 0 is ambiguous. 

[Bing] As I learned from RFC4862, it is ambiguous.

>I'm not quite
> sure what the use case is for separating the A flag and Preferred Lifetime
> settings. Did you also run the test by changing to A=0 and Preferred Lifetime
> = 0? I would hope that there would be consistent behavior in that case.

[Bing] We haven't run that, but could do it later. Thanks for the remind.
For separating A flag and Preferred Lifetime, it is just the concept of separating "_address configuration_ methods" and "address aging" raised by Mark Smith in another mail on this thread. I think it is a good point of view, and if we can initiate subsequence revision of host behavior, we should consider it.

> For the "DHCPv6-only host receiving A=1&M=0" case, I'm curious as to
> whether you also tried sending a DHCPv6 Reconfigure message and forcing
> the host to release the DHCPv6-assigned address; and send A=1&M=0 in an
> RA directly after sending the Reconfigure. I'm not sure what the use case is
> for trying to force the release or deprecation of a DHCPv6 address via flags
> in an RA message. Once a host has a DHCPv6 address, I would have expected
> its subsequent behavior relating to that address and that DHCPv6 server to
> be governed by RFC 3315. 

[Bing] We haven't tried this, could do later. But we used to talk about it in 6renum WG. DHCPv6-Reconfiguration is considered not suitable for bulk usage, since it is stateful and unicast, might cause heavy load for the DHCPv6 server, this has been documented in [draft-ietf-6renum-gap-analysis]. Moreover, it is more difficult for administration to simultaneously operate DHCPv6 and ND together.  

The Linux/MAC behavior appears consistent with
> what I would have expected. The Windows 7 does not. I'm unaware of even
> a "hint" that suggests RA flags have a role in governing DHCPv6 behavior
> once RFC 3315 is in play.

[Bing] That is just the ambiguous of the RA flags behavior. IMHO, we need to specify it clear in the standard. Whether the RA flags should govern DHCPv6 behavior or not, we can discuss it in the next step if the groups agree we should deal with the ambiguous problem firstly.

B.R.
Bing

> in

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 27 Feb 2013 05:56:03 +0000

Hi, Mark

Thanks for your comment. 
I like the concept of separating "_address configuration_ methods" and "address aging methods", if we could initiate the subsequence work, it should be considered.

All the best
Bing

> From: Mark Smith [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2013 4:35 AM
> Thanks for writing this, I've been thinking about doing something similar over
> the last few months since, IIRC, I heard about Windows 7 invalidating IPv6
> addresses learned via DHCPv6 when SLAAC was enabled and DHCPv6 was
> disabled on a link.
> 
> Firstly, I came to realise that the mistake being made by Windows 7 was the
> assumption that the aging of the assigned IPv6 addresses was tightly coupled
> to the DHCPv6 session state, meaning that if DHCPv6 went away, so would
> the assigned addresses. This is generally the way DHCPv4 has worked.
> However, in IPv6/DHCPv6, it seems the address lifetime values in the IA_NA
> are not coupled to the T1 and T2 times, so if DHCPv6 goes away (perhaps
> because the M bit was switched off in a latter RA), the configured IPv6
> addresses should be left to age out as per their preferred and valid lifetimes.
> 
> The other thing I noticed was that the M RA flag and the PIO A flags aren't
> mutually exclusive - I couldn't find any text in RFC4861 that says if the M bit
> is switched on, the PIO A flags must be switched off and vice-versa. So that
> suggests that the DHCPv6 and SLAAC can co-exist, and I think that is quite
> reasonable if you're transitioning a link from DHCPv6 to SLAAC address
> configuration or vice-versa.
> 
> Thinking about it more, I came realise that DHCPv6 and SLAAC are _address
> configuration_ methods, but are not address aging methods - IPv6 takes care
> of address aging via it's preferred and valid aging mechanisms, regardless of
> the address configuration method. Static assignment is also just an address
> configuration method, although typically the addresses don't age out, but
> only because they're normally set to infinity. Perhaps in the future there
> might be other address configuration methods.
> 
> I didn't seem to be able to find an RFC that made it clear that address
> configuration and address aging are quite separate, so perhaps this ID could
> be the one.
> 
> Regarding this text:
> 
> 'For the host behavior, there is an explicit rule in the SLAAC specification
> [RFC4862]: "If the Autonomous flag is not set, silently ignore the Prefix
> Information option."'
> 
> I think RFC5942, "IPv6 Subnet Model: The Relationship between Links and
> Subnet Prefixes." updates that advice, as the PIO option is used to indicates
> which prefix/range of addresses are on-link, via the PIO O bit, even if the PIO
> A bit is switched off.
> 
> Best regards,
> Mark.
> 
> the standard (mainly RFC4862). I presented a draft discussing M flag

---

From: Karl Auer <[email-masked]>
Date: Wed, 27 Feb 2013 17:00:28 +1100

On Wed, 2013-02-27 at 05:56 +0000, Liubing (Leo) wrote:
> I like the concept of separating "_address configuration_ methods" and
> "address aging methods", if we could initiate the subsequence work, it
> should be considered.

Hear, hear!

Regards, K.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 27 Feb 2013 06:16:35 +0000

Hi, Sheng

Thanks for your comments.
This is the first step, to see if there is consensus of agreeing the problems should be fixed in current standard. If so, we'll submit a draft to fix the ambiguous issue.

B.R.
Bing

> From: Sheng Jiang
> Sent: Wednesday, February 27, 2013 11:37 AM
> To: Liubing (Leo); [email-masked]
> Cc: [email-masked]
> This has been a historic issue. Although there was discussions several times,
> the specification still remain ambiguous. The differences in OS
> implementations are good proof that we need to do something in IETF.
> 
> This document has well described the current standard status and reality
> operational issues. However, for me, this document fails to suggest what we
> may do to fix this issue, neither in the gap section or as conclusion. It is clear
> that part of RFC4862 needs to be updated to make the configuration
> behavior clear and consistent. For that, this document fails to give a feasible
> proposal. Maybe, the authors has saved that for another follow up standard
> track document.
> 
> Best regards,
> 
> Sheng
> 
> behavior

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 27 Feb 2013 06:44:55 +0000

Hi, Bing,

It is better to at least mention the direction of next step - clearly redefine the flag correspondent host behavior in standards.

A couple of more detailed comments: you have used word "gap" several times, while you did not clear describe what gap it is. You have only described issues/problems. Gaps should be something that issue solved if you could fill them. Subsections of Section 3 are problem scenarios. But your subsection titles do not clear express the meaning.

Cheers,

Sheng

>From: Liubing (Leo)
>Sent: Wednesday, February 27, 2013 2:17 PM
>To: Sheng Jiang; [email-masked]
>Cc: [email-masked]
>This is the first step, to see if there is consensus of agreeing the problems
>should be fixed in current standard. If so, we'll submit a draft to fix the
>ambiguous issue.
>
>B.R.
>Bing
>
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 27 Feb 2013 07:17:33 +0000

> Sent: Wednesday, February 27, 2013 2:45 PM
> It is better to at least mention the direction of next step - clearly redefine the
> flag correspondent host behavior in standards.

[Bing] Agree. Thanks for your clarification.

> 
> A couple of more detailed comments: you have used word "gap" several
> times, while you did not clear describe what gap it is. You have only
> described issues/problems. Gaps should be something that issue solved if
> you could fill them. Subsections of Section 3 are problem scenarios. But your
> subsection titles do not clear express the meaning.

[Bing] OK, I can make it more clear in the next version or in the new solution draft. Thanks for your careful review.

B.R.
Bing