[Gen-art] Assignments for 28 August 2008
Hi all, Here's the link to the summary of assignments for the August 28, 2008 telechat: http://www.softarmor.com/rai/temp-gen-art/reviewers-080828.html With the updated spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html For your convenience, the updated review boilerplate template is included below. Note that reviews should ideally be posted to the gen-art mailing list by COB next Tuesday, per the review guidelines: http://www.alvestrand.no/ietf/gen/art/review-guidelines.html Mary. --- 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. Document: Reviewer: Review Date: IESG Telechat date: 28 August 2008 Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] A *new* batch of IETF LC reviews - 21 Aug 2008
Hi all, Here's the link to the new LC assignments for this week: http://www.softarmor.com/rai/temp-gen-art/reviewers-080821-lc.html The assignments are captured in the spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html Please note the changes to the template below to ensure that the major issues are listed at the beginning, etc. Thanks, Mary. --- 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: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-tsvwg-udp-guidelines-09
Hi,
thanks for your comments!
On 2008-8-12, at 15:27, ext Ben Campbell wrote:
Section 3.1.1, paragraph 3:
I think this paragraph may be confusing to some implementors, in
that you suggest monitoring packet-loss to determine fair bandwidth
competition with UDP. A few worlds elaborating on how packet-loss
relates to fair use of bandwidth would be helpful. An example would
help even more.
The text in that section is actually taken from RFC3551 Section 2,
which has a bit more more detail. I could add a sentence that refers
to that RFC, instead of copying (more of) the text.
Note, however, that there is no easy answer, because essentially what
needs to be done is building a custom congestion control scheme - far
from trivial. That's why the draft strongly recommends to use an
existing scheme. There is no easy example that can be given, because
the task is fairly complex.
Section 3.1.2, paragraph 1:
Should I take this to mean that implementing TFRC is insufficient
for low-volume applications, and that they should follow the
guidelines in this section even if they implement TFRC? If so, this
conflicts with the previous statement that applications implementing
TFRC do not need to worry about the other recommendations in section
3.1.
Yes, TFRC is only effective for bulk transfers, and Section 3.1.1 is
fairly clear about this. Section 3.1.2 is on low-datarate
applications, where different mechanisms are needed. Please take a
look at Sections 3.1, 3.1.1 and 3.1.2 again, and let me know if you
still think this is unclear.
Paragraph 3:
The few sentences seem redundant with previous paragraph. Given that
they are about pre-determined initial intervals, I assume they fit
better in this paragraph than the previous.
There is some similar text, because the initialization of the
intervals is the same in both cases. But paragraph 3 (and 4) are about
applications that can't maintain an RTT sample (for various reasons),
so there is a key difference.
I could remove the duplicate text and say something like "the initial
timeout is set to the same values as in the previous paragraph", but I
don't believe that'd be much clearer.
Section 3.1.3, numbered list:
Item 1 assumes all IP-based payloads are congestion-controlled,
while 2 explicitly calls out non-congestion controlled IP-based
payloads. I assume the intent was for item 1 to refer just to
congestion-controlled IP-based payloads.
Right. 1 is on IP traffic, and the general assumption is that any IP
traffic would be congestion controlled. 2 is on non-IP traffic or IP
traffic that is *known* to not be congestion controlled. Is that not
clear?
Section 3.4, paragraph 1:
I'm not sure what what the practical meaning of "a coding point of
view" is in this context.
Sloppy writing. What is meant is "coding theory". I'll change that.
Section 3.5, paragraph 6, last sentence:
This advice seems counter to the idea that applications should be
designed to work on the internet at large, rather than for some
specific network configuration. Perhaps you meant to say "The
deployers of applications should investigate..."?
Sorry, which paragraph are you referring to here?
(The last sentence of paragraph 6 of Section 3.5 is the following,
which I can't bring in relation to the above comment: "It is
RECOMMENDED that applications apply slight random variations
("jitter") to the timing of keep-alive transmissions, in order to
reduce the potential for persistent synchronization between keep-alive
transmissions from different hosts.")
Section 3.5, last paragraph:
This first few sentences of this paragraph are redundant with
previous text in this section.
Yup. We wanted to stress this point, this repetition is on purpose.
Section 3.6, paragraph 3, first sentence:
Sentence is ambiguous as to whether "with an IP source address..."
refers to the received datagram or the one being sent in response. I
think the sentence would be clearer if you just removed the text "in
reply...UDP datagrams".
Yes, that reads much better.
Paragraphs 4 and 5:
Is there any guidance associated with these paragraphs?
Some WG participants felt that the document should point out that the
socket API for UDP is subtly different than that for TCP, which
developers are more familiar with, and those two paragraphs give some
examples. I guess the guidance would be "pay attention to that." Do
you have a suggestion how we could make that more clear?
Thanks,
Lars
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.txt
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-tcpm-tcp-soft-errors-08.txt Reviewer: David L. Black Review Date: 21 August 2008 IETF LC End Date: 26 August 2008 Summary: This draft is on the right track, but has open issues, described in the review. Comments: This is a good draft reporting on problems encountered in practice with TCP's handling of ICMP errors and what has been done about them. This draft has received extensive discussion in the Transport Area, and I believe it is wise to defer to the Transport Area decision that this draft will not make any changes to the TCP standard. While the draft is in generally good shape, I did find three open issues: (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. As part of doing this, please state whether trying v6 and v4 connections in parallel is a good idea or not and why. (2) Section 4.1 describes a mechanism from RFC 3168 that retransmits a modified SYN when an RST is received in response to an ECN-setup SYN, and suggests that this mechanism is applicable to ICMP errors received in response to an ECN-setup SYN. This mechanism was specified in RFC 3168 because there were known deployed middleboxes with this problem-causing RST behavior, and the mechanism was necessary to deal with them. Are there any known middleboxes that send an ICMP error in response to a SYN that signals ECN capability? - If yes, state the specific ICMP error(s) that is(are) used and limit the recommendation to the actual error(s). - If no, remove this entire RFC 3168 discussion as speculative, or describe it as a possible response should this problem scenario ever arise in practice. (3) Section 5.3 describes a NAT behavior that causes a host TCP problem and then suggests changing the NAT to fix it. While that's a good idea in an ideal world (and needs to be stated in the draft), in practice, deployed NATs have to be dealt with as-is. In addition to recommending fixing the NAT, please discuss what could be done when the NAT cannot be fixed. Nits: Section 1 - reduce generality of this text. OLD: This document analyzes the fault recovery strategy of TCP [RFC0793], and the problems that may arise due to TCP's reaction to ICMP soft errors. NEW: This document analyzes problems that may arise due to TCP [RFC0793] fault recovery reactions to ICMP soft errors. It would be good to provide the text expansion of the codes in Figure 1, as was done in the text before the figure. In section 4, please provide the expansion of TCPM WG (TCP Maintenance Working Group). idnits 2.08.10 ran clean. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [EMAIL PROTECTED]Mobile: +1 (978) 394-7754 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] gen-art review of draft-ietf-avt-rtp-atrac-family-16.txt
Mr.Brim, Thank you for your comment and suggestion. We will update the draft reflecting your idea if we have no other comments. Best Regards, Jun > On 8/21/08 5:35 AM, actech allegedly wrote: >> Mr.Brim and Mr.Jennings, >> >> Thank you for your comments. >> I still make a friendly suggestion that you document that dependency, because if there is an extension to the ATRAC specification in the future to support a higher bit rate, this protocol might break. Scott If we assume that the smallest MTU is 576, would anything need to be changed? >> In order to solve the problem, we have two ways that >> - incorporating rollover mechanism >> - increasing of bit number for fragment counter(FrgNo) >> >> Incorporating rollover is easy to modify the standard. >> However, the determination of right order of the packets are sometimes >> impossible if the received packets have the identical FrgNo and >> severely reversed or inverted arrival of the packets are occured. >> >> Regarding on increasing of the bit number, appropriate bit number should be >> determined considering various MTU size, or assuming some limitation. >> In addition, the impact of modification of the draft is not small in >> current (our) system. >> >> We are happy if we can have your further comments. >> >> Regards, >> >> Jun > > My suggestion is not to change the specification, but simply to document > the assumption. For example: > >Fragment Number (FrgNo): 3 bits >In the event of data fragmentation, this value is one for the first >packet, and increases sequentially for the remaining fragmented data >packets. This value SHOULD be zero for an unfragmented frame. (Note: >3 bits is sufficient to avoid Fragment Number rollover given the >current maximum supported bit-rate in the ATRAC specification. If >that changes, the choice of 3 bits for the Fragment Number should be >revisited.) > > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] gen-art review of draft-ietf-avt-rtp-atrac-family-16.txt
On 8/21/08 5:35 AM, actech allegedly wrote: > Mr.Brim and Mr.Jennings, > > Thank you for your comments. > >>> I still make a friendly suggestion that you document that dependency, >>> because if there is an extension to the ATRAC specification in the >>> future to support a higher bit rate, this protocol might break. >>> >>> Scott > >>> If we assume that the smallest MTU is 576, would anything need to be >>> changed? > > In order to solve the problem, we have two ways that > - incorporating rollover mechanism > - increasing of bit number for fragment counter(FrgNo) > > Incorporating rollover is easy to modify the standard. > However, the determination of right order of the packets are sometimes > impossible if the received packets have the identical FrgNo and > severely reversed or inverted arrival of the packets are occured. > > Regarding on increasing of the bit number, appropriate bit number should be > determined considering various MTU size, or assuming some limitation. > In addition, the impact of modification of the draft is not small in > current (our) system. > > We are happy if we can have your further comments. > > Regards, > > Jun My suggestion is not to change the specification, but simply to document the assumption. For example: Fragment Number (FrgNo): 3 bits In the event of data fragmentation, this value is one for the first packet, and increases sequentially for the remaining fragmented data packets. This value SHOULD be zero for an unfragmented frame. (Note: 3 bits is sufficient to avoid Fragment Number rollover given the current maximum supported bit-rate in the ATRAC specification. If that changes, the choice of 3 bits for the Fragment Number should be revisited.) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] gen-art review of draft-ietf-avt-rtp-atrac-family-16.txt
Mr.Brim and Mr.Jennings, Thank you for your comments. > > I still make a friendly suggestion that you document that dependency, > > because if there is an extension to the ATRAC specification in the > > future to support a higher bit rate, this protocol might break. > > > > Scott > > If we assume that the smallest MTU is 576, would anything need to be > > changed? In order to solve the problem, we have two ways that - incorporating rollover mechanism - increasing of bit number for fragment counter(FrgNo) Incorporating rollover is easy to modify the standard. However, the determination of right order of the packets are sometimes impossible if the received packets have the identical FrgNo and severely reversed or inverted arrival of the packets are occured. Regarding on increasing of the bit number, appropriate bit number should be determined considering various MTU size, or assuming some limitation. In addition, the impact of modification of the draft is not small in current (our) system. We are happy if we can have your further comments. Regards, Jun ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-dime-diameter-api-07.txt
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-dime-diameter-api-07.txt
Reviewer: Francis Dupont
Review Date: 2008-08-20
IETF LC End Date: 2008-08-08
IESG Telechat date: unknown
Summary: Not Ready
Comments: my main concern is the API as it is described up to section 3.7
is clearly impossible to implement so I strongly suggest to add soon
(in section 2 for instance) some text explaining the document only
specifies the visible/public part of some structures.
Another issue is most of the "include" part is missing.
Detailed comments:
- 1 page 4: code need only -> code needs only
- 2.2 page 6: All of the functions -> All functions ?
- 2.5 page 6: a DTD described it -> a DTD describing it
- 2 page 6: IMHO this is the right place to explain the structs
defined in the document are the visible/public part of the real/internal
structs with a reference to section 3.7
- 3.1.12 page 10: if -> when ?
- 3.1.15 page 12: the header (six, four) is obviously about a previous
version...
- 3.1.15 page 12: IMHO you should explain why, despite the name "flags",
it is right to use an enumeration here (exclusive values, etc).
- 3.1.16 page 12: AAAGetDomainInterconnectType() doesn't return
this type (cf. 3.4.3.7) and it is not AAAGetDomainInternconnectType()
^
- 3.2.3 page 15: this type should be opaque, i.e., the name of the
fields should be private. This has two consequences:
* users don't know the names so can't misuse them (they have
AAAGetFirstAVP() & co)
* it justifies a bit the *avpList in the next section (in place
of plain avpList)
BTW in a traditional double-linked list with tail pointer the
tail is a ** pointer
- 3.2.4 page 16: extra *Version fields (unneeded with AAA_IP_ADDR)
- 3.4.3.7 page 24: type should be a AAADomainInterconnect *
- 3.4.4.6 page 27: AAAGetCommandCode() must return an AAAReturnCode
and the return value text be updated to the usual one
- 3.4.5.4 page 29: occured -> occurred
- 3.4.5.6 page 30: AAACreateAndAddAVPToList() is underspecified:
* can be the avpList created when it points to NULL?
(cf next section)
* what is the position when the list is not empty?
- 3.4.5.[67] pages 30 & 31: there is no way to free an AAA_AVP_List
so what to do if something fails? Obviously there are some use
restrictions so at least a reference to 3.6 is wellcome
- 3.4.5.1[45] page 34 (comment): obviously AAAGet{Next,Prev}AVP()
imply link fields in the real AVP struct!
- 3.4.6.1 page 36: extra ipVersion field
- 3.4.6.2 page 36 (comment): again the server id is an internal
AAAMessage field
- 3.6 page 38: (for uniformity)
(char *) ourAddress -> (char *)ourAddress
- 3.7 page 39: this is a key point but one has to read ~40 pages
to find it. Note there are other ways to handle public/private
fields in C (but no highly recommended ways):
* the sub structure way (document's one)
* private fields at the end of the definition with a comment
explaining they are private
* private fields at the end of the definition protected by a #ifdef
I prefer the second one (no cast, sizeof() works but it relies
on the programmer's discipline) but you should simply give the
choice to implementors
- 3.9 page 41: 3.1.13 specifies there can be only one first/last,
for instance:
AAA_APP_INSTALL_FIRST: Install this callback as the first callback
in the chain. If subsequent callbacks are installed with this
code, then AAA_ERR_ALREADY_REGISTERED is returned.
so 3.1.13 and 3.9 are in conflict (note I prefer 3.1.13)
- 7.2 page 45: where are the DIAM_AVP_* & co defined?
I am afraid you have to add them...
- Author's Addresses page 46: please add the Contry (USA? :-)
- I'd like to have a .h in annex (note the names of the .h and
of the DLL/library/... are part of the API)
Regards
[EMAIL PROTECTED]
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
