Scott W Brim wrote:
To start with, the review is it all looks okay to me, carry on.
However, regardless of guidelines for IETF LCs, I'm hesitant to send a
review of a draft in an area where I'm naive, which contains nothing
more than looks okay, to anyone outside of gen-art. If there were
Since it looks like a new version anyway, I will be No Objection
and just point to this thread.
Brian
Lakshminath Dondeti wrote:
Hi Elwyn,
Thanks for your review.
I interpret the word cost as cost of an attack, which is a perfectly
acceptable term in analyzing security properties of a
Since there is a big agenda this week, I have been dealing with
the reviews rather quickly with less email feedback than normal.
But thanks!
I did even read one or two drafts myself today, to get finished
in time ;-)
Brian
___
Gen-art mailing
I'm a bit confused. The version on the IESG agenda this week is -03,
but you attached -04 on January 27. Which should we be looking at?
Brian
Karl Norrman (KI/EAB) wrote:
Hello!
Thank you very much for your review.
Please see the attached updated draft and inline.
[SNIP]
Summary:
[I
Christian,
We have to remember that IETF specs need to be sufficient (with
their normative references attached) for an implementer who has no
access to any existing code. It isn't for the benefit of existing
implementers, but for future ones. I think what Elwyn is suggesting
fits into that
and interoperating for years, what exactly is the problem?
Anyway as I mentioned previously I'll discuss the situation with the
ADs, and possibly the routing directorate in Dallas before deciding
what to do.
Chris.
On Feb 8, 2006, at 1:28 AM, Brian E Carpenter wrote:
Christian,
We have
Yes, and in fact there is already an RFC Editor note
to fix this, and also a -02 version, so I was able to clear
my discuss. (We had an IESG retreat Monday and Tuesday,
so a number of discusses got cleared during coffee breaks.)
Thanks
Brian
[EMAIL PROTECTED] wrote:
Brian filed a discuss
that the LC reviews are having
an effect.
Brian
Brian E Carpenter wrote:
Please note that
a) I will be on travel for an IESG retreat in the early part
of next week. In particular I will be off line after about 11:00 PST
on Wednesday - so reviews that aren't sent at the latest Wednesday
morning (US
Please note that
a) I will be on travel for an IESG retreat in the early part
of next week. In particular I will be off line after about 11:00 PST
on Wednesday - so reviews that aren't sent at the latest Wednesday
morning (US time) won't be used.
b) Because of some stupid flight arrangements
Scott W Brim wrote:
Looks okay to me -- no obj.
I do wonder about the use of roadmap. To me the term means a guide
to where we are going, not to where we are. For this I would use the
name overview or RFC guide. I can't fault him, though, since
Brian himself has
one of the WG chairs of MSEC and I have
answers to your questions below.
-Original Message-
From: [EMAIL PROTECTED] on behalf of Scott W Brim
Sent: Thu 1/19/2006 7:11 AM
To: Brian E Carpenter
Cc: gen-art@ietf.org
Subject: [Gen-art] review of draft-ietf-msec-policy-token-sec-05.txt
I don't see an IPR disclosure against this draft (not even a 3rd party
one). I take it that the concern is related to the disclosure at
http://www.ietf.org/ietf/IPR/CERTICOM-IPSEC-ECC ?
As Russ said, there are precedents for this way to deal with
IPR - in fact if we have failed to get an IPR
I believe it is not necessary to add up-to-date boilerplate to an old
returning document. The boilerplate serves during the IETF work on the
document prior to the IESG review period; at worst, I see us as being
in a grey area with this one. If someone in the IESG decides they
really wanted
James Carlson wrote:
...
(And since the IETF operates an Informational RFC vanity press ...)
Not quite. Independent submissions to the RFC Editor are by definition
not part of the IETF process.
Brian
___
Gen-art mailing list
Gen-art@ietf.org
Bo,
In terms of process documents, yes, it's complicated and large
parts of RFC 2026 are obsolete. Here's a work in progress
that may help slightly:
http://www.ietf.org/internet-drafts/draft-carpenter-procdoc-roadmap-03.txt
Most of us now use the XML2RFC tool instead of a Word template;
that
Let me suggest a new guideline:
Drafts being handled as direct submissions to the RFC Editor
are not IETF documents, but they come up for a quick IESG review.
Under RFC 3932 (BCP 92) the IESG has several options, ranging from
No problem to Please do not publish. Formally, the choices are:
1.
Mark Townsley wrote:
Elwyn Davies wrote:
PWE3-IANA creates a number of registries that this draft uses, it the
registries
that are really normative - not the RFC. The draft is in the
RFC-editor's queue
and we have asked IANA to expedite the registry creation.
An interesting
Hi again,
Here's a suggested update of our review guidelines. (Mary, the changes
are bracketed by font color=red.../font, plus I fixed two
URLs (the NITS and BCP26 references).
Only three changes of significance:
1. About LC reviews. We don't currently follow normal IETF process, which is
I suggest that we need a short home page above
http://www.alvestrand.no/ietf/gen/art/review-guidelines.html
and we could hang the experience document off that.
I have a pointer to Gen-ART at http://www.ietf.org/u/ietfchair/
Brian
Spencer Dawkins wrote:
Hi, Brian,
At last week's meeting,
601 - 619 of 619 matches
Mail list logo
