Re: [MIPSHOP-MIH-DT] draft-melia-mipshop-mstp-solution-01a.txt

[Subir Das <[e-mail]>]

Tele,
In general I support the approach of adding in an appendix for the time 
being.
There were some typos. So pl. use the following text but I did not 
understand the
last part and see my comments below.

-Subir

11. Appendix

   This appendix contains AAA specifications to convey MoS realted
   information from the AAAh to the NAS for scenario 3.  Due to lack of
   time we did not post a separate ID.

11.1.  Attribute Value Pair Definitions

11.1.1.  MoS Info

   The MoS-Info AVP (AVP code TBD) is type of Grouped and contains
   necessary information to assign a MoS to the MN.  When the MoS-Info
   AVP is present in a message, it MUST contain either a MIH-MoS-Address
   AVP or a MIH-MoS-FQDN AVP, but not both.  The grouped AVP has the



Melia, et al.              Expires May 3, 2008                 [Page 24]

Internet-Draft                    MSTP                      October 2007


   following grammar:

   artwork <MoS-Info> ::= < AVP Header: TBD >
                                [ MIH-MoS-Address ]
                                [ MIH-MoS-FQDN ]
                              * [ AVP ]

11.1.2.  MIH-MoS-Address AVP

   The MIH-MoS-Address AVP (AVP Code TBD) is of type Address and
   contains the MoS address.  The Diameter server MAY decide to assign a
   MoS to the MN that is in close proximity to the point of attachment
   (e.g., determined by the NAS-Identifier AVP).  There may be other
   reasons for dynamically assigning MoS to the MN, for example to
   share the traffic load.

   This AVP MAY also be attached by the NAS when sent to the Diameter
   server in a request message as a hint of a locally assigned MoS
   address.

11.1.3.  MIH-MoS-FQDN AVP

   The MIH-MoS-FQDN AVP (AVP Code TBD) is of type UTF8 String and
   contains the FQDN of a MoS.  The usage of this AVP is equivalent to
   the MIH-MoS-Address AVP but offers an additional level of indirection
   via the DNS infrastructure.

11.1.4.  MoS Capability

   The MoS-Capability AVP (AVP Code TBD) is of type Unsigned64 and
   contains a 64 bits flag field of supported capabilities of the NAS/
   ASP.  Sending and receiving the MoS-Capability AVP with value 0 MUST
   be supported.

   The NAS MAY include this AVP to indicate capabilities of the NAS/ASP
   to the Diameter server.  For example, the NAS may indicate that a
   local MoS can be provided.  Similarly, the Diameter server MAY
   include this AVP to inform the NAS/ASP about which of the NAS/ASP
   indicated capabilities are supported or authorized by the ASA/MSA(/
   MSP).

   The following capabilities are defined in this document:

   o  MOBILITY_CAPABILITY (0x0000000000000000) -- The MoS-Capability AVP
      MAY contain value 0 (zero) with the semantics that are defined in
      this document for the Mobile IPv6 bootstrapping functionality.
      This 'zero' flag is always implicitly set when the MoS AVP is
      used.



Melia, et al.              Expires May 3, 2008                 [Page 25]

Internet-Draft                    MSTP                      October 2007


   o  LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000001) -- This flag is
      set by the NAS/ASP when a local MoS can be assigned to the MN.
      This flag is set by the ASA/MSA(/MSP) when the use of a local MoS
      is authorized.

Subir> What are these above two flags?. Looks to me that these are left over
from MIpv6 draft. Either we change the MOBILITY_CAPABILITY as MOS Service
capability like ES, CS and IS and add three flags or delete it for the 
time being. Similarly
LOCAL_HA_ASSIGNEMENT should be LOCAL_MOS_ASSIGNMENT.


Telemaco Melia wrote:
> Guys here it goes -01b.
>
> Log change from version -01a:
> -- input posted on the list included
> -- section 5.3 added with more text (pleas read and check consistency)
> -- added an appendix for the diameter extensions to convey MoS 
> information from AAAh to the NAS.
>
> Subir, with the appendix, the intention is to describe the options 
> required and to show to the WG that we have everything in place.
> We can submit a separate draft later on and explain to the WG already 
> in Vancouver what are our plans.
> What do you think?
>
> Let me know your comments asap...we ll be able to implement your 
> changes only on Monday morning though (still here for few hours).
>
> Tele
>
>
> [e-mail] wrote:
>> Some inline:
>> -----Original Message-----
>> From: ext Telemaco Melia [mailto:[e-mail]] Sent: Tuesday, 
>> November 13, 2007 9:02 AM
>> To: [e-mail]
>> Subject: [MIPSHOP-MIH-DT] draft-melia-mipshop-mstp-solution-01a.txt
>>
>> Guys,
>>
>> I started the editorial work considering the APs agreed last AC.
>> I summarize in the following the list of issues and mark them as
>> solved/open.
>> I ll be in the office still for a while. Let me know if you wan the xml
>> to directly edit the text.
>>
>>
>> - Do not mandate anything to .21 on the use of MIHFIDs: SOLVED The text
>> has been removed accordingly
>>
>> - mandate both TCP/UDP server side and leave it optional for MN" SOLVED
>> Text has been added at the end of section 6.
>> - Gabor to update the DNS draft to reflect previous point: OPEN
>>
>>
>>
>> <Gabor> I can not mandate the support for it in the DNS draft, that has
>> to be done in this mstp-solution draft.  What I will do is to
>> additionally define an application tag for SCTP.
>>
>> The current text in section 6 says that "MIH peers MUST exchange
>> information over either TCP or UDP". I do not think this is right based
>> on the discussions we had. The MIH peers MAY exchange information using
>> any other transport supported by both MIH end points, and whether the
>> server supports it or not, can be discovered using the DNS discovery.
>> Suggested text: "MIH peers MAY exchange information over TCP, UDP or any
>> other transport supported by both the server and client. The client MAY
>> use the DNS discovery mechanism to discover which transport protocols
>> are supported by the server in addition to TCP and UDP".
>> Regarding the usage of ACK: the text should say "MIH ACK mechanism MAY
>> only be used with unreliable transport mechanisms, like UDP" Section 
>> 6.3: "If UDP is being used to carry MIH messages, MIH MUST use
>> MIH ACKs." I propose relaxing this to "If UDP is being used to carry MIH
>> messages, MIH SHOULD use MIH ACKs."
>> Section 6.5: "MIH messages sent over UDP or TCP MUST use the default
>> port number." to be changed to "MIH messages sent over UDP, TCP or other
>> supported transport MUST use the default port number defined for that
>> particular transport."
>>
>>
>> - Gabor to revise section 5: OPEN
>> Text has been proposed and the section adjusted. Still work needed.
>>
>> <GABOR> I have done my part, I thought the rest can be addressed by you
>> guys.
>> Issues:
>> 6.2 Header: change MIN to MN
>> Section 5.3, 2nd paragraph: word "section" is duplicated.
>>
>> I am writing the DHCP options draft. We defined the options: "MoS
>> Identifier Option", "MIP6 Relay Agent MoS Option" and "MoS Information
>> Option" and those should be used instead of the options defined in
>> [I-D.ietf-mip6-hiopt] (and also draft-bajko-dhcp-discovery referenced
>> instead of the hiopt one).
>>
>> This text: "   It should be noted that the AAAh does not know the
>> preferences of the
>>    MN, i.e. whether the MoS should be allocated in the home or in
>>    visited. The MoS info is stored at the relay agent and forwarded to
>>    the MN according to the flags in the Home Network Identifier Option."
>> Should be modified to "It should be noted that the AAAh does not know
>> the preferences of the MN at the time of authentication, i.e. whether
>> the MoS in the home or in the local network is to be sent to the MN. The
>> MoS information will anyway be sent to the AAAV, then stored in the
>> relay agent and ultimately sent to the MN if the MN asks for it, using
>> the procedures defined in [draft-bajko-dhcp-discovery]"
>>
>> - Gabor to update DHCP option draft for scenario 3: OPEN I added the
>> reference to the draft the integrated bootstrapping ID refers to
>> (draft-ietf-mip6-hiopt-08.txt) I think the DHCP option document should
>> contain something similar.
>>
>>
>> I am working on the DHCP options draft. It got a bit complicated because
>> we now want to use it for both local and home MoS discovery. But I'll
>> finish it before the deadline.
>>
>> Thanks,
>> - gabor
>>
>>
>> - me/Subir to suggest AAA extensions based on
>> draft-ietf-dime-mip6-integrated-06.txt: OPEN I did not touch this yet.
>> We can simply refer to it for the time being.
>>
>> - Subir to revise the flow example: SOLVED
>>
>> - Nada to revise the terminology section: SOLVED I already integrated
>> the text David proposed.
>>
>> - Subir to propose some text for L2 security for DHCP: OPEN
>>
>> - Subir to propose text discussing the issue when DHCP authentication is
>> not available: OPEN
>>
>> - Subit to clarify with Yoshi about DTLS/TLS: OPEN
>>
>> - Tele to expand section 5.3: OPEN
>>
>> - Tele to add text that scenario 5.4 only holds for IS: OPEN
>>
>> - No need to change MoS to PoS: SOLVED
>>
>> - Nada to check with David for additional flows: OPEN
>>
>>
>>
>>
>> Tele
>>
>>
>>   
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> MIPSHOP-MIH-DT mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

_______________________________________________
MIPSHOP-MIH-DT mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt