From bpatil1@gmail.com Wed Dec 5 12:38:31 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD8921F8C5C for ; Wed, 5 Dec 2012 12:38:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNKoAH+EGjg4 for ; Wed, 5 Dec 2012 12:38:30 -0800 (PST) Received: from mail-ia0-f180.google.com (mail-ia0-f180.google.com [209.85.210.180]) by ietfa.amsl.com (Postfix) with ESMTP id F103121F8C51 for ; Wed, 5 Dec 2012 12:38:29 -0800 (PST) Received: by mail-ia0-f180.google.com with SMTP id t4so4026327iag.25 for ; Wed, 05 Dec 2012 12:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=eM+saNq4CTKFfT2hcsKznaSMbFG3suIRYNguQWnKKGo=; b=q8vY0Tv+lgmH0iXI49+ppq2+eCocAS1ll/eXOHmSHVZQQBWkssn2f+PZkAwO/Ka2Uy jW1WcHhfiQkJQvs4A0Zr/2bB/iwF0sPVQ/Qosj9B5tESs1E8P+KRPpC9ggvjk26yPP8D hRj+QnkbYIbh5kLGvPsjT1HU9Fk7aZ/7QNPH2a6AMcfbOaoyEPZVi35LVSEJ8XYiEU8Q di8N0r9teiufRqQQroUUmbMuqbl7qivmLNXmoOVXjct4P4uiKcErmiqeslkHxfgpezXF i1qPJ9e22agn+YzVxbxfRtqMKZVxQzzIo5u3XKQc4+r0M4cczOyF51FUBTmxqjpLBdPw PtdA== MIME-Version: 1.0 Received: by 10.50.213.73 with SMTP id nq9mr3530898igc.27.1354739909415; Wed, 05 Dec 2012 12:38:29 -0800 (PST) Received: by 10.43.104.136 with HTTP; Wed, 5 Dec 2012 12:38:28 -0800 (PST) Date: Wed, 5 Dec 2012 14:38:28 -0600 Message-ID: From: Basavaraj Patil To: netext@ietf.org Content-Type: multipart/alternative; boundary=14dae93405f310522604d020f7d0 Subject: [netext] IETF85: Netext WG meeting minutes X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 20:38:31 -0000 --14dae93405f310522604d020f7d0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Network-Based Mobility Extensions WG meeting at IETF85 (Atlanta, USA) Monday, November 5th, 2012 1520-1720 Afternoon Session II Chairs: Basavaraj Patil (basavaraj.patil@nokia.com) Rajeev Koodli (rkoodli@cisco.com) These meeting minutes are courtesy of: 1. Byju Pularikkal (byjupg at cisco.com) 2. Carl Williams (carlw at mcsr-labs.org) ------------------------------------------------------------- The meeting was chaired by Basavaraj Patil. Rajeev Koodli was unable to attend because of a travel conflict. 1. WG Status update - Two documents published as RFC 6705 & 6757 - SIPTO option-7: AD review - RFC5149 bis LC completed ----------------------------------------------------------------- 2. Logical Interface Support for multi-mode IP Hosts I-D: draft-ietf-netext-logical-interface-support-06 Sri Gundavelli Update by Sri on Logical interface support: Key issues covered: What is logical interface (Sri explained). To support many Hand off scenaios we specify 5213. When hand off happens we need to make sure that host does not se any change as far as IP stack is concerned, We do not want application to detect any connectivity lost. Julien: Comment from: Why do u need link identifier on the original interface? When you have a loop back interface and assign the IP to it then it should essentially provide . Virtual interface identifier may not be required when loop back interface is in use. Sri: From network signaling we always identify the interface using some interface identifier. Julien: How is this going to work for IPv4 where there is no link layer identifier. Sri: How does the network identify the attachment point with out virtual t link layer identifier Sri: You are looking at more as a interconnect between physical interface and routing. In some access systems we can say that virtual interface identifier can just map to the physical map. Conclusion: Virtual interface does not need LLID, physical interface may or may not have. Kent: What is the rationale behind LLID, it is not just for pure forwarding The intention to have a single LLID across several interfaces is it feasible or not? But also PMIP needs a LLID at least for WiFi and WiMAX interfaces Julien: If you have different LLIDs on physical interfaces and some does not you can always build a system which will work. I don't see the requirement for virtual LLID Pete McCann's comment regarding multiple provisioning domains. How does logical interface deal with it. Sri's explanation, It will essentially be a single provisioning domain. Logical interface will only be applicable to single provisioning domain. Chairs comment, text too implementation specific: Sri commented this issue will be addressed. Juan: It is time to move this document along. got quite a good amount of feedback. Raj: Fail to understand what is it trying to accomplish. Sri: A working system has been shown matches what ever proposed. 6> Clarity of the draft Kostas: Why don't we do a quick editorial round on the document? Why don't we move the implementation specific aspects into an Appendix? Brian: One of the things that people push back is, what u describe is mandatory for interop with another device then completely required to put in the text; If not, put in appendix. ----------------------------------------------------------------- 3. Proxy Mobile IPv6 Extensions to Support Flow Mobility I-D: draft-ietf-netext-pmipv6-flowmob CJ Bernardos - Detailed reviews received from Marcos and Juan - Draft is ready for WGLC (1) Comments: Section 3.2.1 has nothing normative. Why do u have that section. How does prefix delegation affect flow mobility? May be move that section to appendix or completely remove RFC 5648 & RFC 6089 comments. Multiple Proxy CoA registration, taking it to extremes on this. How are we going to use 5648 and 6089 in PMIP? Raj: Significant progress has been made on this document but just needs some couple of more reviews. Kent has agreed to review . Only concern with the draft is linking with the logical interface. Sri: Are we replicating all the FMI options? Not really replacing PBU-PBA concept. Depends up on the scenario, one one case PBU/PBA is used in other SMI/SMA. Raj also recommended that a issue tracker be setup for this I-D to close open issues and progress the draft to WG last call. ----------------------------------------------------------------- 4. Prefix Delegation for Proxy Mobile IPv6 I-D: draft-ietf-netext-pd-pmip Carl Williams - Authors addressed all the issues. Document is ready for IESG revew: Alex: Read the updated draft. Some more modification discussions going on and will raise them on the list. ----------------------------------------------------------------- 5. Quality of Service Option for Proxy Mobile IPv6 I-D:draft-ietf-netext-pmip6-qos Marco Liebsch Progress: - Initial draft presented at IETF 82 - Version 1 addresses comments about interpretation of QoS policies. Kent: Are u speccing non-3GPP access networks as well? Looks like taking a specific reference for a generic model. So far it is covered. Sri: Application function can notify LMA about a new flow and then can signal QoS. MAg after detecting a new flow can do a PBU/PBA and can get the QoS signaling info. There is another way of loading QoS on MAG. S-9 with non-3GPP access. What is the relationship between that Qos and one in the draft? Inband signaling such as described here may be an easy way to implement QoS There are some updated RFCs is with guidelines about semantics on the DSCP values Raj: Really need some reviews and feedback on this document ----------------------------------------------------------------- 6. Update Notifications for Proxy Mobile IPv6 I-D: draft-krishnan-netext-update-notifications-01 Suresh Krishnan Taken care of all the open comments officially requesting the chair to adopt. Six or seven people in the room have read the draft. Kent: Does it allow LMA to send some generic signaling or even some specific signaling messages? This is pretty much a notification with reason code and mobility options. This is more of a framework and we can add semantics later - LMA to MAG messaging we need some kind of standardization Kent: Make sure: Don't duplicate what ever is out there - 11 people in favor of adopting the document=85 - Draft is pretty simple. Accept the review from x number of people and then move this forward ----------------------------------------------------------------- 7. Network Mobility Support using Mobile MAG in PMIP6 domain I-D: draft-sijeon-netext-mmag-pmip-00.txt Seil Jeon Ahmad:: Is that mMAG just a mobile node? And what is the security requirement to send the binding update to LMA? - mMAG is registered with the LMA. mMAG is not seen as mobile node. MAG is attached to a fixed MAG. - mMAG can be considered as a dual entry, Mobile node from fixed MAG perspective, and MAG for the mobile nodes connected to mMAG - What is the difference between this and the mobile node acting as a route= r Raj: tends to disagree with the concept of mMAG Raj: Have a discussion on this document in the working group mailing list ----------------------------------------------------------------- 8. MN Status Option for Proxy Mobile IPv6 I-D: draft-tu-netext-mn-status-option-02 Yangwei Tu Raj: There are questions about the problem statement itself. We should discuss whether it is a solution for a problem worth solving Sri: There is work related to Opcon and othe notifying the radio congestion to the LMA. MAG is typically not on the access point. Definitely there is merit in notifying it but don't know how MAG will know those characteristics Carlos: LMA can benefit from having additional info from the MAG. Not only about radio conditions, it is just one of the capabilities. This is an important issue to address Raj: Idea is to convey more decisions to LMA , not talking about flow mobility. Some concerns, who knows about the status of the mobile node, idle or active etc ---------------------------------------------- 9. Mapping PMIP Quality of Service in WiFi Network I-D: draft-kaippallimalil-netext-pmip-qos-wifi-01 J. Kaipallimalli - Based up on the comments on version 00 some updates have been made to 01. Kent: Traffic filters based on IP layer.At AP layer it will be mac based, how do u address overlapping IP address support? Raj: Will request additional reviews of the I-D and encourage more discussion on the list. ---------------------------------------------- 10. Seamless Handover for Multiple-Access Mobile Node in PMIPv6 I-D: draft-cui-netext-pmipv6-shpmipv6 Y. Chen Time ran out and hence this I-D was not discussed at the meeting. ---------------------------------------------- Summary and Next steps: - Three documents will go to LC before the next IETF meeting. 1. pd-pmip 2. logical-interface - to be decided whether ready for last call 3. flow-mobility Strong consensus to adapt Suresh's draft. Will follow up on the mailing list. --=20 Basavaraj Patil --14dae93405f310522604d020f7d0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Network-Based Mobility Extensions WG meeting at IETF85 (Atlanta, USA)<= /div>

Monday, November 5th, 2012
1520-1720 Aft= ernoon Session II=A0

Chairs: =A0Basavaraj Patil (<= a href=3D"mailto:basavaraj.patil@nokia.com">basavaraj.patil@nokia.com)<= /div>
=A0 =A0 =A0 =A0 =A0Rajeev Koodli (rkoodli@cisco.com)=A0

These meeting minutes a= re courtesy of:
1. Byju Pularikkal (byjupg at cisco.com)
2. Carl Williams (carlw at mcsr-labs.= org)

-----------------------------------------= --------------------

The meeting was chaired by Ba= savaraj Patil.=A0
Rajeev Koodli was unable to attend because of a travel conflict.
=

1. WG Status update

- Two docu= ments published as RFC 6705 & 6757

- SIPTO opt= ion-7: AD review

- RFC5149 bis LC completed

---= --------------------------------------------------------------
2. Logical Interface Support for multi-mode IP Hosts =A0 =A0 = =A0
=A0 =A0I-D: draft-ietf-netext-logical-interface-support-06 =A0 =A0Sri = Gundavelli

Update by Sri on Logical interface supp= ort:

Key issues covered:

= What is logical interface (Sri explained). To support many Hand off
scenaios we specify 5213. When hand off happens we need to make sure
that host does not se any change as far as IP stack is concerned, = We
do not want application to detect any connectivity lost.=A0


Julien: Comment from: Why do u need link= identifier on the
original interface? When you have a loop back = interface and assign the
IP to it then it should essentially prov= ide . Virtual interface
identifier may not be required when loop back interface is in use.=A0<= /div>

Sri: From network signaling we always identify the= interface using
some interface identifier.=A0

Julien: How is this going to work for IPv4 where there is no link laye= r identifier.=A0

Sri: How does the network identif= y the attachment point with out
virtual t link layer identifier= =A0

Sri: You are looking at more as a interconnect between = physical
interface and routing. In some access systems we can say= that virtual
interface identifier can just map to the physical m= ap. =A0

Conclusion: Virtual interface does not need LLID, physi= cal interface may or may not have.

Kent: What is t= he rationale behind LLID, it is not just for pure forwarding

The intention to have a single LLID across several interface= s is it
feasible or not? But also PMIP needs a LLID at least for = WiFi and
WiMAX interfaces=A0

Julien: If = you have different LLIDs on physical interfaces and some
does not you can always build a system which will work. I don't se= e
the requirement for virtual LLID=A0

Pe= te McCann's comment regarding multiple provisioning domains. How
does logical interface deal with it. Sri's explanation, =A0It will=
essentially be a single provisioning domain. Logical interface w= ill
only be applicable to single provisioning domain.=A0

Chairs comment, text too implementation specific: Sri commen= ted this
issue will be addressed. =A0

Ju= an: It is time to move this document along. got quite a good amount of feed= back.

Raj: <Chairs comment> Fail to understand what is = it trying to accomplish.=A0

Sri: A working system = has been shown matches what ever proposed.=A0

6>= ; Clarity of the draft=A0

Kostas: Why don't we do a quick editorial round on = the document? Why
don't we move the implementation specific a= spects into an Appendix? =A0

Brian: One of the thi= ngs that people push back is, what u describe is
mandatory for interop with another device then completely required to<= /div>
put in the text; If not, put in appendix.

-----------------------------------------------------------------

3. Proxy Mobile IPv6 Extensions to Support Flow Mobilit= y =A0
=A0 =A0I-D: draft-ietf-netext-pmipv6-flowmob =A0CJ Bernardos

- Detailed reviews received from Marcos and Juan

<= div>- Draft is ready for WGLC


(1) C= omments: Section 3.2.1 has nothing normative. Why do u have that
section. How does prefix delegation affect flow mobility? May be move
=
that section to appendix or completely remove=A0

<= div>RFC 5648 & RFC 6089 comments. Multiple Proxy CoA registration, taki= ng
it to extremes on this. How are we going to use 5648 and 6089 in PMIP?= =A0


Raj: Significant progress has b= een made on this document but just
needs some couple of more revi= ews. Kent has agreed to review . Only
concern with the draft is linking with the logical interface. =A0


Sri: Are we replicating all the FMI opt= ions? Not really replacing
PBU-PBA concept.=A0

Depends up on the scenario, one one case PBU/PBA is used in other
SMI/SMA.

Raj also recommended that a issue t= racker be setup for this I-D to
close open issues and progress th= e draft to WG last call.

-------------------------------------------------------= ----------

4. Prefix Delegation for Proxy Mobile I= Pv6 =A0
=A0 =A0I-D: draft-ietf-netext-pd-pmip =A0Carl Williams

- Authors addressed all the issues. Document is ready for IESG revew:

Alex: Read the updated draft. Some more modification discuss= ions going
on and will raise them on the list.

-----------------------------------------------------------------

5. Quality of Service Option for Proxy Mobile IPv6 =A0
= =A0 =A0I-D:draft-ietf-netext-pmip6-qos =A0 =A0 =A0 =A0 =A0 =A0Marco Liebsch

Progress:
- Initial draft presented at IETF 8= 2

- Version 1 addresses comments about interpretat= ion of QoS policies.

Kent: Are u speccing non-3GPP= access networks as well? Looks like
taking a specific reference for a generic model.
So far it i= s covered.=A0

Sri: Application function can notify= LMA about a new flow and then can
signal QoS. MAg after detectin= g a new flow can do a PBU/PBA and can
get the QoS signaling info. =A0

There is anot= her way of loading QoS on MAG. S-9 with non-3GPP
access. What is = the relationship between that Qos and one in the
draft? =A0

Inband signaling such as described here may be an easy = way to implement QoS

There are some updated RFCs i= s with guidelines about semantics on the DSCP values

Raj: Really need some reviews and feedback on this document
=
------------------------------------------------------------= -----

6. Update Notifications for Proxy Mobile IPv= 6 =A0
=A0 =A0I-D: draft-krishnan-netext-update-notifications-01 Suresh Krishnan

Taken care of all the open comments officially request= ing the chair to adopt.

Six or seven people in the room have read the draft.=A0=

Kent: Does it allow LMA to send some generic sign= aling or even some
specific signaling messages? =A0
This is pretty much a notification with reason code and mobility=
options. This is more of a framework and we can add semantics la= ter=A0

- LMA to MAG messaging we need some kind of= standardization

Kent: =A0Make sure: Don't duplicate what ever is ou= t there

- 11 people in favor of adopting the docum= ent=85

- Draft is pretty simple. Accept the review= from x number of people
=A0 and then move this forward=A0

-----------= ------------------------------------------------------

=
7. Network Mobility Support using Mobile MAG in PMIP6 domain =A0=A0
=A0 =A0I-D: draft-sijeon-netext-mmag-pmip-00.txt =A0 =A0 =A0 =A0 =A0 =A0Seil Jeon

Ahmad:: Is that mMAG just a mobile node? And what is = the security
requirement to send the binding update to LMA?=A0

=
- mMAG is registered with the LMA. mMAG is not seen as mobile node. MA= G
=A0 is attached to a fixed MAG. =A0

- = mMAG can be considered as a dual entry, Mobile node from fixed MAG
=A0 perspective, and MAG for the mobile nodes connected to mMAG=A0

- What is the difference between this and the mobile = node acting as a router

Raj: tends to disagree wit= h the concept of mMAG

Raj: Have a discussion on this document in the working = group mailing
list

---------------------= --------------------------------------------

8. MN= Status Option for Proxy Mobile IPv6 =A0
=A0 =A0I-D: draft-tu-netext-mn-status-option-02 =A0Yangwei Tu

Raj: There are questions about the problem statement itself. We sho= uld
discuss whether it is a solution for a problem worth solving=A0
<= div>
Sri: There is work related to Opcon and othe notifying t= he radio
congestion to the LMA. MAG is typically not on the acces= s
point. Definitely there is merit in notifying it but don't know ho= w
MAG will know those characteristics=A0

Carlos: LMA can benefit from having additional info from the MAG. Not
only about radio conditions, it is just one of the capabilities. This<= /div>
is an important issue to address=A0

Raj:= Idea is to convey more decisions to LMA , not talking about flow
mobility. Some concerns, who knows about the status of the mobile
node, idle or active etc=A0

---------------------= -------------------------

9. Mapping PMIP Quality = of Service in WiFi Network =A0
=A0 =A0I-D: draft-kaippallimalil-netext-pmip-qos-wifi-01 =A0 =A0 J. Ka= ipallimalli

- Based up on the comments on version = 00 some updates have been made to 01.


Kent: Traffic filters based on IP layer.At AP layer it will be mac
based, how do u address overlapping IP address support?

=
Raj: Will request additional reviews of the I-D and encourage mo= re
discussion on the list.

-------------= ---------------------------------

10. Seamless Handover for Multiple-Access Mobile Node i= n PMIPv6 =A0=A0
=A0 =A0 I-D: draft-cui-netext-pmipv6-shpmipv6 =A0 =A0 =A0<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> Y. Chen

Time ran out and hence this I-D was not discussed at th= e meeting.

---------------------------------------= -------

Summary and Next steps:

- Three documents will go to LC before the next IETF meeting.

1. pd-pmip
2. logical-interface - to be de= cided whether ready for last call
3. flow-mobility=A0

Strong consensus to adapt Suresh's draft. Will follow up= on the
mailing list.


--
B= asavaraj Patil
--14dae93405f310522604d020f7d0-- From jouni.nospam@gmail.com Sat Dec 8 12:43:42 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CA521F8690 for ; Sat, 8 Dec 2012 12:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.384 X-Spam-Level: X-Spam-Status: No, score=-3.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZJgQoy--34c for ; Sat, 8 Dec 2012 12:43:42 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B2AC821F8568 for ; Sat, 8 Dec 2012 12:43:41 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so1228307lah.31 for ; Sat, 08 Dec 2012 12:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nWH1hZcnSHLNbrOFvnOUHo94g7HuG6FxujA+blZGDw4=; b=BxU0obXo5JZfC/3udhJPbaXOCG2IoKD5etkRzpwsMZ/MLj/4fWuSbvj9kOiqklUx0h 3Qn52vppoQe20DA8CCPNn+mwoBXYdNTs8syYjp/UfcfGQYPt6N8OfGq1MVVDDp8Kd1Wp bQLZatHg7nw0D12OiuUiNYZnXHsvLNs/GtH5i+EuxgTEaG9hnvSgna+hNRlon23l6TYR FpBF1FW9E7AHjlJQebX+5RGZQ7BVS/gxJpXggP/01bX5vASsBnhaqKPvU0KXxeHgFPtA j9YNG4wnlD+++PBVVb8Yy1YqvyS193ogDBjDVYd0HYtDKkwETXTwggfpSitXC7kzl8RV kBBQ== Received: by 10.112.39.74 with SMTP id n10mr4204099lbk.56.1354999420690; Sat, 08 Dec 2012 12:43:40 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:45b3:aa7d:6cca:c78? ([2001:1bc8:101:f101:45b3:aa7d:6cca:c78]) by mx.google.com with ESMTPS id v7sm4931132lbj.13.2012.12.08.12.43.36 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 08 Dec 2012 12:43:39 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: Date: Sat, 8 Dec 2012 22:43:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <512BCA91-B3B8-4687-84B5-DB81D8EA1117@gmail.com> References: To: Basavaraj Patil X-Mailer: Apple Mail (2.1499) Cc: netext@ietf.org Subject: Re: [netext] IETF85: Netext WG meeting minutes X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 20:43:42 -0000 > - RFC5149 bis LC completed I have one late comment to the I-D. In Section 3.1 I should probably = also mention that Service Selection is also usable with binding = revocation [RFC5846]. At least that it what implementations do. - Jouni From sgundave@cisco.com Sun Dec 9 07:57:28 2012 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6021121F8C3B for ; Sun, 9 Dec 2012 07:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJUEdQbB3021 for ; Sun, 9 Dec 2012 07:57:27 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CE3A621F8C01 for ; Sun, 9 Dec 2012 07:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=580; q=dns/txt; s=iport; t=1355068648; x=1356278248; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Seu4F/p8SmAS1bBYnLdWTS56VEZSlYj0Ivm0tQoS8qY=; b=IxlBbJAoxeiGV3wte1cWUt280YdjlJsVdfK5Hb6332Ebzi56YxiT4Tex 2XDJ7MEo1iah3bynkFTJoBqnDfbktVhtWJPjAF7AomfkvdwzyJTHUJtKH OBuRL9wysTh6MHxQ8y4CA0H/HgdnqOiwT1ev4oMi04jFNAxUir1Wt4lxO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFACm0xFCtJXHA/2dsb2JhbABDhXC4bhZzgiABBAEBATctBwsSAQgiFDEGCyUCBAENBQiHdwMPDLRhDYlQBItWhEthA5QwjQ2FEYJzgiI X-IronPort-AV: E=McAfee;i="5400,1158,6920"; a="151013650" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 09 Dec 2012 15:57:27 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qB9FvR9h030295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Dec 2012 15:57:27 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.203]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sun, 9 Dec 2012 09:57:27 -0600 From: "Sri Gundavelli (sgundave)" To: Jouni Korhonen , Basavaraj Patil Thread-Topic: [netext] IETF85: Netext WG meeting minutes Thread-Index: AQHN1iXizWXIMXA1EkSBXnQhhx1mUA== Date: Sun, 9 Dec 2012 15:57:26 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8100357B6@xmb-aln-x03.cisco.com> In-Reply-To: <512BCA91-B3B8-4687-84B5-DB81D8EA1117@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.214] Content-Type: text/plain; charset="us-ascii" Content-ID: <1CC3139ADD5CC54BBECC20A0589FEDF4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "netext@ietf.org" Subject: Re: [netext] IETF85: Netext WG meeting minutes X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Dec 2012 15:57:28 -0000 Ack. The option is relevant for PBU/PBA/BRI/BRA/Notification messages carried between LMA and MAG. Sri On 12/8/12 12:43 PM, "Jouni Korhonen" wrote: > >> - RFC5149 bis LC completed > >I have one late comment to the I-D. In Section 3.1 I should probably also >mention that Service Selection is also usable with binding revocation >[RFC5846]. At least that it what implementations do. > >- Jouni > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext