Gen-Art LC review for draft-cotton-rfc4020bis-01

viewer: Robert Sparks Review Date: 2013-09-11 IETF LC End Date: 2013-09-24 IESG Telechat date: not scheduled Summary: This draft is on the right track but has open issues, described in the review. (That summary was taken from the options in RFC6385. I would prefer to say "There is one minor is

Re: Anyone having trouble submitting I-Ds?

On 8/18/13 4:04 PM, John Levine wrote: The anti-hijacking feature causes the confirmation email to only go to the authors listed on the previous version of the document, so mail was not sent to me and things are working as expected. This behavior is not documented to the user when they submit th

Re: Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34

are a number of issues in here that would be greatly helped by your input! On 2013-06-05 23:56, Robert Sparks wrote: Document: draft-ietf-mmusic-rfc2326bis-34 Reviewer: Robert Sparks Review Date: 05-Jun-2013 IETF LC End Date: 04-Jun-2013 IESG Telechat date: not yet on a telechat The document is

Gen-art last call review: draft-ietf-mmusic-rfc2326bis-34

bis-34 Reviewer: Robert Sparks Review Date: 05-Jun-2013 IETF LC End Date: 04-Jun-2013 IESG Telechat date: not yet on a telechat Summary: This draft is on the right track but has open issues, described in the review. I have not reviewed this document at the level of detail I prefer for Gen-art r

Re: Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt (updated for -07)

ry: Document: draft-ietf-6renum-gap-analysis-05.txt Reviewer: Robert Sparks Review Date: May 10, 2013 IETF LC End Date: April 10, 2013 IESG Telechat date: May 16, 2013 Summary: Ready On 5/2/13 6:02 AM, Liubing (Leo) wrote: Hi, Robert Thanks a lot for your continuous careful review. Pleas

Re: [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

:*dhcwg-boun...@ietf.org [mailto:dhcwg-boun...@ietf.org] *De la part de* Robert Sparks *Envoyé :* vendredi 26 avril 2013 17:42 *À :* dh...@ietf.org; ietf@ietf.org; General Area Review Team; draft-ietf-dhc-triggered-reconfig...@tools.ietf.org *Objet :* [dhcwg] Gen-art review: draft-ietf-dhc-triggered

Gen-art telechat review: draft-ietf-6renum-gap-analysis-06.txt

um-gap-analysis-05.txt Reviewer: Robert Sparks Review Date: April 1, 2013 IETF LC End Date: April 10, 2013 IESG Telechat date: May 16, 2013 Summary: Ready with nits (that border on minor issues) This update improved the readability significantly, and addressed my major concern about being able to

Re: [renum] Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

On 4/2/13 4:58 AM, Brian E Carpenter wrote: Just picking a couple of points for further comment: On 02/04/2013 08:46, Liubing (Leo) wrote: Hi, Robert ... -Original Message- From: Robert Sparks [mailto:rjspa...@nostrum.com] ... The document currently references draft-chown-v6ops

Re: [dhcwg] RE : Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

ernie Volz (volz) [mailto:v...@cisco.com] Envoyé : samedi 27 avril 2013 06:24 À : Robert Sparks; BOUCADAIR Mohamed OLNC/OLN Cc : dh...@ietf.org; General Area Review Team; ietf@ietf.org; draft-ietf- dhc-triggered-reconfig...@tools.ietf.org Objet : RE: [dhcwg] RE : Gen-art review: draft-ietf-dhc-tri

Re: RE : [dhcwg] Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

On 4/26/13 10:58 AM, mohamed.boucad...@orange.com wrote: Dear Robert, Thank you for the review. Please see inline. Cheers, Med De : dhcwg-boun...@ietf.org [dhcwg-boun...@ietf.org] de la part de Robert Sparks [rjspa...@nostrum.com] Date d'

Gen-art review: draft-ietf-dhc-triggered-reconfigure-05

figure-05 Reviewer: Robert Sparks Review Date: April 26, 2013 IETF LC End Date: May 6, 2013 IESG Telechat date: May 16, 2013 Summary: This draft is on the right track but has open issues, described in the review. Major issues: Overall, this document is solid, but I think there is a bug in s

Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

On 4/2/13 4:54 AM, Alexey Melnikov wrote: Hi Eric, I am sorry if I sound pedantic below, but I think your suggestion can be misinterpreted and thus needs improving: On 28/03/2013 12:13, Burger Eric wrote: Rather than guessing all of the bad things that could happen, I would offer it would be

Re: Missing requirement in draft-sparks-genarea-imaparch?

On 4/1/13 6:49 PM, Sam Hartman wrote: May I suggest that the specific details of this be left to the implementation effort. What is easy to implement in this area depends significantly on what platform (and here I mean more imap libraries and imap server technology than say python vs ruby vs .ne

Re: Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

On 3/28/13 1:17 PM, SM wrote: Hi Eric, At 05:13 28-03-2013, Burger Eric wrote: Rather than guessing all of the bad things that could happen, I would offer it would be better to say what we mean, like: The IMAP interface MUST NOT provide any IMAP facilities that modify the underlying mes

Gen-art review: draft-ietf-6renum-gap-analysis-05.txt

05.txt Reviewer: Robert Sparks Review Date: April 1, 2013 IETF LC End Date: April 10,2013 IESG Telechat date: Not yet scheduled for a telechat Summary: This document is not ready for publication as an Informational RFC. It may be on the right track, but there issues both in substance

Missing requirement in draft-sparks-genarea-imaparch? (was Re: New Version Notification - draft-sparks-genarea-imaparch-05.txt)

All - draft-sparks-genarea-imaparch has been revised to address comments from Pete Resnick and Barry Leiba. Jari Arkko has suggested that the security considerations section contain something like what RFC6778 contained about potential risks to CPU and I/O utilization. I plan to make that chan

Re: Is there a Git repository of RFCs? Or of Internet-Drafts?

On 3/15/13 1:40 PM, Dale R. Worley wrote: From: Christopher Morrow curious why rsync doesn't also seem 'straightforward' and 'well supported' ? Is this an advocacy of a particular tool? Or are you asserting that rsync can be used to maintain a directory of RFCs? If the latter, could you supp

Re: Last Call: (Methodology for Benchmarking SIP Networking Devices) to Informational RFC

Please see my response to the last call message for draft-ietf-bmwg-sip-bench-term. That review covered this document and that one at the same time. RjS On 1/16/13 3:47 PM, The IESG wrote: The IESG has received a request from the Benchmarking Methodology WG (bmwg) to consider the following do

Re: Last Call: (Terminology for Benchmarking Session Initiation Protocol (SIP) Networking Devices) to Informational RFC

Reviews of draft-ietf-bmwg-sip-bench-term-08 and draft-ietf-bmwg-sip-bench-meth-08 Summary: These drafts are not ready for publication as RFCs. First, some of the text in these documents shows signs of being old, and the working group may have been staring at them so long that they've become h

Re: Issues relating to managing a mailing list...

The current plan is to investigate both a web based archive access mechanism and an IMAP based one. I split the requirements for them into two drafts so the projects could be pursued separately. See also On 3/15/12 12:57 PM,

Re: Paris IETF Codesprint

If you are planning to join this codesprint, please make sure you've let us know by adding yourself to this page: so we can provision correctly. If you've not thought about the codesprint, take a couple of minutes now to look ove

Proposal to remove three datatracker pages (https://datatracker.ietf.org/iesg/ann/ind/, /new, and /prev

There are three pages exposed at the datatracker that have become stale or are producing erroneous information. https://datatracker.ietf.org/iesg/ann/ind/ https://datatracker.ietf.org/iesg/ann/new/ https://datatracker.ietf.org/iesg/ann/prev/ Has anyone been using those links? The first link, in

Re: meeting slots

I understand Dave's concern, but I think it would be valuable to make it easy to see what has been requested. Any changes to the conflict list would still have to come through the chairs, encouraging that distributed work model. I've entered this as an idea that someone might pick up for work a

Re: draft-housley-two-maturity-levels

Scott - Didn't RFC 5657 address your point 2? The current proposal no longer requires this report during advancement, but it does not disallow it. I hope it's obvious that I believe these reports are valuable, but I am willing to accept the proposed structure, with the hope and expectation that

Re: Late comment on draft-ietf-sippping-sip-offeranswer-14

I believe the current text in the draft reflects the discussion from 2007 at To summarize, while we think there may be implementations that interpret a change of session-id as a session reset, RFC3264 doesn't support the notion.

Re: Last Call: (Requirements for a Working Group Charter Tool) to Informational RFC

Hi Paul - In section 2.2, I would prefer either using the names the tracker currently uses for IESG evaluation: "Discuss" and "Comment", or some set of words that do not intersect those, perhaps "Blocking" and "Not-Blocking". The current set ("discuss" and "regular") will lead to confusion. In

Re: Last Call: (Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker) to Informational RFC

y to match against the values (or absence of value) of a state for the various state machines tracked by the tracker? RjS On Mar 14, 2011, at 4:26 PM, Robert Sparks wrote: > Paul - > > 1) If we publish this as an RFC, note that imgur.com will only keep an image > if it's viewe

Re: Last Call: (Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker) to Informational RFC

Paul - 1) If we publish this as an RFC, note that imgur.com will only keep an image if it's viewed at least once every three months. 2) In the list of things constituting an "update to an RFC", could you call out marking an RFC as Historic, and changing the maturity level of an RFC in place (su

Fwd: [Sip] New version of draft-ietf-sip-ipv6-abnf-fix

fyi Begin forwarded message: > From: "Vijay K. Gurbani" > Date: May 3, 2010 9:45:53 AM CDT > To: IETF SIP List > Cc: Brian E Carpenter , Brett Tate > > Subject: [Sip] New version of draft-ietf-sip-ipv6-abnf-fix > > Folks: A new version (-05) of draft-ietf-sip-ipv6-abnf-fix > is ready to be s

Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes

John, Jari - I was one of the folks expressing the concern Jari points to below, and it's a small facet of a larger worry I have about a potential (and I think likely) unintended consequence of the header/boilerplate changes. To capture that in this thread (with apologies for walking throug

Reminder: Tools codesprint at IETF74

If you are planning to join the codesprint at IETF74, please add yourself to the wiki page at to help us build a rough idea of how many folks will be present. More information about this sprint can be found at

Re: Proposed Experiment: More Meeting Time on Friday for IETF 73

I support conducting this experiment. RjS On Jul 17, 2008, at 4:33 PM, IETF Chair wrote: The IESG is considering an experiment for IETF 73 in Minneapolis, and we would like community comments before we proceed. Face-to-face meeting time is very precious, especially with about 120 IETF WGs com

Re: SHOULD vs MUST

fwiw - I have, for many SIPits (a rather large interop event for SIP implementations) worked to get the people writing code from these documents to understand that MUST means MUST and SHOULD means MUST ... (very long pause)... unless you _really_ know that not following the SHOULD won't re

Re: [Sip] NOTIFY on call transfer procedure

Section 6 of RFC3515 calls out why REFER is constructed this way. The root cause is the fixed length of any SIP non-INVITE transaction. The approach you sketch won't work as provisional responses to non-INVITE requests do _not_ lengthen the transaction. If you want a more detailed description, l