I've uploaded the reviews received to date, with the spreadsheets available at: http://www.alvestrand.no/ietf/gen/art/gen-art.html http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html Let me know any if you see any errors or omissions. Mary.
I was selected as General Area Review Team reviewer for this specification (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Document: draft-ietf-dnsop-dnssec-operational-practices-07.txt Intended Status: Informational Shepherding AD: David Kessens Review Trigger: IESG Telechat 2 March 2006 Summary: Slightly surprised this isn't a BCP even given the disclaimer - I know it updates RFC2541 which was Informational. It does after all represent the best advice that is around at the moment and unlike RFC2541 it really is about operational practice. I think I would support BCP for this. Either way it is almost ready. In general the document seems well written and helpful: Not being a DNS administrator I can't vouch for its completeness or accuracy. I think a brief section summarizing what DNSSEC needs and how it works would make it useful for operators trying to get a feel for the operational load before diving into the details. Otherwise there are a number of editorial nits that ought to be fixed: they are IMO a bit more than copy editing but could be handled that way. In particular the tables in sections 4.2.x need more captioning and the non-IETF references need additional information. Editorial: s1: Refs to the defining RFCs for DNSSEC would be a good idea.(Continue reading)
I was selected as General Area Review Team reviewer for this specification (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Document: draft-ietf-netconf-beep-08.txt Intended Status: Proposed Standard (WG submission) Shepherding AD: Bert Wijnen Review Trigger: IESG Telechat 2 March 2006 Summary: This document is not ready for PS. There is a considerable lack of clarity in mapping the requirements and roles between the various protocols which are being combined in this protocol, and the manager/agent terminology used has been eschewed by NETCONF in favour of client/server. If used at all manager/agent terminology should be confined to the 'reversability' motivation in the introduction. The emphasis on reversability may be confusing: Checking with the NETCONF protocol, if I understand correctly, a given endpoint in a session is confined to being a client or a server. Thus although a BEEP channel is reversible the NETCONF session that runs over it is not and indeed the transport protocol has to tell NETCONF which sort of endpoint (client or server) it is. The security considerations section specifies requirements and operations rather than just discussing the threats and their mitigation. Review:(Continue reading)
Intended Status: Experimental As this is intended as an experimental document, and that it clearly describes the applicability of the protocol & its documenting existing implementations, I would vote no obj for this document. John
Intended Status: Proposed Standard
1) Having read this several times, I would suggest a DISCUSS, due to the
IANA considerations section. I do not think that the IANA consideration
section give enough guidence to the expert reviewer about what makes a
good token. Also, I found many of the location types confusing, for
example:
water:
The person is on water, such as an ocean, lake, river, canal or
other waterway.
watercraft:
The person is traveling in a boat or ship.
What about a swimmer or SCUBA diver? What if the boat is not moving, is
it still traveling? My gut feeling is that the place needs to be
separate from the action. Addtionally, prepositions should be separate
from the place (i.e. - on, in, above, under, etc.).
In summary - the location places should be just locations, there should
be no linkage to the activity of the target with respect to the
location.
2) The IANA Consideration section says:
To ensure widespread usability across protocols, tokens should follow
the character set restrictions for XML Names.
(Continue reading)
I've uploaded the reviews received since last nite/this morning, with the spreadsheets available at: http://www.alvestrand.no/ietf/gen/art/gen-art.html http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html Let me know any if you see any errors or omissions. Mary.
Hi all,
I had wanted to wait until there were more to assign, but one of these is now less than a week away and the other 2 are just over a week away:
http://www.alvestrand.no/ietf/gen/art/gen-art.html
http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html
Thanks,
Mary.
---------------------------
Reviewer: Harald Alvestrand
- 'Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs '
<draft-ietf-l3vpn-bgpvpn-auto-06.txt> as a Proposed Standard
IETF LC ends on 2006-03-07.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgpvpn-auto-06.txt
---------------------------
Reviewer: Joel Halpern
- 'Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup
Operations '
<draft-ietf-disman-remops-mib-v2-09.txt> as a Proposed Standard
IETF LC ends on 2006-03-09.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-09.txt
---------------------------
Reviewer: John Loughney
- 'Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0 '
RFC 2613 as a Draft Standard
IETF LC ends on 2006-03-09.
NOTE: this document was IETF Last Called back in 2003. That IETF Last Call
uncovered that this document has a normative depency on RFC2021
which was at PS. RFC2021 has been obsoleted by a new revision, which
has been approved as DS. This doc is now in RFC-Editor queue:
http://www.rfc-editor.org/queue.html#draft-ietf-rmonmib-rmon2-v2
Since the previous IETF Last Call was so long ago, this new IETF
Last Call is intended to make everyone aware that the doc is again
on the IESG agenda.
The file can be obtained via
http://www.ietf.org/rfc/rfc2613.txt
Implementation Report can be accessed at
http://www.ietf.org/IESG/Implementations/RFC2613-Implementation.txt
---------------------------
_______________________________________________ Gen-art mailing list Gen-art <at> ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
FYI - I just this week started working for Google (as of Feb 27). It's going to be a busy startup.... can you put me on a max of 1 doc per week until further notice? I'll try to deal with the backlog RSN...
| "Spencer Dawkins" <spencer <at> mcsr-labs.org>
02/15/2006 04:16 PM |
To: "General Area Review Team" <gen-art <at> ietf.org> cc: "Margaret Wasserman" <margaret <at> thingmagic.com>, "H.K. Jerry Chu" <jerry.chu <at> sun.com>, "Bill Strahm" <bill <at> strahm.net>, Vivek Kashyap/Beaverton/IBM <at> IBMUS Subject: Gen-ART Review of draft-ietf-ipoib-connected-mode-02.txt |
_______________________________________________ Gen-art mailing list Gen-art <at> ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
>>>>> "Elwyn" == Elwyn Davies <elwynd <at> dial.pipex.com> writes:
Elwyn> I was selected as General Area Review Team reviewer for
Elwyn> this specification (for background on Gen-ART, please see
Elwyn> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Hi.
I'm sorry it has taken me so long to get back to your comments.
I've been busy trying to clear documents before the Dallas IETF.
Elwyn> Summary: [Note: This is the first time that I have done a
Elwyn> Process Experiment review and I will have to stretch the
Elwyn> usual review criteria a bit. Basically I believe I should
Elwyn> be looking for internal self-consistency, consistency with
Elwyn> associated processes and likelihood of damage to the
Elwyn> functioning of the IETF.]
That seems like a good approach. I'm also doing this for the first
time so your cooperation in helping me is greatly appreciated.
Elwyn> I think this draft is NOT currently in a suitable state to
Elwyn> produce a well-defined experiment. The main reason for
Elwyn> this conclusion is that the experiment consists of enabling
Elwyn> a meta-mechanism and suggesting something the IESG might
Elwyn> possibly do with this power rather than explicitly stating
Elwyn> that this is what the IESG should put in place.
I'd like to focus on your general comments about the draft not being
ready. I think we can come back to specific textual comments after
we've reached general agreement. I'd like to first take your issue of
the IESG charter and then come back to the meta issue that all this
experiment does is enable the IESG to do things.
Elwyn> My reading
Elwyn> of s7.2 of the IESG Charter [RFC3710] is that the IESG has
Elwyn> the power to do this sort of thing already anyway.
Note that the IESG charter is an informational document. It cannot
give the IESG power that it does not otherwise have.
It was not clear to the participants on the IETF list that the IESG
has the power to create mechanisms between 3683 and 3934 without a BCP
or experiment. If the consensus of the IETF community is that the
IESG already has that power and that the IESG's power is already well
documented then I will withdraw my draft. My personal opinion is that
the power is not well documented and thus is subject to higher
probability of successful appeal.
Elwyn> Were
Elwyn> the suggested mechanisms eventually adopted, I would have
Elwyn> some qualms about the possibility of indefinite bans being
Elwyn> possible without allowing a wider (possibly IETF as opposed
Elwyn> to IESG) consensus, but that point is currently moot as the
Elwyn> actual proposals that would be put in place are not
Elwyn> specified by this document.
I don't think the point is moot. If there are specific limits on the
IESG's power that should be put in place, here is the place to do it.
Alternatively when we evaluate the experiment we could decide
additional limits are needed.
But let's come back to the question of whether meta-experiments are a
good idea. I think that in order for 3933 to be a valuable tool many
of the experiments are going to be meta-experiments. So let me first
explain why I think that's the case and then discuss how to evaluate a
meta experiment.
The primary reason you want to encourage meta-experiments is that a
lot of the hypotheses you want to test involve delegation. For
example I want to test the hypothesis that the right way to solve the
mailing list mess is to delegate it to the IESG. I could delegate it
to the IESG as part of an experiment along with a initial procedure.
But if I do that I'm testing a different hypothesis: is delegating
something to the IESG with the whole IETF designing the initial
conditions a way to solve the problem. As you might imagine that's a
different hypothesis. Since I'm on the IESG I'm actually in a
reasonably good position to negotiate an initial procedure that the
IESG will be happy with and that would be similar to a procedure the
IESG would come up with on its own. However we want 3933
experiments--even experiments delegating things to the IESG--to be
documents that anyone can write. So we should require that authors of
3933 experiments demonstrate stakeholder buy-in for experiments but
not require that they take actions as if they were the stakeholders.
The second reason that you want to allow meta-experiments is that we
want to encourage RFC 3933 as the first step in process change.
Process change often results in BCPs. You want the 3933 experiment to
be reasonably similar to a BCP so that when appropriate you can easily
convert a successful experiment into a BCP. You would probably
replace any evaluation criteria with results of the evaluation,
replace the sunset clause with something else. However you want the
operative language to remain the same. A significant result of the
mailing list discussion is the concern that our BCPs are too specific
and encode operational details. If you require that meta-experiments
are not allowed you strongly push us in the direction of
overly-specific BCPs. I think that would be a very bad idea.
Finally, we want 3933 experiments to be easy to write. One of my
personal goals with this particular experiment was to see how easy I
could make it to write the experiment. I think we want to come away
from this process with the conclusion that writing the document is
easy. The hard part of process change should be building consensus,
recruiting stakeholders, educating the community and actually trying
to use a process to do superior technical work. We should not make it
hard for people who clearly know what they want to try to express it.
So I'd like to resist the temptation to raise the bar for experiments
beyond what is necessary. Bars I'm asked to meet will probably be at
least as high as future experiments.
In conclusion, the hypothesis I'm testing is meta, so my experiment is
meta. i think allowing this is desirable because it allows us to test
the hypothesis, begins to align with an eventual BCP if the test is
successful and supports the cultural engineering goal of making
experimentation the preferred direction for process change.
You are absolutely right that we need to evaluate this at the end.
I'll first point to RFC 3933 and remind you that specific criteria for
evaluation are not required. In that case the basic evaluation will
be based on community reaction. Let us take a look at how that might
work in this case.
One possibility is that the IESG adopts no procedures based on this
experiment. That sounds like a failed experiment to me: why is the
power needed if never used. There might be some arguments that having
a power prevents future problems, but these arguments would be
unlikely to be compelling.
Another case is that the IESG adopts some procedures and these
procedures never get used. We'd actually learn a lot in this case.
The IESG would get a feel for whether this specification was clear
enough to describe what procedures could be adopted and what steps
need to be followed to adopt a procedure. It's a strong
understatement to say that there tend to be rough edges around any
process document the first time it is run. There are things I'd word
more clearly in 3683, 3934, 3933, 3932 and other process documents.
These tend to pop out the first time you try and use them. We would
get a significant part of that feedback from just adopting procedures
under this experiment. We'd need to have a community discussion about
whether we wanted to extend the experiment, codify it in a BCP or drop
it. If the reason no procedures were used was that no problems popped
up on any mailing lists, I'd argue against dropping it. If the
community felt comfortable, we could publish a BCP. Otherwise we
could renew the experiment. If the discussion proved contentious then
the next round of the experiment would probably need more evaluation
criteria.
[As an aside, RFC 3933 seems to have a rough edge that you cannot
renew an experiment without publishing a new RFC. I'm not at all sure
that's desirable. However if you end up needing to add evaluation
criteria most times you renew and experiment, perhaps that is OK.]
If procedures are adopted and used, I think we're in a reasonable
position to evaluate the results. I know one criteria I'd apply: was
the situation less disruptive to the work of the IETF and the IETF
leadership than an RFC 3683 action
If so, then we made progress. Others might have different criteria to
apply. One possible outcome of the evaluation is that we need to
renew the experiment with explicit criteria because we cannot agree on
an evaluation. Another is that the experiment should be the basis for
a BCP. Another is of course that the experiment made things worse and
should terminate.
In conclusion I've proposed evaluation criteria that I believe cover
the possible outcomes. These criteria are fuzzy. I believe it is no
more fuzzy than if a specific procedure is included. Clearly such
fuzzy criteria are allowed by RFC 3933.
All that said, if the community wants changes then the draft will
change. We're looking for an IETF consensus here. If there is
significant demand for specific evaluation criteria we can include
those. If there is a community requirement for a specific initial
procedure, I can include one. I think that particular change would
set a harmful precedent but would make the change if that is what the
community wants. However, having explained that I'm explicitly trying
to experiment with delegation and having proposed possible ways of
thinking about evaluating the result,I would want to see a much
stronger call for change than one review. If the experiment actually
isn't viable then one comment should be sufficient. However I don't
think that is the case.
Elwyn> Review:
Elwyn> s1: I think that this section of the last paragraph of s1
Elwyn> overstates/mis-states what this document actually does:
>> This memo is an RFC 3933[RFC3933] experiment to provide the
>> community with additional mechanisms to manage its mailing
>> lists while the community decides what mailing list guidelines
>> are appropriate. IN particular this experiment creates a level
>> of sanction between RFC 3934 and RFC 3683 for working group
>> lists and creates sanctions other than RFC 3683 for
>> non-working-group lists.
>>
Elwyn> In practice all that s4 mandates is:
>> During the experiment period, the IESG MAY approve other
>> methods of mailing list control besides those outlined in RFC
>> 3683 and RFC 3934 to be used on a specified set of IETF mailing
>> lists.
>>
Elwyn> i.e., it enables a meta-mechanism. s4 then goes on to
Elwyn> suggest some things the IESG *might* adopt (second half of
Elwyn> para 1 and all of para 2 of s4) and the procedures that it
Elwyn> must go through to get them adopted. The result of this is
Elwyn> (in the first instance) merely the provision to allow the
Elwyn> IESG to decide to do something. I don't think this
Elwyn> constitutes a well-formed experiment.
Often, the community creates mechanisms by delegating the power to
someone. I'd be interested in other comments on whether the last
sentence of S1 over states things?
I think I'd rather hear your responses to these general comments
before going through the rest of your detailed comments.
--Sam
RSS Feed58 | |
|---|---|
147 | |
92 | |
107 | |
85 | |
72 | |
62 | |
79 | |
60 | |
73 | |
62 | |
90 | |
63 | |
87 | |
61 | |
92 | |
130 | |
50 | |
80 | |
97 | |
89 | |
77 | |
85 | |
126 | |
59 | |
85 | |
77 | |
94 | |
101 | |
127 | |
53 | |
61 | |
62 | |
68 | |
49 | |
89 | |
76 | |
85 | |
117 | |
74 | |
96 | |
106 | |
74 | |
128 | |
108 | |
131 | |
81 | |
122 | |
94 | |
118 | |
51 | |
59 | |
79 | |
145 | |
123 | |
98 | |
92 | |
58 | |
67 | |
108 | |
105 | |
97 | |
122 | |
95 | |
72 | |
49 | |
115 | |
117 | |
73 | |
66 | |
47 | |
102 | |
72 | |
44 | |
69 | |
106 | |
92 | |
62 | |
116 | |
89 | |
98 | |
115 | |
69 | |
121 | |
99 | |
68 | |
67 | |
127 | |
120 | |
133 | |
115 | |
28 |
