> > No real disagreement here but I do see a way forward.
> First, clarify the
> > terminology. Second publish a pair of RFCs rather like 1009 entitled
> > "Requirements for Consumer Internet Gateways" and "Requirements for
> > Enterprise Internet Gateways".
>
> Are you aware of RFC 4084 "Termin
Russ Housley wrote:
>
> >2) If this was published in a more academic environment, it would be
> >proper (and required) to cite related work, tracing the source of
> >ideas that were not entirely new. We don't usually have extensive
> >citations in RFCs, but in this context, perhaps it would be
> >
Noel,
On 2007-03-04 22:36, Noel Chiappa wrote:
> From: Brian E Carpenter <[EMAIL PROTECTED]>
> the problems that NAT causes, and that having suffcient address space
> (a.k.a. IPv6) solves
This comment seems to posit that insufficient address space is the only thing
driving deployme
John,
(after also reading Michael's response)
I don't disagree. I think there is scope for writing a list of
desirable properties for SOHO routers in the light of these
various inputs. I'm less certain it can be done for enterprise
boundary routers. But it would be a tricky and contentious job
i
On Mon, 26 Feb 2007, The IESG wrote:
The IESG has received a request from the IS-IS for IP Internets WG
(isis) to consider the following document:
- 'IS-IS Extensions for Advertising Router Information '
as a Proposed Standard
This document has a normative reference to two informational RFCs
--On Monday, 05 March, 2007 11:44 +0100 Brian E Carpenter
<[EMAIL PROTECTED]> wrote:
> John,
>
> (after also reading Michael's response)
>
> I don't disagree. I think there is scope for writing a list of
> desirable properties for SOHO routers in the light of these
> various inputs. I'm less c
> From: Noel Chiappa [mailto:[EMAIL PROTECTED]
> > From: Brian E Carpenter <[EMAIL PROTECTED]>
>
> > the problems that NAT causes, and that having suffcient
> address space
> > (a.k.a. IPv6) solves
>
> This comment seems to posit that insufficient address space
> is the only thin
*> FWIW, I don't think we want to start bouncing specs because they
*> don't pay homage - in this case all the similarities are probably
*> the only obvious ways to add authorization tokens to a TLS
*> handshake. Such downrefs to dead documents would anyway add yet
*> more cruft to the R
Bob Braden <[EMAIL PROTECTED]> writes:
> *> FWIW, I don't think we want to start bouncing specs because they
> *> don't pay homage - in this case all the similarities are probably
> *> the only obvious ways to add authorization tokens to a TLS
> *> handshake. Such downrefs to dead document
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> IPv6 is also a technology refresh, i.e. it forces vendors to
> reimplement their boxes. It forces people to buy new systems.
> If the only thing that they get is a new protocol with wider
> addresses, then they will see this as a generally
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
> John,
>
> (after also reading Michael's response)
>
> I don't disagree. I think there is scope for writing a list
> of desirable properties for SOHO routers in the light of
> these various inputs. I'm less certain it can be done for
> en
At 8:53 AM -0800 3/5/07, Bob Braden wrote:
*> FWIW, I don't think we want to start bouncing specs because they
*> don't pay homage - in this case all the similarities are probably
*> the only obvious ways to add authorization tokens to a TLS
*> handshake. Such downrefs to dead documents w
--On Monday, 05 March, 2007 09:19 -0800 Paul Hoffman
<[EMAIL PROTECTED]> wrote:
> At 8:53 AM -0800 3/5/07, Bob Braden wrote:
>> *> FWIW, I don't think we want to start bouncing specs
>> because they *> don't pay homage - in this case all the
>> similarities are probably *> the only obvious
> From: EKR [mailto:[EMAIL PROTECTED]
> On the general I think I agree with Stephen. While it's
> important to give credit to direct antecedents to one's work,
> this isn't academic publishing or a patent application and I
> don't think it's necessary to cite all prior or related work,
> esp
On Mon, 05 Mar 2007 12:39:35 -0500
John C Klensin <[EMAIL PROTECTED]> wrote:
> >
> > How does adding a downref to a dead document add more
> > integrity to the RFC process?
>
> Independent of the merits in this particular case, it provides
> history and context. We have learned, or should ha
--On Monday, 05 March, 2007 09:15 -0800 "Hallam-Baker, Phillip"
<[EMAIL PROTECTED]> wrote:
>
>> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
>
>> John,
>>
>> (after also reading Michael's response)
>>
>> I don't disagree. I think there is scope for writing a list
>> of desirable prope
John C Klensin wrote:
--On Monday, 05 March, 2007 09:19 -0800 Paul Hoffman
<[EMAIL PROTECTED]> wrote:
At 8:53 AM -0800 3/5/07, Bob Braden wrote:
*> FWIW, I don't think we want to start bouncing specs
because they *> don't pay homage - in this case all the
similarities are probably *>
At 12:39 PM -0500 3/5/07, John C Klensin wrote:
--On Monday, 05 March, 2007 09:19 -0800 Paul Hoffman
<[EMAIL PROTECTED]> wrote:
At 8:53 AM -0800 3/5/07, Bob Braden wrote:
*> FWIW, I don't think we want to start bouncing specs
because they *> don't pay homage - in this case all the
si
> From: Paul Hoffman [mailto:[EMAIL PROTECTED]
> Fully disagree. A reference to a dead document that the
> reader cannot find directly provides no histor nor context.
Many of the most important events in history are only known through second hand
accounts.
We are in danger of falling into th
> > We have IPv6 Locally Assigned Local Addresses.
>
> Doesn't this presume that if people used these locally assigned
> addresses they would then NAT to a public address space?
No. Locally Assigned Local Addresses are for talking to
other machines within the locally assigne
On Mon, 5 Mar 2007, Stephen Farrell wrote:
I think something along these lines might be ok, so long as
its not a significant barrier to progress - I'd hate if every
new author had to be an I-D historian, or if anyone who wanted
to slow down a document could play the system using this. I
have a
> Since tags of 1 character are never well-formed, I suggest that the
> definition:
>
> SYNTAX OCTET STRING (SIZE (0..60))
>
> be amended to exclude the 1-character case. I assume that a zero-length
> tag, while also not defined in RFC 4646, was included in the I-D to
> allow the special
The IETF is pleased to announce its selection of Philadelphia,
Pennsylvania, USA as the site of IETF 71 being held March 9th through
the14th in 2008. Philadelphia claims to be "America's Birthplace" as
the location where the Declaration of Independence and the Constitution
were drafted. It is
The IETF is pleased to announce its meeting locations for IETF's 70 and
73, and they are locations we have been to before.
IETF 70 will be held in Vancouver at the Vancouver Westin from December
2nd through the 7th 2007. You may recall IETF 64 was at this facility.
IETF 73 will be held in Mi
> From: John C Klensin [mailto:[EMAIL PROTECTED]
> --On Monday, 05 March, 2007 09:15 -0800 "Hallam-Baker, Phillip"
> <[EMAIL PROTECTED]> wrote:
> While I have disagreed with many of the other things Phillip
> has said in this thread, I am in complete agreement with this
> one and taken much th
Ray,
On 2007-3-6, at 0:44, ext Ray Pelletier wrote:
IETF 70 will be held in Vancouver
IETF 73 will be held in Minneapolis
while it's absolutely fantastic to see announcements of specific
locations and dates this far ahead, we seem to have been moving to a
cycle of 3 meetings in North Ameri
26 matches
Mail list logo
