Yaron,
- Only non-expired drafts should be directly accessible from the
tools area, or in fact have a stable IETF URL.
Everything at tools.ietf.org is volunteer-maintained and unofficial.
That's why the I-D announcements contain the URL that they do, which
only allows you to recover
Roy,
Just a couple more comments below, and then I will have
said all I can usefully say.
On 2009-11-14 12:57, Roy T. Fielding wrote:
On Nov 13, 2009, at 2:26 PM, Brian E Carpenter wrote:
On 2009-11-13 23:35, Julian Reschke wrote:
Brian E Carpenter wrote:
On 2009-11-13 20:19, Julian Reschke
I read mail and listen and look at the slides, when I'm
in a session that is secondary to my main interests.
That doesn't mean I'm bored (maybe I always look bored),
but I don't see that it affects the question whether we
can fit all the parallel sessions into 4.5 days.
Brian
On 2009-11-11
Who would like to adopt this idea:
http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits-all-01.txt
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document:
Greg,
On 2009-10-28 05:42, Greg Daley wrote:
Hi Dean,
I appreciate that this is a realistic challenge for one of the key
users of the technology.
As a key user of the technology. Why didn't we learn about this
earlier in the process?
Well, the military interest in damage-proof
Eliot,
Now that Last Call is over, some considered replies to
your thoughtful comments.
On 2009-09-10 23:19, Eliot Lear wrote:
Dear Authors IESG,
Congratulations for providing us a comprehensive and interesting piece
of work that describes an abundance of issues that face administrators
Russ,
On 2009-10-10 07:16, Russ Housley wrote:
Dave:
You have the motivations for rfc3932bis completely confused. The IESG
is not the source for the proposed changes to RFC 3932. RFC 3932 as it
stands works fine for the IESG, and the IESG continues to operate under
it. The Independent
On 2009-10-06 10:20, Richard Shockey wrote:
...
The Utility Industry does not understand the current IPv4 number exhaust
problem and the consequences of that if they want to put a IP address on
every Utility Meter in North America.
Ironic, really, since IP addresses for every streetlight was
FWIW, this version resolves my remaining objection.
Thanks
Brian
On 2009-10-01 11:45, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : IESG Procedures for Handling of Independent and IRTF
Stream
On 2009-09-23 21:05, Olivier MJ Crepin-Leblond wrote:
...
Is a dual stack IPv4-IPv6 likely to be more unstable than pure IPv4 or
pure IPv6?
Apart from the software engineering principle that more of almost
anything is less reliable, there is a specific problem that if your
computer believes
I am assuming that VISA information will be provided on the IETF web
site, and that we will need a letter of invitation which the IETF will
provide.
You really have to check with a local expert. For my last visit,
I needed not a letter of invitation from my host, but an official
invitation
On 2009-09-21 20:56, Jari Arkko wrote:
Brian,
I think my comment still applies - it should be the IESG that appeals
against the Editor's final decision, not the other way round.
Ok. I have no problem placing the burden on initiating the formal
dispute resolution from the IESG side
Hi Jari,
On 2009-09-19 20:34, Jari Arkko wrote:
Here's the problem I see with draft-housley-iesg-rfc3932bis-09.
You responded before I had a chance to explain what the rationale and
options are. Sorry, but I was asleep at the time the draft came out :-)
I knew that this timezone must have
On 2009-09-19 08:08, Fred Baker wrote:
On Sep 18, 2009, at 12:29 PM, Henk Uijterwaal wrote:
I think it is safe to assume that the government did run some checks
on what the IETF is doing
The government has been negotiating to bring an IETF meeting to China
since 1997, and has been very
Hi Jari,
Here's the problem I see with draft-housley-iesg-rfc3932bis-09.
Suggesting a dialogue when there is disagreement is fine.
Allowing the IESG to consult the IETF as a whole is fine. But
then the final part of the dispute resolution procedure attempts
to undercut the editorial independence
Eliot,
We'll respond in detail to your helpful comments in due course.
However,
Still, I would argue strongly for inclusion of a fuller discussion about
technologies that obviate the need to renumber.
The hypothesis of the document is there will always be circumstances in
which partial or
Masataka,
You say: scope of the document is seemingly wrong.
Well, the scope of the document is to discuss how actual networks
running IPv4 and IPv6 can deal with renumbering. That can't be wrong;
it is simply what we chose to write about.
If you'd like to start a thread about IPng, can you use
On 2009-09-10 03:53, Noel Chiappa wrote:
From: Donald Eastlake d3e...@gmail.com
The burden of proof rests on those ... who wish to change the
independent stream from a respected independent publishing channel to
something subservient to the Area Directors, a change which
Sam,
On 2009-09-03 05:53, Sam Hartman wrote:
...
1) Open up the rfc-editorial board so that it was selected by some sort of
nomcom/community process. That nomcom could of course draw from a broader
community than the IETF as a whole
I'm certainly in favour of transparency in the process
Nico,
On 2009-09-03 07:54, Nicolas Williams wrote:
...
I do not subscribe to the IETF list
(ietf@ietf.org), for the very obvious reason that its signal-to-noise
ratio is too poor, thus completely missed the IETF LC of draft-igoe-
secsh-aes-gcm
Last Calls are announced on the
Forwarded here at the request of one of the authors:
Original Message
Subject: Re: I-D Action:draft-klensin-iasa-policy-00.txt
Date: Wed, 02 Sep 2009 17:10:32 +1200
From: Brian E Carpenter brian.e.carpen...@gmail.com
Organization: University of Auckland
To: John Klensin klen
On 2009-09-01 05:56, Ben Campbell wrote:
On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:
Yes, I understand, this only applies to the Independent Submission
stream.
We ask the IESG to review these documents, and that review is technical.
I don't think it is appropriate for an editor to
On 2009-09-01 13:14, Ben Campbell wrote:
On Aug 31, 2009, at 6:14 PM, Brian E Carpenter wrote:
On 2009-09-01 05:56, Ben Campbell wrote:
On Aug 31, 2009, at 11:39 AM, Brian Rosen wrote:
Yes, I understand, this only applies to the Independent Submission
stream.
We ask the IESG to review
On 2009-08-28 03:56, Russ Housley wrote:
RFC4846 section 5 uses the word recommend
If the IESG, after completing its review, identifies issues, it may
recommend explanatory or qualifying text for the RFC Editor to
include in the document if it is published.
Olaf, I believe this means
Hi,
Is this the correct list for discussing draft-klensin-iaoc-member?
o workload and full-time positions
Even without IAOC and Trustee roles, the IETF Chair and IAB Chair
roles require considerable time and effort.
This has been true for many years of the IETF Chair role.
I agree with the proposed policy, except that I propose
calling it just Procedure. It isn't policy, it's just
common sense about how to implement policy.
On 2009-08-18 07:57, Simon Josefsson wrote:
...
This is another reason why the current approach of getting IETF
consensus on an RFC and
On 2009-07-31 02:25, Pete Resnick wrote:
On 7/30/09 at 3:03 PM +0100, Samuel Weiler wrote:
What harms would come from destroying those old records and/or not
collecting such details in the future? And how widespread is the
support for destroying them?
Repeating something I just mentioned
On 2009-07-31 11:23, Marc Petit-Huguenin wrote:
Stephan Wenger wrote:
Hi Brian,
One can sit in a WG meeting for years, and never incur a disclosure
obligation under BCP78, correct? Just sitting there and not
saying/writing/contributing a thing does not trigger a disclosure
obligation.
This may seem like a small comment but I believe it is important.
We know that we have an issue to resolve collectively, namely the
IPR regimes for non-IETF stream documents. We probably agree that
(as the revised TLP says or implies) it is for each stream individually
to decide whether it accepts
Hi,
I am baffled why this announcement, of fundamental importance,
was not sent to the correct list for IETF announcements.
The same applies to the original announcement, sent as I
understand it on 23 June, at a time when I wasn't reading
the discussion list for personal reasons.
I will comment
This version of the draft describes a completely modified procedure
compared to the one presented at IETF74, which did not obtain consensus.
It contains small and large changes throughout.
Discussion is invited on the ipr...@ietf.org list.
Brian
Original Message
Subject:
On 2009-04-21 02:44, Dave CROCKER wrote:
Andrew Sullivan wrote:
On Fri, Apr 17, 2009 at 04:18:06PM -0400, Sam Hartman wrote:
My question is whether treating tools.ietf.org aliases as IETF lists
is reasonable policy.
In my opinion, it is.
+1
But the question is not whether they are
On 2009-04-18 05:57, Russ Housley wrote:
...
If these mail lists were the only convenient way to reach these
individuals, I might agree with your [Sam Hartman's] reasoning. That is not
the case.
These actions do not prevent Dean from communicating with Document
Authors, WG Chairs or ADs.
On 2009-04-17 17:14, Fernando Gont wrote:
On Mon, Apr 13, 2009 at 10:23 PM, Anantha Ramaiah (ananth)
ana...@cisco.com wrote:
* The document never mentions the fact that this document is
IPR-encumbered.
...
I personally believe this should be noted in all RFCs on which there's
a known
Steve,
Thanks for writing such a nice piece. I especially liked
As we rebuild our economy, I do hope we keep in mind the value
of openness, especially in industries that have rarely had it.
Did you ever actually get any comments on RFC1?
Brian
___
On 2009-03-23 08:26, Iljitsch van Beijnum wrote:
On 20 mrt 2009, at 14:40, Brian E Carpenter wrote:
NAT does not offer ANY multihoming benefits whatsoever, in fact, NAT
breaks multihoming because after a rehoming event, the addresses are
translated differently.
It's correct that NAT
On 2009-03-22 06:11, Rémi Després wrote:
Brian E Carpenter - le (m/j/a) 3/20/09 2:40 PM:
...
Also, NAT-based multihoming has value for large international corporate
networks with dozens or hundreds of interconnection points to
the public network. It basically solves their address management
Iljitsch,
On 2009-03-21 05:18, Iljitsch van Beijnum wrote:
...
NAT does not offer ANY multihoming benefits whatsoever, in fact, NAT
breaks multihoming because after a rehoming event, the addresses are
translated differently.
It's correct that NAT changeovers break existing sessions. But your
I recently had this exchange with Dan Wing on the BEHAVE list:
... it seems to me
that we might consider defining a generic 'referral object', containing
more information than just an address, that could be passed among
application entities. It could contain TLVs that would provide the
Larry,
On 2009-03-11 08:28, Lawrence Rosen wrote:
...
I don't think we should publish under the IETF imprimatur if there are
*unresolved* known patent issues about which ignorant and cautious people
continue to speculate blindly. Why should any of us waste time and money on
IETF and
Marc, and Henry,
I think adding any new mandatory section to all I-Ds is a bad idea.
It will quickly become bureaucratic. We've had proposals for mandatory
Management Considerations, IPv6 Considerations, and no doubt others
that I've forgotten, and they all have the same problem.
However, I
On 2009-03-01 15:39, George Michaelson wrote:
write your auth number down.
Or print the Authorization Approved page, since the auth number
is 16 alphanumerics and a mistake would be easy.
Brian
once you complete an app, the number is valid for 2+ years with
modifications to travel plans
Dave,
On 2009-03-02 07:17, Dave CROCKER wrote:
...
What is particularly interesting to me, about this line of comment, is
not whether the relevant IETF-based technologies are superior or whether
Can you point me to the IETF WG(s) that are considering identity
management as a whole? I know
On 2009-03-02 10:21, Dave CROCKER wrote:
Brian E Carpenter wrote:
Dave,
On 2009-03-02 07:17, Dave CROCKER wrote:
...
What is particularly interesting to me, about this line of comment, is
not whether the relevant IETF-based technologies are superior or whether
Can you point me
On 2009-02-25 14:05, David Morris wrote:
On Tue, 24 Feb 2009, Cullen Jennings wrote:
On Feb 13, 2009, at 11:15 AM, David Morris wrote:
while providing the operational efficiency of collecting all
discussion in one place for actual analysis of last call
While there may be better ways
On 2009-02-15 03:44, Theodore Tso wrote:
On Sat, Feb 14, 2009 at 09:12:16AM +1300, Brian E Carpenter wrote:
Or afterwards, since the license a contributor grants to the
IETF Trust is non-exclusive. So contributing these words to the IETF
does not affect in any way my ability to do as I wish
On 2009-02-13 21:15, Henk Uijterwaal wrote:
Noel Chiappa wrote:
(Discussion deleted)
I think these (and the per-draft mailboxes others have mentioned) are
probably
all steps in a long-term plan, with the eventual optimum system being the
web-based thing you mention.
What is exactly
On 2009-02-13 16:47, Steven M. Bellovin wrote:
On Thu, 12 Feb 2009 21:38:44 +0100
Simon Josefsson si...@josefsson.org wrote:
The discussion started by Stephan suggesting that free software
authors publish their work as free standards in the IETF. My point
was that since the IETF disallow
Phill,
On 2009-02-14 10:41, Hallam-Baker, Phillip wrote:
...
The proposal that I made then was that when a working group is started, it
specify the IPR criteria under which it is chartered. In some cases it makes
perfect sense to charter a group that will be using encumbered technology. In
On 2009-02-13 13:15, Noel Chiappa wrote:
From: Clint Chaplin clint.chap...@gmail.com
I wouldn't create two places to send comments and attempt to segregate
who can post to which group. However, creating an ietf-comm...@ietf.org
email list and asking all last call comments
On 2009-02-12 08:09, ned+i...@mauve.mrochek.com wrote:
...
P.S. I've read the IPR dlsclosure and the patents claims, but what would
be useful to see is the document shepard writeup. Are those available
somewhere
online? If they are I don't know where to find them and I was unable
to coerce
Tim,
On 2009-02-10 18:32, Tim Bray wrote:
On Mon, Feb 9, 2009 at 5:50 PM, Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
FWIW (and it would be good if other actual
IETF participants care to indicate +1 if they agree):
The actual words in RedPhone's current disclosure:
RedPhone
Hi Steve,
On 2009-02-11 08:19, Steven M. Bellovin wrote:
On Tue, 10 Feb 2009 10:59:52 -0800
Lawrence Rosen lro...@rosenlaw.com wrote:
Why don't we organize to answer the patent claim infringement issues
like professionals do? Ask technical experts. Consult a patent
attorney. Render
Eric,
On 2009-02-11 03:35, Eric Burger wrote:
...
If anything, I would offer the excellent prescriptions described below
should either be part of an update to 2026 or a BCP for how AD's should
monitor and work with Work Groups, in general.
It seems to me that everything involved is well
On 2009-02-11 11:44, Robinson Tryon wrote:
...
I read parts of the document. Then I went to RedPhone's license page
(http://redphonesecurity.com/license.htm) and tried to read their
license -- it's pretty complicated, including language such as
RedPhone Security will grant royalty-free
FWIW (and it would be good if other actual
IETF participants care to indicate +1 if they agree):
The actual words in RedPhone's current disclosure:
RedPhone Security hereby asserts that the techniques for
sending and receiving authorizations defined in TLS Authorizations
Extensions (version
On 2009-02-10 15:12, David Morris wrote:
On Mon, 10 Feb 2009, John Levine wrote:
Any chance we could require that one subscribes to the list before
posting to it? I realize that sufficiently motivated drive-bys could
subscribe, send, and leave, but it might reinforce the idea that IETF
Hi,
I think that all the proposed actions and decisions in the draft
statement are reasonable, and well within the IESG's scope
under RFC2026 and RFC2418. So almost no problems there.
Almost, because I'm not sure that the MUST NOT publish should
apply to Experimental. I think SHOULD NOT is
Simon,
My recollection, without doing an archive search, is that our counsel
took the opposite view, i.e. that the parenthesis expanded the scope
beyond ISOC and the IETF. IANAL and YMMV.
Brian
On 2009-01-23 23:20, Simon Josefsson wrote:
Brian E Carpenter brian.e.carpen...@gmail.com writes
Julian,
On 2009-01-23 05:40, Julian Reschke wrote:
...
That leaves us with the question whether any contributor (IPR-wise)
needs to be called author. Not sure about that. But if we don't call
them authors, they should be listed in a agreed-upon place in the spec.
For minor contributors, the
Original Message
Subject: Gen-ART LC review of draft-ietf-behave-turn-12.txt
Date: Tue, 20 Jan 2009 12:44:36 +1300
From: Brian E Carpenter brian.e.carpen...@gmail.com
Organization: University of Auckland
To: General Area Review Team gen-...@ietf.org
CC: behave-cha
On 2009-01-15 13:32, Randy Presuhn wrote:
Hi -
I originally asked this question on the WG chairs' list, and
was asked to ask again here...
The discussion about RFC 5378 (what little I've been able to
understand of it, anyway) has focussed on I-Ds and RFCs.
However, the definition of
Ted,
On 2009-01-11 08:10, Theodore Tso wrote:
...
If the
goal is to allow code to be allowed in Open Source Software, then
requiring a maximally compatible OSS license for code makes sense.
But requiring for random protocol text, especially if this is going to
make reuse of older RFC's
10, 2009 11:07 +1300 Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
Thanks John, I believe that is an excellent summary of the
viable options. My draft implicitly adds
(2.5) Post-5378 documents that incorporate pre-5378
materials whose original contributors have duly agreed
+1.
Which is why I suggest that we should support the Trustees' proposed
short term fix, to allow normal work to continue +/- cutting and pasting
some boilerplate. We do have a glitch in 5378 to mend, but let's get that
off the critical path.
Brian
On 2009-01-11 09:12, John C Klensin wrote:
On 2009-01-11 09:52, Dave CROCKER wrote:
Brian E Carpenter wrote:
Which is why I suggest that we should support the Trustees' proposed
short term fix, to allow normal work to continue +/- cutting and pasting
some boilerplate. We do have a glitch in 5378 to mend, but let's get that
off
On 2009-01-11 10:55, Dave CROCKER wrote:
Brian E Carpenter wrote:
Er, is that a Last Call comment on draft-ietf-ipr-outbound-rights
and draft-ietf-ipr-3978-incoming? A bit late, if so.
Brian, too late makes sense for stray comments.
It doesn't make sense when we discover that a spec
John,
On 2009-01-10 07:15, John Leslie wrote:
...
In other words, remove the new requirement and we no longer have a
crisis. We have an issue to pursue -- the same one that prompted
the new requirement -- but no crisis.
Alas, I must disagree. We have an IETF Consensus document (5378),
John,
On 2009-01-10 10:32, John C Klensin wrote:
...
And note that makes a clear and plausible transition model:
(1) Pre-5378 documents exist under pre-5378 rules, so
any potential user for non-traditional purposes needs to
either figure out who the relevant authors are
Ed,
Thanks for this.
As I understand it, the proposal boils down to adding a disclaimer to
affected documents that reads:
This document contains material from IETF Documents or IETF Contributions
published before November 10, 2008 and, to the Contributor’s knowledge,
the person(s) controlling
On 2009-01-09 13:59, Stephen Farrell wrote:
+1 to fred's proposal, let the exceptions be just that and don't bother
most I-D authors,
Stephen.
On 8 Jan 2009, at 22:49, Fred Baker f...@cisco.com wrote:
You asked me to make this comment publicly, so here it is.
In my opinion, we need a
A draft on this topic has been updated:
http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-01.txt
Comments and discussion are invited on the OPS Area list,
ops-a...@ietf.org
Brian Carpenter
Ran Atkinson
Hannu Flinck
P.S. Apologies if you receive multiple copies, but that
Noel,
On 2008-12-30 05:28, Noel Chiappa wrote:
From: John Day jeanj...@comcast.net
Multihoming is fundamentally a routing problem.
(snip)
It is a problem of routing not be able to recognize that two points of
attachment go to the same place. Portraying it as anything
Hi Christian,
On 2008-12-30 11:55, Christian Huitema wrote:
I would agree with this, except I defer to the 'get down off an
elephant'
principle. If both points of attachment are bound to a single
transport level
entity, then it ought to be relatively easy, and not involve the
routing at
Jorge,
I'm working on the assumption that once a contributor or a
contributor's assign has signed the license form in its
RFC5378 version, we can all submit drafts including that
contributor's earlier text without further ado. Is that correct?
Brian
On 2008-12-19 11:37, Contreras, Jorge
Dave,
On 2008-12-18 11:32, Dave CROCKER wrote:
...
My assumption was not that the work was available for IETF use.
Correct.
My assumption was that the IETF owned the work. Pure and simple.
False. You never implicitly transferred ownership.
The IETF was free to do whatever the hell if
On 2008-12-14 05:12, Scott Kitterman wrote:
On Sat, 13 Dec 2008 08:12:17 -0800 Eric Rescorla e...@networkresonance.com
wrote:
At Sat, 13 Dec 2008 09:49:09 +1300,
Brian E Carpenter wrote:
On 2008-12-13 08:20, Russ Housley wrote:
...
Process are clearly already available, but the contributor
I hereby extend the rights in my contributions that I have personally
granted in the past to the IETF and to the IETF Trust to include
the additional rights required by RFC5378. Obviously by doing so,
I cannot extend the rights granted by my various employers.
I'm going to print the updated
On 2008-12-12 12:40, John C Klensin wrote:
...
So, given that, the Trustees now believe that it is reasonable
to [re] impose a deadline that gives the community two working
days (it is already well into December 12 in much of the world)
to modify and update tools to incorporate the new
On 2008-12-13 08:20, Russ Housley wrote:
At 01:28 PM 12/12/2008, Simon Josefsson wrote:
As far as I understand, I can no longer take RFC 4398, fix some
minor problem, and re-submit it as a RFC 4398bis. Even though I was
editor of RFC 4398. The reason is that some material in that document
Keith,
With some reluctance, I have't changed your cc list. But
my conclusion is that this particular discussion belongs
on the RRG list as much as anywhere.
On 2008-12-02 09:52, Keith Moore wrote:
...
(Because at present the we need NATs for routing argument looks, to my
intuition, a bit like
Steve,
Can you clarify whether this work applies to one particular sign
language or to many? I am completely illiterate in these languages,
but I understand that there are many of them.
Regards
Brian Carpenter
On 2008-11-29 08:28, [EMAIL PROTECTED] wrote:
Hi -
There are several issues
Sam,
I agree with Russ. I think the clearest possible result is the one
we achieved in the case appended below, but that required quite
some work in the absence of a well-defined procedure, even without
there being an independent submission to synchronize. I think the
draft makes such cases
Guess i will use the jabber / streaming stuff anyway to get informed
As long as people upload their slides to the meeting materials page,
I find this works very well. But I think the idea of experimenting
with a variety of more recent tools is a good one.
Brian
I'm happy with this version. I think it updates the procedures in
accordance with what we've learned since RFC3932.
Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On 2008-10-21 23:00, IAB Chair wrote:
Dear Colleagues,
The IAB intends to publish the following document and invites any
comments you might have:
On RFC Streams, Headers, and Boilerplates
draft-iab-streams-headers-boilerplates-03 [1]
I think this is ready to publish, except for
On 2008-10-10 18:39, Thierry Moreau wrote:
Brian E Carpenter wrote, to multiple mailing lists of which
ietf@ietf.org is the only relevant as far as I am individually concerned:
On 2008-10-10 03:50, Olaf Kolkman wrote:
There are links to a number of process flow diagrams that may
On 2008-10-10 03:50, Olaf Kolkman wrote:
There are links to a number of process flow diagrams that may interest
you.
For easy accessibility of those links see:
http://www.ntia.doc.gov/DNS/DNSSEC.html
I don't think we should endorse in any way the implication that
the NTIA or any other part
On 2008-08-21 12:45, Scott O. Bradner wrote:
Oh gosh, I hope we're not archiving all those WG millstones...
in the fiction department :-)
In the non-fiction department, there's also
http://www.ietf.org/html.charters/OLD/index.html
(which is the Concluded link at the top of the
basic IETF
On 2008-08-16 10:48, Ted Hardie wrote:
...
Reading through this, I see that the recommendation that
an IPR discloser withdraw a previous disclosure if a revised
Contribution negates the previous IPR disclosure made it into
the BCP. Someone else will have to decide if this is already
On 2008-08-16 05:44, Powers Chuck-RXCP20 wrote:
I agree with John, and expect that if the IETF Trust will now be allowed
to take an expired ID, and do with it want it wants outside of the
standards process,
I read the text of RFC 2026 as Simon does, but RFC 3667 and 3978 added
the phrase
On 2008-08-20 12:03, Simon Josefsson wrote:
Brian E Carpenter [EMAIL PROTECTED] writes:
the result will (appropriately) be to have more
finely tuned IPR declarations, which make it clear that the declaration
is targeted at the specific standard in question, and is not applicable
beyond
On 2008-08-16 06:23, Paul Hoffman wrote:
At 1:37 PM -0400 8/15/08, Powers Chuck-RXCP20 wrote:
In general, not a bad approach. However, does a valid amendment include
the statement this IPR declaration is now null and void, since the
technology did not make it into the targeted standard? This
On 2008-08-16 02:57, Simon Josefsson wrote:
...
I'd like to suggest that the IETF patent disclosure mechanism be changed
to postings to a mailing list. All patent disclosures can be sent to
it, archived as any other IETF work. The postings would then also be
subject to the dispute handling
On 2008-08-14 19:25, Simon Josefsson wrote:
...
If removals should be permitted, the reasons for accepting a removal
request should be well established. I can think of at least two reasons
that are valid:
* Exact duplicates
* Spam
Beyond this I'm less sure we can get away the liability
On 2008-08-15 01:48, SM wrote:
At 03:59 14-08-2008, Marshall Eubanks wrote:
One solution would be to require a TDMA like confirmation of the
existence of posters (do they
exist, and are they with the company they claim to be speaking for)
_before_ the posting is accepted.
The submission
On 2008-08-14 05:10, John C Klensin wrote:
--On Wednesday, August 13, 2008 2:21 PM +0200 Simon Josefsson
[EMAIL PROTECTED] wrote:
If the IETF removes patent disclosures, I believe the IETF
will find itself in the position of evaluating the
_correctness_ of patent related claims. This
How about adding some weasel words, or even simply making the
attribution requirement a should? I think it's perfectly reasonable
to ask for attribution when possible, so any form of words that
doesn't break the BSD license in a narrow legalistic sense
would do fine for me.
It's not like we're
On 2008-08-10 07:58, John C Klensin wrote:
--On Saturday, 09 August, 2008 20:52 +0200 Bert Wijnen
\\(IETF\\) [EMAIL PROTECTED] wrote:
John and Dave,
I think that both of you (and some others) arwe looking at the
ID_Checklist
too much as if it is part of our (rigid) process. Our
501 - 600 of 1719 matches
Mail list logo
