Thanks Russ,
https://github.com/tlswg/sslkeylogfile/pull/11 and
https://mailarchive.ietf.org/arch/msg/media-types/5IW3tN6mJkqZMyuYWLwoOMNVhgM/
should address those issues.
Cheers,
Martin
On Fri, Apr 12, 2024, at 14:30, Russ Housley via Datatracker wrote:
> Reviewer: Russ Housley
> Review resu
I just got bounced. Novice move, I know, but in case anyone else is late…
On Sun, Jul 23, 2023, at 18:13, Charles Eckel (eckelcu) wrote:
> Got it (before and again now). See you there soon!
>
> Cheers,
> Charles
>
>> On Jul 23, 2023, at 6:11 PM, Lars Eggert wrote:
>>
>> Could someone ACK the rec
On Wed, Jul 12, 2023, at 03:34, Adrian Farrel wrote:
>> Please consider redrawing the figures using SVG instead of ASCII.
>> Especially Figure 4 would greatly benefit from this enhancement.
>
> I think Figure is about as complex as they get, and it doesn't delight me.
> But using SVG is a step too
Hi Peter,
You are the first to review the new revision, so thanks.
https://github.com/ietf-wg-ohai/oblivious-http/pull/235 contains most of the
fixes here.
On Fri, Dec 16, 2022, at 16:37, Peter Yee via Datatracker wrote:
> Page 6, section
> 2.1, 1st bullet item: should this be “two additional r
Hey David,
I blame laziness for not trying this earlier, but once I tried out something
*like* your suggestion I found I was pleased.
https://github.com/httpwg/http-extensions/pull/2127
It might not be as much of a change as you imagined, but I think that a small
change like this does improve
Thanks Brian,
On Sun, Feb 23, 2020, at 17:01, Brian Carpenter via Datatracker wrote:
> Is this draft intended to become part of BCP25? I think it would be
> useful for the IESG to clarify this rather than leave it to the RFC Editor.
This is a good question. Given the intended status of BCP, I wo
Thanks for the review Robert,
On Wed, Nov 27, 2019, at 09:47, Robert Sparks via Datatracker wrote:
> Neither the document nor the shepherds write-up acknowledge or explain the
> replacement of RFC6838 with RFC3986 for a reference for specifying fragment
> identifier syntax and semantics (hence dro
Thanks Pete,
On 6 April 2017 at 15:52, Pete Resnick wrote:
> A "keyid" parameter SHOULD be a UTF-8
> [RFC3629] encoded string, particularly where the identifier
> might
> need to appear in a textual form.
>
> I presume that simply means "might need to be rendered" and does not
>
Hi Russ, sorry for missing this. I have a pull request open against
my spec with the changes I've made.
https://github.com/martinthomson/drafts/pull/31
On 19 April 2016 at 05:35, Russ Housley wrote:
> Minor Concerns:
>
> I think it would really help
> the reader to say at the beginning somethi
I apologize for missing this, it was badly filed. Thanks for the
comments. Fresh eyes are always helpful here, and you identified lots
of little pieces of potentially confusing text.
The changes will be in -05, but you can preview them on github:
https://httpwg.github.io/http-extensions/tunnel-p
Thanks. I think that you have everything in hand. I'm happy with the
promised changes.
On 23 March 2015 at 01:16, Stefan Winter wrote:
> Diameter defines its own S-NAPTR tags in its own RFCs
Ack.
>> S2.1.1.2 uses SHOULD to recommend that clients retry with their other
>> certificates. I'd re
ery-13
Reviewer: Martin Thomson
Review Date: 2015-03-21
IETF LC End Date: 2015-03-20
IESG Telechat date: 2015-04-19
Summary: This document is of a quality I rarely see even for proposed
standard. It is certainly fit for publication as an experimental RFC.
(In case it isn't clear, I agr
On 12 March 2015 at 15:27, A. Jean Mahoney wrote:
> Martin Thomson2015-03-20 draft-ietf-radext-dynamic-discovery-13
I'll try, but that time frame is a little tight.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/
That looks fine.
On 10 March 2015 at 02:41, Francois Le Faucheur (flefauch)
wrote:
...
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
On 9 March 2015 at 10:13, Francois Le Faucheur (flefauch)
wrote:
> Hi Martin,
>
> Getting onto you first batch of comments:
>
>>
>> Summary:
>>
>> Major issues:
>>
>> Minor issues:
>>
>> S3.1 needs to define the basic atom that is used for the logging file.
>> It appears as though the atom is an o
Gotta run, but I hope these responses help.
On 9 March 2015 at 10:13, Francois Le Faucheur (flefauch)
wrote:
> Hi Martin,
>
> Getting onto you first batch of comments:
>
>>
>> Summary:
>>
>> Major issues:
>>
>> Minor issues:
>>
>> S3.1 needs to define the basic atom that is used for the logging f
On 5 March 2015 at 07:21, Francois Le Faucheur (flefauch)
wrote:
...
> I have added this at the end of S3.3:
>
> NEW:
> “
> An uCDN-side implementation of the CDNI Logging interface MUST reject a CDNI
> Logging File that does not comply with the occurences specified above for
> each and every dire
On 4 March 2015 at 18:44, Jari Arkko wrote:
> But back to your review. As you may have seen, I think -02 addresses this
> issue. (By deleting the text, which I think also works.)
Indeed, I now have no concerns.
___
Gen-art mailing list
Gen-art@ietf.or
do).
Nit: HTTP/2 not HTTP/2.0
Question: There is no mention made of range requests, for which this
might be well suited, particularly if files get large.
I note the privacy considerations are pretty reasonable. I'd be much
happier if IP anonymization were not optional though.
On 12 February
viewer: Martin Thomson
Review Date: 2015-02-12
IETF LC End Date: 2015-02-18
IESG Telechat date: (if known)
Summary:
Major issues:
Minor issues:
S3.1 needs to define the basic atom that is used for the logging file.
It appears as though the atom is an octet.
S3.2 uses the wildcard ABNF rule (i.e.,
I've updated the pull request. You can see the changes there.
Note that the reason I'm pushing back hard on text additions is that
it's hard to ensure that I've correctly maintained the intent of text
that has already been extensively reviewed. Deletions are easier, but
only slightly. If you fe
I definitely want to avoid making prescriptive statements about what to
protect, even couched as suggestions. However, I think that a more generic
statement that describes the characteristics of a header that might need
protection is definitely a good idea.
If Herve doesn't get there first, I can
On 20 January 2015 at 10:48, RUELLAN Herve wrote:
> I did a few additional ones in:
> https://github.com/http2/http2-spec/pull/694
LGTM, I suggested a reword of one of the sentences.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailma
In the absence of answers from the editors, I can provide an
explanation for the choices you have identified as being issues.
I've also turned your comments into a pull request.
https://github.com/http2/http2-spec/pull/693
You can review that; but the editors will likely have some more to say
ab
Thanks for the thorough review Elwyn.
I've made changes in the form of a proposed change set against the
editor's copy.
https://github.com/http2/http2-spec/pull/692
You can review the changes at that link. Note that some of the typos
you caught were already fixed, or will be fixed in other prop
ses-03
Reviewer: Martin Thomson
Review Date: 2015-01-02
IETF LC End Date:
IESG Telechat date: (if known)
Summary: Ship it.
Nits/editorial comments:
I think that there are a few too many Unnecessarily Capitalized
Phrases. Consider downcasing for statements like "Power, Energy,
Demand and Power
spf-te-metric-extensions-09
Reviewer: Martin Thomson
Review Date: 2014-12-29
IETF LC End Date: 2014-12-24 (nice)
IESG Telechat date: 2015-01-08
Summary: Good for PS with some minor issues.
Observations:
I find it a little disappointing that measurement techniques are so
nebulously defined. Valu
On 25 November 2014 at 07:59, Jari Arkko wrote:
> I agree with many of these comments (were they observed?) but I also agree
> with the part about “ship it” :-)
I have not seen a response.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org
ity-05
Reviewer: Martin Thomson
Review Date: 2014-10-31
IETF LC End Date: 2014-11-18
IESG Telechat date: (if known)
Summary: Ship it; it's more important to have this stake in the ground
than it is to have it right.
Major issues:
This is the first attempt at definition, which appears at th
On 29 October 2014 03:52, Dearlove, Christopher (UK)
wrote:
> Any objection that something better can be done needs to provide that
> something better, not just say "asymmetric, therefore something better".
That's a totally fair comment. I was trying for expediency, since
that is fairly obvious
On 28 October 2014 06:37, Dearlove, Christopher (UK)
wrote:
> From my perspective, and with support shown in the WG, this is an option that
> several people want. The need for a trusted authority is a minus point, but
> acceptable by some users and should not be blocked because it is not ideal
On 24 October 2014 11:17, Dearlove, Christopher (UK)
wrote:
> I am also not aware of a solution that overcomes this problem without
> introducing different limitations, so it is a question of tradeoffs. This is
> one point in that tradeoff space. If anyone has a clearly superior solution
> that
ibs-03
Reviewer: Martin Thomson
Review Date: 2014-10-23
IETF LC End Date: 2014-10-27
IESG Telechat date: (if known)
Summary: Ready with questions.
The language is quite clear and precise. I did find that
comprehension required a non-trivial amount of digging into other
documents, but nothi
viewer: Martin Thomson
Review Date: 2014-10-16
IETF LC End Date: past
IESG Telechat date: 2014-10-16
Summary: I found no major issues here, but I'm not able to give this
proper time to do this justice. I have some comments, but these need
to be considered in context of the time I've spe
On 17 August 2014 23:09, Juergen Schoenwaelder
wrote:
>
> can we get things unstuck with the following NEW text replacing the
> first paragraph in the security considerations section in -03? (I
WFM
___
Gen-art mailing list
Gen-art@ietf.org
https://www
ct SNMP SET operations.
>
> In general, I prefer to not change the boilerplate. Suggestions for
> boilerplate changes should be sent to the responsible AD (Benoit
> Claise) I think.
>
> /js
>
> On Mon, Aug 11, 2014 at 03:41:36PM -0700, Martin Thomson wrote:
> > I am th
viewer: Martin Thomson
Review Date: 2014-08-11
IETF LC End Date: 2014-06-22
IESG Telechat date: (if known)
Summary: Ready.
Nits/editorial comments:
Looks like the first paragraph of the Security Considerations was left
hanging. I looked and this sentence is a little confusing, since all
the MAX-
On 14 July 2014 10:44, wrote:
> Part of your comments has already addressed into the latest version. Some are
> still applicable. Please see below.
> Let me know if it is OK for you and I will produce a revision of the draft.
Sounds good. Look to your sponsoring AD for guidance on when to post
(Please keep the To/Cc; the responsible ADs/shepherds probably need to
see these emails. Add ietf@ if you feel you want the larger audience;
I figured saag was a large enough peanut gallery :)
On 10 July 2014 19:41, Viktor Dukhovni wrote:
> On Thu, Jul 10, 2014 at 05:16:15PM -0700, Mar
curity-01
Reviewer: Martin Thomson
Review Date: 2014-07-08
IETF LC End Date: 2014-08-05
IESG Telechat date: (if known)
Summary: This reads a little like it was rushed. This needs some work
before it can be considered ready.
(I've cc'd saag here. That seemed appropriate, strip as you s
ns to ask.
>
> - Jouni
>
>
>
> On Sep 14, 2013, at 3:13 AM, Martin Thomson wrote:
>
>> 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/GenArtfa
On 5 June 2014 20:29, Anoop Ghanwani wrote:
> It is possible for a sophisticated attacker with knowledge of the details of
> large flow recognition algorithm (packet fields used and parameters of the
> algorithm) and the network topology to launch an attack in which sufficient
> traffic is generat
bis-01
Reviewer: Martin Thomson
Review Date:
IETF LC End Date: 2014-06-20
IESG Telechat date: (if known)
Summary: Looks good.
Major issues: None
Minor issues:
This seems like a prohibition by omission:
MAY also serve the root-servers.net zone, and the zone for the
.arpa top-level
Inline...
On 6 May 2014 19:16, Anoop Ghanwani wrote:
>> There's not a lot of discussion about the costs of maintaining an
>> exception list for rebalanced flows. A hash-based distribution is
>> going to cost essentially zero state because the outbound path can be
>> determined on a per-packet ba
w-load-balancing-11
Reviewer: Martin Thomson
Review Date: 2014-04-24
IETF LC End Date: 2014-05-06
IESG Telechat date: (if known)
Summary: Basically ready. Looks like a pretty straightforward, even
commonsense, coverage of the ways that flow distribution might be
achieved and a need for it identified.
On 10 April 2014 07:15, Jari Arkko wrote:
>>
>> A lot has happened since RFC 3455 was published. The privacy considerations
>> around the use of P-Access-Network-Info are unchanged from their pre-Geopriv
>> form. In particular, I find the UA knowledge part to be problematic;
>> Geopriv defini
On 9 April 2014 05:41, Jari Arkko wrote:
> Have there been any responses or changes based on your comments? I do not see
> the document version having changed...
I have seen no response or revision.
___
Gen-art mailing list
Gen-art@ietf.org
https://ww
On 4 March 2014 20:10, Haynes, Tom wrote:
> In reviewing the Gen-ART reviews of 3530bis, I realized I had not
> responded to your review. We had been very focused on S12.
I thank you for taking the time. I honestly hope that I've helped in
some way to improve the document.
It's been too long si
bis-13
Reviewer: Martin Thomson
Review Date: 2014-02-27
IETF LC End Date: 2014-03-14
IESG Telechat date: (if known)
Summary: I find it strange that this 3GPP document is being published
on the standards track. But since it's a -bis there is clearly
precedent, and it is otherwise sound.
Major is
On 5 February 2014 05:01, Elwyn Davies wrote:
> This is not really anything to do with me but I would point out that the
> Information Centric Networking folks would probably disagree with the
> view on "new data" that Martin expresses below - ICN would prefer that
> if the data is the same then i
On 27 January 2014 08:16, Wendy Roome wrote:
> An “ALTO Server” is a collection of services provided by a provider. That
> provider may distribute these services over several different physical
> servers, and that distribution may change over time. If we used URIs to
> identify those services, the
viewer: Martin Thomson
Review Date: 2014-01-25
IETF LC End Date: 2014-02-04
IESG Telechat date: ?
Summary: This is a pretty damned good document and an impressive
achievement. Don't let the number of issues I raise lead you to
conclude that it isn't. It's huge and complex and
d of section **
>
> regards,
>
> Victor K
>
>
>
> On Wed, Jan 22, 2014 at 10:01 AM, Martin Thomson
> wrote:
>>
>> On 22 January 2014 13:00, Benoit Claise wrote:
>> > Is your concern that the sentence "IPv6 is considered the strategic
>> > ans
On 22 January 2014 13:00, Benoit Claise wrote:
> Is your concern that the sentence "IPv6 is considered the strategic answer"
> in section 2 is not stressed enough?
I think that the text in the second paragraph is slightly more loaded.
In particular,
These issues
leave an operator in a p
On 15 January 2014 19:40, Victor Kuarsingh wrote:
>> Which seems wise given their somewhat contentious nature. But then
>> the entirely of Section 2 does exactly the opposite. I don't know
>> what the right answer is here, but maybe the right thing to do is
>> delete Section 2.
>
>
> [VK] The i
ent-04
Reviewer: Martin Thomson
Review Date: 2014-01-06
IETF LC End Date: 2014-01-06
IESG Telechat date: (if known)
Summary: This document describes a generic way that MPLS LSPs can be
deployed to support the deployment of CGNs in a way that addresses a
range of common requirements. As a draft, it&#
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 Last Call comments
you may receive.
Document: draft-ietf-6man-ug-05
Reviewer:
Inline.
On 28 October 2013 17:24, Carlos Jesús Bernardos Cano wrote:
>> Where is ALL_ZERO defined? (Same for NON_ZERO.) I can guess, but I
>> don't like doing that.
>
> [Authors] These are defined in RFC5213. We can add a explicit reference
> first time we introduce these terms.
Thanks.
> [Au
viewer: Martin Thomson
Review Date: 2013-10-27
IETF LC End Date: 2013-10-31
IESG Telechat date: ?
This document is ready (PS), modulo a few niggles.
Minor issues:
Where is ALL_ZERO defined? (Same for NON_ZERO.) I can guess, but I
don't like doing that.
S5.3:
It's been a while since I&#
ide-19
Reviewer: Martin Thomson
Review Date: 2013-09-13
IETF LC End Date: unknown, early review
IESG Telechat date: (if known)
Summary: This document is ready, with some minor issues and nits.
Minor issues:
I would find it a lot easier to read this document if it did as the
goals state (the first obj
Thanks Peter.
I fixed all the nits:
https://github.com/martinthomson/drafts/commit/0e7cc6089e96f6b4b2a2cff0d094733b313b8e39
On 31 July 2013 13:50, Peter Yee wrote:
> Page 9, section 4.2, 2nd paragraph, 1st sentence: I'll admit my ignorance
> of the finer points of the DNS and inquire what this s
Hi Carsten,
I wasn't really looking for a defense of the design in the form you
just provided, cogent as it was. I want to know what value you get
from these extensibility features, not a reiteration (and expansion)
of the characteristics of those features.
My operating assumption was that JSON
On 5 August 2013 18:43, Joe Hildebrand (jhildebr) wrote:
> Sorry, my response is also correspondingly long.
I'll be brief. Though Joe missed my point on several of his rebuttals
(which I found to be an odd thing to do anyway), I see no reason to
quibble. I think that the bulk of the comments ar
Adding draft-relevant recipients.
On 30 July 2013 00:05, Martin Thomson wrote:
> 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
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 Last Call comments
you may receive.
Document: draft-bormann-cbor-04
Reviewer:
On 11 July 2013 13:03, Brian E Carpenter wrote:
> but IMHO it would be better
> if we submitted our reviews via the review tool, which could then
> send them on as email automatically.
I have all the same problems as Brian. And this might also make
access control easier, such that reviews could
Correct. There are a number of DISCUSS positions that will be resolved by -08.
I haven't read all the DISCUSS material yet, but I expect that there will need
to be a few more edits to catch the rest of them. I'll have to coordinate with
Richard to determine when to ship -08. I don't want to
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>
Document: draft-ietf-dhc-dhcpv6-radius-opt-12
Reviewer: Martin Thomson
Review Date: 30 May 2013
IETF LC End Date: 30 May 2013
IETF Te
On 30 May 2013 05:29, Jari Arkko wrote:
> Also, did I miss a response form the authors/WG to this review? I can not
> find one in my e-mail archives…
Nor can I.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Thanks Suresh.
I've made the changes in the -08 that I'm holding for AD go-ahead. I'll try to
remember to send you a note when this goes out.
> Summary: This draft is almost ready for publication as a Proposed
> Standard, but I have a few minor comments that you may wish to address.
>
> * Sect
On 26 April 2013 10:44, Stewart Bryant wrote:
> Section 6.3 now says
>
> The HMAC proceedure described in [RFC2104] is used to compute the hash.
s/proceedure/procedure/
> The hash is computed over the entire GAP message as shown in Fig1.
What value does the Authentication TLV have when it is in
hernet-addressing-07
Reviewer: Martin Thomson
Review Date: 2013-04-19
IETF LC End Date: 2013-02-18 (!)
IESG Telechat date: 2013-04-25
Summary: This document is almost ready for publication as proposed
standard. There are some minor issues
Major issues: None
Minor issues:
The structure of the docum
viewer: Martin Thomson
Review Date: 2013-04
IETF LC End Date: too soon
IESG Telechat date: ditto
Summary: I have some confidence that this document is ready for
publication. What I have seen is sufficiently well specified that it
could be implemented, mostly. There are large parts of this documen
Hi Stewart,
Looks like you have most of this in hand. A few comments.
On 27 March 2013 13:11, Stewart Bryant wrote:
>>> In Section 4.4, how does the duration interact with the lifetime?
>>> What happens when the duration is longer than lifetime such that the
>>> TLV is expunged before the durat
I sent the following review a few weeks back. I just wanted to make sure
that it didn't get accidentally stored in /dev/null.
On 15 February 2013 14:33, Martin Thomson wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ a
viewer: Martin Thomson
Review Date: 2013-02-15
IETF LC End Date: 2013-02-27
IESG Telechat date: (if known)
Summary: The document is almost ready for publication as proposed
standard. There is a major issue that should be easy to resolve.
Major issues:
Section 6.3 duplicates the description o
I've reviewed the latest (-06) and it is equally ready. (That is,
I've seen no changes as a result of this review.)
On 17 January 2013 13:49, Martin Thomson wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the
FYI, I can't believe that I did this again.
Sorry Russ.
-- Forwarded message --
From: Martin Thomson
Date: 17 January 2013 13:49
Subject: Gen-ART review of draft-ietf-avtcore-srtp-encrypted-header-ext-04
To: draft-ietf-avtcore-srtp-encrypted-header-ext@tools.ietf.org
I have reviewed the changes in -06. All my concerns were addressed.
(Not that they were significant.)
Now that OIDs were allocated, it's really, truly ready now.
--Martin
On 6 December 2012 17:02, Martin Thomson wrote:
> Document: draft-schaad-pkix-rfc2875-bis-03
> Reviewer: Mar
On 7 December 2012 00:25, Jim Schaad wrote:
>> Needs more ASN.1
>
> I'm lost with this, what do you believe needs to be added? The ASN.1 as it
> stands is complete.
'twas in jest. Don't worry about it. I didn't see any errors, but
I'm not a very good ASN.1 parser.
bis-03
Reviewer: Martin Thomson
Review Date: 2012-12-06
IETF LC End Date: Aaaages
IESG Telechat date: (if known)
Summary: Looks good to me. Ship it.
Nits/editorial comments:
Section 3 does not establish a notation convention for multiplication.
I didn't find a specific place that this was a prob
On 17 November 2012 00:16, Brian E Carpenter
wrote:
> I don't quite understand that. RFC3986 section 2.1 says
> pct-encoded = "%" HEXDIG HEXDIG
> with no restrictions on HEXDIG, so why is %01 disallowed?
> (I agree it would be meaningless, but that's another matter).
Meaningless is precisely my
Try again, this time with the right recipients.
On 16 November 2012 12:22, Martin Thomson wrote:
> 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>.
>
>
viewer: Martin Thomson
Review Date: 2012-11-16
IETF LC End Date: 2012-11-26
IESG Telechat date: not scheduled
Summary: This document is ready for publication as Proposed Standard,
with nits.
Nits/editorial comments:
The document could be made shorter by removing:
We now present the nec
ppsawg-media-type-suffix-regs-06
Reviewer: Martin Thomson
Review Date: 2012-10-16
IETF LC End Date: 2012-10-19
IESG Telechat date: 2012-10-25
Summary: This document is ready for publication as a (?) RFC.
Minor issues: Is BCP status really appropriate? Informational seems
more appropriate for this s
I have reviewed -15 of this draft and my major issues have been
resolved. This document is ready.
On 21 September 2012 16:43, Martin Thomson wrote:
> Lucky you. I am the assigned Gen-ART reviewer for this draft. For
> background on Gen-ART, please see the FAQ at
> <http://wiki.to
fer-14
Reviewer: Martin Thomson
Review Date: 2012-09-21
IETF LC End Date: 2012-10-12
Summary: This document is in pretty good shape. I have a concern over
how Prefer: wait might be implemented that I believe needs to be
addressed prior to publication as Proposed Standard. There are also a
num
fwk-04
Reviewer: Martin Thomson
Review Date: 2012-09-23
IETF LC End Date: 2012-08-24
IESG Telechat date: -
Summary:
This document is ready for publication as an Informational RFC.
Nits:
I think that you probably meant to have the second letter of
"Antonymous System" rotated 180 degrees. This
es are inline below.
>
> Thanks,
> --David
>
>> -Original Message-
>> From: gen-art-boun...@ietf.org [mailto:gen-art-boun...@ietf.org] On Behalf Of
>> Martin Thomson
>> Sent: Tuesday, July 24, 2012 6:54 PM
>> To: draft-ietf-storm-iscsi-sam@tools.ietf.org; g
: draft-ietf-storm-iscsi-sam-06
Reviewer: Martin Thomson
Review Date: 2012-07-24
IESG Telechat date: ?
Summary: This document has a few issues that would need to be
addressed before it is published as a Standards Track RFC.
Major Issues: None
Minor Issues:
Is the intent to reference RFC 3720 or
On 8 June 2012 00:33, Brian E Carpenter wrote:
> Please see attached review. I haven't cc'ed the IETF or IESG since
> my comment is only a process issue, but this can be forwarded as you
> think fit. If the IESG can see a way round it consistent with RFC 2026,
> that would be fine by me.
The "Upd
neling-02
Reviewer: Martin Thomson
Review Date: 2012-06-08
IETF LC End Date: 2012-07-02
IESG Telechat date: (if known)
Summary: This document is ready for publication as an Experimental
RFC, with one question.
Major issues: None
Minor issues:
I'm not sure that I agree with the SHOULD strength
Feature request for the tool: a place to put reviews so that I don't
keep forgetting to CC the gen-art list.
-- Forwarded message --
From: Martin Thomson
Date: 20 May 2012 19:34
Subject: Gen-ART review of draft-ietf-tcpm-tcpmss-04
To: draft-ietf-tcpm-tcpmss@tools.ietf.or
Look, this really doesn't bother me that much. But I can't even
imagine what a sensible implementation would do for these two points.
I don't like 2119 language that I can't see how to comply with.
Maybe I'm just not imaginative enough.
On 13 April 2012 12:14, Murray S. Kucherawy wrote:
>> Sect
On 13 April 2012 14:05, Barry Leiba wrote:
> The advantage here is that the AS is a standards-track document, and
> will progress along the standards track just as a Technical
> Specification would. Making it Information loses that aspect.
It wouldn't make sense for this to be made informational
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 Last Call comments
you may receive.
Document: draft-ietf-marf-as-13
Reviewer:
Thanks! Looks good.
On 11 April 2012 09:31, Bocci, Matthew (Matthew)
wrote:
> Martin,
>
> On 11/04/2012 16:55, "Martin Thomson" wrote:
>
>>On 11 April 2012 06:44, Bocci, Matthew (Matthew)
>> wrote:
>>> MB> Yes, it's really the communication
On 11 April 2012 06:44, Bocci, Matthew (Matthew)
wrote:
> MB> Yes, it's really the communication mechanisms. Those details are
> specified in the separate, standards-track,
> draft-ietf-pwe3-redundancy-bit, which does impact interoperability.
> Therefore I propose updating this sentence to clarify
-05 is good.
On 10 February 2012 10:15, Martin Thomson wrote:
> 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 wit
viewer: Martin Thomson
Review Date: 2012-03-15
IETF LC End Date: 2012-03-21
IESG Telechat date: (if known)
Summary: The draft has some minor issues.
Major issues: none
Minor issues:
3.2.2 states: "The mechanisms for achieving this selection are outside
the scope of this document."
1 - 100 of 107 matches
Mail list logo
