Re: D116 Design draft, misc. comments

hi tero,  

please find a minor comment below: 

> -----Ursprüngliche Nachricht-----
> Von: [email protected] 
> [mailto:[email protected]] Im Auftrag von Tero Kivinen
> Gesendet: Dienstag, 3. Januar 2006 19:45
> An: [email protected]
> Cc: [email protected]
> Betreff: [Mobike] D116 Design draft, misc. comments
> 
> [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 protected] 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. 

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.

and 

[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.

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.

> 
> > - 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. 

ciao
hannes

> -- 
> [email protected]
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>