Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-10

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Dec 2017 14:47:49 -0500

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-capwap-alt-tunnel-10
Reviewer: Paul Kyzivat
Review Date: 2017-12-11
IETF LC End Date: 2017-12-13
IESG Telechat date: TBD

Summary:

This draft is on the right track but has open issues, described in the 
review.

(Thanks for fixing most of the issues I raised in the previous round.)

Issues:

Major: 0
Minor: 7
Nits:  1

(1) MINOR:

In Section 1.3, if this document is intended to serve as a *historical* 
reference, then why isn't then intended status "Historic" rather than 
"Experimental"?

(2) MINOR:

Section 3 contains:

    Since AC can configure a WTP with more than one AR available for the
    WTP to establish the data tunnel(s) for user traffic, it may be
    useful for the WTP to communicate the selected AR.  To enable this,
    the IEEE 802.11 WLAN Configuration Response may contain the AR list
    element containing the selected AR.

But "IEEE 802.11 WLAN Configuration Response" is not defined in this 
version of the document. Seems like this may be a dangling reference 
from a prior version.

(3) MINOR:

In Section 3.1, Figure 6 shows Tunnel-Type1 occupying the first 16 bits 
of a 32 bit value, and Tunnel-Type (2..N) all occupying the 2nd 16 bits 
of that value. That doesn't work for N>2. I *presume* that the intent is 
that this be an array of 16 bit values in network order starting with 
Tunnel-Type1, but that is not what it says. Needs some work.

(4) MINOR:

In Section 3.3 I find the wording of the usage unclear in the following:

    The Alternate Tunnel Failure Indication message element is sent by
    the WTP to inform the AC about the status of the Alternate Tunnel.
    It MAY be included in the CAPWAP Station Configuration Request
    message.  ...

It is the way "MAY" is used here that causes me confusion, as if there 
is some other way to achieve this goal. Perhaps the following would be 
clearer:

    The WTP MAY include the Alternate Tunnel Failure Indication message
    in a CAPWAP Station Configuration Request message to inform the AC
    about the status of the Alternate Tunnel.

(5) MINOR:

In Section 4.2 I find the usage of the term "Access Router (LMA) 
Information Element" confusing. I find no definition of this as a 
distinct thing, so I gather the intent is that this is a particular 
usage of "Access Router Information Element". I think this would be 
clearer to remove "(LMA)" from Figure 10.

(6) MINOR:

Section 5.2 uses "ARs" and "ARs information" in ways that are unclear 
and improper grammar. IIUC "AR" in this document means "Access Router", 
and so "ARs" should mean "Access Routers". It is used that way once in 
section 3.3, and once in 5.2. But several other usages in 5.2 are 
different, and seem to be intended to refer to "Access Router 
Information Elements". I suggest the following change:

OLD

    ... If there are more than one ARs
    information provided by the AC for reliability reasons, the same
    Tunnel DTLS Policy (see Figure 14) is generally applied for all
    tunnels associated with the ARs.  Otherwise, Tunnel DTLS Policy MUST
    be bonding together with each of the ARs, then WTP will enforce the
    independent tunnel DTLS policy for each tunnel with a specific AR.

NEW

    ... If, for reliability reasons, the AC has provided more than one
    AR address in the Access Router Information Element, the same
    Tunnel DTLS Policy (see Figure 14) is generally applied for all
    tunnels associated with those ARs.  Otherwise, Tunnel DTLS Policy
    MUST be bonded together with each of the Access Router Information
    Elements, and the WTP will enforce the independent tunnel DTLS policy
    for each tunnel with a specific AR.

In addition the mechanics of this "bonding" aren't entirely clear. This 
seems to be covered by:

    A: If A bit is set, there is an AR information associated with the
    DTLS policy.  There may be an array of pairs binding DTLS policy
    information and AR information contained in the Tunnel DTLS Policy
    Element.  Otherwise, the same Tunnel DTLS Policy (see Figure 14) is
    generally applied for all tunnels associated with the ARs configured
    by the AC.

The above says "There may be an array of pairs". How is the array 
encoded and how is its length specified? I'm guessing you intend:

When A=0:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Tunnel DTLS Policy Element Type|        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reserved                       |A|D|C|R|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When A=1:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Tunnel DTLS Policy Element Type|        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reserved                       |A|D|C|R|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                       AR Information                          .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reserved                       |A|D|C|R|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                       AR Information                          .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reserved                       |A|D|C|R|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                       AR Information                          .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where the number of repeats is equal to the number of AR addresses 
previously specified.

This needs to be made much clearer. ISTM it would be cleaner to forget 
the flag, and simply say this is always a list, where the last element 
has no AR Information and provides options for any address not 
previously mentioned. (But this isn't an option if it is documenting 
existing usage.)

In Figure 9, I gather that "AR Information" means "Access Router 
Information Element", and in this context it must be restricted to a 
single address, and must be the address of one of previously specified 
AR addresses. If so, please say this explicitly.

(7) MINOR:

Section 5.3 has a similar construction to that in 5.2, with the same 
issues and should get a comparable fix.

(8) NIT:

IdNits reports that the reference to RFC2460 in section 5.6 is obsolete.

---

From: Duzongpeng <[email-masked]>
Date: Wed, 13 Dec 2017 08:16:52 +0000

Hi, Paul

	Thank you very much for your careful review. 
	We will updated the draft accordingly. 

Best Regards
Zongpeng Du

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, December 12, 2017 3:48 AM
To: [email-masked]
Cc: General Area Review Team
Subject: Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-10

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Summary:

This draft is on the right track but has open issues, described in the review.

Issues:

Major: 0
Minor: 7
Nits:  1

(1) MINOR:

In Section 1.3, if this document is intended to serve as a *historical* reference, then why isn't then intended status "Historic" rather than "Experimental"?

(2) MINOR:

Section 3 contains:

But "IEEE 802.11 WLAN Configuration Response" is not defined in this version of the document. Seems like this may be a dangling reference from a prior version.

(3) MINOR:

In Section 3.1, Figure 6 shows Tunnel-Type1 occupying the first 16 bits of a 32 bit value, and Tunnel-Type (2..N) all occupying the 2nd 16 bits of that value. That doesn't work for N>2. I *presume* that the intent is that this be an array of 16 bit values in network order starting with Tunnel-Type1, but that is not what it says. Needs some work.

(4) MINOR:

It is the way "MAY" is used here that causes me confusion, as if there is some other way to achieve this goal. Perhaps the following would be
clearer:

(5) MINOR:

In Section 4.2 I find the usage of the term "Access Router (LMA) Information Element" confusing. I find no definition of this as a distinct thing, so I gather the intent is that this is a particular usage of "Access Router Information Element". I think this would be clearer to remove "(LMA)" from Figure 10.

(6) MINOR:

Section 5.2 uses "ARs" and "ARs information" in ways that are unclear and improper grammar. IIUC "AR" in this document means "Access Router", and so "ARs" should mean "Access Routers". It is used that way once in section 3.3, and once in 5.2. But several other usages in 5.2 are different, and seem to be intended to refer to "Access Router Information Elements". I suggest the following change:

OLD

NEW

In addition the mechanics of this "bonding" aren't entirely clear. This seems to be covered by:

The above says "There may be an array of pairs". How is the array encoded and how is its length specified? I'm guessing you intend:

When A=0:

       0                   1                   2                   3

When A=1:

       0                   1                   2                   3

where the number of repeats is equal to the number of AR addresses previously specified.

This needs to be made much clearer. ISTM it would be cleaner to forget the flag, and simply say this is always a list, where the last element has no AR Information and provides options for any address not previously mentioned. (But this isn't an option if it is documenting existing usage.)

In Figure 9, I gather that "AR Information" means "Access Router Information Element", and in this context it must be restricted to a single address, and must be the address of one of previously specified AR addresses. If so, please say this explicitly.

(7) MINOR:

Section 5.3 has a similar construction to that in 5.2, with the same issues and should get a comparable fix.

(8) NIT:

---

From: Duzongpeng <[email-masked]>
Date: Wed, 13 Dec 2017 09:07:37 +0000

I received an email saying that 

Your mail to 'Gen-art' with the subject

    RE: Gen-ART Last Call review of
draft-ietf-opsawg-capwap-alt-tunnel-10

Is being held until the list moderator can review it for approval.

The reason it is being held:

    Message body is too big: 421423 bytes with a limit of 400 KB

So I send again just including the new txt version of the draft.
If any problem, please connect me.

-----Original Message-----
From: Duzongpeng 
Sent: Wednesday, December 13, 2017 4:56 PM
To: 'Paul Kyzivat'; [email-masked]
Cc: General Area Review Team
Subject: RE: Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-10

Hi, Paul

	Please see inline. 
	Thank you very much for your careful review. 
	We have updated the draft accordingly. 
	If any problem, please connect us.

Best Regards
Zongpeng Du

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, December 12, 2017 3:48 AM
To: [email-masked]
Cc: General Area Review Team
Subject: Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-10

Summary:

Issues:

Major: 0
Minor: 7
Nits:  1

(1) MINOR:

In Section 1.3, if this document is intended to serve as a *historical* reference, then why isn't then intended status "Historic" rather than "Experimental"?
<zongpeng>There have been discussions about it among the authors, chairs, and the ADs. Finally, the "Experimental" type is decided.
According to https://tools.ietf.org/html/rfc2026#section-4.2, the historical type means:
   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level.
Our document is a new one, so it is not very proper for us to declare a historical type.

	Also in RFC2026, it is said that  
   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).

	So we consider that the "Experimental" type is more suitable here.

	And to avoid ambiguity, we have changed the "This experimental document is intended to serve as a historical reference for any future work as to the operational and deployment requirements." To
	"This experimental document is intended to serve as **an archival record** for any future work as to the operational and deployment requirements."
</zongpeng>
 (2) MINOR:

Section 3 contains:

But "IEEE 802.11 WLAN Configuration Response" is not defined in this version of the document. Seems like this may be a dangling reference from a prior version.
<zongpeng>Thanks for proposing the problem. We add some explanations for the problem.
Firstly, change the sentence to " the IEEE 802.11 WLAN Configuration Response may contain the AR list
    element containing the selected AR *as shown in Figure 5*."
Secondly, change the Config. To Configuration in the Figure 5, and add the [ AR List Element ]  in the IEEE 802.11 WLAN Configuration Response message.</zongpeng> 

(3) MINOR:

<zongpeng>Thanks for proposing the problem. We add some explanations for the problem.
Firstly, add some explanations into the Tunnel-type Field.
Tunnel-Type: This is identified by value defined in Section 3.2. *There may be one or more Tunnel-Types as shows in Figure 6.* Secondly, change the graph to:
	0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Tunnel-Type 1            |      Tunnel-Type 2            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            ...                |      Tunnel-Type N            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</zongpeng>

(4) MINOR:

<zongpeng> Thanks for proposing the problem. We revise accordingly. </zongpeng>

(5) MINOR:

<zongpeng> Thanks for proposing the problem. We revise accordingly. </zongpeng>

(6) MINOR:

OLD

NEW

When A=0:

       0                   1                   2                   3

When A=1:

       0                   1                   2                   3

<zongpeng> Thanks for proposing the problem. We revise accordingly.
The change is a little complicated, and is described following the comments. 
Several people had edited the draft, so that there was some conflicts in the description.
But the main opinion among the authors is the same. Thanks again for the suggestion.</zongpeng>

(7) MINOR:

(8) NIT:

IdNits reports that the reference to RFC2460 in section 5.6 is obsolete.
<zongpeng> Thanks for proposing the problem. We revise accordingly. </zongpeng>

About the (6) and (7), we choose to forget the flag as you have suggested. However, it is found that it is not enough to just modify section 5.2 and 5.3, so that section 5.4, 5.5, 5.6 are also modified to support information providing of more than one ARs.
Among them, section 5.5 is a little different, because every GRE key should be independent, and needs not to be the same.
Also for section 5.6, IPv6 MTU are not needed in the context of IPv4 environment, so there is no default value, neither.

For the detailed modifications, please refer to the new version of draft attached. 
Perhaps we will update the draft recently if it is ok for you.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Dec 2017 17:55:15 -0500

> 	"This experimental document is intended to serve as **an archival record** for any future work as to the operational and deployment requirements."

Now I am more confused. This is new, rather than documenting existing 
deployed practice. It is not standards track, so this is not an intent 
to define something that can be deployed But it is being published as an 
archive.

Was this once intended to be standards track, but without sufficient 
interest or support to complete it as a standard. Is this then 
reflecting that "we did a lot of work on this and want to publish it in 
case there is future interest in doing something like this"?

If so, that is fine. If it is something else, then it would be helpful 
to have further explanation.

> Secondly, change the Config. To Configuration in the Figure 5, and add the [ AR List Element ]  in the IEEE 802.11 WLAN Configuration Response message.</zongpeng>

I'm still confused about what message is used to convey this. Is it an 
existing message in another spec, in which the AR List Element may be 
inserted? If so, does that message already allow elements defined 
elsewhere, such as this one, to be included? How would it be deciphered?

> Secondly, change the graph to:

Looks good.

> <zongpeng> Thanks for proposing the problem. We revise accordingly. </zongpeng>

Thanks.

> <zongpeng> Thanks for proposing the problem. We revise accordingly. </zongpeng>

Looks good.

> The above says "There may be an array of pairs". How is the array encoded and how is its length specified? I'm guessing you intend:

The fix looks good to me.

> <zongpeng> Thanks for proposing the problem. We revise accordingly. </zongpeng>

Looks right.

> Perhaps we will update the draft recently if it is ok for you.

	Thanks,
	Paul

---

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Dec 2017 21:27:20 -0500

On Wed, Dec 13, 2017 at 5:55 PM, Paul Kyzivat <[email-masked]> wrote:
>> I am the assigned Gen-ART reviewer for this draft. The General Area Review
>> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
>> the IETF Chair. Please treat these comments just like any other last call
>> comments. For more information, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> <zongpeng>There have been discussions about it among the authors, chairs,
>> and the ADs. Finally, the "Experimental" type is decided.
>>         And to avoid ambiguity, we have changed the "This experimental
>> document is intended to serve as a historical reference for any future work
>> as to the operational and deployment requirements." To
>>         "This experimental document is intended to serve as **an archival
>> record** for any future work as to the operational and deployment
>> requirements."
>> </zongpeng>
>
>
> deployed practice. It is not standards track, so this is not an intent to
> define something that can be deployed But it is being published as an
> archive.
>
> interest or support to complete it as a standard. Is this then reflecting
> that "we did a lot of work on this and want to publish it in case there is
> future interest in doing something like this"?
>

Yup :-)

> If so, that is fine. If it is something else, then it would be helpful to
> have further explanation.

Yup, up until version 8 this was a Standards Track document. It got
significant review (and went though an IETF LC / IESG ballot) as that
but ran into some issues and was returned to the WG. It seems like the
interest in deploying it decreased -- but, it is still a valid use,
and interest may return in the future. Experimental might not be the
right status, but I don't really think Historic is either. It could be
Informational, but that doesn't quite feel right either.

W

>> version of the document. Seems like this may be a dangling reference from a
>> prior version.
>> Secondly, change the Config. To Configuration in the Figure 5, and add the
>> [ AR List Element ]  in the IEEE 802.11 WLAN Configuration Response
>> message.</zongpeng>
>
>
> inserted? If so, does that message already allow elements defined elsewhere,
> such as this one, to be included? How would it be deciphered?
>
>> (3) MINOR:
>>
>> In Section 3.1, Figure 6 shows Tunnel-Type1 occupying the first 16 bits of
>> a 32 bit value, and Tunnel-Type (2..N) all occupying the 2nd 16 bits of that
>> value. That doesn't work for N>2. I *presume* that the intent is that this
>> be an array of 16 bit values in network order starting with Tunnel-Type1,
>> but that is not what it says. Needs some work.
>>
>> Tunnel-Type: This is identified by value defined in Section 3.2. *There
>> may be one or more Tunnel-Types as shows in Figure 6.*
>> Secondly, change the graph to:
>>         0                   1                   2                   3
>> It is the way "MAY" is used here that causes me confusion, as if there is
>> some other way to achieve this goal. Perhaps the following would be
>> clearer:
>>
>> Information Element" confusing. I find no definition of this as a distinct
>> thing, so I gather the intent is that this is a particular usage of "Access
>> Router Information Element". I think this would be clearer to remove "(LMA)"
>> from Figure 10.
>>
>> Section 5.2 uses "ARs" and "ARs information" in ways that are unclear and
>> improper grammar. IIUC "AR" in this document means "Access Router", and so
>> "ARs" should mean "Access Routers". It is used that way once in section 3.3,
>> and once in 5.2. But several other usages in 5.2 are different, and seem to
>> be intended to refer to "Access Router Information Elements". I suggest the
>> following change:
>>
>> OLD
>>
>> The above says "There may be an array of pairs". How is the array encoded
>> and how is its length specified? I'm guessing you intend:
>>
>> When A=0:
>>
>>         0                   1                   2                   3
>> This needs to be made much clearer. ISTM it would be cleaner to forget the
>> flag, and simply say this is always a list, where the last element has no AR
>> Information and provides options for any address not previously mentioned.
>> (But this isn't an option if it is documenting existing usage.)
>>
>> Information Element", and in this context it must be restricted to a single
>> address, and must be the address of one of previously specified AR
>> addresses. If so, please say this explicitly.
>>
>> About the (6) and (7), we choose to forget the flag as you have suggested.
>> However, it is found that it is not enough to just modify section 5.2 and
>> 5.3, so that section 5.4, 5.5, 5.6 are also modified to support information
>> providing of more than one ARs.
>> Among them, section 5.5 is a little different, because every GRE key
>> should be independent, and needs not to be the same.
>> Also for section 5.6, IPv6 MTU are not needed in the context of IPv4
>> environment, so there is no default value, neither.
>>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Dec 2017 22:49:00 -0500

> Informational, but that doesn't quite feel right either.

OK. Then this makes sense. Maybe we need a new category for this sort of 
thing. (I think I have another use for it.)

	Thanks,
	Paul

---

From: Duzongpeng <[email-masked]>
Date: Thu, 14 Dec 2017 07:12:58 +0000

Hi, Paul

	Thank you for your reply.
	We have updated the draft again, the version 11-2. 
	If any problem, please connect us.
	
Best Regards
Zongpeng Du

About the comments:

	Now I am more confused. This is new, rather than documenting existing deployed practice. It is not standards track, so this is not an intent to define something that can be deployed But it is being published as an archive.

Was this once intended to be standards track, but without sufficient interest or support to complete it as a standard. Is this then reflecting that "we did a lot of work on this and want to publish it in case there is future interest in doing something like this"?

If so, that is fine. If it is something else, then it would be helpful to have further explanation.

<zongpeng>Yes, this was once to be standards track. But market trend changed while the work was going on, and then it was not finished.
Your understanding about "we did a lot of work on this and want to publish it in case there is future interest in doing something like this" is right. </zongpeng>

I'm still confused about what message is used to convey this. Is it an existing message in another spec, in which the AR List Element may be inserted? If so, does that message already allow elements defined elsewhere, such as this one, to be included? How would it be deciphered?

<zongpeng>We made some corrections about it. It is a mistake to include it directly in the IEEE 802.11 WLAN Config. Response
Firstly, we change the Figure. Now, the IEEE 802.11 WLAN Configuration Response message contains an alternate tunnel encapsulation message element, in which the AR list element can be included.
Secondly, we rewrite the explanation under the graph. Now, it is said that "To enable this, the IEEE 802.11 WLAN Configuration Response may carry the alternate tunnel encapsulation message element containing the AR list element	corresponding to the selected AR as shown in Figure 5."
Thirdly, in Section 3.2.  Alternate Tunnel Encapsulations Type, we add some explanations:
" Besides, the message element can also be sent by the WTP to communicate the selected AR(s). "
Fourthly, in Section 5.1.  Access Router Information Elements, we add some explanations:
" If the Alternate Tunnel Encapsulations Type message element is sent	
 	   by the WTP to communicate the selected AR(s), this Access Router	
 	   Information Element SHOULD be contained."
</zongpeng>

Another problem:
 A message is mistaken used in the draft because of negligence, and we correct it.
In current version, it is said that WTP Alternate Tunnel Fail Indication (defined in this specification)
   MAY be carried in the CAPWAP Station Configuration Request message
   which is defined in [RFC5415].
However, it should be *WTP Event Request * message instead.
The CAPWAP Station Configuration Request message is sent by the AC to the WTP,
And the WTP Event Request message is used by a WTP to send information to its AC.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, December 14, 2017 6:55 AM
To: Duzongpeng; [email-masked]
Cc: General Area Review Team
Subject: Re: Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-10

> 	"This experimental document is intended to serve as **an archival record** for any future work as to the operational and deployment requirements."

Now I am more confused. This is new, rather than documenting existing deployed practice. It is not standards track, so this is not an intent to define something that can be deployed But it is being published as an archive.

Was this once intended to be standards track, but without sufficient interest or support to complete it as a standard. Is this then reflecting that "we did a lot of work on this and want to publish it in case there is future interest in doing something like this"?

If so, that is fine. If it is something else, then it would be helpful to have further explanation.

> Secondly, change the Config. To Configuration in the Figure 5, and add 
> the [ AR List Element ]  in the IEEE 802.11 WLAN Configuration 
> Response message.</zongpeng>

I'm still confused about what message is used to convey this. Is it an existing message in another spec, in which the AR List Element may be inserted? If so, does that message already allow elements defined elsewhere, such as this one, to be included? How would it be deciphered?

> Tunnel-Type: This is identified by value defined in Section 3.2. 
> *There may be one or more Tunnel-Types as shows in Figure 6.* Secondly, change the graph to:
> 	0                   1                   2                   3

Looks good.

Thanks.

Looks good.

Looks right.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 14 Dec 2017 10:21:58 -0500

> 	If any problem, please connect us.

This resolves my concerns.

	Thank you,
	Paul
  	
> " Besides, the message element can also be sent by the WTP to communicate the selected AR(s)."