..: draft-ietf-ipfix-mediators-problem-statement-09
Reviewer..: Christian Vogt
Review date...: May 7, 2010
IESG Telechat date: May 6, 2010
Summary: This draft is ready for publication as a Informational RFC.
This document identifies scalability problems with modern flow-based
measurement
tately that these enhancements only apply when multiple instances
> are being used to support multiple address families as defined in
> the draft.
>
> Thanks,
> Acee
>
> |-Original Message-
> |From: Christian Vogt
> |Sent: Wednesday, December 02, 2009 6:18 PM
&g
..: draft-ietf-ospf-af-alt-09
Reviewer..: Christian Vogt
Review date...: December 2, 2009
IESG Telechat date: December 3, 2009
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
The document describes small
On Sep 23, 2009, Avshalom Houri wrote:
> - It would be worth mentioning in the introduction of the document
what
>the expected result of this document should be. Obviously, we
are
>expecting (or hoping for) an improvement in the scalability of
>SIP/SIMPLE, but this should be ma
..: draft-ietf-sipcore-presence-scaling-requirements-02
Reviewer..: Christian Vogt
Review date...: September 22, 2009
IESG Telechat date: September 24, 2009
Summary: This draft is basically ready for publication, but has nits
that should be fixed before
Adrian -
Your proposed RFC Editor notes are excellent. I consider this Gen-ART
review addressed. Thanks.
- Christian
On Jul 16, 2009, Adrian Farrel wrote:
All,
I propose the following RFC Editor note...
Section 1
OLD
Although both static and dynamic configuration of MPLS-TP transport
..: draft-ietf-mpls-tp-requirements
Reviewer..: Christian Vogt
Review date...: July 15, 2009
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
This document specifies protocol requirements for MPLS in packet
transport
.
Document..: draft-ietf-softwire-security-requirements-07
Reviewer..: Christian Vogt
Review date...: 2009-04-01 (no, not a joke)
IESG Telechat date: 2009-04-02
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication
..: draft-ietf-ippm-delay-var-as-01
Reviewer..: Christian Vogt
Review date...: Jan. 7, 2009
IESG Telechat date: Jan. 8, 2009
Summary: This draft is ready for publication as Informational RFC.
This document compares two widely used metrics for measuring packet
delay
..: draft-ietf-nfsv4-rfc1831bis-10
Reviewer..: Christian Vogt
Review date...: December 11, 2008
IESG Telechat date: December 11, 2008
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
Document draft-ietf
..: draft-ietf-mmusic-sdp-capability-negotiation-09
Reviewer..: Christian Vogt
Review date...: October 24, 2008
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
The document on "SDP Capability Negotiation&quo
..: draft-sanchez-webdav-current-principal-01
Reviewer..: Christian Vogt
Review date...: September 24, 2008
IESG Telechat date: September 25, 2008
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
This
..: draft-ietf-pwe3-cep-mib-12
Reviewer..: Christian Vogt
Review date...: August 6, 2007
Summary: This draft is ready for publication as a Proposed Standard
RFC
I have no objections against publishing this document, yet would
suggest considering the following three
Yuji -
To address your comment, I propose to add a new parragraph below in
this section (after 4st paragraph). I think your question was if this
requirement has benefit or not, so I'm trying to clarify that.
" This policy will benefit customers. Some customers would like to
detect failure
Hi Yuji,
thanks for addressing my comments on your document. I like the
changes you are suggesting. These settle the questions/concerns I had.
Regarding your clarifications on fate sharing: Do you think you could
add these thoughts to the document, perhaps as an introductory
paragraph
Never mind. The document is great also without the modifications.
- Christian
On Jul 25, 2008, at 20:45, Tony Li wrote:
Hi Christian,
Thank you very much for your review.
Unfortunately, the document has already been approved by the IESG:
https://datatracker.ietf.org/idtracker/draft-ietf-is
..: draft-ietf-isis-te-bis-00
Reviewer..: Christian Vogt
Review date...: 2008/07/25
Summary: This draft is ready for publication as a Proposed Standard
RFC.
The document is clearly ready for publication. Just two nits:
In section 3, you write:
Further, there is no defined mechanism
..: draft-iijima-netconf-soap-implementation-09
Reviewer..: Christian Vogt
Review date...: 2008/07/03
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
One comment regarding section 3.1.2 ("Se
Gonzalo,
the modifications you are proposing definitely address the
comments I had. Thanks!
- Christian
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
..: draft-ietf-bfd-v4v6-1hop-08
Reviewer..: Christian Vogt
Review date...: 2008/06/04
IESG Telechat date: 2008/06/05
Summary: This draft is basically ready for publication, but has 1 nit
that should be fixed before publication.
Comments:
This draft describes the use of
Acee,
thanks for clarifying this in the OSPFv3 document. The changes you
applied make it clear what the purpose and scope of the document is.
This addresses my comments from the Gen-ART review.
Best,
- Christian
On Apr 15, 2008, at 21:59, Acee Lindem wrote:
> Hi Christian,
> Actually, I miss
review this large document. See inline.
>
> On Apr 10, 2008, at 6:05 AM, Christian Vogt 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/ietf/gen/art/gen-
-ospfv3-update-18.txt
Reviewer: Christian Vogt
Review Date: April 10, 2008
Summary: This draft is ready for publication as a Proposed
Standard RFC.
Comments:
This document specifies OSPF for IPv6 networks. It is very well
written, clear overall, structured, and easily understandable
-sipping-consent-format-06
Reviewer: Christian Vogt
Review Date: March 10, 2008
IETF LC End Date: March 6, 2008
IESG Telechat date: --
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
Comments:
(1) It would be nice if section 3.1
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).
Document: draft-ietf-manet-jitter-04
Reviewer: Christian Vogt
Review Date: 12/23, 2007
IETF LC End Date: 11
Hi Eliot -
I think we are actually on the same page regarding section 3.1, and this
is just a terminology question. What you consider "private" is the
personal data desired by the attacker, whereas I was considering this to
be the user's username and password.
Mechanisms attackers use to ac
..: draft-ietf-l2vpn-vpls-mcast-reqts-05
Reviewer..: Christian Vogt
Review date...: Nov 15, 2007
IESG Telechat date: --
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
Comments:
(1) Section 4.1.2
: draft-ietf-sigtran-rfc4233update-02
Reviewer: Christian Vogt
Review Date: 15 Nov 2007
IESG Telechat date: 15 Nov 2007
Summary: Ready for publication after this nit.
Comments:
This document updates RFC 4233 ("Integrated Services Digital Network
(ISDN) Q.921-User Adaptation Layer&q
-simple-prescaps-ext-08.txt
Reviewer: Christian Vogt
Review Date: October 26, 2007
Summary: Ready.
Comments: This document is ready for publication from my
perspective. Just two nits, which the authors may want to
correct:
Section 3.2.8. (" element"):
The element indicate
-ietf-sigtran-rfc4233update-01
Reviewer: Christian Vogt
Review Date: Oct 25, 2007
Summary: Almost ready.
Comments:
This document updates RFC 4233 ("Integrated Services Digital
Network (ISDN) Q.921-User Adaptation Layer"). It changes a
message type code to resolve a type code coll
Francis,
I think we disagree on this issue. IMO the I-D is missing a clear
statement that a binding between the home address and IPsec SA is
required. If you don't want to add this statement, let's agree to disagree.
Regards,
- Christian
Francis Dupont wrote:
In your previous mail you w
Francis,
unless you bind the IPsec security association to the home address, an
attacker could send a Binding Update message with a spoofed home address
using its own IPsec SA. The correspondent node's IPsec instance would
accept that message and hand it on to the Mobile IPv6 instance. The
Francis,
the purpose of Mobile IPv6 is to redirect packets for a home address to a
care-of address. To authorize such redirection, one needs to ensure that the
node requesting it is the home address owner. This is why it is necessary to
have a strong binding between an IPsec SA and the home addr
Francis:
> => in fact the home address impersonation attack exists only in the mobile
> node - home agent case, not in the mobile node - correspondent case. If a
> node can use the address of another node to communicate with the
> correspondent, establish some security association, etc, this is an
-mip6-cn-ipsec-05
Reviewer: Christian Vogt
Review Date: September 10, 2007
IETF LC End Date: September 9, 2007
IESG Telechat date: --
Summary: Ready with nits.
Comments:
An important requirement for IPsec-based protection of Mobile IPv6 route
optimization is that the IPsec security associations
Hannes:
> I hope that the new draft version addresses your comments.
> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-05.txt
It does, addressing my main comment right in the introduction.
Thanks for the revision,
- Christian
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).
Document: draft-ietf-ipfix-biflow-05
Reviewer: Christian Vogt
Review Date: August 21, 2007
IESG Telechat date
: draft-crispin-collation-unicasemap-06
Reviewer: Christian Vogt
Review Date: August 21, 2007
IESG Telechat date: August 23, 2007
Summary:
This draft is basically ready for publication, but has nits that should be fixed
before publication.
Comments:
The document describes the collation
Henning and Hannes, one brief comment:
>> Maybe this should be clarified either in this document, or in the
>> Requirements document -- in particular because the Requirements document
>> currently only talks about verifying the caller's location, rather than
>> verifying whether there actually exi
Jonathan,
two small comments.
>> (1) Section 2.6, 1st paragraph:
>>
>> However, it is possible that packet
>> losses will cause a higher priority check to take longer to complete.
>> In that case, allowing ICE to run a little longer might produce
>> better resu
-mmusic-ice-17.txt
Reviewer: Christian Vogt
Review Date: August 16, 2007
IETF LC End Date: August 13, 2007
Summary:
This document is of very good quality. It also has a very plausible
problem statement and an excellent summary of the ICE operation. I
support this document going forward in the
Scott:
> I appreciate your comment and question. Measurement of each component
> requires white-box knowledge of the DUT. The BMWG by charter focuses on
> black-box measurements, which is the externally-observable sum of the
> components.
Yeah, I was assuming that. Maybe you just add a sentenc
: draft-ietf-sip-gruu-14
Reviewer: Christian Vogt
Review Date: August 10, 2007
IESG Telechat date: August 9, 2007
Summary:
This draft is ready for publication as a Proposed Standard RFC. Just 2
really small editorial nits.
Comments:
Section 1, 5th paragraph: s/the the/the/
The initialism
-dataplane-conv-app-13
Reviewer: Christian Vogt
Review Date: August 10, 2007
IETF LC End Date: --
IESG Telechat date: --
Summary:
This draft is basically ready for publication, but has a nit that I
think should be fixed before publication.
Comments:
Section 3 structures the components of
-security-threats-04.txt
Reviewer: Christian Vogt
Review Date: July 12, 2007
IETF LC End Date: --
IESG Telechat date: (if known)
Summary:
This document identifies and describes threats that affect emergency
call mechanisms. As the Requirements document, this document is already
in good shape
Great, this looks good.
- Christian
Brian Trammell wrote:
> Christian,
>
> We have addressed your comments in the present working copy, slated to
> be submitted as -05 after coordination with the document shepherd.
> Please see inline for specific comments...
>
> Regards,
>
> Brian
>
> [...]
Christian Vogt wrote:
> Document: draft-crispin-collation-unicasemap-04.txt
> Reviewer: Christian Vogt
> Review Date: 07 June 2007
> IESG Telechat date: 07 June 2007
There is actually no IESG telechat scheduled AFAIK. This was my
copy-and-paste mistake; it should be:
Document: d
: draft-ietf-ipfix-biflow-04.txt
Reviewer: Christian Vogt
Review Date: 07 June 2007
IESG Telechat date: --
Summary:
Ready with comments.
Comments:
The document is in a good shape overall. One thing I liked in
particular is the "Rationale and History" section, which describes
possi
: draft-crispin-collation-unicasemap-04.txt
Reviewer: Christian Vogt
Review Date: 07 June 2007
IESG Telechat date: 07 June 2007
Summary:
This document describes an extension to existing work on collation, and
it should go ahead for publication. One improvement suggestion below,
though.
Comments
Marshall,
the new version is fine with me. I think this document should go
forward now.
Best regards,
- Christian
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
hepherd
or AD before posting a new version of the draft.
Document: draft-ietf-tcpm-syn-flood-04.txt
Reviewer: Christian Vogt
Review Date: May 23, 2007
IESG Telechat date: --
Summary:
The draft is certainly ready for publication. I found it very
well-structured and easy to read. The introduc
-historic-01.txt
Reviewer: Christian Vogt
Review Date: May 21, 2007
IETF LC End Date: June 13, 2007
IESG Telechat date: (if known) --
Summary: Ready for publication
Comments:
- The introduction is precise and convincing.
- The security considerations were quite funny to read, I thought. It
Hello Roman:
>> I found that it might be useful to allow a telephone number to be
>> accompanied by a time range during which it should be used. E.g., it
>> might be ok to call an office number between 8 am and 5 pm, but a
>> cell-phone number should be used outside this time range. Possibly, th
: draft-ietf-inch-iodef-12.txt
Reviewer: Christian Vogt
Review Date: 9 May 2007
IESG Telechat date: 10 May 2007
Summary:
This draft is in a good condition. Especially the introduction provides
a reasonable understanding of the purpose and background of the standard
for an unexperienced reader. Few
tm.uka.de/2007/draft-ietf-mipshop-cga-cba-02to03.html
Best regards,
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
t change I was suggesting...
Yes.
Will incorporate your suggestions into the draft ASAP. Thanks!
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
d it should appear after "security
model" rather than after "base Mobile IPv6". Thanks for catching this!
Eric, my co-authors and I appreciate your review. Thanks again for taking
your time!
Regards,
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
s, please correct me if this is incorrect.
Kind regards,
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
Francis Dupont wrote:
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on G
58 matches
Mail list logo
