Hi,
Sundar Yamunachari wrote:
> Dave,
>
> Thanks for the review.
>
>
> Dave Miner wrote:
>> Sundar Yamunachari wrote:
>>> Hi,
>>>
>>> The functional specifications for AI transport (Web Server
>>> redesign) is available at
>>> http://wikis.sun.com/display/OSOLInstall/Web+Server+Redesign+Functional+Specification.
>>>
>>> Please review the specs and provide your feedback by 06/15/09
>>>
>>
>> Most of this looks pretty good. Some things to consider:
>>
>> General: Please retitle this from redesign to version 2, or similar.
> okay
>>
>> 1.b: I've never encountered use of the security attributes noted here
>> for torrents; is there a reference you can point to on cases where
>> this has been done?
> That may be a typo. Keith looked at the bittorrant and I will check
> with him.
I just spent about a half hour looking into this; most of the scenarios
for securing bittorrent traffic are targeted at obfuscating the fact
that the traffic is bittorrent (with the purpose of preventing ISPs from
throttling BT traffic). There is some potential for secure transmission
using Message Stream Encryption (see link below); however, that is noted
as targeted at, again, obfuscating traffic - I am unsure of how secure
it actually would be. The biggest issue with encrypting bittorrent
traffic is the number of connections that a client initiates; encrypting
each connection would add a lot of overhead, it seems.
http://www.azureuswiki.com/index.php/Message_Stream_Encryption
>>
>> 2.f.: Could use discussion of goals for multiple servers might
>> interact, and how to scale the server infrastructure. Will a
>> transport be expected to work correctly with content caching
>> infrastructures such as squid? What would a high-availability server
>> environment look like? Are we relying merely on clustering for HA?
> We discussed caching proxies like squid. The discussion is documented
> at
> http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/transport_options.pdf.
>
> We haven't discussed about high-availability environments. We will
> have a discussion and update the spec.
>>
>> 5.c: Are all transports required to provide secure options?
> We looked at the security options that can be supported in the
> transport. It should be noted that it is optional. If the transport
> support security, we will provide means to enable the security. I will
> update the spec to indicate that it is optional and depends on the
> transport.
That loops back to the point above.
>>
>> 5.f: There seem to be requirements here to enhance the TFTP service.
>> Should discuss with networking team.
> That is a good idea. Who is the contact in the networking team?
>>
>> 6.b: This is identical, or nearly so, to 6.a, which isn't surprising
>> since they are really just two pieces of the same puzzle. Recommend
>> consolidating and up-leveling: rather than specific reference to
>> solaris.zlib or solarismisc.zlib (both are undefined terms in this
>> document), I would suggest referring generally to "archives required
>> to assemble the complete installation environment" or something of
>> that ilk.
> We will fix the use case. We started with the transport diagram
> (http://www.opensolaris.org/os/project/caiman/auto_install/ai_design/transport_data_diagram.pdf)
>
> with a single step for getting all the stuff other than the
> boot_archive. To understand the current use case, it is split in to two.
>>
>> 6.d: I'm not sure how well this use case maps to a P2P transport;
>> they typically operate on a pull model, yet this appears to be a push
>> model.
> We are learning about the P2P model. So this needs work.
Also, as mentioned in Note 2, this use case may not necessarily be
handled by the same transport mechanism. Certainly, connections that
involve a client's specific log file being transmitted to a single
location do not fit into a P2P model - P2P implies that groups of
clients desire identical files; in this use case, only 2 actors are
involved - the client (creating the log file) and the observer (reading
the log file).
>>
>> 6.e: Standard term is derived manifests.
> Okay
>>
>> 6.f: Is P2P really a use case? It seems like a solution to (at least
>> some of) the other use cases, rather than a use case in its own right.
> We try to fit our current transport requirements to P2P. We will work
> on it to make it better.
>>
>> A use case for archive-based installation seems worth adding.
> You mean replication? I can have a use case bases on existing flash
> technology with out any of the implementation details of flash.
>>
>> Finally, I'm wondering how this relates to a "serverless" automated
>> installation, which is what the Virtual Machine Constructor seems to
>> be requiring. Is there a sort of "null" transport that would be used
>> there? Just trying to sort out how the architecture is anticipated
>> to adapt to that case.
> In our use cases, the client ask for the specific data and server
> provides the data. In the case self-contained AI, the client will not
> use any transport. So I think it should work. Still have to think
> about how the client gets the AI manifest.
>
> Thanks,
> Sundar
>>
>> Dave
>
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
