Hi Sundar,
On 02/25/09 07:02, Jan Damborsky wrote: > Hi Sundar, > > > Sundar Yamunachari wrote: >> Jan Damborsky wrote: >>> Hi Sundar, >>> >>> Sundar Yamunachari wrote: >>>> jan damborsky wrote: >>>>> Hi Dave, >>>>> >>>>> >>>>> On 02/19/09 22:48, Dave Miner wrote: >>>>>> A couple of comments in-line: >>>>>> >>>>>> jan damborsky wrote: >>>>>>> Hi Sundar, >>>>>>> >>>>>>> I have been thinking about support for unicast DNS part (section >>>>>>> 1.2) >>>>>>> and it seems we would need to provide option for specifying DNS >>>>>>> domain for unicast DNS, since DNS server might reside in different >>>>>>> domain than AI server, for instance >>>>>>> >>>>>>> # installadm create-service [-u domain] ... >>>>>>> >>>>>>> '-u' would be optional and its presence would determine if unicast >>>>>>> DNS is to be used. If not provided, unicast DNS wouldn't be taken >>>>>>> into account. >>>> Currently we find unused port numbers and start AI web server. When >>>> it comes to unicast, we should allow user to use the same well >>>> known port for the service. Otherwise preconfiguring or replicating >>>> same DNS entries difficult. I would like us to take port numbers to >>>> start web servers in the case of unicast setup. >>> >>> If you agree, then we might use optional '-p port' command line option >>> in order to provide user with a way to explicitly specify which port >>> should be picked up by the service. >>> >>> If not specified, port number for unicast DNS would be determined by >>> utilizing >>> the same algorithm which is used for for multicast DNS. >>> >>> In order to provide consistent user experience, we might allow this >>> to be used for both multicast as well as unicast DNS. >> I understand the desire to have consistency for unicast and >> multicast. What I am saying is that the default behavior is multicast >> if the user doesn't specify the option to setup multicast. The port >> number makes more sense for the user if the unicast is setup since >> the DNS records needs to be updated. >> In the case of multicast, the user doesn't care about the port since >> the user doesn't need to update anything. > > As far as update of DNS database is concerned, I think that AI server > might > generate exact format of PTR and SRV records to be added including > service > name and location of install service (machine along with port number), > so that user > could use copy-paste approach - it would be similar to what we do for > DHCP macros. > Since service name as well as service location are to be determined > automatically > by AI server, why not to follow the same approach for port number ? > I agree with you that this would be useful feature to have - I am > thinking if we could let > AI server to pick up port number for unicast DNS by default, or if > there are some > restrictions which would mean that port number would need to be always > provided. in order to close loop on this discussion, I have captured outcome from our talk regarding this problem - please feel free to correct me in cases I have misunderstood. For unicast DNS, the port number parameter would be optional and would serve in cases, when user would like the service to be available on particular port - e.g. when the network infrastructure allows the net traffic to go only through dedicated ports (for instance due to the configuration of firewalls) or when unicast DNS server is to be prepopulated with appropriate records first before install service is created. As far as multicast DNS is concerned, port number parameter will not be supported - to be honest I don't remember the particular reason - might you please help me to clarify what was the reason ? Thank you, Jan
