I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq .
Please resolve these comments along with any other comments you may receive.
Summary:
This draft is basically ready for publication, but
Phil,
The draft is well written - it was a pleasure to review it. The added
text on automated systems conveys the warning well (e.g., "worse than
useless and absolutely unsafe to rely on a robot voice"), thanks for
adding it. On backup/restore, I would elaborate somewhat on this added
text at th
I have performed an Operations Directorate review of
draft-zimmermann-avt-zrtp-17
Operations directorate reviews are solicited primarily to help the area
directors improve their efficiency, particularly when preparing for IESG
telechats, and allowing them to focus on documents requiring their
John,
> If I'm correct and transfer of a Standard to another SDO is
> really a non-issue, then perhaps the question of what problem(s)
> 5378 was intended to solve becomes more relevant... or perhaps
> it does not. But, given the problems the 5378/5377 model has
> turned out to create, eliminatin
Christian,
Thank you for doing this review.
On the volume identification offset:
> - Section 2.2.1 ("Volume Identification") specifies two methods for
>identifying a position on a disk: by positive offset starting at
the
>beginning of the disk, and by negative offset starting at the end
This is a combined Gen-ART and Transport Area review, hence
the introductory "boilerplate" for both reviews follows:
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.htm
Fernando,
> >(1) The I-D Tracker says that the v6ops-v6onbydefault draft is Dead.
> >Relevant portions of that draft should be reproduced or otherwise
> >explained in Section 3.2.
>
> The reference to this I-D has been updated to the corresponding RFC.
Thanks - please send the reference to the s
Larry,
> Paul Hoffman wrote:
> > Which SDOs that you participate in want to see other SDOs publishing
> > *incompatible* versions of their protocols?
>
> Hi Paul,
>
> Of course none of the SDOs that I work with want to see incompatible
> versions. But this turns the issue on its head. Open sour
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: draft-ietf-tc
Futemma-san,
The proposed new version of the draft looks ok to me - it has dealt
with all of the concerns in the Gen-ART review. I have one comment
on the changes.
The second paragraph of Section 8 now recommends clearing the
saved mh_id (and I would think also the saved header) if the
decoder d
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Docume
Authors,
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: draft-i
Alexey,
Thank you for your prompt response.
Keeping the To: and Subject: lines in the IANA registration
in Section 11.1 is fine since they are in RFC 2506, and
RFC 2506 is noted in that section as having established
the registry. Please consider adding an informative
reference to RFC 2506, but t
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: draft-ietf-le
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Docume
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: draft-ietf-av
Gonzalo,
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
D
This draft has not been revised since it was reviewed in
August. It is still basically ready for publication, but
has nits that should be fixed before publication.
An RFC Editor Note should be used to correct the bad section
reference (see below), and the IESG should ensure that this
correction i
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: draft-evain-ebu-
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: draft-ietf-nfsv4
Elisa,
> > Note that we're not singling out IPFIX here. The forthcoming
revisions
> > to the syslog documents, for example, will have the following
statement
> > ("TLS" is "TLS over TCP"):
> >
> >Because syslog can generate unlimited amounts of data,
transferring this
> >data over UDP i
Elisa,
> > Most of these responses look fine. I do think additional text
> > should be added on the topics of:
> > - warnings about when not to use unordered delivery
> > - explanation of when UDP use is appropriate
> > More details inline ...
> >
>
> Some responses also in line. I ha
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: draft-ietf-enum-
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Docume
Jonathan,
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: draft-
Elisa,
Most of these responses look fine. I do think additional text
should be added on the topics of:
- warnings about when not to use unordered delivery
- explanation of when UDP use is appropriate
More details inline ...
Many thanks,
--David
> David,
>
> thanks for your revi
Colin,
idnits 2.04.12 found a couple of reference nits:
Checking references for intended status: Proposed Standard
(See RFC 3967 for information about using normative references to
lower-maturity documen
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents.
These comments were written primarily for the transport
area directors, but are copied to the document's authors
for their information and to allow them to address any
issues raised.
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: draft-ietf-avt-r
Colin,
More comments inline.
> Thanks for the review - some comments inline.
>
> On 16 Jul 2007, at 22:35, [EMAIL PROTECTED] wrote:
> > 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/
Gonzalo,
The -05 draft looks fine, and I have no problem with leaving comment
(1) [whether to say something applicable beyond BFCP on the subjects
of IP address selection and use of SubjectAltName] to the discretion
of the ADs.
Thanks,
--David
> -Original Message-
> From: Gonzalo Camaril
Gonzalo,
Most of this looks good; I have a few comments:
(1) In the two places where there are general recommendations that
are not specific to BFCP (IP address selection and use of
SubjectAltName in certs in preference to Subject), it would
be good to note that these are
I've reviewed this document as part of the transport area
directorate's ongoing effort to review key IETF documents.
These comments were written primarily for the transport
area directors, but are copied to the document's authors
for their information and to allow them to address any
issues raised.
Pekka,
> > [logical components being:] encoding and transport along forward
> > path from marker to egress, metering of congestion information at
> > the egress, and transport of congestion information back to the
> > controlling ingress.
>
> I'd like to see it explicitly stated that transport
Ray,
Looking at the 2007 and 2008 dates on events.cal, it looks
like ANSI T10 (SCSI) is the primary conflict for the first week
of November, and ANSI T11 (Fibre Channel) is the primary conflict
for the first week of December. The currently proposed schedule
is first week of December for the 3rd I
Ray,
Let me check that I understand your answer - it sounds like you're
keeping
a 1-week buffer clear on both sides of IEEE 802, so that a November
IEEE
802 meeting makes it impossible for IETF to
meet in November as the
IEEE week plus the 1-week before and after buffers take out the
entir
36 matches
Mail list logo
