Pekka,
>On Mon, 4 Mar 2002, Atsushi Inoue wrote: >> >A few comments in addition to ones I sent for -00.. >> > >> > Table 1. Resource restrictions of LCNA >> > >> > ===============+===============+==================+======= >> > Memory CPU Performance OS >> > ===============+===============+==================+======= >> > PC >64MB Pentium/64bits Windows >> > ---------------+---------------+------------------+------- >> > PDA 2-8MB RISC/32bits(50MHz) WinCE >> > VxWorks >> > PalmOS >> > >> >==> I think it'd be policitally correct to _at least_ change 'Windows' >> >there to 'Any', and possibly add 'Others' to PDA section (e.g. I like >> >Linux and NetBSD on PDA's :-). >> >> The footprint of WinCE is 1MB as announced, but the CPU performance >> of pocket PC becomes higher and higher. So, as you suggested we >> should replace winCE with embedded Linux or others if we keep on >> this device class. > >No, I'm proposing something like: > >--8<-- > ===============+===============+==================+======= > Memory CPU Performance OS > ===============+===============+==================+======= > PC >64MB Pentium/64bits Any > ---------------+---------------+------------------+------- > PDA 2-8MB RISC/32bits(50MHz) WinCE > VxWorks > PalmOS > Others >--8<-- > >Or even, remove WinCE from there completely. This is just what I proposed on the last reply, so I will change as you suggested. >> >2.7 Security >> > In Section 4 "Security for LCNA", we will regulate a baseline for >> > guaranteeing that a minimum host can communicate securely. However, >> > Denial of Service (DoS) and intrusion are out of scope. So, we have >> > to consider defending from DoS and/or intrusion in another place. >> > Also, the authentication of users is out of scope, because some >> > minimum hosts can omit a mechanism of user accounts. >> > >> >==> intrusion out of scope? What do you mean by that? >> >Auth? >> >> Here, we mention about intrusion as a typical case that LCNA and >> other device (such as firewall) work togather in order to provide >> specific security solution. "Intrusion out of scope" simply means >> that our spec only treats the end node itself and the security >> functionality provided by node and other network devices is not >> considered yet. > >Did you perhaps mean 'Interaction with Intrusion Detection Systems'? If >so, I definitely agree. By intrusion I understand a remote break-in into >the device, which is _definitely_ in the scope.. (you really don't want >your oven being heated up when you're away, do you :-) Agree. But we have not decided whether we have a concept of valid users when using LCNAs. Of course, some mechanism for authentication and authorization is necessary, but how those discriminatgion of access is done is out of scope for our draft. So, the correct description is: Preventing DOS and/or intrusion by collabotration with other network devices is out of scope. Intrusion to node itself have to be handled by some security mechanisms, but the detail of that is not described yet (FFS). > >> > - When it can recognize the extension header but does not support >> > the options in it, it MUST perform error processing according to >> > the option number. >> > >> >==> you mean s/extension header/destination options header/? There is no >> >processing defined by option number for extension headers. >> >> This is our typo. The correct description is as follows: >> >> When it can recognize the extension options headers but does not >> support the options in it, it MUST perform error processing according >> to the option type. (as secified in section 4.2 of RFC2460) > >Not all extension headers necessarily have TLV-encoded options which >contain the option type coded like that. E.g. routing header has RH type >coded differently. > >This is a bit of academic discussion though, as LCNA's don't intend to >support RH; but there might be some headers in the future that behave the >same way: you might not always find TLV-encoded options coded like that >inside. So, the wording might be a bit more careful. Thanks for pointing out that. > >> > [Receiving] >> > A minimum host SHOULD recognize it as a Hop-by-Hop Options Header, >> > and perform the processing according to the option and option >> > number in it. Because this option is used for signaling and router >> > alert, in order to control routers on the path, all nodes on the >> > transmission path have to interpret this header but do not need to >> > interpret all options in it. >> > >> >==> I don't understand your reasoning for router alert; LCNA's aren't >> >routers by definition :-) >> >> RFC2460 says, >> "The Hop-by-Hop Options header is used to carry optional >> information that must be examined by every node along a packet's >> delivery path." >> so we regulated that the examination of Hop-by-Hop option have to be >> performed even on LCNA. Is it too redundant ? > >Yes, I think the latter part of that paragraph is being overly verbose >(discussing non-LCNA issues and motivations) -- one _might_ add something >there about the applicability of HBH for e.g. signalling, but I'm not sure >if it's necessary. We will revise the wording of this part on -02 draft. --inoue -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
