Sending it here for tracking purposes, we need to correct the following
statement on page 5
If the PE hosting the AIIs is present in an autonomous system
where the provider is not running BGP, chooses not to expose this
information or does not wish to use the global ID,
I recently got notice from IETF mailing lists that my mail has been
bouncing. The notice didn't have any examples of the bounces, so I
couldn't get any clue what is wrong. However, now I got a bounce
notice from bugtrag.. and it had this note
---
The Postfix
---
Apparently networksolutions for some reason occasionally resolves
burp.tkv.asdf.org into resalehost.networksolutions.com.
Isn't this behaviour totally antisocial from networksolutions and how
can it be stopped?
Well, insert foot in mouth... possibly the domain
Markku Savela wrote:
I recently got notice from IETF mailing lists that my mail has been
bouncing. The notice didn't have any examples of the bounces
Those bounces are delivery problems, see below why.
so I couldn't get any clue what is wrong. However, now I got a bounce
notice from
At 1:50 -0700 3/28/07, Ole Jacobsen wrote:
However, I think it would be useful to at least include company/organization
name (perhaps even country)...
I like that, and I have one more request - folk's names presented in
their (personally preferred, etc.) native script.
--
Folks, we didn't get a lot of support expressed in the second last
call. If I were making a consensus call today I'd say we do not have
consensus to publish draft-housley-tls-authz-extns as a proposed
standard given the IPR claims against it.
However Russ pointed out to me that it may be that
I don't care strongly about the standards track status. However,
speaking as implementer of the protocol: If the document ends up as
informational or experimental, I request that we make an exception and
allow the protocol to use the already allocated IANA protocol
constants. That will avoid
Sam Hartman wrote:
I propose to conduct a last call to confirm that we don't
have consensus to publish as a proposed standard. Does
this seem like the right approach to folks?
Did that ever happen before ? A Last Call trying to get
consensus that there's no consensus.
If silence means
Simon == Simon Josefsson [EMAIL PROTECTED] writes:
Simon I don't care strongly about the standards track status.
Simon However, speaking as implementer of the protocol: If the
Simon document ends up as informational or experimental, I
Simon request that we make an exception and
On Thu Mar 29 15:39:07 2007, Frank Ellermann wrote:
Sam Hartman wrote:
I propose to conduct a last call to confirm that we don't
have consensus to publish as a proposed standard. Does
this seem like the right approach to folks?
Did that ever happen before ? A Last Call trying to get
I think that the current texts would merit some additional work.
In particular to permit authorisation statements and to clarify
that how which client acts as a proxy for someone else.
I mentioned the first part to the authors some time ago, but
they didn't buy the idea.
Sam Hartman wrote:
Sam Hartman [EMAIL PROTECTED] writes:
Simon == Simon Josefsson [EMAIL PROTECTED] writes:
Simon I don't care strongly about the standards track status.
Simon However, speaking as implementer of the protocol: If the
Simon document ends up as informational or experimental, I
At 10:06 AM -0400 3/29/07, Sam Hartman wrote:
Folks, we didn't get a lot of support expressed in the second last
call. If I were making a consensus call today I'd say we do not have
consensus to publish draft-housley-tls-authz-extns as a proposed
standard given the IPR claims against it.
However
Ted == Ted Hardie [EMAIL PROTECTED] writes:
Ted I thought Eric Rescorla and Pasi Eronen had suggested that
Ted this document be evaluated by the TLS working group and the
Ted IPR terms evaluated there. I have that suggestion in an
Ted email thread on the main IETF list, started
At 1:05 PM -0400 3/29/07, Sam Hartman wrote:
The problem is that this work is outside the charter of the TLS
working group. So, I don't think asking them to take on the document
would be appropriate.
I also don't think rechartering TLS for this purpose would be appropriate.
It is actually fairly
On Thu, 29 Mar 2007 17:12:18 +0200
Simon Josefsson [EMAIL PROTECTED] wrote:
The community needs to evaluate patent claims, and preferably reach
conservative agreement (rough consensus is not good enough) on whether
we should care about a particular patent or not. Input to that
community
Ted == Ted Hardie [EMAIL PROTECTED] writes:
Ted At 1:05 PM -0400 3/29/07, Sam Hartman wrote:
The problem is that this work is outside the charter of the TLS
working group. So, I don't think asking them to take on the
document would be appropriate. I also don't think
At 4:25 PM -0400 3/29/07, Sam Hartman wrote:
Ted, I'd like to do this. However I could use some help figuring out
exactly what question I'm asking the TLS working group to provide
advice on. I guess it could be as simple as Do you think
draft-housley-tls-authz-extns is worth publishing on the
Ted == Ted Hardie [EMAIL PROTECTED] writes:
Ted At 4:25 PM -0400 3/29/07, Sam Hartman wrote:
Ted, I'd like to do this. However I could use some help
figuring out exactly what question I'm asking the TLS working
group to provide advice on. I guess it could be as simple as
Marshall Rose wrote:
the server broke and is being rebuilt. we'll remove the A RR for that ip
address until it's fixed.
It occurs to me that xml2rfc has become important enough to the IETF to
warrant at least having a mirrored copy of the site be maintained by the IETF
secretariat.
With
- Original Message -
From: Edward Lewis [EMAIL PROTECTED]
To: The IETF ietf@ietf.org
Cc: [EMAIL PROTECTED]
Sent: Thursday, March 29, 2007 9:51 PM
Subject: Re: Identifying meeting attendees
At 1:50 -0700 3/28/07, Ole Jacobsen wrote:
I like that, and I have one more request - folk's
A new Request for Comments is now available in online RFC libraries.
RFC 4820
Title: Padding Chunk and Parameter for
the Stream Control Transmission Protocol (SCTP)
Author: M. Tuexen, R. Stewart,
P. Lei
A new Request for Comments is now available in online RFC libraries.
RFC 4817
Title: Encapsulation of MPLS over Layer
2 Tunneling Protocol Version 3
Author: M. Townsley, C. Pignataro,
S. Wainner, T. Seely,
23 matches
Mail list logo
