[Gen-art] Re: Gen-ART review of draft-ietf-ospf-mt-06.txt
Just restricting to the point that requires further discussion: Padma Pillay-Esnault wrote: Miguel Garcia wrote: - None of the figures in the draft include a caption. Captions are nice to refer to figures (even from other drafts). I would suggest to add captions to all the figures. Can you be more explicit here. Take for example the figure located in Section 4.1. I am suggestion to add a caption, so I can see that this is Figure 1 (and not Figure 3), and there is a title for such figure. Assuming that Figure 1 represents the OSPF Options field, then you could write: +---+---+---+---+---+---+---+---+ |DN |O |DC |EA |NP |MC |E |MT | +---+---+---+---+---+---+---+---+ Figure 1: The OSPF Options field Also, you should capitalize Options in the text, as it is done in RFC 2328. BR, Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:[EMAIL PROTECTED] Nokia Research Center Helsinki, Finland ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-ART review of draft-ietf-ospf-mt-06.txt
Miguel Garcia 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-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ospf-mt-06.txt Reviewer: Miguel Garcia [EMAIL PROTECTED] Review Date: 2006-11-01 IETF LC Date: 2006-11-02 IESG Telechat date: not known Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: The draft has two important issues that should be clarified, and a number of nits. In order of importance: - IANA Considerations section. In this section the draft explains what the draft does, but not what IANA has to do. It does not provide any instruction to IANA. Most likely IANA has to do something, operate or create some registry, and fill it with some values, but it is not explained. We will modify this portion we do not want IANA management of the MT space. - Normative text in configuration: The second paragraph of Section 5 reads: ... an MT capable router MUST be configured in DefaultExclusionCapability mode. I failed to understand how to implement and test a normative MUST in a configuration issue. I don't see how this affects the implementation. excerpt If links need to be removed from the default topology, an MT capable router MUST be configured in DefaultExclusionCapability mode. excerpt What we mean is: By default the DefaultExclusionCapabilityMode is off. If you need to exclude links from the default topology then you must turn the DefaultExclusionCapabilityMode on by configuration. In my opinion, the above MUST is not a MUST, but perhaps an explanatory text that provides guidelines to the human being that configures an MT capable router in a non-normative way. I also have a doubt about the normative MUST that appears in the first paragraph of Section 3.6, which reads: Each nexthop computed during the MT SPF MUST belong to the same MT. If I understand correctly, a router is computing some received information, so how can it make sure that each MT SPF belongs to the same MT in a received data? This smells like another un-implementable MUST. Agree this can be removed as well. Nits: - Expand the first occurrence of every acronym, e.g., OSPF, TOS, etc. ok - Section 3.3: add an informative reference to RFC 2328. ok - Text is easier to read if the future tense is not used. I would recommend to turn the first paragraph in Section 3.6 to present tense. ok - Section 3.7: the usage of brackets to indicate value ranges can mislead the reader with references, which they aren't. I would suggest to use some other type of brackets for value ranges or explain the contents, e.g.: s/[0-127]/from 0 to 127 s/[128-255]/ranging 128 to 255 ok - None of the figures in the draft include a caption. Captions are nice to refer to figures (even from other drafts). I would suggest to add captions to all the figures. Can you be more explicit here. - Section 4.1, last paragraph: s/enable/enabled ok - Section 4.2, last paragraph. It is hard to parse this sentence. I think an important comma is missing. Suggestion: OLD: When an area data structure is created the DefaultExclusionCapability is disabled by default. NEW: When an area data structure is created, the ^^^ DefaultExclusionCapability is disabled by default. ok - Section 5.1. The hellos and hello are hard to parse without quoting or capitalization. RFC 1793 refers to them as Hellos and Hello Packet (notice the capitalization), so I would suggest to capitalize them as well for better understanding. ok - The way of making references is not consistent. Sometimes they are used by name, such as [OSPF], some other times by RFC, such as [RFC1583]. There should be a consistent reference scheme. ok Thanks for your review Padma Regards, Miguel Garcia [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-ART review of draft-ietf-ospf-mt-06.txt
Miguel Miguel Garcia wrote: Just restricting to the point that requires further discussion: Padma Pillay-Esnault wrote: Miguel Garcia wrote: - None of the figures in the draft include a caption. Captions are nice to refer to figures (even from other drafts). I would suggest to add captions to all the figures. Can you be more explicit here. Take for example the figure located in Section 4.1. I am suggestion to add a caption, so I can see that this is Figure 1 (and not Figure 3), and there is a title for such figure. Assuming that Figure 1 represents the OSPF Options field, then you could write: +---+---+---+---+---+---+---+---+ |DN |O |DC |EA |NP |MC |E |MT | +---+---+---+---+---+---+---+---+ Figure 1: The OSPF Options field Also, you should capitalize Options in the text, as it is done in RFC 2328. OK. Thanks! Padma BR, Miguel ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] RE: Gen-ART LC review of draft-ietf-rohc-rtp-impl-guide-21.txt
Spencer, Thanks for this thorough review, responses can be found inline. Cheers, /L-E There are several places in the draft (section 3.3 and 4.1 are examples, but I noted others) where the INCOMPLETE, INCORRECT, INCORRECT AND INVALIDATED, CORRECTED, FORMAL ADDITION notation is not used, and the text doesn't say anything using 2119, but it seems to be changing the protocol. Given that the implementer will have two specifications open at the same time, being absolutely clear about what the text says NOW seems pretty important. I think this has also been the guiding principle when writing the draft, let's look at the specific cases. Abstract RFC 3095 defines the RObust Header Compression (ROHC) framework and profiles for IP, UDP, RTP, and ESP. Some parts of the specification Editorial: IP and UDP are probably OK, but ESP should certainly be expanded on first use, and RTP is an almost certainly expand on first use. Agree! (now I also noticed UDP-Lite was mis-spelled UPD) 1. Introduction and terminology RFC 3095 [1] defines the RObust Header Compression (ROHC) framework and profiles for IP [8][9], UDP [10], RTP [11], and ESP [12]. Editorial: same comment for RTP and ESP expansion on first use as in abstract. Agree! This document summarizes identified issues and provides corrections needed for implementations of RFC 3095 to interoperate, i.e. it constitutes an update to RFC 3095. This document also provides other clarifications related to common misinterpretations of the specification. When referring to RFC 3095, this document should therefore also be referenced. Editorial: when referring to RFC 3095, this document should therefore also be referenced. is probably correct but easy to misinterpret, I think. Perhaps something like References to RFC 3095 should also include this document. OK! When a section of this document makes formal corrections, additions or invalidations to text in RFC 3095, this is clearly summarized. The text from RFC 3095 that is being addressed is given and labeled INCOMPLETE, INCORRECT or INCORRECT AND INVALIDATED, followed by the correct text labeled CORRECTED, where applicable. When a formal addition is provided, it is given with the label FORMAL ADDITION. Technical Comment: I'm not sure formal addition is a widely used term - at least, not widely used enough to allow circular self-definition. Perhaps When text is added that does not simply correct text appearing in a previous specification, it is given with the label FORMAL ADDITION. No problem with using the label elsewhere in the document, it just needs to be described more clearly here. Agree, and your suggestions seem to be fine! 2.3. CRC coverage in CRC feedback options Section RFC3095-5.7.6.3 is incomplete, as it does not mention how the size field is handled when calculating the 8-bit CRC used in the CRC feedback option. Since the size field can be considered an extension of the code field, it must be treated in the same way. Editorial: if the specification is being corrected based on this consideration, perhaps it should be field is considered an extension. OK, I would even remove considered. 2.4. CRC coverage of the ESP NULL header Section RFC3095-5.8.7 gives the CRC coverage of the ESP NULL [13] header as Entire ESP header. This must be interpreted as including only the initial part of the header (i.e. SPI and Sequence number), and not the trailer part at the end of the payload. Therefore, the ESP NULL header has the same CRC coverage as the ESP header used in the ESP profile (section RFC3095-5.7.7.7). Technical Comment: Doesn't this actually need a text correction? I'm reading this section as saying [Entire must be interpreted as only the initial part], and if I'm intrpreting this correctly, the statement doesn't work for me. We do not consider this a correction, only an observation, making clear the only reasonable interpretation. Entire header excludes trailer, in this regard RFC 3095 and RFC 4303 (2406) are consistent. 3.1. Feedback during mode transition to U- and O-mode These enhanced procedures should be considered only as a possible improvement to a decompressor implementation, since interoperability is not affected in any way. A decompressor implemented according to the optimized procedures will interoperate with an RFC3095 compressor, as well as a decompressor implemented according to the procedures described in RFC3095 does. Editorial: The last sentence reads oddly to me. It would read more clearly if the sentence ended will interoperate with an RFC3095 compressor., without the last clause, but even removing the final does would be clearer. Ok, agree! 3.1.1. Mode transition procedures allowing sparse feedback This enhanced transition, where
[Gen-art] last reviews
I have some unfilled reports in gen-art-by-reviewer.html: - draft-ietf-isis-caps-06.txt: done after the last update (summary: Ready with nits) - draft-ietf-behave-multicast-03.txt: summary: Ready - draft-ietf-rddp-rdmap-07.txt: updated after the review, the main issue, reference to the old version of IPsec/IKE, should be solved by the update of RFC 3723, so there is no blocking point (i.e., summary: Ready). - draft-ietf-rddp-ddp-07.txt: same than for rddp-rdmap even I still don't like the used terminology which could be far simpler for rddp-ddp... Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
