Subject: [mif] Fw: TR: I-D Action:draft-ietf-mif-problem-statement-03.txt

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 6 May 2010 08:53:52 -0700 (PDT)

Hi Pierrick,
  This comment that I posted on March 24 has not been resolved?

Regards,

Behcet

----- Forwarded Message ----
> From: Behcet Sarikaya <[email-masked]>
> To: Marc Blanchet <[email-masked]>
> Cc: [email-masked]
> Sent: Wed, March 24, 2010 2:36:52 PM
> Subject: Re: [mif] WG LC for MIF PS
> 
> Here is one more issue that I forgot to write about last week:
In Sec. 3.1 
> you say:
Proxy MIP allows sharing a single IP address across multiple 
> interfac
  es (e.g., WiMAX and CDMA, LTE and HSPA, etc) to disparate 
> networks.
  From the IP stack view on the node, there is only a single 
> interface
  and single IP address.  Therefore, this situation is 
> out of scope.
  Furthermore, link aggregation done under IP where a 
> single interace
  is shown to the IP stack is also out of 
> scope.

I don't quite understand what this paragraph is really referring 
> to. Are you talking about MIPv6 which has the Home Address concept, i.e. outside 
> world know MN by its HoA and the different interfaces only get care-of addresses 
> which are temporary. Is the problem described above referring to this?
In 
> PMIPv6 each interface is independent of others, at least in the current RFC 
> 5213. Are you saying that this causes 
> problems?

Regards,

Behcet

----- Original Message 
> ----
> From: Marc Blanchet <> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]>
> 
> To: Behcet Sarikaya <> href="mailto:[email-masked]">[email-masked]>
> Cc: > ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]
> Sent: Tue, March 23, 2010 
> 11:06:58 AM
> Subject: Re: [mif] WG LC for MIF PS
> 
> Behcet 
> Sarikaya a écrit :
> I read this draft. I also support this draft 
> 
> moving forward because it describes the problems nicely.
> My comments are 
> 
> as follows:
> 1. Reading statements like there is no set of high 
> level API 
> to
>    provide all required services for a 
> connection 
> manager
>  the draft sounds like a requirements 
> draft while it is in 
> fact PS draft.

stating a fact like there is 
> no high level API is not 
> necessarily a requirement. A REQ document 
> would define requirements such as " 
> This feature MUST be ...".  I 
> don't think we have this kind of text in the 
> current PS.

> 2. 
> All references are informational. In PS documents 
> (RFC 4093, 4487, 
> etc.) formative references can be made, like RFC 1122, 3484, 
> 4294, etc. 
> so why not have some?

I'm not sure what we gain to have 
> 
> normative references for PS documents. Having said that, if you can provide the 
> 
> list of normative references, then we can change them.

> 3. I 
> think 
> Section 11 should be removed.
>  

does not 
> harm. will 
> remove.

> Here are some typos I found:
> 
> 
> s/interfac
>    es (e.g., WiMAX and CDMA, LTE and HSPA, 
> 
> etc)/interfaces (e.g., WiMAX and CDMA, LTE and HSPA, etc.)
> 
> s/single 
> interace/single interface
> s/Default Address Selection 
> [RFC3484]/Default 
> Address Selection specification [RFC3484]
> 
> s/MIF similar issues/issues 
> similar to MIF
> s/of a same 
> connection/of the same connection
> In 
> Sec. 4.3 it says
> 
> Any of the following situations may occur:
> but 
> only one is 
> listed?
> s/4) Address selectiona and 5) connexion 
> 
> management/4)Address selection and 5) connection management
> s/the 
> 
> [RFC1122] strong model/the strong host model 
> 
> [RFC1122]

thanks!

Marc.

> 
> 
> 
> Regards,
>  Behcet
> 
> 
>      
> 
> _______________________________________________
> mif mailing 
> list
> 
> 
> href="mailto:> href="mailto:[email-masked]">[email-masked]">> href="mailto:[email-masked]">[email-masked]
> 
> href="> href="https://www.ietf.org/mailman/listinfo/mif" target=_blank 
> >https://www.ietf.org/mailman/listinfo/mif" target=_blank 
> >> href="https://www.ietf.org/mailman/listinfo/mif" target=_blank 
> >https://www.ietf.org/mailman/listinfo/mif

-- =========
IPv6 
> 
> book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn 
> server for 
> VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news 
> service: 
> http://reeves.viagenie.ca
NAT64-DNS64 Opensource: 
> 
> http://ecdysis.viagenie.ca

_______________________________________________
mif mailing list
> ymailto="mailto:[email-masked]" href="mailto:[email-masked]">[email-masked]
> href="https://www.ietf.org/mailman/listinfo/mif" target=_blank 
> >https://www.ietf.org/mailman/listinfo/mif

---

From: <[email-masked]>
Date: Fri, 7 May 2010 10:24:06 +0200

Hi Behcet,

Section 3.1 just states that MIF issues do not arise when using mechanisms presenting a single IP infterface, i.e. a logical interface, to applications, even when multiple physical interface come into play. PMIP is just an example; I agree text could be clarified.

Regards,
Pierrick

-----Message d'origine-----
De : Behcet Sarikaya [mailto:[email-masked]] 
Envoyé : jeudi 6 mai 2010 17:54
À : SEITE Pierrick RD-RESA-REN; [email-masked]
Objet : Fw: [mif] TR: I-D Action:draft-ietf-mif-problem-statement-03.txt

Hi Pierrick,

Regards,

Behcet

----- Forwarded Message ----
In Sec. 3.1 

> to. Are you talking about MIPv6 which has the Home Address concept, 
> i.e. outside world know MN by its HoA and the different interfaces 
> only get care-of addresses which are temporary. Is the problem described above referring to this?
In 
> PMIPv6 each interface is independent of others, at least in the 
> current RFC 5213. Are you saying that this causes problems?

Regards,

Behcet

----- Original Message 
> To: Behcet Sarikaya <> 
> href="mailto:[email-masked]">[email-masked]>
> 1. Reading statements like there is no set of high  level API  to
>    provide all required services for a  connection  manager
>  the draft sounds like a requirements  draft while it is in  fact PS 
>draft.

> no high level API is not
> necessarily a requirement. A REQ document would define requirements 
> such as "
> don't think we have this kind of text in the current PS.

does not 

thanks!

Marc.

-- =========
IPv6 
Stun/Turn 
DTN news