Sam Hartman wrote:
One of the things coming out of the most recent BOF was a
strong desire for PA-level interoperability. That can be
accomplished through standardized attributes or
vendor-specific attributes that are sufficiently well
documented (and not subject to patents) that third
Narayanan, Vidya wrote:
Harald,
This seems to be missing the point. I think there is a general sense
that NEA could be helpful for some level of protection to complying
endpoints in an enterprise scenario, which is exactly what you have
described below. The disagreement seems to be on the topics
Vidya Narayanan wrote:
I am very apprehensive of achieving any meaningful PA-level
interoperability. I am not sure what minimum set of PA attributes will
be standardized, but, whatever that set is, I doubt will be sufficient
to provide any acceptable level of security, even for the endpoints.
At 11:06 PM 10/16/2006, Harald Alvestrand wrote:
Narayanan, Vidya wrote:
Harald,
snip
Noting the scenarios above, I claim that NEA-like functionality has
proved useful already in protecting the computing environment of an
enterprise. I have not seen compelling evidence that it has any use
in
At 12:00 AM 10/17/2006, Khosravi, Hormuzd M wrote:
Sam,
I believe if we move 'quickly' in this WG we will be able to meet
interoperability goals to certain extent atleast. The bottom-line is
this technology is already being deployed by different vendors in
academia and enterprises. The question
Lakshminath Dondeti wrote:
At 11:06 PM 10/16/2006, Harald Alvestrand wrote:
Narayanan, Vidya wrote:
Harald,
snip
Noting the scenarios above, I claim that NEA-like functionality has
proved useful already in protecting the computing environment of an
enterprise. I have not seen compelling
At 12:29 AM 10/17/2006, Harald Alvestrand wrote:
Lakshminath Dondeti wrote:
At 11:06 PM 10/16/2006, Harald Alvestrand wrote:
Narayanan, Vidya wrote:
Harald,
snip
snip
NEA is applicable to computing environments of enterprises where
endpoints accessing the enterprise's network are owned
-Original Message-
From: Sam Hartman [mailto:[EMAIL PROTECTED]
Sent: Friday, October 13, 2006 1:33 PM
To: ietf@ietf.org
Subject: Re: Last Call: 'Extensible Provisioning Protocol
(EPP)' to DraftStandard (draft-hollenbeck-epp-rfc3730bis)
Hi. RFC 3967 is not applicable in cases
Ted,
As I understand your concerns expressed below, you are concerned
that standardizing attributes for NEA would be redundant and
pointless: redundant because vendor-specific attributes will
cover the same information in more detail and pointless because
remediation will not be possible given
Hollenbeck, == Hollenbeck, Scott [EMAIL PROTECTED] writes:
-Original Message- From: Sam Hartman
[mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006
1:33 PM To: ietf@ietf.org Subject: Re: Last Call: 'Extensible
Provisioning Protocol (EPP)' to DraftStandard
Michael == Michael Thomas [EMAIL PROTECTED] writes:
Michael John C Klensin wrote:
(1) The supporter procedure/requirement should be triggered
only is someone shows symptoms of being a vexatious appellant.
People who are entering their first appeals don't trigger it.
Sam, et al,
I doubt that noting an appeal has been determined to have merit
is especially useful. As Sam implies below, it is possible to have
controversy over this point, and any controversy is likely to mean no
annotation of merit will occur in many cases.
Ignoring for the
Gray, Eric wrote:
Sam, et al,
I doubt that noting an appeal has been determined to have merit
is especially useful. As Sam implies below, it is possible to have
controversy over this point, and any controversy is likely to mean no
annotation of merit will occur in many cases.
--On Tuesday, 17 October, 2006 11:10 -0400 Sam Hartman
[EMAIL PROTECTED] wrote:
Michael Can an appeal be rejected with merit?
Yes. I think Robert's recent appeal was rejected that way. I
personally think that Jefsey's appeal against the LTRU
registry doc set was a reasonable
At 2:04 AM -0400 10/17/06, Stephen Hanna wrote:
Will we be able to meet these interoperability goals? Why or why not?
Yes, we can. If we define a small set of standardized attributes
(OS and app version, AV status, etc.) and make them mandatory to
implement,
Sorry, but doesn't AV status above
John == John C Klensin [EMAIL PROTECTED] writes:
John And, if deciding which appeals are vexatious and which ones
John are ok is too burdensome --especially relative to hearing a
John few more appeals-- then, IMO, we shouldn't be spending time
John on trying to figure out ways to
Ted,
Sorry, but doesn't AV status above refer to the existing, proprietary
anti-virus
systems? How does standardizing an attribute for carrying that help
create a standardized understanding of what it means?Don't I still
have to treat that as, essentially, a vendor attribute, since I have
At 8:22 PM +0200 10/17/06, Eliot Lear wrote:
would think that five or six values are appropriate:
1. Vendor name (string)
2. Vendor engine version (integer)
3. Vendor virus definitions version (integer)
4. Enabled? (binary)
5. Buggered? (binary)
6. Other gobbledigook the vendor wants
On Oct 17, 2006, at 11:22 AM, Eliot Lear wrote:
I would think that five or six values are appropriate:
1. Vendor name (string)
2. Vendor engine version (integer)
3. Vendor virus definitions version (integer)
4. Enabled? (binary)
5. Buggered? (binary)
6. Other gobbledigook the
Hi,
We are implementing an Ethernet protection ring. Then we found there is
an information RFC3619.
It is submitted by Extreme network and its IPR is protected by the
company too. We also found there are
some patents filed by Extreme. In addition to EAPS, we also found there
is MRP from
Hollenbeck, Scott wrote:
RFC 3339 (Date and Time on the Internet: Timestamps)
Referenced by: draft-hollenbeck-epp-rfc3730bis-03,
draft-hollenbeck-epp-rfc3731bis-04, draft-hollenbeck-epp-rfc3732bis-03,
draft-hollenbeck-epp-rfc3733bis-04
This reference is sited to capture a format that is also
Sam Hartman wrote:
I think the SPF and Sender ID appeals clearly had merit.
One decision said we have found merit, and the other said
we thank...
I'm not sure whether we rejected them though.
...the latter was in essence accepted, and the former also
had some effect, together resulting in
Bill,
The IETF stays strictly out of such discussions. It is entirely
up to each implementor to decide whether or not the claimed IPR is
valid and to make arrangements with the IPR owners if so.
Please see RFC 3979 for more details, and see
https://datatracker.ietf.org/public/ipr_disclosure.cgi
The IESG has approved the following document:
- 'Stream Control Transmission Protocol (SCTP) Direct Data Placement
(DDP) Adaptation '
draft-ietf-rddp-sctp-07.txt as a Proposed Standard
This document is the product of the Remote Direct Data Placement Working
Group.
The IESG contact
The IESG has approved the following document:
- 'Administration of the IANA Special Purpose Address Block '
draft-huston-ipv6-iana-specials-01.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is
The IESG has approved the following document:
- 'Internet Application Protocol Collation Registry '
draft-newman-i18n-comparator-14.txt as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Lisa
The IESG has approved the following document:
- 'Quick-Start for TCP and IP '
draft-ietf-tsvwg-quickstart-07.txt as an Experimental RFC
This document is the product of the Transport Area Working Group Working
Group.
The IESG contact persons are Lars Eggert and Magnus Westerlund.
A URL of
A new IETF working group has been proposed in the Security Area.
The IESG has not made any determination as yet. The following UPDATED
draft charter was submitted, and is provided for informational purposes
only. Please send your comments to the IESG mailing list (iesg@ietf.org)
by October
A modified charter has been submitted for the Host Identity Protocol
(hip) working group in the Internet Area of the IETF. The IESG has not
made any determination as yet. The modified charter is provided below
for informational purposes only. Please send your comments to the IESG
mailing list
29 matches
Mail list logo
