> >To address this problem, an IP_BROADCAST_TTL socket option is proposed.
> >This option will be identical to the existing stable IP_MULTICAST_TTL
> >socket option, but will apply to broadcast traffic.
>
> is there some reason we can't simply extend IP_MULTICAST_TTL to also
>
> >We do have it for setsockopt(). It affects unicast traffic.
>
> Is there any dependency between IP_BROADCAST_TTL and
> SO_BROADCAST?
Given that SO_BROADCAST doesn't actually seem to do anything on Solaris
(other than retrieve the value it was set to), there's no interaction
today. In t
On Mon, 2007-11-05 at 15:06 -0500, Peter Memishian wrote:
>To address this problem, an IP_BROADCAST_TTL socket option is proposed.
>This option will be identical to the existing stable IP_MULTICAST_TTL
>socket option, but will apply to broadcast traffic.
is there some reason we can't
Darren Reed wrote:
> Peter Memishian wrote:
>
>> > >To address this problem, an IP_BROADCAST_TTL socket option is
>> proposed.
>> > >This option will be identical to the existing stable
>> IP_MULTICAST_TTL
>> > >socket option, but will apply to broadcast traffic. > > is
>> there som
I am sponsoring this case for Sriram Natarajan and myself and marking
it approved automatic as it is only enables a handful of built-in
extensions in the previously delivered php5.
Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI
This information is Copyright 2007 Sun Microsystems
1. Introd
James Carlson wrote:
> During review, one member noted that libcrypto and GNU TLS
> will require contracts. However, subsequent updates from
> the project team have removed the libcrypto usage, and the
> project intends to integrate via the SFW consolidation along
> with GNU TLS. Based on
> DHCP works on non-local LANs because of special forwarding
> performed for DHCP/BOOTP by routers.
I'm not sure why you call this "special forwarding" -- it's simply normal
DHCP relay agent behavior. Also, there is no requirement that a DHCP
relay agent be an IP router.
> I'd recommend upda
Peter Memishian wrote:
> > >To address this problem, an IP_BROADCAST_TTL socket option is proposed.
> > >This option will be identical to the existing stable IP_MULTICAST_TTL
> > >socket option, but will apply to broadcast traffic.
> >
> > is there some reason we can't simply extend
Peter Memishian wrote:
> > >We do have it for setsockopt(). It affects unicast traffic.
> >
> > Is there any dependency between IP_BROADCAST_TTL and
> > SO_BROADCAST?
>
>Given that SO_BROADCAST doesn't actually seem to do anything on Solaris
>(other than retrieve the value it was set to), there
Peter Memishian wrote:
> > DHCP works on non-local LANs because of special forwarding
> > performed for DHCP/BOOTP by routers.
>
>I'm not sure why you call this "special forwarding" -- it's simply normal
>DHCP relay agent behavior. Also, there is no requirement that a DHCP
>relay agent be an IP r
On Mon, 2007-11-05 at 15:13 -0800, Darren Reed wrote:
> Or do we simply say that the project defines whatever it wants
> to be its spec, use the internet draft as a reference and if/when
> the RFC becomes published and there's a change, someone
> hopefully remembers and publishes another case that
On Mon, Nov 05, 2007 at 03:13:44PM -0800, Darren Reed wrote:
> To PSARC:
>
> So this brings up a question - how do we approve a case where:
> - the primary spec is currently a draft (an IETF one at that)
> - defined by an outside body
> - the spec may change after the project completes (unlikely)
Below is an exchange from Steve Uhler, from SubLabs,
and the OSS architect from 4Front. From the inception
review, PSARC asked that Steve's issues be summarized and
sent to PSARC.
Main issues are:
1) SADA leverages streams and as a result, better able
to control latencies. Latency key to S
Hi Paul,
Yes, it looks like there is an open bug against gdb
6593753 gdb cannot read corefiles from gcore on Solaris 10
which behaves the same in the current development release (Nevada).
The current plan is not to upgrade software, although
gdb could be upgraded in a separate case. Thi
Darren J Moffat writes:
> James Carlson wrote:
> > During review, one member noted that libcrypto and GNU TLS
> > will require contracts. However, subsequent updates from
> > the project team have removed the libcrypto usage, and the
> > project intends to integrate via the SFW consolidatio
Nicolas Williams wrote:
> On Mon, Nov 05, 2007 at 03:13:44PM -0800, Darren Reed wrote:
>
>>To PSARC:
>>
>>So this brings up a question - how do we approve a case where:
>>- the primary spec is currently a draft (an IETF one at that)
>>- defined by an outside body
>>- the spec may change after the
james wahlig writes:
> return EAGAIN. When the NFSv2 server gets this, it will simply drop the
> response, causing the client to reissue the request. When the NFSv3
> server gets the EAGAIN w/CC_WOULDBLOCK, it will return the error
> NFS3ERR_JUKEBOX to the client. The NFSv3 client knows to re
Peter Memishian wrote:
>
>Details
>---
>
> To prevent broadcast packet storms, the TCP/IP stack sends all broadcast
> packets with a time-to-live of 1 (though this can be overridden with the
> ndd ip_broadcast_ttl tunable). This restriction has existed since
> Solaris 2.0 (if not
Darren J Moffat wrote:
> I'm happy with the need for this and vino. However I'm not at all happy
> with only a Volatile taxonomy. I think at very very least the pathname
> and the hostname:port needs to be Committed other options can be
> Volatile but I suspect some of them could be Committed too
http://www.opensolaris.org/os/community/arc/announcements/
OpenSolaris ARC Agenda
TELECONFERENCE NUMBERS:
(866)545-5223 (Within US)
(865)673-9887 (International)
External (to Sun Microsystems) callers ACCESS CODE 939-55-86
Times are US/Pacific Timezone
ARC meetings are recorde
Darren J Moffat wrote:
> With Windows heritage, shouldn't this feature eventually support the
> PSARC 2007/315 interfaces used by the CIFS server?
> >>> star will do this soon. it already allows to archive and restore the
> >>> *BSD
> >>> extended file flags.
> >> Can we _please_ s
Sangeeta Misra wrote:
> Darren Reed wrote:
>
>> Sangeeta Misra wrote:
>>
>>> Darren Reed wrote:
>>>
How will the configuration of class E addresses be handled by routed?
>>>
>>> RIPV1 wont be able to handle Class E , but RIPv2 should ( in.routed
>>> has both version) I will be filing a
Overview
This case proposes a consolidation-private IP_BROADCAST_TTL socket option
which will be used by the DHCP client to preserve interoperability with
broken DHCP servers. Patch binding is requested. Since this case should
be straightforward and since we'd like to addre
James Carlson wrote:
> Joerg Schilling writes:
> > James Carlson wrote:
> >
> > > Danek Duvall writes:
> > > > As a caution to anyone who uses 7z, it is not useful as a
> > > > general
> > > > purpose archiver on unix systems, as it does not store user and
> > > > group
Gary Winiger writes:
> Nit: Unstable isn't a current taxonomy. Uncommitted?
Yes; that leaked through. Fixed.
--
James Carlson, Solaris Networking
Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fa
James Carlson wrote:
>Rich.Brown at Sun.COM writes:
>
>
>> The first two new flags to be defined:
>> #define CC_WOULDBLOCK 0x1 /* set upon return by monitor */
>> #define CC_DONTBLOCK0x2 /* set by caller */
>>
>> The caller sets CC_DONTBLOCK in cc_flags to direct th
Joerg Schilling wrote:
> James Carlson wrote:
>
>> Joerg Schilling writes:
>>> James Carlson wrote:
>>>
Danek Duvall writes:
> As a caution to anyone who uses 7z, it is not useful as a general
> purpose archiver on unix systems, as it does not store user and
> group permis
James Carlson wrote:
> Danek Duvall writes:
> > As a caution to anyone who uses 7z, it is not useful as a general
> > purpose archiver on unix systems, as it does not store user and
> > group permissions. This is thanks to its Windows heritage.
> > However, there is no issue with
Bill Sommerfeld writes:
> In this case:
>
> "The integration of wireshark effectively makes snoop obsolete"
>
> gets the same message across in many fewer words.
OK; will change.
--
James Carlson, Solaris Networking
Sun Microsystems / 35 Network Drive71.232W Vox +
On Mon, 2007-11-05 at 12:50 -0500, James Carlson wrote:
> John Beck writes:
> > Is the first part of the sentence ("legacy Solaris") a typo, or ARC short-
> > hand with which I am not familiar? The rest looks fine.
> Scott Rotondo writes:
> > I think the word "snoop" is missing in the introductory
John Beck writes:
> Is the first part of the sentence ("legacy Solaris") a typo, or ARC short-
> hand with which I am not familiar? The rest looks fine.
Scott Rotondo writes:
> I think the word "snoop" is missing in the introductory clause, unless
> this project makes all of Solaris obsolete. ;-)
Danek Duvall writes:
> On Mon, Nov 05, 2007 at 07:37:37AM -0500, James Carlson wrote:
>
> > Danek Duvall writes:
> > > As a caution to anyone who uses 7z, it is not useful as a general
> > > purpose archiver on unix systems, as it does not store user and
> > > group permissions. This is tha
Please review and submit any comments you have to me by 11/12/2007.
Note to the project team and external observers: this is just a review
of the written opinion itself, to make sure that it accurately
reflects the issues discussed at the review. It's not intended as a
means to reopen or reargue
This fast-track has timed out with no comments and the
contract has been approved by both managers so I am
marking it closed approved.
Thanks,
Jerry
On Thu, 1 Nov 2007, Don Cragun wrote:
> I am submitting this case for April Chin.
> It seeks a minor release binding.
>
> I believe it qualifies for self review and am marking it closed
> approved. If anyone disagrees, let me know and I will change it to a
> fast track with the normal one week ti
> __
> |Interfaces Exported |
> ||_|_|
> |Interface | Classification | Comments |
> |
James Carlson wrote:
> 4.4. Snoop Obsolescence
>
> The integration of wireshark effectively makes legacy
> Solaris obsolete, and turns it into a burden both for sup-
> port and for future networking projects that may be required
> to provide both snoop and wireshark enhancements.
I thin
James> 4.4. Snoop Obsolescence
James> The integration of wireshark effectively makes legacy Solaris obsolete,
James> and turns it into a burden both for support and for future networking
James> projects that may be required to provide both snoop and wireshark
James> enhancements.
Is the first pa
Joerg Schilling writes:
> MS-Win has different interfaces and if you like to support the aditional
> flags,
> you would need to write compltely new interface code.
>
> For this reason, James introduced the level of off-topic-ness that I just
> followed up.
I never asked the team to make any ch
On Mon, Nov 05, 2007 at 07:37:37AM -0500, James Carlson wrote:
> Danek Duvall writes:
> > As a caution to anyone who uses 7z, it is not useful as a general
> > purpose archiver on unix systems, as it does not store user and
> > group permissions. This is thanks to its Windows heritage
Joerg Schilling writes:
> James Carlson wrote:
>
> > Danek Duvall writes:
> > > As a caution to anyone who uses 7z, it is not useful as a general
> > > purpose archiver on unix systems, as it does not store user and
> > > group permissions. This is thanks to its Windows heritage.
> > > H
Danek Duvall writes:
> As a caution to anyone who uses 7z, it is not useful as a general
> purpose archiver on unix systems, as it does not store user and
> group permissions. This is thanks to its Windows heritage.
> However, there is no issue with its usage for compressio
Rich.Brown at Sun.COM writes:
> The first two new flags to be defined:
> #define CC_WOULDBLOCK 0x1 /* set upon return by monitor */
> #define CC_DONTBLOCK0x2 /* set by caller */
>
> The caller sets CC_DONTBLOCK in cc_flags to direct the monitor not to
> perfo
43 matches
Mail list logo
