Subject: [Mobike] D116 Design draft, misc. comments

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Jan 2006 20:44:50 +0200

[issue list: http://www.kivinen.iki.fi/ietf/mobike-design-issues.html
 working copy of document:
 http://www.kivinen.iki.fi/ietf/draft-ietf-mobike-design-06.txt]

[email-masked] writes:
> - Section 1, "for example when using SecurID cards" -> "for example, 
>   when using human-operated token cards" 

Done.

> - Section 3.2: "Each peer selects one of its IP addresses as the
>   preferred address which is used for subsequent communication."
>   There's some conflict here. It's the initiator who selects
>   which addresses are used for subsequent communication (except
>   in relatively rare situations, ie. responder address changes).

In mobike-protocol it is initiator. Here we also describe other
options. No conflict, we simply do not fully support that scenario in
current protocol (i.e. responder preference is ignored). 

> - Section 4: "The MOBIKE protocol should be able to perform...":
>   this text may need to be rewritten once we either come up 
>   with a reasonable definition for "preferred address", or 
>   get rid of the term completely.

Again disagree. This is not describing only the current protocol, but
also design choises behind the current protocol. That means we need to
describe things in more general ways than what current protocol
document requires.

> - Section 4: The talk about "MOBIKE daemon" creates the impression
>   that there typically would be both an "IKEv2 daemon" and
>   "MOBIKE daemon", running as separate processes. While this is  
>   not impossible, I would find it a very strange way to implement
>   a relatively minor extension to IKEv2. (After all, if we implement 
>   some other IKEv2 extension like draft-nir-ikev2-auth-lt,
>   we don't call it the "Repeated Authentication Daemon" or something.)

True. Perhaps MOBIKE module would be better term. Changed to MOBIKE
module. 

> - Section 5.1.4, 1st paragraph: closing parenthesis missing.

Fixed. 

> - Section 5.2.1, a couple of informative references might be 
>   in order (UNSAF, MIDCOM, NSIS NATFW)

Sure, give RFC / Internet-draft names, I will add them. 

> - Section 6.3: "The selected format needs to be flexible enough to
>   include additional information in future versions of the protocol
>   (e.g. to enable load balancing).  This may be realized with an
>   reserved field, which can later be used to store additional
>   information.  As there may arise other information which may have to
>   be tied to an address in the future, a reserved field seems like a
>   prudent design in any case."
> 
>   IMHO it would be quite difficult to design the protocol in a way 
>   that would totally prevent future extensions from sending
>   additional information. But currently we don't have any "reserved" 
>   fields there (simply because they're not needed -- the normal 
>   IKEv2 extension mechanisms will allow us to add more stuff later).

Actually we do. We have notification data, that is either empty of
fixed length, which means we can add stuff to it. 

> - References: should draft-ietf-mobike-protocol be normative?

I do not think so. It is not mandatory to read current protocol to
understand why we ended up there, and what other options were
considered and rejected. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 5 Jan 2006 13:05:53 +0100

hi tero, 
 
> -----Ursprüngliche Nachricht-----
> Von: Tero Kivinen [mailto:[email-masked]] 
> Gesendet: Donnerstag, 5. Januar 2006 12:13
> An: Tschofenig, Hannes
> Cc: [email-masked]; [email-masked]
> Betreff: Re: [Mobike] D116 Design draft, misc. comments
> 
> Tschofenig, Hannes writes:
> > here are the references: 
> >    [UNSAF]  Daigle, L. and IAB, "IAB Considerations for UNilateral
> >          Self-Address Fixing (UNSAF) Across Network Address
> >          Translation", RFC 3424, November 2002.
> > 
> > 
> > for midcom we could reference:
> > 
> > [RFC3303]   Srisuresh, P., Kuthan, J., Rosenberg, J., 
> Molitor, A. and A.
> >             Rayhan, "Middlebox communication architecture and
> >             framework", RFC 3303, August 2002.
> 
> Added those. 
> 
> > [MIDCOM-MIB]  Quittek, J., Stiemerling, M. and P. 
> Srisuresh, "Definitions of Managed Objects for Middlebox 
> Communication", draft-ietf-midcom-mib-05.txt (work in 
> progress), March 2005.
> 
> Is the mib here really relevant for the mobike design? I think the
> architecture and framework should be enough. I didn't add this one
> yet. 

it is ok for me to reference just the framework. i guess that everyone then already understands what is meant. 

ciao
hannes

> 
> > here is the nsis reference: 
> > 
> > [NSISNATFW]   Stiemerling, M., Tschofenig, H. and C. Aoun, 
> "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", 
> Internet-Draft draft-ietf-nsis-nslp-natfw-08, October  2005.
> 
> Added that. 
> -- 
> [email-masked]
>