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

[Telemaco Melia <[e-mail]>]

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