Re: [Gen-art] Genart last call review of draft-ietf-emailcore-rfc5322bis-11
Thanks for the review Thomas. Comments inline, only on those things that you had as issues: On 21 Apr 2024, at 13:03, Thomas Fossati via Datatracker wrote: * (234:23): error: This parser will truncate strings at %x00 * (236:28): error: This parser will truncate strings at %x00 * (238:25): error: This parser will truncate strings at %x00 * parsing failed: 3 errors encountered I don't understand what the error message is trying to tell me though. Looks to me like it is complaining about long lines once unwrapped. Nothing to fix here AFAICT. 1. It'd be good to state the reasons why this document updates 3864 earlier than in §6.1. [1] recommends using the intro section for that. Given that 3864 and 4021 are purely about IANA considerations, it seemed silly to call them out in the Abstract or Section 1 since they are not of technical import to the document. 2. Any reason for using the .test TLD rather than .example? RFC2606 says: ".test" is recommended for use in testing of current or new DNS related code. ".example" is recommended for use in documentation or as examples. [1] https://authors.ietf.org/required-content, Introduction checklist Two reasons: First, we needed enough easily distinguishable example addresses and using only .example and example. seemed like it would be too easily confused visually. But second, we were having problems keeping the examples to 72 characters for the text versions of the document. Using .test seemed the safest way to address the problem given that 2606 reserves it. Any downside you can see in using it? Nits/editorial comments: In §1.2.3: OLD: One reason for this latter requirement is that there are long-established sites on the Internet with mail archives that go back decades, archives with messages containing these elements. NEW: One reason for this latter requirement is that long-established Internet sites have mail archives dating back decades with messages containing these elements. No objection. Works for me. In §3.6.4: OLD: Though listed as optional in the table (Table 1) in section 3.6 NEW: Though listed as optional in Table 1 of Section 3.6 That's an annoying artifact of xml2rfc. I'll have a go at fixing it. Thanks again, pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-httpapi-rfc7807bis-04
Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-httpapi-rfc7807bis-04 Reviewer: Pete Resnick Review Date: 2022-10-27 IETF LC End Date: 2022-11-03 IESG Telechat date: Not scheduled for a telechat Summary: Ready to go; one comment below. Major issues: None Minor issues: None Nits/editorial comments: This paragraph in section 4 struck me oddly: An extension member (see Section 3.2) MAY occur in the Problem field if its name is compatible with the syntax of Dictionary keys (see Section 3.2 of [STRUCTURED-FIELDS]) and if the defining problem type specifies a Structured Type to serialize the value into. That almost sounds like what you want to say is: If an extension member (see Section 3.2) occurs in the Problem field, its name MUST be compatible with the syntax of Dictionary keys (see Section 3.2 of [STRUCTURED-FIELDS]) and the defining problem type MUST specify a Structured Type to serialize the value into. I'm curious if you are making a normative statement that would get lost in the current form. But I'm not sure what the high-order bit here is, so I leave it to you. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-regext-epp-eai-10
Reviewer: Pete Resnick Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-regext-epp-eai-10 Reviewer: Pete Resnick Review Date: 2022-06-01 IETF LC End Date: 2022-06-09 IESG Telechat date: Not scheduled for a telechat Summary: I think this proposal is reasonable, but I don't think enough explanation has been given regarding the case where one side supports the protocol but the other side doesn't. Major issues: The last bullet item in section 5.3.2 talks about "alternative ASCII address", but I don't see anywhere in the document which defines how to provide an alternative ASCII address in the data. For example, RFC 5733 implies that there will be only one email address in the Contact Mapping; can an implementation simply add a second? Does the server then need to distinguish these by the presence or absence of non-ASCII characters to determine which is an EAI and which is an alternative ASCII address? At the very least, some discussion of this seems necessary in the document. Minor issues: In the bullets in section 5.3.2, there are quite a few SHOULDs with no explanation of why one might choose to violate these. Why are these not MUSTs? I can't think of any reason, for example, that the server would not validate the email property, and it seems like a really bad idea not to. Nits/editorial comments: Abstract: Strike the word "appearing" Section 3: Change "By applying the syntax rules of [RFC5322]" to "By applying the syntax rules of [RFC6532]" ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-cbor-file-magic-11
Reviewer: Pete Resnick
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-cbor-file-magic-11
Reviewer: Pete Resnick
Review Date: 2022-04-15
IETF LC End Date: 2022-04-15
IESG Telechat date: 2022-04-21
Summary: Some mostly nit/editorial comments that really should be taken care
of, but no showstoppers.
Major issues: None
Minor issues: None
Nits/editorial comments:
Section 1 could use a solid edit. Here are some editorial issues that stuck out
to me (as always, just suggested changes):
Paragraph 3 (this one is a content problem rather than strictly nits, but also
isn't a technical issue with the document):
OLD
For instance, in classical MacOS, a
resource fork was maintained that includes media type ("MIME type")
information and therefore ideally never needs to know anything about
the file.
NEW
For instance, in classical MacOS, a
resource fork was maintained separately from the file data that
included file type information and therefore the OS ideally never
needed to know anything about the file data contents to determine the
media type.
No "But" is required at the beginning of paragraph 4.
Paragraph 5: Change "file" to "file contents". (For what it's worth, I disagree
with the paragraph, in that I think it's actually worse to keep the media type
information in the data portion of the file, but I don't have a problem with
you disagreeing with that in the introduction.)
Paragraph 8: Change the colon to a semicolon.
Paragraph 9: Replace "A third" with "An additional".
Swap paragraphs 9 & 10.
Paragraphs 13 & 14 seem confusing, if not contradictory.
Move paragraph 14 up after paragraph 8.
The last paragraph repeats the information in the 9th paragraph.
Section 2.1, last paragraph: Change "has already been allocated" to "is
described".
Appendix C, last paragraph before C.1: This is a repeat of the last paragraph
of section 2.3. I don't think it's necessary to repeat.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-carpenter-rfced-iab-charter-05
[Sorry; resending from the proper From address.] Oh, one other bit: In the directive at the top of the XML, you should add seriesNo="39" as an indicator to the RFC Editor to make sure that this document is added to BCP 39, not create a new BCP number. On 15 Feb 2022, at 14:02, Pete Resnick via Datatracker wrote: Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq> . Document: draft-carpenter-rfced-iab-charter-05 Reviewer: Pete Resnick Review Date: 2022-02-15 IETF LC End Date: 2022-03-07 IESG Telechat date: 2022-03-10 Summary: Looks fine, save one typo Major issues: None Minor issues: None Nits/editorial comments: In section 2, change "(b) RFC Series and IANA" to "(d) RFC Series and IANA" -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-carpenter-rfced-iab-charter-05
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-carpenter-rfced-iab-charter-05 Reviewer: Pete Resnick Review Date: 2022-02-15 IETF LC End Date: 2022-03-07 IESG Telechat date: 2022-03-10 Summary: Looks fine, save one typo Major issues: None Minor issues: None Nits/editorial comments: In section 2, change "(b) RFC Series and IANA" to "(d) RFC Series and IANA" ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-pim-igmp-mld-extension-05
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-pim-igmp-mld-extension-05 Reviewer: Pete Resnick Review Date: 2022-01-13 IETF LC End Date: 2022-01-19 IESG Telechat date: Not scheduled for a telechat Summary: One possible minor issue and a couple of nits, but otherwise ready. Major issues: None. Minor issues: In section 3 it says, There is no alignment or padding. Are you sure that implementations are going to work with this? In my old brain, there are still memories of trying to read 16-bit values out of an odd-aligned location caused all sorts of problems. Are you sure you don't want to at least pad this to even lengths? Nits/editorial comments: In section 3, this sentence confused me for a moment: A previously reserved bit in the IGMPv3 and MLDv2 headers is used to indicate whether this extension is used. I suggest: For each of the IGMPv3 and MLDv2 headers, a previously reserved bit is used to indicate the presence of this extension. In section 3: When this extension mechanism is used, the number of Group Records in each Report message should be kept small enough that the entire message, including any extension TLVs can fit within the network MTU. That "should" looks pretty interoperability-related to me. Perhaps "SHOULD"? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart early review of draft-ietf-opsawg-l3sm-l3nm-14
Reviewer: Pete Resnick Review result: Ready Got this review late; apologies for finishing it a few days later that it should. As usual for YANG reviews (not my forte), I simply looked for data items being compared in i18n-unsafe ways or other misuses. Nothing obvious. Seems ready to go as far as this app layer reviewer is concerned. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-core-new-block-10
Thanks for the followup. Just to close the loop on some of these: On 26 Apr 2021, at 5:31, mohamed.boucad...@orange.com wrote: In section 4.4: I find this paragraph confusing: The requested missing block numbers MUST have an increasing block number in each additional Q-Block2 Option with no duplicates. The server SHOULD respond with a 4.00 (Bad Request) to requests not adhering to this behavior. So, given the SHOULD in the second sentence, it appears that the MUST in the first sentence doesn't apply to the server (i.e., to enforce this), but rather to the client doing the request. You should probably say it that way. [Med] Yes. This text should be linked to the previous paragraph when the client issues the request for missing blocks. Anyway, I agree it is better to be explicit here. Fixed. Excellent. Here's a purely editorial suggestion; entirely up to you whether to use it: The missing block numbers requested by the client MUST have an increasing block number in each additional Q-Block2 Option with no duplicates. Also, the SHOULD in the second sentence is not entirely clear to me: Are you saying that the server can choose to use some other response code, or are you saying that the server can accept the request and do something interesting with it? [Med] The latter. Normally the server must discard such request but given that one of the target use cases for this spec is DDoS mitigation, servers may be tolerant. Ah, OK, then what you have is correct as-is. In section 4.3: In several response code definitions: The token used MUST be any token that was received in a request using the same Request-Tag. That doesn't really parse well. I think you either mean "The token used MUST be a token" or you mean "The token used can be any token". [Med] The second para of this section specifies that all block requests must use the same Request-Tag. The 4th para indicates that each of these block requests will use a new token. The server must use one of these tokens when replying. Updated the text as follows: NEW: The token used MUST be one of the tokens that were received in a request for this block-wise exchange. I like it. In section 7.2: For the server receiving NON Q-Block1 requests, it SHOULD send back a 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS payloads to prevent the client unnecessarily delaying. Otherwise... When you say "Otherwise", Do you mean, "For other payloads"? Either way, you should probably change that to make it clear. [Med] Changed to: "If not all of the MAX_PAYLOADS payloads were received, ..." Perfect. All of the others look fine. Thanks again for the quick reply. Cheers, pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-core-new-block-10
On 24 Apr 2021, at 17:38, John C Klensin wrote: --On Saturday, April 24, 2021 14:33 -0700 Pete Resnick via Datatracker wrote: Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. ... Nits/editorial comments: In section 4.3: In several response code definitions: The token used MUST be any token that was received in a request usingthe same Request-Tag. That doesn't really parse well. I think you either mean "The token used MUST be a token" or you mean "The token used can be any token". If the first meaning is intended, isn't that tautologically true? If the token used is not a token, what would it be? You need to put it in the context of the example give. It could be: The token used MUST be a token that was received in a request using the same Request-Tag. which means it can't be a token with a different Request-Tag, or it could be: The token used can be any token that was received in a request using the same Request-Tag. which means that there might be different tokens that use the same Request-Tag, but you can use any of them. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-core-new-block-10
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-core-new-block-10 Reviewer: Pete Resnick Review Date: 2021-04-24 IETF LC End Date: 2021-04-28 IESG Telechat date: Not scheduled for a telechat Summary: The document looks pretty solid to me. There is one item I marked as a minor "issue", but it may simply be an editorial item that confused me; I figured I'd call it an issue just in case so it doesn't get left to the last minute to look at. Do note that I have not reviewed the examples for correctness; I simply don't have the expertise to be convinced I'd do it right. Major issues: None. Minor issues: In section 4.4: I find this paragraph confusing: The requested missing block numbers MUST have an increasing block number in each additional Q-Block2 Option with no duplicates. The server SHOULD respond with a 4.00 (Bad Request) to requests not adhering to this behavior. So, given the SHOULD in the second sentence, it appears that the MUST in the first sentence doesn't apply to the server (i.e., to enforce this), but rather to the client doing the request. You should probably say it that way. Also, the SHOULD in the second sentence is not entirely clear to me: Are you saying that the server can choose to use some other response code, or are you saying that the server can accept the request and do something interesting with it? Below is an attempt to fix it, but might not be correct depending on what you mean: The client MUST use an increasing block number in each additional Q-Block2 Option when requesting missing block numbers, and MUST request no duplicates. The server MUST reject requests not adhering to this behavior and SHOULD respond with a 4.00 (Bad Request) to such requests. There are other places in the document that use MUST with regard to what needs to be in a piece of data (see for example sections 4.5 and 4.6), but don't make it clear who is responsible for enforcing that MUST (the client or the server). You should read through the entire document for MUSTs (or SHOULDs) like that and make sure it's clear from the context. Nits/editorial comments: In section 4.3: In several response code definitions: The token used MUST be any token that was received in a request using the same Request-Tag. That doesn't really parse well. I think you either mean "The token used MUST be a token" or you mean "The token used can be any token". Specific response codes: 4.00 (Bad Request) This Response Code MUST be returned if the request does not include neither a Request-Tag Option nor a Size1 Option but does include a Q-Block1 option. Either change "neither...nor" to "either or", or change "does not include" to "includes". 4.02 (Bad Option) Either this Response Code (in case of Confirmable request) or a reset message (in case of Non-confirmable request) MUST be returned if the server does not support the Q-Block Options. That sort of buries a MUST requirement for the Non-confirmable case inside this requirement for a Response Code. I suggest instead: This Response Code MUST be returned for a Confirmable request if the server does not support the Q-Block Options. (A reset message is sent in case of Non-confirmable request.) In section 4.4: The passive here is not great form, particularly because it doesn't name the actor: It is permissible to set the M bit to request this... How about instead: The client MAY set the M bit to request this... Maybe that's obvious, since the client does the requesting, but I think the non-passive form is easier to read. In the second to last paragraph: If the server transmits a new body of data (e.g., a triggered Observe notification) with a new ETag to the same client as an additional response, the client should remove any partially received body held for a previous ETag for that resource as it is unlikely the missing blocks can be retrieved. I'm ambivalent about whether that "should" ought to be uppercased, but I just wanted to make sure you intended the lowercase. In section 7.2: For the server receiving NON Q-Block1 requests, it SHOULD send back a 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS payloads to prevent the client unnecessarily delaying. Otherwise... When you say "Otherwise", Do you mean, "For other payloads"? Either way, you should probably change that to make it clear. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-acme-authority-token-tnauthlist-07
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-acme-authority-token-tnauthlist-07 Reviewer: Pete Resnick Review Date: 2021-03-15 IETF LC End Date: 2021-03-16 IESG Telechat date: Not scheduled for a telechat Summary: Looks fine. Some of the MUSTs look weird or superfluous to me and could probably use a scrub, and a couple are a bit confusing, but none is so bad that I would raise them as an "issue"; call them "nits/editorial comments". Major issues: None Minor issues: None Nits/editorial comments: Section 1: It's not clear to me what the purpose of the third paragraph in the intro is. It sounds like it's just describing section 9 of RFC 8226, but it is not distinguishing it from or comparing it to this document. Is it really needed? Section 3: Instead of a reference to 7.4 of RFC 8555, perhaps a reference to section 7 generally would help, or perhaps a reference later in this section to 7.1.4. Once I got down to the examples, I had to go look at 7.1.4 to familiarize myself with the operation to understand what I was looking at. Total nit, and just a personal pet peeve: It always seems silly to me to use MUST where the meaning of that word is "MUST do what the protocol we are hereby defining says to do". So instead of "MUST include", it could simply be "includes", and "MUST be" could be "is" in the two places it occurs. These three did not cause any significant confusion, whereas the ones is section 4 and 5.4 did cause some (see below). Either way, you should review all of them in the document and decide what is truly needed. Section 4: Where it says, "a CA MUST use the Authority Token challenge type of "tkauth-01" with a "tkauth-type" of "atc"", I am left to wonder what other choice the CA might make such that you have to warn it that it MUST use these. Why is "uses" not sufficient? Conversely, when you say that the "token-authority" parameter is "optional" (did you mean OPTIONAL): Is that really true? Is it that it MUST be used "in cases where the VoIP telephone network requires the CA to identify the Token Authority" (in which case it's not OPTIONAL), or is that simply an operational consideration, and protocol-wise it is truly OPTIONAL? On the other hand, the MAY and MUST at the end of the paragraph seem more appropriately to be "can" and "can only". And the MUST in the following paragraph seems like another of the ones in which you could change "MUST respond" to "responds". Section 5: The last paragraph seems superfluous. Section 5.4: The MUST NOT in the third bullet actually caused me a bit of confusion: I tried to read it as a requirement of this document. I think you mean "is not" instead of "MUST NOT be". Section 5.5: The response to the POST request if successful MUST return a 200 OK with a JSON body that contains, at a minimum, the TNAuthList... I think instead you mean: The response to the POST request if successful returns a 200 OK with a JSON body that MUST contain, at a minimum, the TNAuthList... Then you won't need the "...however..." bit at the end of the next sentence. In the last paragraph, why "SHOULD" and not "MUST"? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-6lo-blemesh-08
Reviewer: Pete Resnick
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-6lo-blemesh-08
Reviewer: Pete Resnick
Review Date: 2020-12-04
IETF LC End Date: 2020-10-21
IESG Telechat date: Not scheduled for a telechat
Summary: Looks good to me, with two items that seemed confusing enough that
they should be addressed.
Note that this review is being done well after the close of the Last Call.
Since this is not yet scheduled for a telechat, the AD asked that I go ahead
and complete the review anyway.
Major issues: None
Minor issues:
3.3.2, #4:
Implementations of this specification MAY support
the features described in sections 8.1 and 8.2 of RFC 6775, as
updated by RFC 8505, unless some alternative ("substitute") from some
other specification is supported by the implementation.
This bit confused me. I think it was the "unless". Do you mean it MAY support
the 6775/8505 features, or MAY support some substitute, or MAY support neither,
or do you mean that it MUST support either the 6775/8505 features or MUST
support some substitute? I think you want to rewrite this to make it clear
which one you mean.
3.3.3, last two paragraphs:
When a 6LN transmits a packet, with a non-link-local source address
that the 6LN has registered with EARO in the next-hop router for the
indicated prefix, the source address MUST be fully elided if it is
the latest address that the 6LN has registered for the indicated
prefix (SAC=1, SAM=11). If the source non-link-local address is not
the latest registered by the 6LN, then the 64 bits of the IID SHALL
be fully carried in-line (SAC=1, SAM=01) or if the first 48 bits of
the IID match with the latest address registered by the 6LN, then the
last 16 bits of the IID SHALL be carried in-line (SAC=1, SAM=10).
When a router transmits a packet to a neighboring 6LN, with a non-
link-local destination address, the router MUST fully elide the
destination IPv6 address if the destination address is the latest
registered by the 6LN with EARO for the indicated context (DAC=1,
DAM=11). If the destination address is a non-link-local address and
not the latest registered, then the 6LN MUST either include the IID
part fully in-line (DAM=01) or, if the first 48 bits of the IID match
to the latest registered address, then elide those 48 bits (DAM=10).
Both of these were a bit confusing to me. I think you want to reverse the order
of the last two choices. Say something like (for the first paragraph), "If the
source non-link-local address is not the latest registered by the 6LN and the
first 48 bits match..., then the last 16 bits SHALL be carried in-line.
Otherwise, if first 48 bits do not match, then the 64 bits shall be carried
inline." Similarly for the second. As it is, it takes a while to figure out
what it means.
Nits/editorial comments: Do fix the reference nits noted by the nits tool; they
appear to be simple typos.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-extra-sieve-mailboxid-05
Reviewer: Pete Resnick
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-extra-sieve-mailboxid-05
Reviewer: Pete Resnick
Review Date: 2020-11-30
IETF LC End Date: 2020-12-02
IESG Telechat date: Not scheduled for a telechat
Summary: Looking good. Just one minor issue and one nit.
Major issues:
None.
Minor issues:
Section 4 says:
If there is no such mailbox, the "fileinto" action proceeds as it
would without the ":mailboxid" argument.
But the in the example in section 6, it shows:
if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" {
fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
"INBOX.harassment";
} else {
fileinto "INBOX.harassment";
}
That appears correct, but as far as I can tell, it is semantically identical to:
fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
"INBOX.harassment";
That is, the rule in section 4 means that fileinto already does an implicit
existence check and only uses the named mailbox if the one specified by the
mailboxid doesn't exist. It's not that the example is particularly a problem,
but it did confuse me for a few minutes while I tried to figure out what it was
trying to do. Perhaps if the example was:
if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" {
fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
"this.name.will.never.be.used";
} else {
fileinto "INBOX.harassment";
}
or an example that did something other than "fileinto" it would have made a bit
more sense. Certainly not absolutely necessary to fix, but a change might
improve understanding.
Nits/editorial comments:
In sections 4.1 and 4.2, you have references that appear as "[!@RFC5490]" and
"[!@RFC5879]". I assume that's some sort of markdown or other formatting tool
mistake.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-v6ops-cpe-slaac-renum-04
I missed that. And indeed the Last Call went out for Proposed Standard. Warren should probably look into this before it goes to the IESG. pr On 9 Sep 2020, at 19:50, Bernie Volz (volz) wrote: Interesting that the datatracker says the document is "Proposed Standard", but the document has "Intend status: Informational". The two should be made to agree. - Bernie On Sep 9, 2020, at 8:45 PM, Fernando Gont wrote: Hello, Pete, Thanks a lot for your feedback! In-line.... On 9/9/20 16:39, Pete Resnick via Datatracker wrote: [] Major issues: None draft-ietf-v6ops-cpe-slaac-renum Minor issues: The shepherd writeup says: The document so far has been approved by the V6OPS working group (successful working group last call). The document does not specify new protocol, but rather changes to the default parameters in existing protocols. However, the document is Informational, as confirmed by the shepherd writeup. If this is actually updating default parameters in protocols, that sounds like it should either be a Standards Track document or more likely a BCP. As 2026 says: The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. [...] ...[G]ood user service requires that the operators and administrators of the Internet follow some common guidelines for policies and operations. While these guidelines are generally different in scope and style from protocol standards, their establishment needs a similar process for consensus building. That sounds like what this is doing, especially with all of the 2119 language in here. Maybe this is Informational because 7084 (and 6204 before it) were Informational, but perhaps 7084 (and other such document) should be BCP as well. Indeed, it sounds like all of these SLAAC operational documents could be in one BCP together. FWIW, the reason for which this document is informational is because the document it's formally updating (RFC7084) is also informational. -- Me, I'd probably agree with you that both RFC7084 and this document should be BCPs, rather than Informational. I'd like to hear from our AD regarding how to proceed here. FWIW, I'm fine with changing the track to BCP, although I'd also note that there's plenty of existing practice of documents of this type published as Informational. Either way, Informational seems wrong. Nits/editorial comments: Throughout the document, it says, "This document RECOMMENDS..." or "This document also RECOMMENDS" or "Additionally, this document RECOMMENDS". RFC 2119 does not use "RECOMMENDS". You can say "CE Routers SHOULD..." or "A Router Lifetime of ND_PREFERRED_LIMIT is RECOMMENDED" or if you must "It is RECOMMENDED that..." (blech, I hate the passive form), since SHOULD and RECOMMENDED are equivalent in 2119, but using the "This document RECOMMENDS..." form is weird and isn't in 2119. Fair enough. I'll apply the suggested edit unless I hear otherwise from others. In 3.3, it says: o Upon changes to the advertised prefixes, and after bootstrapping, the CE router advertising prefix information via SLAAC SHOULD proceed as follows: But then each of the things under there has a SHOULD or a MUST. The SHOULD here is confusing. Instead, the sentence could simply be: o Upon changes to the advertised prefixes, and after bootstrapping, the CE router advertising prefix information via SLAAC proceeds as follows: Similarly: This document RECOMMENDS that if a CE Router provides LAN-side DHCPv6 (address assignment or prefix delegation), the following behavior be implemented: Just make the sentence: If a CE Router that provides LAN-side DHCPv6 (address assignment or prefix delegation), then: FWIW, the motivation for the "SHOULD" in Section 3.3 is that it generally implies that the device records prefixes on non-volatile storage. But there are valid reasons for which a device might be unable to (e.g., economical, if you wish). Then, the "MUSTs" elsewhere essentially try to signal how crucial implementation of each specific behavior is. Thoughts? Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-v6ops-cpe-slaac-renum-04
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-v6ops-cpe-slaac-renum-04 Reviewer: Pete Resnick Review Date: 2020-09-09 IETF LC End Date: 2020-09-09 IESG Telechat date: Not scheduled for a telechat Summary: Ready with one process issue, and some assorted nits. Major issues: None Minor issues: The shepherd writeup says: The document so far has been approved by the V6OPS working group (successful working group last call). The document does not specify new protocol, but rather changes to the default parameters in existing protocols. However, the document is Informational, as confirmed by the shepherd writeup. If this is actually updating default parameters in protocols, that sounds like it should either be a Standards Track document or more likely a BCP. As 2026 says: The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. [...] ...[G]ood user service requires that the operators and administrators of the Internet follow some common guidelines for policies and operations. While these guidelines are generally different in scope and style from protocol standards, their establishment needs a similar process for consensus building. That sounds like what this is doing, especially with all of the 2119 language in here. Maybe this is Informational because 7084 (and 6204 before it) were Informational, but perhaps 7084 (and other such document) should be BCP as well. Indeed, it sounds like all of these SLAAC operational documents could be in one BCP together. Either way, Informational seems wrong. Nits/editorial comments: Throughout the document, it says, "This document RECOMMENDS..." or "This document also RECOMMENDS" or "Additionally, this document RECOMMENDS". RFC 2119 does not use "RECOMMENDS". You can say "CE Routers SHOULD..." or "A Router Lifetime of ND_PREFERRED_LIMIT is RECOMMENDED" or if you must "It is RECOMMENDED that..." (blech, I hate the passive form), since SHOULD and RECOMMENDED are equivalent in 2119, but using the "This document RECOMMENDS..." form is weird and isn't in 2119. In 3.3, it says: o Upon changes to the advertised prefixes, and after bootstrapping, the CE router advertising prefix information via SLAAC SHOULD proceed as follows: But then each of the things under there has a SHOULD or a MUST. The SHOULD here is confusing. Instead, the sentence could simply be: o Upon changes to the advertised prefixes, and after bootstrapping, the CE router advertising prefix information via SLAAC proceeds as follows: Similarly: This document RECOMMENDS that if a CE Router provides LAN-side DHCPv6 (address assignment or prefix delegation), the following behavior be implemented: Just make the sentence: If a CE Router that provides LAN-side DHCPv6 (address assignment or prefix delegation), then: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-mpls-sfl-framework-08
On 30 Jun 2020, at 7:24, Stewart Bryant wrote: On 29 Jun 2020, at 18:30, Pete Resnick via Datatracker wrote: Minor issues: It is not clear to me why this is being sent for Informational instead of Proposed Standard. The shepherd's writeup does not justify it, and in fact the writeup refers to the document as a "specification", which is exactly what it appears to be. It defines the use of SFLs, describes how they are processed by the endpoints, describes how they are aggregated, etc. While the document may not be standalone, I don't see how it's really an Informational document. I suggest restarting the Last Call for Proposed, and if for some reason it needs to be Informational, it can always be downgraded after Last Call. Pete - the “tradition”... I hear songs from "Fiddler on the Roof" in my head... ...in routing is that such documents are Informational and the detailed protocol specifications are standards (there are a couple of those in progress about to finish baking). I leave it up to our AD to pass judgement on the matter as this is a simple fix, but I don’t think the changed status is REQUIRED. Absolutely agreed that it is not required, but given that this does contain specification, and how much less scrutiny is given to Informational document as against Standards Track (see, for example, the IESG balloting rules on each), Standards Track seems more sensible. But the world remains intact either way. The Security Considerations section says, "The issue noted in Section 6 is a security consideration." I'm not sure I understand why that is. Section 6 explains the privacy considerations, and privacy and security are close friends so I cross referenced the section rather than repeating it. I suggest that we wait to see what SECDIR wants to do before changing any text. Yes, glad to defer to SECDIR on this. Nits/editorial comments: Section 1: "(see Section 3)" seems unnecessary. I can take that out on the next version, it was intended as a forward reference to a completely new contract in MPLS. Section 3: I thought the "Consider..." construction made those paragraphs unnecessarily wordy and a bit harder to follow. I will reword the first two sentences para 2 of section 3 to simplify the language. Thanks. As I said, both very minor things. Thanks for the comments My pleasure. Thanks for your quick followup. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-mpls-sfl-framework-08
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-mpls-sfl-framework-08 Reviewer: Pete Resnick Review Date: 2020-06-29 IETF LC End Date: 2020-07-06 IESG Telechat date: Not scheduled for a telechat Summary: A couple of minor issues and a couple of *extremely* nitty nits, but overall looks ready to go. Major issues: None. Minor issues: It is not clear to me why this is being sent for Informational instead of Proposed Standard. The shepherd's writeup does not justify it, and in fact the writeup refers to the document as a "specification", which is exactly what it appears to be. It defines the use of SFLs, describes how they are processed by the endpoints, describes how they are aggregated, etc. While the document may not be standalone, I don't see how it's really an Informational document. I suggest restarting the Last Call for Proposed, and if for some reason it needs to be Informational, it can always be downgraded after Last Call. The Security Considerations section says, "The issue noted in Section 6 is a security consideration." I'm not sure I understand why that is. Nits/editorial comments: Section 1: "(see Section 3)" seems unnecessary. Section 3: I thought the "Consider..." construction made those paragraphs unnecessarily wordy and a bit harder to follow. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-gellens-lost-validation-08
Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-gellens-lost-validation-08 Reviewer: Pete Resnick Review Date: 2020-05-24 IETF LC End Date: 2020-06-18 IESG Telechat date: Not scheduled for a telechat Summary: Looks good. Thanks for addressing my previous comments. Major issues: None Minor issues: None Nits/editorial comments: None ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05
Reviewer: Pete Resnick Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dhc-problem-statement-of-mredhcpv6-05 Reviewer: Pete Resnick Review Date: 2020-05-20 IETF LC End Date: 2020-05-25 IESG Telechat date: Not scheduled for a telechat Summary: This document is not ready for publication. Major issues: Nowhere in the Introduction does this document explain its motivation: Why is a survey of these mechanisms important for the IETF to publish? It claims that it is doing "a detailed analysis" in order to "clarify the problems, design principles, and extract and unify the design specifications to help better solve the multi-requirement extension problems", but the rest of the document seems to do nothing more than describe extensions, not do any real analysis of design principles. And after reading the introduction, I still don't understand what a "multi-requirement extension" is (the term is never defined), nor do I know what the problem is with them. Unless the motivation for this document can be better explained, I do not see this document as being appropriate for publication. Minor issues: None. Nits/editorial comments: The entire document could use a good editorial scrub. There are quite a few grammatical issues. 3.2, 4.2.2, and 4.2.4 give lists of example implementations and options. These seem unnecessary. When particular examples are useful, of course they can be included, but simply long lists are not useful. The general model in 4.1 seems unnecessary; this is nothing that you wouldn't already know if you understand DHCP. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-dnsop-multi-provider-dnssec-04
Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dnsop-multi-provider-dnssec-04 Reviewer: Pete Resnick Review Date: 2020-03-31 IETF LC End Date: 2020-03-31 IESG Telechat date: 2020-04-09 Summary: Ready. Good to go. A straightforward document easy enough for this non-expert to get. Thanks to the shepherd for a straightforward writeup; it made the review even easier. Major issues: None Minor issues: None Nits/editorial comments: Just two comments, neither of them should stop progress on the document in any way: 1. I could see this document being a BCP, since the advice in here seems pretty prescriptive. I think it will still be perfectly useful as an Informational document, but it does seem to have important operational advice. 2. In section 3, it occurs to me that another thing you might add to the problem list is the issue of some servers caching BAD Data. Paul Hoffman was nice enough to point me to section 4.7 of RFC 4035. Perhaps a reference to there from this document would be useful. Again, take them for what they're worth. If you decide not to do either, I feel the document could go forward as-is without a problem. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-gellens-lost-validation-05
Hi Randy, We probably at some core level disagree about whether "informational text that explains how it is expected to be used" is in-and-of-itself "normative"; I think in IETF documents, that's really all that it means. But that might be moot: If the NENA document is going to be updated to describe the how clients and servers are to use the tag, why not simply remove sections 3 & 4 from this document and put in a reference to the NENA document as "Work In Progress"? If the IETF is not defining how the tag is going to be used, then point to the document that will. In its current state, the document reads like protocol to me and therefore worthy of standards track. If you truly want simply a registration, make the reference and it will be a perfectly reasonable Informational document. pr On 8 Mar 2020, at 15:22, Randall Gellens wrote: Hi Pete, The document adds a tag. It also contains informational text that explains how it is expected to be used. There isn't any normative text. Once the tag is defined, then NENA i3 will be updated to refer to it, and to mandate how NENA-compliant clients and servers use it. But a non-NENA-i3 client or server can use the tag or not as they wish. --Randall On 8 Mar 2020, at 12:59, Pete Resnick wrote: Hi Randy, Section 3 of the document defines the operations that one must perform in order to use the tag. It explains how to go beyond what 5222 provides by defining which order to look up the servers and what to do depending on the results received. It changes the discovery procedure defined in 5222. The fact that it is backwards compatible and doesn't break 5222 implementations is good, but it doesn't make it any less a protocol. Indeed, if it is an "optimization" of an existing protocol, that makes it a protocol. I can't see any other way of describing section 3. pr On 8 Mar 2020, at 14:27, Randall Gellens wrote: Hi Pete, I don't see this as a new protocol. It is a new service tag that is optional to use. Not using it won't break anything that wouldn't be broken without the tag being defined. Using it is an optimization. I see the draft as only adding a new tag, not defining a new protocol. --Randall On 7 Mar 2020, at 8:52, Pete Resnick via Datatracker wrote: Reviewer: Pete Resnick Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-gellens-lost-validation-05 Reviewer: Pete Resnick Review Date: 2020-03-07 IETF LC End Date: 2020-03-31 IESG Telechat date: Not scheduled for a telechat Summary: Abstract, Scope, and Introduction do not accurately reflect the content of the document, which is not simply a registration. Major issues: The Abstract and sections 1 & 2 (Scope and Introduction) indicate that this document is simply an IANA registration of an S-NAPTR Application Service Tag. However, section 3 is quite clearly new protocol, some of which changes how RFC 5222 implementations should operate if used in a particular context, and section 4 lays out the backward compatibility of this new protocol with legacy RFC 5222 implementations. There is the implication that the NENA i3 documents will actually be the home of that protocol, but the current i3 document referenced here does not do so, making this document the canonical statement of the protocol operations necessary to implement the i3 architecture. That doesn't seem appropriate for an Informational document that purports to simply be a registration. At the very least, the Abstract, Scope, and Intro would need to be updated to reflect the actual contents of the document. I think things would be better served by making this a Proposed Standard document so that it gets the appropriate level of review. I understand from the Shepherd writeup that the ECRIT WG doesn't have the energy to really work on this document. However, this is a simple enough extension to the LoST protocol that I think it's unproblematic to have it as an AD-sponsored standards track document. -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-gellens-lost-validation-05
Hi Randy, Section 3 of the document defines the operations that one must perform in order to use the tag. It explains how to go beyond what 5222 provides by defining which order to look up the servers and what to do depending on the results received. It changes the discovery procedure defined in 5222. The fact that it is backwards compatible and doesn't break 5222 implementations is good, but it doesn't make it any less a protocol. Indeed, if it is an "optimization" of an existing protocol, that makes it a protocol. I can't see any other way of describing section 3. pr On 8 Mar 2020, at 14:27, Randall Gellens wrote: Hi Pete, I don't see this as a new protocol. It is a new service tag that is optional to use. Not using it won't break anything that wouldn't be broken without the tag being defined. Using it is an optimization. I see the draft as only adding a new tag, not defining a new protocol. --Randall On 7 Mar 2020, at 8:52, Pete Resnick via Datatracker wrote: Reviewer: Pete Resnick Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-gellens-lost-validation-05 Reviewer: Pete Resnick Review Date: 2020-03-07 IETF LC End Date: 2020-03-31 IESG Telechat date: Not scheduled for a telechat Summary: Abstract, Scope, and Introduction do not accurately reflect the content of the document, which is not simply a registration. Major issues: The Abstract and sections 1 & 2 (Scope and Introduction) indicate that this document is simply an IANA registration of an S-NAPTR Application Service Tag. However, section 3 is quite clearly new protocol, some of which changes how RFC 5222 implementations should operate if used in a particular context, and section 4 lays out the backward compatibility of this new protocol with legacy RFC 5222 implementations. There is the implication that the NENA i3 documents will actually be the home of that protocol, but the current i3 document referenced here does not do so, making this document the canonical statement of the protocol operations necessary to implement the i3 architecture. That doesn't seem appropriate for an Informational document that purports to simply be a registration. At the very least, the Abstract, Scope, and Intro would need to be updated to reflect the actual contents of the document. I think things would be better served by making this a Proposed Standard document so that it gets the appropriate level of review. I understand from the Shepherd writeup that the ECRIT WG doesn't have the energy to really work on this document. However, this is a simple enough extension to the LoST protocol that I think it's unproblematic to have it as an AD-sponsored standards track document. -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-gellens-lost-validation-05
Reviewer: Pete Resnick Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-gellens-lost-validation-05 Reviewer: Pete Resnick Review Date: 2020-03-07 IETF LC End Date: 2020-03-31 IESG Telechat date: Not scheduled for a telechat Summary: Abstract, Scope, and Introduction do not accurately reflect the content of the document, which is not simply a registration. Major issues: The Abstract and sections 1 & 2 (Scope and Introduction) indicate that this document is simply an IANA registration of an S-NAPTR Application Service Tag. However, section 3 is quite clearly new protocol, some of which changes how RFC 5222 implementations should operate if used in a particular context, and section 4 lays out the backward compatibility of this new protocol with legacy RFC 5222 implementations. There is the implication that the NENA i3 documents will actually be the home of that protocol, but the current i3 document referenced here does not do so, making this document the canonical statement of the protocol operations necessary to implement the i3 architecture. That doesn't seem appropriate for an Informational document that purports to simply be a registration. At the very least, the Abstract, Scope, and Intro would need to be updated to reflect the actual contents of the document. I think things would be better served by making this a Proposed Standard document so that it gets the appropriate level of review. I understand from the Shepherd writeup that the ECRIT WG doesn't have the energy to really work on this document. However, this is a simple enough extension to the LoST protocol that I think it's unproblematic to have it as an AD-sponsored standards track document. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-6man-icmp-limits-07
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-6man-icmp-limits-07 Reviewer: Pete Resnick Review Date: 2020-02-17 IETF LC End Date: 2020-02-25 IESG Telechat date: Not scheduled for a telechat Summary: Nice simple document, easy to read, and pretty much ready to go. The one "issue" I have listed below is a process nit, but one that should be taken care of. Major issues: None. Minor issues: The tracker and the shepherd writeup say that the status of the document is "Proposed Standard", but the header of the document says "Standard". That's why the nits checker is complaining about downrefs; it thinks that this is going for Full Standard. The header should either say "Standards Track" (which is normal) or "Proposed Standard". (I hereby give Bob crap for missing that one as shepherd, and I think he should owe me a beer. ;-) ) Nits/editorial comments: The Abstract and 1.1 both indicate that a source host that receives such an ICMPv6 error may be able to modify what it sends, which sounds to me like it means "on the fly". While that might be true, it seems more likely to me that it will be used for diagnostics to modify future behavior of either the sender or the receiver at a later date, as mentioned in 4.2. I think it's worth mentioning up at the top. Section 1.3: You should probably update to the RFC 8174 text. Section 5.1: "RECOMMENDS" isn't one of the keywords. It's not a problem in itself, but if people search the document for the keywords (and they do), they'll miss this one. Suggest reformulating the sentence to use RECOMMENDED. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-stir-passport-divert-07
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Note that while this is labeled a Last Call review, this review comes well after the Last Call completed. However, the author and AD felt it would be useful anyway since the document has not yet been updated for Last Call comments. Document: draft-ietf-stir-passport-divert-07 Reviewer: Pete Resnick Review Date: 2020-01-09 IETF LC End Date: 2019-12-02 IESG Telechat date: Not scheduled for a telechat Summary: Ready with Nits While I found the document (and particularly section 4) very technically dense, I think the detail will help implementers tremendously. Nothing other than a few editorial issues. Major issues: None Minor issues: None Nits/editorial comments: Section 3, paragraph 1: Note that a new PASSporT is only necessary when the canonical form of the "dest" identifier (per the canonicalization procedures in [RFC8224] Section 8) changes due to this retargeting. If the canonical form of the "dest" identifiier is not changed during retargeting, then a new PASSporT with a "div" claim MUST NOT be produced. Seems to me that these two sentences should be in their own paragraph. It took me a second to figure out that the following sentence was not related to these. Section 4: ...Other using protocols of PASSporT Don't you mean "Other protocols using PASSporT"? Section 4.2, paragraph 2: I think you mean "necessarily", not "necessary" ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-mboned-ieee802-mcast-problems-11
Reviewer: Pete Resnick Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-mboned-ieee802-mcast-problems-11 Reviewer: Pete Resnick Review Date: 2020-01-08 IETF LC End Date: None IESG Telechat date: 2020-01-09 Summary: On the Right Track As far as I can tell, none of the issues I raised in the Last Call GenART review were ever addressed. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-pim-drlb-13
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-pim-drlb-13 Reviewer: Pete Resnick Review Date: 2019-11-05 IETF LC End Date: 2019-11-07 IESG Telechat date: Not scheduled for a telechat Summary: Ready with some minor issues and nits, plus one "interesting note". Major issues: None. Minor issues: In 5.1, the SHOULDs regarding the default hash masks seem a bit odd: Usually SHOULD means that bad things are likely to happen if you choose otherwise, but if you know what you are doing, you might choose something different. Is there any real harm to choosing some other hash masks, or are you simply saying that these are perfectly reasonable? Not a big deal one way or the other, but if there is harm, you should probably say something about that. In 5.1: "The hash value computed will be the ordinal number of the GDR Candidate that is acting as GDR." I'm not sure what that sentence means, but then again, this entire document is way outside my area of expertise, so perhaps this is obvious. Nits/editorial comments: The IDNITS tool reports: == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Are those the addresses in 5.2.1? Are they kosher? In 5.3.2, why is it "RECOMMENDED that the addresses are sorted in descending order."? Is that what's mentioned in 5.4? If so, perhaps a forward reference would be helpful. Finally, my "interesting note": I see in the shepherd report: (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Yes, there is IPR and it has been declared with #1713. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, IPR has been declared and the WG has been notified. That seems to indicate that nobody had any comment about the IPR declaration. But I also see noted in the shepherd report, "Cisco has an implementation of this protocol. No other vendors have indicated plan to implement the specification". That leads to a pretty obvious question: Are other vendors not implementing this because of the IPR (which you'd think would be a concern), or are other vendors planning on implementing this in the future, or is this just a Cisco-private extension that requires no interoperability? It seems curious that there was no discussion at all. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-mboned-ieee802-mcast-problems-09
Reviewer: Pete Resnick Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-mboned-ieee802-mcast-problems-09 Reviewer: Pete Resnick Review Date: 2019-10-14 IETF LC End Date: 2019-10-14 IESG Telechat date: Not scheduled for a telechat Summary: This document has good information and analysis of multicast problems and is certainly valuable. However, there are some things in the document which could use clarification or editing. Major issues: The first paragraph of section 8 really has too little useful comment. There is no reference for 802.1ak, the reference to 802.1Q is inline instead of in the references section, and the content of neither of these standards is explained in this document. The paragraph doesn't really lay out what the topic of discussion is, at least for someone like myself who is not versed in the topic. I really think this needs to be addressed. Minor issues: (Some of these issues are more or less "minor".) Section 3.1.4 seems a little thin to this non-expert. It is certainly true that "every station has to be configured to wake up to receive the multicast", but it seems like only a poorly designed protocol would create the situation where "the received packet may ultimately be discarded" on any kind of regular basis. If there are a class of packets that the receiver will ultimately discard, that sounds like they should be on a separate multicast address, or the sender should be determining if the packet will be discarded before sending it. Perhaps what this section is driving at is that multicast protocols are often designed without taking power-saving considerations into account, but then *that's* what this section should probably talk about. As it is, it sounds like the old joke about saying to the doctor, "My arm hurts when I do this" and the doctor replying, "The stop doing that". In section 3.2.1, the last paragraph is missing a bunch of information: "It's often the first service that operators drop": What is "it"? "Multicast snooping" is not defined. In what scenario are devices "registering"? Section 3.2.2: "This intensifies the impact of multicast messages that are associated to the mobility of a node." I don't understand why. Are you simply saying that as the number of addresses goes up, more discovery packets must be sent? Section 3.2.4: This seems like more of general problem than a multicast-specific one, and as described it sounds like an attack rather than a poor outcome of a protocol design decision like the rest of the examples. Perhaps framing it that way would make the section clearer. Section 4.4: Which problem in section 3 is 4.4 supposed to address? Section 5.1: "...and sometimes the daemons just seem to stop, requiring a restart of the daemon and causing disruption." What a strange thing to say. Does this simply mean "and the current implementations are buggy"? Also section 5.1: "The distribution of users on wireless networks / subnets changes from one IETF meeting to the next". This document doesn't seem to be about the IETF meeting network. This sentence seems inappropriately specific. The "NAT" and "Stateful firewalls" sections are also overly specific to the IETF meeting network. Generalizing would help. 7: This section seems quite thin, and perhaps unnecessary. The recommendations are implicit in the previous sections. Nits/editorial comments: Section 3.2.4: The mention of the face-to-face (probably better: "plenary") meeting seems unnecessary. Section 5.1: Numbering the subsections would probably be useful. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-cbor-sequence-01
Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-cbor-sequence-01 Reviewer: Pete Resnick Review Date: 2019-09-17 IETF LC End Date: None IESG Telechat date: 2019-09-19 Summary: Nice simple tight document. No concerns. (Having read the IESG comments, I think Barry's clarification is nice.) Major issues: None. Minor issues: None. Nits/editorial comments: None. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-pce-stateful-path-protection-08
Hi Dhruv, On 29 Aug 2019, at 5:17, Dhruv Dhody wrote: Hi Pete, Thanks for your review and nits. Just snipping to two points... OLD | PT | Path Protection Association Flags |S|P| NEW | PT |Unassigned |S|P| I feel it is important to keep the name "flags" in the figure to match with the text following the figure. Also this seems to be our usual practice in past documents as well. We can change to just "flags" if you would prefer that? For context -> The format of the Path Protection Association TLV (Figure 1) is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PT | Path Protection Association Flags |S|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Path Protection Association TLV format Path Protection Association Flags (32 bits) - The following flags are currently defined - So this is what confused me about the diagram: "Path Protection Association Flags" is the entire 32-bit field, which includes PT, S, and P. But in the diagram, you have the unassigned 24 bits labeled "Path Protection Association Flags", which seems incorrect. Perhaps "Unassigned Flags" would be best. Section 6: At the top of the section, I suggest putting in the following: [Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain "TBD1" through "TBD5" those should be replaced by the values that IANA assigns. Also, Section 4.5 includes several occurrences of the phrase "(Early allocation by IANA)"; please confirm that the value mentioned there is correct and delete that phrase from the document before publication.] I would suggest the authors to remove the phrase "(Early allocation by IANA)" in the document now as the referenced draft is in RFC-EDITOR queue and the early allocation tag is removed in the IANA page - https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects That's fine too. pr -- Pete Resnick http://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-pce-stateful-path-protection-08
Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-pce-stateful-path-protection-08 Reviewer: Pete Resnick Review Date: 2019-08-28 IETF LC End Date: 2019-08-28 IESG Telechat date: Not scheduled for a telechat Summary: Ready No issues of substance that I can see. A few editorial suggestions below, but nothing earth-shattering. Major issues: None. Minor issues: None. Nits/editorial comments: Purely editorial suggestions: Section 3.1: Delete: This document defines a new Association type, the "Path Protection Association Type", value will be assigned by IANA (TBD1). You already say this in the first paragraph. Section 3.2: OLD The type (16 bits) of the TLV is to be assigned by IANA. The length field (16 bit) has a fixed value of 4. NEW The type (16 bits) of the TLV is TBD2. The length field (16 bit) has a fixed value of 4. It would probably be caught by the RFC Editor the way you had it, but this way IANA and the RFC Editor can search and replace for anything with "TBD". OLD | Type = TBD2 | Length | NEW | Type = TBD2 | Length = 4 | OLD | PT | Path Protection Association Flags |S|P| NEW | PT |Unassigned |S|P| Section 6: At the top of the section, I suggest putting in the following: [Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain "TBD1" through "TBD5" those should be replaced by the values that IANA assigns. Also, Section 4.5 includes several occurrences of the phrase "(Early allocation by IANA)"; please confirm that the value mentioned there is correct and delete that phrase from the document before publication.] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-lpwan-ipv6-static-context-hc-21
Thanks for the changes. Followup comments inline below; trimming the ones that already look fine. On 22 Aug 2019, at 8:51, dominique.bart...@orange.com wrote: Le 07/08/19 05:13, « Pete Resnick via Datatracker » a écrit : Section 7.1 or 7.3: [DB] your proposed rephrasing is not quite accurate. We are looking for a Rule that has a function for all of the header fields and *no more* than the header fields in the packet being compressed. This is reflected in the detailed algorithm. Regarding an overview statement, how about changing OLD TEXT the set of Rules is browsed to identify which Rule will be used to compress the packet header. The Rule is selected by matching the Fields Descriptions to the packet header. The detailed steps are the following: NEW TEXT the general idea is to find in the Rule set a Rule that has a matching Field Descriptor (given the DI and FP) for exactly each and every header field of the packet being compressed. The detailed algorithm is the following: I would use "all and only those header fields that appear in the packet" instead of "each and every header field of the packet". The phrase "each and every" is so idiomatic in English that I think the native English speakers might misread it. But otherwise I think this is fine. Section 7.5.2: This encoding seems to use more space than needed. I assume you kept the size in multiples of 4 to make it on nibble boundaries, but I don't understand why you'd want 28 bits instead of 24. The larger sizes could simply be 0xFF followed by the 16-bit value. [DB] I don't quite understand his proposal. Is it a two-sized approach (4 bits and 24 bits), or a three-sized approach (4, 12 and 24 bits). In the former case, we pay a high cost for value sizes 15 and upward. In the latter case, the intermediate size (12 bits) is only applicable to value size 15 (or 15-31?). I like the three-sized approach and suggest we don't change our current spec. We expect the 4 and 12 bits encodings to be used most of the time, and added the 24 bits encoding as a safety net. Three sizes is fine, but I thought that you should have: - 0 to 14 : 4 bits - 15 to 254 : 12 bits, 0b followed by the value in 8 bits - 255 to 65535 : 24 bits, 0xff followed by the value in 16 bits Why do you need the 4 extra bits? 8.2.4: "The W field is optional" - Is OPTIONAL not appropriate here? If so, this appears in many places in section 8. DB: True. I haven't paid enough attention to the use of capital OPTIONAL, overall. I will give it another pass. The places where it's appropriate are places where an implementer needs to take notice that they have to implement the cases with and without the feature. As I said above, all of your other changes look great. Thanks for taking my comments into account. pr -- Pete Resnick http://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-lpwan-ipv6-static-context-hc-21
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lpwan-ipv6-static-context-hc-21 Reviewer: Pete Resnick Review Date: 2019-08-06 IETF LC End Date: 2019-07-19 IESG Telechat date: Not scheduled for a telechat Summary: Some minor issues, but otherwise looks good to me. My apologies for this very late review. I hope these comments are useful, but none of these are showstoppers in my opinion. Major issues: None. Minor issues: Section 5: If the SCHC Packet is to be fragmented, the optional SCHC Fragmentation MAY be applied to the SCHC Packet. Don't you mean: If the SCHC Packet is to be fragmented, the OPTIONAL SCHC Fragmentation is applied to the SCHC Packet. or even just: SCHC Fragmentation is applied if the SCHC Packet is to be fragmented. I think it's confusing to say that using SCHC is optional if the SCHC Packet is to be fragmented. If you're fragmenting, it's not optional, is it? Section 7.1 or 7.3: It took me a while to get that what you're looking for is a Rule in the list of Rules that has a function for *all* of the header fields given the DI and FP. It would be good to say some sort of overview thing like this explicitly, either in 7.1 or at the top of 7.3. It's possible this is obvious to someone versed in this topic, but it wasn't for me. Section 7.3: Question: Is it possible for multiple Rules to match a given packet? What happens if you find more than one? That should probably be specified. Section 7.5.2: This encoding seems to use more space than needed. I assume you kept the size in multiples of 4 to make it on nibble boundaries, but I don't understand why you'd want 28 bits instead of 24. The larger sizes could simply be 0xFF followed by the 16-bit value. Nits/editorial comments: Section 7.3: In the last bullet of the Rule selection algorithm, it says: Sending an uncompressed header may require SCHC F/R. Sending a compressed header may also require F/R, couldn't it? Seems to me this sentence is superfluous. Section 8.1, second paragraph: It seems like you'd want one or both occurrences of "optional" to be "OPTIONAL", in the 2119 sense. Is there a reason they're not? I'm not sure I understand the last sentence of that paragraph. Do you simply mean, "You can ignore the rest of section 8"? That seems unnecessary to say. Section 8.2.2.2: Change: o their numbers MUST increase from 0 upward, from the start of the SCHC Packet to its end. to: o their numbers MUST increase by 1 from 0 upward, from the start of the SCHC Packet to its end. in order to avoid someone being inordinately cute (or stupid). 8.2.4: "The W field is optional" - Is OPTIONAL not appropriate here? If so, this appears in many places in section 8. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-intarea-frag-fragile-13
On 5 Jul 2019, at 10:00, Fred Baker wrote: In Section 2.1 and 2.2, Instead of "set to one" and "set to zero", it would read easier with "set to (1)" and "set to (0)", or some similar construction. That seems to me to be stylistic - I'm not at all sure what makes "(1)" more readable than "one". I'm making the change, but I can't begin to fathom how it improves the document. Yes, it is completely stylistic and I'm sorry I was not more explicit about that earlier: It was mostly that it was inconsistent (sometimes using the digit in parens, sometimes using the word), but in at least one instance I read "set to one" too quickly and parsed it as "set to one of" something or other. Just using the digit as you had in your second message is perfectly fine. Section 3 is in an odd place. I'd say either move it up to the top, or put it down in section 7. Moved to section 1. Yeah, that's fine. Again, just a stylistic thing. 4.2 mentions virtual reassembly. Virtual reassembly applies to 4.1, 4.3, and 4.4 as well. Perhaps moving the discussion of virtual reassembly up to the top of 4 would make more sense. I think you're inferring the applications to 4.1, 4.3, and 4.4. 4.1, for example, makes rather a point that in the absence of virtual reassembly the router will make different routing decision. (I could say "incorrect", but the issue is that it is in fact making a correct decision in what could be argued to be the wrong context). I'll see what I can do with this, but I'm going to have to ask you to look at the diff and see whether you agree with the change. Yeah, that's exactly what I was thinking of. I like the new 3.1, though I would change "It can be useful in" to "It could be useful to address the problems in". That is, it doesn't really address those problems, because you couldn't really use it in those contexts. In 4.5, insert "duplicate IDs resulting in" after prevent. It took me a bit to figure out what this was referring to. Also, change "are not easily reproducible" to "do not occur as frequently"; I think it reads better. Ack And just to yell into the wind: Section 7.3 seemed a little wimpy to me, but I can't for the life of me figure out how to make it any stronger or more likely to be listened to. End of pointless yelling. Ron started out with "let's just deprecate Internet Layer Fragmentation entirely." Good luck, great way to create an RFC that will be completely ignored. Ain't Gonna Happen In Practice. We backed off to this in a quest for comments that could actually have an impact. Agree that they don't have teeth. Yep, what I figured. Would you kindly review the attached diff and comment on the changes? I'll wait for your comments before uploading. Yep, looks pretty good to me. Thanks. pr -- Pete Resnick http://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-intarea-frag-fragile-13
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-intarea-frag-fragile-13 Reviewer: Pete Resnick Review Date: 2019-07-04 IETF LC End Date: 2019-07-04 IESG Telechat date: Not scheduled for a telechat Summary: A document so well-written that even this application-layer idiot could follow along easily. Thanks for that. I see no significant issues with this document going forward as a BCP; just a few editorial bits. Major issues: None Minor issues: None Nits/editorial comments: In Section 2.1 and 2.2, Instead of "set to one" and "set to zero", it would read easier with "set to (1)" and "set to (0)", or some similar construction. Section 3 is in an odd place. I'd say either move it up to the top, or put it down in section 7. 4.2 mentions virtual reassembly. Virtual reassembly applies to 4.1, 4.3, and 4.4 as well. Perhaps moving the discussion of virtual reassembly up to the top of 4 would make more sense. In 4.5, insert "duplicate IDs resulting in" after prevent. It took me a bit to figure out what this was referring to. Also, change "are not easily reproducible" to "do not occur as frequently"; I think it reads better. And just to yell into the wind: Section 7.3 seemed a little wimpy to me, but I can't for the life of me figure out how to make it any stronger or more likely to be listened to. End of pointless yelling. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08
Hi Jen, Thanks for the additional updates. A few comments inline. On 3 Jul 2019, at 20:07, Jen Linkova wrote: Again, hosts pick default addresses for applications to use, and applications pick the addresses that packets will use. OK, I guess we are just using different terminology here... For me 'a host' is a whole element connected to the network, including all subsystems and applications running. Until your email I was thinking about an application as an element of a host. If I got you right, when the draft says 'host' you read it as 'network stack on a host', right? Well, yes, to a certain extent. But my point here was a bit different: Even if we call it "the network stack on a host", it isn't picking the addresses that packets will use, at least not on a packet-by-packet basis. That gets back to the point about dynamic updates: Even if the host stack were to change its mind about which the correct address is, that host isn't using that new address for packets unless/until currently running apps shut down their existing connections and make new ones. They're using the old address until doing so actually fails, and then only if they reinitiate communications. The "stack" can't change that, it can only suggest to the upper layers that they stop using what they're currently using. (You've talked about this in the new paragraph in 6.) How about this? : "It should be noted that [RFC6724] only defines the behavior of IPv6 hosts to select default addresses that applications and upper-layer protocols can use. Applications and upper-layer protocols can make their own choices on selecting source addresses. The mechanism proposed in this document attempts to..." I've updated that paragraph: "It should be noted that [RFC6724] only defines the behavior of IPv6 hosts to select default addresses that applications and upper-layer protocols can use. Applications and upper-layer protocols can make their own choices on selecting source addresses. The mechanism proposed in this document attempts to ensure that the subset of source addresses available for applications and upper-layer protocols is selected with the up-to-date network state in mind. The rest of the document discusses various aspects of the default source address selection defined in [RFC6724], calling it for the sake of brevity "the source address selection". I hope that the last sentence makes the rest of the document less confusing. What do you think? Yes, that'll be OK. I'd also suggest taking a look through the rest of section 6 for use of the word "host" and see if the word "default" needs to be inserted somewhere after it (like "...hosts to choose the correct *default* source address"), or if it needs to be changed to "application". I've updated a number of places as well. There are still quite a few places that I would change in section 6, but I'll leave it to Alissa to decide which (if any) are really worth diving into. I think now you understand what I'm trying to get at. Nice. If it were me, I'd add a forward pointer to mptcp in 8.3 as another mechanism (in addition to BGP) to deal with the problem. It is there: https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3 Sorry, I wasn't clear: I meant it would be nice if there reference in 6.7.1 to section 8.3, or a mention in 6.7.1 of MPTCP in addition to its mention of BGP. My suspicion is that section 7.3 underestimates the availability (current and future) of multipath transport. You can have the half empty glass; I'll take the half full one. ;-) As per Magnus's suggestion, I've updated the text to mention that PA-based multihoming and MP transport could benefit from each other: https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3 Fair enough. Thanks again for the updates. As the boilerplate for the review says, wait for instructions from your AD for further guidance, particularly in order to address Alissa's DISCUSS. pr -- Pete Resnick http://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08
addition to BGP) to deal with the problem. My suspicion is that section 7.3 underestimates the availability (current and future) of multipath transport. Apple is using it now in production, and Linux already has it in their implementation. I think this is actually a reasonable possible solution in the future, and I would be a little more optimistic than the WG in this section. I've added "(even if new releases of operating systems get multipath protocols support there will be a long tail of legacy hosts)." to clarify my lack of optimism.. You can have the half empty glass; I'll take the half full one. ;-) Nits/editorial comments: Two editorial bits in section 1: This document defines routing requirements for enterprise multihoming using provider-assigned IPv6 addresses. We have made no attempt to write these requirements in a manner that is agnostic to potential solutions. Instead, this document focuses on the following general class of solutions. Is that second sentence right? If you are giving a general class of solutions, that seems agnostic to the particular solution. Just a bit confusing. Updated. A host SHOULD be able respond dynamically... Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems overdone. Fixed, thanks! -- SY, Jen Linkova aka Furry Thanks for your work to address these. pr -- Pete Resnick http://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08
Reviewer: Pete Resnick Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-rtgwg-enterprise-pa-multihoming-08 Reviewer: Pete Resnick Review Date: 2019-06-04 IETF LC End Date: 2019-06-04 IESG Telechat date: Not scheduled for a telechat Summary: Almost Ready. I found this overall to be an excellent document with clear technical explanations that even an upper-layer knucklehead like me could understand. However, there a couple of issues could use more discussion. I put them as "Minor issues", in that they're not showstoppers, but I do think they're important and hope you'll be able to address them. Major issues: None. Minor issues: Throughout, but particularly in section 5, this document refers to "hosts" doing address selection. To be fair, so does RFC 6724, but 6724 is referring to *default* address selection. In reality, *applications* do address selection on a host; the host stack will only do address selection if the application requests a default address. That works well for the scenarios in 6724, but in this document, for example section 5.2.3, I'm not so sure. The idea that a host would receive an ICMP destination unreachable and re-arrange its address selection seems at least an incomplete picture: An application with a (normal, non-multi-path) TCP connection to a remote application is not able to "try another source address to reach the destination"; the source address is already set for that TCP connection, so the only choice is to close the connection entirely. If the application chooses to re-establish the connection with a default address, yes, the host stack could then give a new default address back to the application, but this is hardly the dynamic and quickly adjusting process that the document seems to be envisioning. I don't think the above invalidates the core of the document or requires some grand rewrite. But I do think some clarification is in order, saying that the mechanisms described help with the *default* address selection, and some short discussion of the limitations for what applications can (and more importantly cannot) do with these mechanisms would be useful. My suspicion is that section 7.3 underestimates the availability (current and future) of multipath transport. Apple is using it now in production, and Linux already has it in their implementation. I think this is actually a reasonable possible solution in the future, and I would be a little more optimistic than the WG in this section. Nits/editorial comments: Two editorial bits in section 1: This document defines routing requirements for enterprise multihoming using provider-assigned IPv6 addresses. We have made no attempt to write these requirements in a manner that is agnostic to potential solutions. Instead, this document focuses on the following general class of solutions. Is that second sentence right? If you are giving a general class of solutions, that seems agnostic to the particular solution. Just a bit confusing. A host SHOULD be able respond dynamically... Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems overdone. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-sidrops-https-tal-07
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-sidrops-https-tal-07 Reviewer: Pete Resnick Review Date: 2019-03-22 IETF LC End Date: 2019-03-18 IESG Telechat date: 2019-04-11 Summary: I MUST say that this document is quite MUSTy. I only noted those that caused me confusion or seemed useless. All of these are either minor issues or nits. Either way, the document is generally ready. Major issues: None. Minor issues (or might be nits): In 2.3: The validity interval of this trust anchor SHOULD reflect the anticipated period of stability... Are there cases where it wouldn't reflect the period of stability? If so, it would be good to give an example. If not, then s/SHOULD reflect/reflects. Similarly for: Thus, the entity that issues the trust anchor SHOULD issue a subordinate CA certificate that contains... In this case, that SHOULD might even be a MUST. In section 4, in the last full paragraph and the bullets, I'm not at all clear why these are RECOMMENDEDs and SHOULD [NOT]s. If they're not MUSTs, it seems like you should explain circumstances (at least in general terms) where an implementation would choose to do deviate from these. Nits/editorial comments: In the introduction, the "SHOULD" seems superfluous; it doesn't indicate some important implementation advice that someone wouldn't otherwise notice in the protocol. But it's a nit if ever there was one. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-sipbrandy-rtpsec-07
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-sipbrandy-rtpsec-07 Reviewer: Pete Resnick Review Date: 2019-03-04 IETF LC End Date: 2019-02-21 IESG Telechat date: 2019-03-07 Summary: No concerns about the content of the document; looks like reasonable security recommendations. I'm not clear on why it's BCP (which usually implies "one and done") instead of proposed standard; this thing looks like it could evolve with implementation experience in the future. By no means a showstopper, but worth considering. (Note that it doesn't require a new Last Call if you decide to change the status.) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-lisp-rfc6833bis-24
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lisp-rfc6833bis-24 Reviewer: Pete Resnick Review Date: 2019-02-05 IETF LC End Date: 2018-08-31 IESG Telechat date: 2019-02-07 Summary: The changes made to this version look fine to me. No concerns save the editorial comment below. Major issues: None. Minor issues: None. Nits/editorial comments: Section 2: Get rid of everything except the last paragraph. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-bess-evpn-vpls-seamless-integ-05
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-bess-evpn-vpls-seamless-integ-0 Reviewer: Pete Resnick Review Date: 2018-12-19 IETF LC End Date: 2018-12-18 IESG Telechat date: Not scheduled for a telechat Summary: Ready with some nits, but one process issue/query. Major issues: None Minor issues: This document is intended for Proposed Standard. It doesn't have protocol as much as operational configuration information for integration. RFC 2026 section 5 says: The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. [...] Historically Internet standards have generally been concerned with the technical specifications for hardware and software required for computer communication across interconnected networks. However, since the Internet itself is composed of networks operated by a great variety of organizations, with diverse goals and rules, good user service requires that the operators and administrators of the Internet follow some common guidelines for policies and operations. That sounds like what this document is doing. It also sounds like this document is unlike to advance to Internet Standard, as there's not the kind of iterative implementation that protocols go through. It's not a big deal either way, but this does seem better suited to a BCP. Nits/editorial comments: Abstract: s/draft/document/g Introduction: "Many Service Providers (SPs) who...". You don't use "SP" anywhere else in the document, and other places where you use the phrase it isn't capitalized. Suggest just saying "Many service providers who..." §1, Definitions: (PBB-)VPLS: refers to both, PBB-VPLS and VPLS. As for EVPN, this abbreviation is used when the text applies to both technologies. It says EVPN in the second sentence. I don't understand. Did you mean VPLS? §2: The 4 "MUST"s and 1 "MAY" aren't requirements on the implementation; they're the requirements this document will satisfy. Seems like they shouldn't be capitalized. §3.2, second bullet, 3.4.1, last paragraph, §4.2, second bullet, and §4.4.1, last paragraph: Why are the "must"s not capitalized? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart telechat review of draft-ietf-ospf-ospfv3-segment-routing-extensions-19
Hi Acee, On 3 Dec 2018, at 15:46, Acee Lindem (acee) wrote: Hi Pete, While both you and I would have done it differently, the variable length SID encoding across the three LSR protocols (OSPFv2, OSPFv3, and IS-IS) has been implemented, deployed, and will not be changed during the IESG review (you'll note these SR protocol drafts have been in development for over 5 years). There is, however, an update to all three which clarifies the usage of the flags. See (for example): https://tools.ietf.org/rfcdiff?difftype=--hwdiff=draft-ietf-ospf-ospfv3-segment-routing-extensions-20.txt Thanks, Acee (Document Shepherd and LSR Co-chair) Totally understood, and that's why I said that I certainly don't want to stand in the way of the doc. And I appreciate the clarification in -20; it helps. My job as a GenART reviewer is to make sure that the Gen AD is aware of any issues. I think it's highly unlikely that she (or anyone on the IESG) would balk at this point in history. Thanks for your (and Peter's) quick replies to these reviews. pr -- Pete Resnick http://www.episteme.net/ All connections to the world are tenuous at best ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-ospf-ospfv3-segment-routing-extensions-19
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ospf-ospfv3-segment-routing-extensions-19 Reviewer: Pete Resnick Review Date: 2018-12-03 IETF LC End Date: 2018-11-16 IESG Telechat date: 2018-12-06 Summary: I think this document is ready, and I certainly don't want to stand in the way of it moving forward, but I do want to note the following issues I mentioned in my previous review. The document editor notes that similar sorts of things have been done in previous OSPF document without problems, but they still make me nervous. Thanks to the editor for quickly addressing all of the issues in my previous review. Major/minor issues: In 3.1: Length: Either 3 or 4 octets SID/Label: If length is set to 3, then the 20 rightmost bits represent a label. If length is set to 4, then the value represents a 32-bit SID. This sort of mechanism worries me. The Length is not a length, but rather a flag. This means you can't have a general parsing implementation, as it would treat the field as a length and get the left-most 24 bits when the value is 3. Even if the implementation chooses the right-most 24 bits, it's only supposed to take the right-most 20 bits and mask off the extra 4 bits, which are not required to be zeroed. I understand that similar things have been done before without problems, but this seems like an implementation accident waiting to happen. In 7.1 and 7.2: When the V-flag is set (making SID/Index/Label is a label), the value is in the low 20 bits of the first 3 bytes of the field (i.e., bits 4-23). As with the comment regarding 3.1, this seems like it has the potential for implementation problems. You could explicitly say to mask of bits 0-3 and 24-31 (since there is no requirement for producing implementations to clear those bits) and shift the value 8 bits to the right, but this just seems like a bad way to design this. That said, I again understand that similar things have been done before without problems. Nits/editorial comments: None. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-18
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ospf-ospfv3-segment-routing-extensions-18 Reviewer: Pete Resnick Review Date: 2018-11-16 IETF LC End Date: 2018-11-16 IESG Telechat date: Not scheduled for a telechat Summary: One serious concern, one minor issue, and some nits. Major issues: In 3.1: I get worried when I see this: SID/Label: If length is set to 3, then the 20 rightmost bits represent a label. So, the Length is not a length, but rather a flag. This seems like it has the potential for an interop problem. If a general implementation treats it as a length, it's going to get the left-most 24 bits when the value is 3. Even if the implementation chooses the right-most 24 bits, it's only supposed to take the right-most 20 bits and mask off the extra 4 bits. Or are you going to specify that implementations must always set the extra 4 bits to 0? Maybe this sort of thing is the way things have always been done for TLVs, and if so feel free to ignore me, but from an code implementation perspective, this seems like an accident waiting to happen. (Known sometimes as a "foot-gun".) Minor issues: In 4.4: The SRMS Preference TLV MAY only be advertised once in the OSPFv3 Router Information Opaque LSA and has the following format: You mean MUST, not MAY there. In 7.1 and 7.2: If SID/Index/Label is a label, is it using the low 20 bits of the first 3 bytes of the field (i.e., bits 4-23)? Is there a requirement that the high 4 bits and the low 8 bits must be cleared by the implementation? Some clarification would be useful. In 8.1: You talk about setting the IA-flag, but this version of the document doesn't define the IA-flag anymore. Is it defined elsewhere? Nits/editorial comments: In 3.1: Ignoring the issue stated above, I also found this text a bit confusing: Length: Variable, 3 or 4 octets Obviously you mean that the value of Length is either 3 or 4. At first I read it as the value of Length was variable, and that it took up 3 or 4 octets in the Sub-TLV. If this is the way you've always written these things, fine, but it seems to me it would be clearer to say. Length: Either 3 or 4 In 5: s/we need a single advertisement/a single advertisement is needed Just being pedantic. If you like it, use it. If not, don't. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-detnet-use-cases-19
Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-detnet-use-cases-19 Reviewer: Pete Resnick Review Date: 2018-10-18 IETF LC End Date: 2018-10-03 IESG Telechat date: 2018-10-25 Summary: Ready Thanks for the updates to address my previous comments. Good to go. Major issues: None. Minor issues: None. Nits/editorial comments: None. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-bfcpbis-rfc4583bis-26
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-bfcpbis-rfc4583bis-26 Reviewer: Pete Resnick Review Date: 2018-10-18 IETF LC End Date: 2018-10-17 IESG Telechat date: 2018-10-25 Summary: Ready, but one issue with the IANA Considerations section. I reviewed the diff with 4583. The changes were easily understandable and the improvements were obvious. Well done. No major issues at all. I think section 13 isn't as clear as it ought to be, but not a showstopper. A couple of nits noted. Major issues: None. Minor issues: 13: I found this section confusing. You could just explain this interactively with IANA, as I suspect they will find it confusing too, but I'd suggest: - Where you need to have IANA do something new, identify that to IANA as "IANA is requested to register...", replacing "This document defines" in 13.6. - For the remainder, identify those with "IANA has registered...", replacing "This document defined" in 13.2 through 13.5. You can put a parenthetical note next to each one that says, "No new IANA action requested here" This all gets cleaned up by the RFC Editor anyway, but the whole idea of the IANA Considerations is to make it clear what IANA needs to do, not format the section for what it should look like when published. Finally, I don't see a need for the "contact i...@ietf.org" bit. This is going to be a standards track document, and that is always the case for standards track documents. Nits/editorial comments: 5.1: - Table 1 contains "c-s", but it has not yet been explained. I would move it below the subsequent paragraph. - In the paragraph that begins, "Endpoints compliant with [RFC4583]", the comma in the second sentence belongs after "present", not "client". 5.2: - In the section title, s/Attributes/Attribute ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-detnet-use-cases-18
input, and please let me know if the above resolutions make sense to you. Best, Ethan (as editor of the DetNet Use Cases draft). Thanks for the complete response. pr -Original Message- From: Pete Resnick Sent: Thursday, October 04, 2018 11:02 AM To: gen-art@ietf.org Cc: det...@ietf.org; i...@ietf.org; draft-ietf-detnet-use-cases@ietf.org Subject: Genart last call review of draft-ietf-detnet-use-cases-18 Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-detnet-use-cases-18 Reviewer: Pete Resnick Review Date: 2018-10-04 IETF LC End Date: 2018-10-03 IESG Telechat date: Not scheduled for a telechat Summary: Ready with Nits This was a really cool document to read simply because of the breadth of the industries involved. It clearly is going to need a good grammatical editing pass by the RFC Editor, but none of the errors are the kind that make the text hard to understand. All of my comments below are editorial in nature. Major issues: None Minor issues: None Nits/editorial comments: For all of the below, the world does not end if you don't fix them, but please consider: Abstract: The first paragraph of intro seems like a better abstract. I don't think the abstract needs as much detail as you've got in there. The Intro says: For DetNet, use cases explicitly do not define requirements; The DetNet WG will consider the use cases, decide which elements are in scope for DetNet, and the results will be incorporated into future drafts. Then why was 2.1.4 removed? It seems like it might be useful for historical context. In general, I don't like using "we" in consensus documents because it makes it ambiguous whether the "we" is the "the author(s), "the detnet WG"", "the IETF", or "this document". Additionally, using phrases like "we believe" or "we think" are superfluous in most cases. Search for " we" and think about how to get rid of such uses. A few examples: 2.2 I think you can simply just delete "we believe that". This document is making a statement; no reason to hedge. 4.3 "In the future we expect". Changing to the passive voice solves the problem: "It is expected that in the future" 5.3.2.1 "We would like to see DetNet define such a protocol". Detnet is the author of this document, so "we" here seems really weird. There are many other examples. Doing a search for " we " and seeing if you can clean them up would be useful. Throughout 3.1.1, 6.1.2, 7.3, 7.4: I presume "###us" is meant to be "###µs". I believe I-Ds are now allowed to have such characters. In 3.3.2.3, there is no discussion about how this relates to NTP. I'm not sure if that is necessary, but it seems odd for an IETF document. I like that you have security considerations sprinkled throughout the document instead of trying to combine them into one big section. However, some of the sections are missing security considerations. For example, I think even I could come up with some security considerations for the mining industry case. SECDIR might have more to say, but I think it's worth adding these. The FQDN idnit is because of Juergen Schmitt's email address, and it is fine. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-detnet-use-cases-18
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-detnet-use-cases-18 Reviewer: Pete Resnick Review Date: 2018-10-04 IETF LC End Date: 2018-10-03 IESG Telechat date: Not scheduled for a telechat Summary: Ready with Nits This was a really cool document to read simply because of the breadth of the industries involved. It clearly is going to need a good grammatical editing pass by the RFC Editor, but none of the errors are the kind that make the text hard to understand. All of my comments below are editorial in nature. Major issues: None Minor issues: None Nits/editorial comments: For all of the below, the world does not end if you don't fix them, but please consider: Abstract: The first paragraph of intro seems like a better abstract. I don't think the abstract needs as much detail as you've got in there. The Intro says: For DetNet, use cases explicitly do not define requirements; The DetNet WG will consider the use cases, decide which elements are in scope for DetNet, and the results will be incorporated into future drafts. Then why was 2.1.4 removed? It seems like it might be useful for historical context. In general, I don't like using "we" in consensus documents because it makes it ambiguous whether the "we" is the "the author(s), "the detnet WG"", "the IETF", or "this document". Additionally, using phrases like "we believe" or "we think" are superfluous in most cases. Search for " we" and think about how to get rid of such uses. A few examples: 2.2 I think you can simply just delete "we believe that". This document is making a statement; no reason to hedge. 4.3 "In the future we expect". Changing to the passive voice solves the problem: "It is expected that in the future" 5.3.2.1 "We would like to see DetNet define such a protocol". Detnet is the author of this document, so "we" here seems really weird. There are many other examples. Doing a search for " we " and seeing if you can clean them up would be useful. Throughout 3.1.1, 6.1.2, 7.3, 7.4: I presume "###us" is meant to be "###µs". I believe I-Ds are now allowed to have such characters. In 3.3.2.3, there is no discussion about how this relates to NTP. I'm not sure if that is necessary, but it seems odd for an IETF document. I like that you have security considerations sprinkled throughout the document instead of trying to combine them into one big section. However, some of the sections are missing security considerations. For example, I think even I could come up with some security considerations for the mining industry case. SECDIR might have more to say, but I think it's worth adding these. The FQDN idnit is because of Juergen Schmitt's email address, and it is fine. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Detnet] Preliminary Qs for Genart review of draft-ietf-detnet-use-cases
On 24 Sep 2018, at 15:26, Lou Berger wrote: Hi Pete, It's a reasonable question. I think the document serves a number of purposes: - It has been the document that has been guiding the scope of the solutions being worked in the WG this is the one that I think you are keying off of. - It also serves a long lived purpose to help those learning / new-to detnet, to understand the types of applications that can be supported by DetNet. Again this is about DetNet scope, but learning about it in the future rather defining it now. - The final value I think about (I'm sure others have their own list) is that it allows those WG contributors who are users ensure that their concerns are addressed by the WG. For them, this document covers both their contribution and provides a long term reference to the problems they expect to be served by the technology, both in the short term deliverables and as the technology evolves in the future. If you think the Shepherd write up needs to say more, I'm very open to suggestions. Actually, better than just saying these things in the shepherd writeup, I think it's worth saying in the intro of the document. I'll make sure that's in my editorial comments in the review. Thanks to you and others for the explanations. pr On 9/24/2018 11:43 AM, Pete Resnick wrote: Hi Lou, I've got a preliminary question about draft-ietf-detnet-use-cases that isn't answered in the intro to the document or in your shepherd writeup. I've Cced the WG just to make sure they're in the loop, and I've Cced the gen-art list and the responsible AD just in case Deborah or any of my Genart colleagues wish to say, "Pete, stop worrying your pretty little head and go finish your Genart review!" And I swear, I'm not asking this just to delay having to read 79 pages. (OK, maybe a little.) What's the motivation behind publishing this document? From the intro, it looks like it's purpose was to document the use cases so that the WG could do its work. Is there a reason that it needs to be published for posterity? Will people in the future need to reference this document? It would help me to review the document if I understood why it is being published instead of simply being a tool that the WG used and now no longer needs. I promise, in the meanwhile I'll continue to read the document and get the rest of my review finished, but I'd like to understand more about the purpose of the document. Thanks, pr ___ detnet mailing list det...@ietf.org https://www.ietf.org/mailman/listinfo/detnet ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Preliminary Qs for Genart review of draft-ietf-detnet-use-cases
Hi Lou, I've got a preliminary question about draft-ietf-detnet-use-cases that isn't answered in the intro to the document or in your shepherd writeup. I've Cced the WG just to make sure they're in the loop, and I've Cced the gen-art list and the responsible AD just in case Deborah or any of my Genart colleagues wish to say, "Pete, stop worrying your pretty little head and go finish your Genart review!" And I swear, I'm not asking this just to delay having to read 79 pages. (OK, maybe a little.) What's the motivation behind publishing this document? From the intro, it looks like it's purpose was to document the use cases so that the WG could do its work. Is there a reason that it needs to be published for posterity? Will people in the future need to reference this document? It would help me to review the document if I understood why it is being published instead of simply being a tool that the WG used and now no longer needs. I promise, in the meanwhile I'll continue to read the document and get the rest of my review finished, but I'd like to understand more about the purpose of the document. Thanks, pr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-lisp-rfc6833bis-15
Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lisp-rfc6833bis-15 Reviewer: Pete Resnick Review Date: 2018-09-19 IETF LC End Date: 2018-08-31 IESG Telechat date: 2018-09-27 Summary: Ready Major issues: None. Minor issues: None. Nits/editorial comments: None. Thanks for all of the cleanup based on my previous review. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-lisp-rfc6833bis-13
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lisp-rfc6833bis-13 Reviewer: Pete Resnick Review Date: 2018-09-05 IETF LC End Date: 2018-08-31 IESG Telechat date: 2018-09-13 Summary: Ready with Nits By no means my area of expertise, but particularly comparing this document to 6833, it's clear what changed and the new material looks reasonable. One overall nitty thing below. Major issues: None. Minor issues: None. Nits/editorial comments: Somebody went a bit "2119-mad" in this document. In particular, *most* of the MAYs are just goofy and wrong, and many of the SHOULDs shouldn't be there. When you're putting in a 2119 keyword, they should point out a place where an implementer needs to look to make sure they get their implementation correct. A lot of these aren't helpful in that regard. A few examples: In 8.2: In addition to the set of EID-Prefixes defined for each ETR that MAY register, That's not a protocol option being described. (such as those indicating whether the message is authoritative and how returned Locators SHOULD be treated) That's not a piece of implementation advice. In 8.3: This MAY occur if a Map Request is received for a configured aggregate EID-Prefix for which no more- specific EID-Prefix exists; If "MAY" can be replaced with "might or might not", you probably want "may" or "can". Unless also acting as a Map-Resolver, a Map-Server SHOULD never receive Map-Replies; That's a statement of fact, not an implementation instruction. Please go through and get rid of the bogus ones. If it's not an indication of an implementation option (or lack thereof), it shouldn't be 2119ed. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-extra-imap-objectid-06
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-extra-imap-objectid-06 Reviewer: Pete Resnick Review Date: 2018-07-27 IETF LC End Date: 2018-07-13 IESG Telechat date: 2018-08-02 Summary: Ready with Nits Major issues: None Minor issues: None Nits/editorial comments: Thanks for the changes responding to my review. Good work. §5.2, ¶6: OLD THREADID is optional, if the server doesn't support THREADID or is NEW THREADID is OPTIONAL; if the server doesn't support THREADID or is §5.2 ¶7: Not clear to me why the THREADID and EMAILID can't be the same. I assume given the MUST it's going to be some sort of interoperability problem, but it does seem odd. But don't change it on my account. §8.2 ¶2: s/backend object collide/backend object identifiers ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-extra-imap-objectid-03
Reviewer: Pete Resnick
Review result: Almost Ready
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-extra-imap-objectid-03
Reviewer: Pete Resnick
Review Date: 2018-07-14
IETF LC End Date: 2018-07-13
IESG Telechat date: Not scheduled for a telechat
Summary:
I've got a few concerns about the document, but it is almost ready. I hope
these can be addressed easily. (Also, my apologies for being a day late, though
hopefully not a dollar short. I also apologize for being a GenART reviewer who
happens to know the topic area, but hasn't been following the WG; you would
have had an easier time with someone else. ;-) )
Major issues:
§4 ¶2
I don't believe this ought to be a SHOULD. While the document explains that
this allows for disaster recovery, I don't understand what sort of disaster
would allow the server to preserve UIDVALIDITY and name, yet not be able to
preserve MAILBOXID. If you're talking about things like re-building a crashed
disk, that doesn't justify downgrading the MUST: Even though 5321 says that the
server MUST take responsibility for the message after delivering the 200, if
lightning strikes immediately after writing the message to disk and scrapes
just those sectors, that's not something that an implementer SHOULD anticipate.
This sort of softening also has the horrible side-effect (as do many other
things in IMAP) of not allowing a client to properly depend on the feature: If
a server is permitted, for whatever reasons it believes are really strongly
justified, reset MAILBOXIDs, clients will have to keep using name +
UIDVALIDITY, even if the capability is advertised. That's bogus.
Please either explain the justification for this SHOULD better, or simply
change it to a MUST and remove the bit about disaster recovery.
§4 ¶5
Why would this be allowed? If you can't preserve MAILBOXID across RENAMEs,
there's no point in advertising this capability.
§5.1 ¶2
See above on §4 ¶2.
Minor issues:
§5.1 ¶3&4
I think you need to add an explanation here that there is no way to use
MAILBOXID with a STORE command or other similar ones, and there never will be a
way (unless you really want to be able to all occurrences of a message across
all mailboxes). Maybe this goes in §9.
§8.2 ¶2
Why isn't it advisable (or even RECOMMENDED) that *all* object identifiers (not
just MAILBOXID) be globally unique? Seems like the recommendation applies to
all of them.
In the example, it is plausible that an OBJECTID proxy could rewrite
identifiers to avoid conflicts (e.g., append "-from-servername" to each
identifier). So I think it would be clearer to say:
OLD
the backends will not use the same identifiers for different objects
NEW
different objects never use the same identifiers, even if backend system
have identifiers that collide
§8.3
I'm not clear on the SHOULDs in this section. These seem like perfectly good
operational guidance statements, but not interoperability requirements. I say
lowercase them.
Nits/editorial comments:
§1 ¶3
s/If a mailbox is successfully renamed, the client knows/If a mailbox is
successfully renamed by a client, that client will know
§5
No need for the sentence at the top of this section. Just go right to 5.1.
§5.2 ¶5
The sentence is ungrammatical ("to in all")
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart telechat review of draft-ietf-ippm-twamp-yang-11
Hi Mahesh,
Trimming a bit:
On 20 Jun 2018, at 0:36, Mahesh Jethanandani wrote:
3.1 - s/The test session name that MUST be identical/The test session
name,
which MUST be identical (Unless you mean something really weird that
I don't
think you mean. If you don't see the difference, then trust me, you
mean
"which", not "that”.)
You mean in Section 3.3.
Yes, sorry about that. Section 3.1 has a similar problem:
s/The test session name that uniquely identifies/The test session name,
which uniquely identifies
and I forgot to note that one.
How about s/The test session name that MUST be identical with the/The
test session name MUST be identical to the/?
That's not quite right. You are giving a list of fields (as you say,
"Primary configuration fields include:"), so you don't want something in
that list that is a rule. The field is "the test session name", and that
field MUST be identical to the client name.
When you say, "the test session name that MUST be identical with...", it
sounds like there is more than one test session name, and you're talking
about the one that MUST be identical with the client name. Similarly
with the above, it sounds like there's one test session name which
uniquely identifies it, and one that doesn't uniquely identify it.
That's not what you mean.
4.1 -
OLD
Specifically, mode-preference-chain lists the
mode and its corresponding priority, expressed as a 16-bit unsigned
integer, where zero is the highest priority and subsequent integers
increase by one.
This is a bit confusing. I think you mean:
NEW
Specifically, mode-preference-chain lists the mode and its
corresponding priority, expressed as a 16-bit unsigned integer.
Values for the priority start with zero, the highest priority, and
subsequent priority value increases by one.
I can see why this can be confusing. How about ...
NEW
Specifically, mode-preference-chain lists the
mode and its corresponding priority as a 16-bit unsigned
integer. Values for the priority start with zero, the highest
priority, and
decreasing priority value is indicated by every increase of value
by one.
That's fine. It's a little verbose, but the RFC Editor can suggest any
wordsmithing if necessary during their edit.
OLD
In turn, each ctrl-connection holds a list of test-session-request.
test-session-request holds information associated with the Control-
Client for this test session.
A bit awkward. I suggest:
NEW
In turn, each ctrl-connection holds a test-session-request list.
Each
test-session-request holds information associated with the
Control-Client for this test session.
Ok.
Thanks.
OLD
The Control-Client is also responsible for scheduling TWAMP-Test
sessions so test-session-request holds information related to these
actions (e.g. pm-index, repeat-interval).
The word "so" in there is weird. Do you mean "therefore", or "such
that", or
something else? I just had a bit of trouble understanding what you
meant.
We meant “therefore”. Will make the change.
Ah, good. The other solution is to put a comma before "so".
4.2 - In the penultimate paragraph, change "key-id" to either "The
key-id" or
"The KeyID”.
Will change it to “The key-id”.
Sounds good.
Please note: I did not thoroughly review the YANG in section 5.2 or
the
examples in Section 6 or Appendix A. I gave them a quick run through,
but did
not check for complete consistency with the rest of the text. The
below two
items are simply things I happened to spot because I was looking at
particular
pieces of the module.
5.2 -
leaf priority {
type uint16;
description
"Indicates the Control-Client Mode preference priority
expressed as a 16-bit unsigned integer, where zero is
the highest priority and subsequent values
monotonically increasing.";
}
I am almost positive that you don't mean "monotonically increasing".
I'm
guessing you mean "increase by one”.
Will update this description to match the comment you made above or
whatever we agree to.
Thanks.
Depending on the Modes available in the TWAMP Server
Greeting message (see Fig. 2 of RFC 7717), the
this Control-Client MUST choose the highest priority
Mode from the configured mode-preference-chain list.";
Typo: "the this Control-Client”
Will fix it to say “the Control-Client”.
Perfect.
Thanks.
Thanks for your speedy reply.
pr
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-ippm-twamp-yang-11
Reviewer: Pete Resnick
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-ippm-twamp-yang-11
Reviewer: Pete Resnick
Review Date: 2018-06-19
IETF LC End Date: 2018-04-27
IESG Telechat date: 2018-06-21
Summary:
Ready with maybe Issues, but probably just Nits. Not my area of expertise by
any means, but the document looks generally solid. Could definitely use a bit
of copy editing.
Major issues:
None.
Minor issues:
I don't think there are any issues here. However, some of the things I've got
as Nits in the below section could amount to actual issues if I've
misunderstood what you meant. The editorial suggestions I give below should be
fine if they are nits, but do make sure that I haven't identified a real issue.
Nits/editorial comments:
3.1 - s/The test session name that MUST be identical/The test session name,
which MUST be identical (Unless you mean something really weird that I don't
think you mean. If you don't see the difference, then trust me, you mean
"which", not "that".)
4.1 -
OLD
Specifically, mode-preference-chain lists the
mode and its corresponding priority, expressed as a 16-bit unsigned
integer, where zero is the highest priority and subsequent integers
increase by one.
This is a bit confusing. I think you mean:
NEW
Specifically, mode-preference-chain lists the mode and its
corresponding priority, expressed as a 16-bit unsigned integer.
Values for the priority start with zero, the highest priority, and
subsequent priority value increases by one.
OLD
In turn, each ctrl-connection holds a list of test-session-request.
test-session-request holds information associated with the Control-
Client for this test session.
A bit awkward. I suggest:
NEW
In turn, each ctrl-connection holds a test-session-request list. Each
test-session-request holds information associated with the
Control-Client for this test session.
OLD
The Control-Client is also responsible for scheduling TWAMP-Test
sessions so test-session-request holds information related to these
actions (e.g. pm-index, repeat-interval).
The word "so" in there is weird. Do you mean "therefore", or "such that", or
something else? I just had a bit of trouble understanding what you meant.
4.2 - In the penultimate paragraph, change "key-id" to either "The key-id" or
"The KeyID".
Please note: I did not thoroughly review the YANG in section 5.2 or the
examples in Section 6 or Appendix A. I gave them a quick run through, but did
not check for complete consistency with the rest of the text. The below two
items are simply things I happened to spot because I was looking at particular
pieces of the module.
5.2 -
leaf priority {
type uint16;
description
"Indicates the Control-Client Mode preference priority
expressed as a 16-bit unsigned integer, where zero is
the highest priority and subsequent values
monotonically increasing.";
}
I am almost positive that you don't mean "monotonically increasing". I'm
guessing you mean "increase by one".
Depending on the Modes available in the TWAMP Server
Greeting message (see Fig. 2 of RFC 7717), the
this Control-Client MUST choose the highest priority
Mode from the configured mode-preference-chain list.";
Typo: "the this Control-Client"
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-dcrup-dkim-crypto-12
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dcrup-dkim-crypto-12 Reviewer: Pete Resnick Review Date: 2018-06-11 IETF LC End Date: 2018-06-12 IESG Telechat date: 2018-06-21 Summary: Nice simple document; Ready to go with nits. Major issues: None. Minor issues: None. Nits/editorial comments: Nit: You should update the 2119 template to the 8174 template. Comment: If this kind of update is only going to happen every 6 or 7 years, I guess it's fine, but all that this document really does is: - Trivially update the ABNF - Add the algorithm to the registry - Update the normative instructions to indicate that this new algorithm be used. That really could have all be done with a registry update if the registry had a field for normative instructions for use of the algorithm. I suppose it's no longer a big deal to add one more document to the eight-odd-thousand RFCs, but still... pr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [ippm] I-D Action: draft-ietf-ippm-twamp-yang-09.txt
Thanks Mahesh. Looks great. pr On 23 Apr 2018, at 11:54, Mahesh Jethanandani wrote: Tom/Pete, We believe this version of the draft addresses your comments. Thanks. On Apr 23, 2018, at 9:48 AM, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Two-Way Active Measurement Protocol (TWAMP) Data Model Authors : Ruth Civil Al Morton Reshad Rahman Mahesh Jethanandani Kostas Pentikousis Filename: draft-ietf-ippm-twamp-yang-09.txt Pages : 68 Date: 2018-04-23 Abstract: This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). The document defines the TWAMP data model through Unified Modeling Language (UML) class diagrams and formally specifies it using YANG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-09 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-twamp-yang-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-twamp-yang-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ ippm mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ippm Mahesh Jethanandani mjethanand...@gmail.com ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-ippm-twamp-yang-07
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ippm-twamp-yang-07 Reviewer: Pete Resnick Review Date: 2018-04-16 IETF LC End Date: 2018-04-27 IESG Telechat date: Not scheduled for a telechat Summary: This document appears ready to go forward. The only "issue" I have here might end up being an editorial issue, but I list it as a Minor issue because it might be substantive. Major issues: None. Minor issues: In the paragraph after Figure 3, it says, "and subsequent values are monotonically increasing". I'm not sure I understand what that means. If 0 is the highest priority, then 1 is a *lower* priority than 0, not an increasing priority. If you are trying to say that the numeric value of the priority field is increasing by 1 for each subsequent value, then "monotonically increasing" is wrong; the sequence "0 2 5 36" is monotonically increasing. You'd say instead, "and subsequent values increase by one". If all you mean is that values start at 0 and go up from there, I think you should just delete the entire phrase; it doesn't add anything and strikes me as confusing. Nits/editorial comments: Why are RFC 4086, RFC 8018, and ietf-ippm-metric-registry Informative References instead of Normative? The uses appear to be normative. I'm not clear why the examples were split between Section 6 and Appendix A; seems like you could just use the long one in section 6 and explain only the important bits. I also note that neither of them make any claims about normativity: That is, most examples in documents I see always say something like, "If there is a conflict between anything here and the syntax in the model, the model wins." Is that not the case in these sorts of model documents? Pet peeve: Except in Acknowledgements, I really don't like the use of "we" in IETF documents (even though it's becoming more and more common). It's not clear to whom it refers (the WG? the authors? the IETF?). In most places, it can be replaced with "This document", or using passive voice (e.g., s/We define X as/X is defined as). There are only 4 occurrences: Abstract, 1.1, 3, and 3.1. Easy enough to change. Note to shepherd: In the shepherding writeup, question 1 is not answered correctly. This document is going for *Proposed* Standard, not *Internet* Standard. Further, there is no explanation for why this should be a standards track document (though I believe the answer is pretty straightforward). You should go correct that. While you're at it, you can update answer 15, as that nit was corrected. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-mtgvenue-iaoc-venue-selection-process-11
ulations may not be identical with actual accessibility. This simply says that IASA should take that into account. 7. Section 3.2.3 - the second bullet seems to be redundant with the last bullet in section 3.1 (Mandatory Criteria). In any case, this 'need' seems to be mandatory, not only 'important'. I tend to agree, particularly if 3.1 is rewritten as you suggest. Unless someone sees a subtlety both of us are missing, that can probably be deleted. 8. Section 4: 'It is anticipated that those roles will evolve. The IASA is responsible for keeping the community informed in this regard, and MAY do so without updating this memo.' I would be a little concerned if some of the key roles would change without this document being updated. I understand the need to be flexible, but we need to put some limits. Maybe at least emphasize the need to inform the community by a MUST. For example: 'It is anticipated that those roles will evolve. The IASA MUST keep the community informed in this regard, and MAY do so without updating this memo.' I don't think the MUST significantly changes the meaning, so I'm ambivalent about the change. Since this text was put in to address a comment in AD Evaluation, I'm inclined to hear from Alissa. 9. Section 4.3 - be clear that by 'Secretariat' what is meant is 'IETF Secretariat'. Yes, I believe the first occurrence of "Secretariat" moved in an edit, thereby dropping the "IETF". It probably wouldn't hurt to put "IETF" in front of all of them. 10. Two statements about the responsibility on setting the meetings dates seem to be contradictory or at least confusing: in section 4.4: 'It (DR - the IAOC) approves the IETF meetings calendar.' in section 5.1: 'The IASA selects regions, cities and dates for meetings' 4.4 is the approval. 5.1 is the selection. I don't think that's a problem. Perhaps change "approves" to "gives final approval of"? But I'm not sure that's necessary. Is really the IASA responsible with setting or proposing dates? I thought that the calendar is set years in advance taking into account different criteria (avoiding conflicts with other SDOs calendars, avoiding major holidays, etc.) Ah, so you're saying that the dates are first researched by the Secretariat. Is that true? If so, it could be clarified. 11. I am not sure that it is clear what is meant by 'travel risks' in 5.2 and 5.4. In any case, wherever we are talking about sharing with the community information about 'travel risks' we need also to mention if there are any exceptions from the Important Criteria detailed in Section 3.2 I always read "travel risks" as identical with the "economic, health, and safety risks" mentioned in 3.2.1. Do you think we should change the text? Nits/editorial comments: 1. In Section 1, expand SSID Sure, pending your above comment on section 1. 2. In Section 2: 'We meet to pursue the IETF’s mission [RFC3935]' - RFC 3935 is also BCP 95, the other BCPs are indicated by both BCP and RFC numbers, this should be the same 3. also in Section 2: s/Meeting attendees need unfiltered access to the general Internet and our corporate networks./Meeting attendees need unfiltered access to the general Internet and their corporate networks. 4. also in Section 2: "Bar BOF" can be referred by RFC 6771 (also include in Informational References) 5. section 3.2.3 - unless there is a special reason I suggest to delete the double-dashes before and after -- or at an acceptable -- 6. Section 4.6: s/The meetings budget is managed by the IAD/The IAD manages the meetings budget./ No objection to any of those. Thanks again Dan. Excellent review. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] draft-baeuerle-netnews-cancel-lock-06 and RFCs 5536 & 5322
On 19 Sep 2017, at 9:23, Alexey Melnikov wrote: optional-field =/ *( approved / archive / control / distribution / expires / followup-to / injection-date / injection-info / lines / newsgroups / organization / path / summary / supersedes / user-agent / xref ) I see one issue with the above. appears *twice* in the definition of in 5322. I don't understand what the intent was there - whether it was a mistake or was trying to express something that I am missing. I believe it was entirely intentional. The first instance allows to add new trace header fields (which should be kept together in groups), the second allows adding other types of header fields. Correct, that was the intention. In 5322, optional-field is a catchall for any new header field, so you need one for new trace fields and one for other fields. Otherwise, there's no way to put a new field between two trace fields. This was a fix in 5322 from 2822. This really needs some further discussion. (E.g., should the valid values for as used with trace be distinct from those in its later appearance? Yes. It would have been better to have 2 separate productions, like trace-optional-field and other-optional-field, but what Pete did seems to be Ok. Yes, that might have been nice, but putting extensibility syntax throughout the grammar starts to get ugly. (Imagine resent-optional-field, originator-optional-field, etc.) I think just one is fine. This needs to be thrashed out with mail experts before this fix is finalized. I don't know what forum is appropriate for that. I am not sure. Pete? Probably ietf-822, but (a) I personally haven't read the list in a very long time, and (b) I don't think there's anything terribly controversial about the change. Ignoring that, I agree this change to 5536 would achieve the goal without requiring a change in 5322, which is progress. However I think a tweak to the above would be be a bit cleaner: optional-field =/approved / archive / control / distribution / expires / followup-to / injection-date / injection-info / lines / newsgroups / organization / path / summary / supersedes / user-agent / xref This is definitely a better fix than I was suggesting. (Thank you Pete!) Good. You're very welcome. I am equally fine with Alexey and Julien's version: optional-field = news-fields = approved / archive / control / distribution / expires / followup-to / injection-date / injection-info / lines / newsgroups / organization / path / summary / supersedes / user-agent / xref optional-field /=newsfields pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] 答复: Genart last call review of draft-ietf-ospf-encapsulation-cap-06
On 24 Aug 2017, at 11:24, Acee Lindem (acee) wrote: For 1, 2, 6, and 7, that's easy; the drafts defining the values can do the registrations. For 5, the reference would be to an existing RFC that doesn't do the registration. I'm not sure what to do about that; perhaps register it here and make the reference both 5640 and this document. Actually, this document does assign these code points in the registry so “This document” is appropriate. The value portion of these TLVs just happened to be described via a reference rather than text. There is nothing preventing the IANA registry from having useful information. :-) Yes, this document registers it, but really what the implementer is going to need is this document *and* 5640, so I see no particular harm in putting both references in the registry, and it's probably useful. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-ospf-encapsulation-cap-06
On 21 Aug 2017, at 10:58, Acee Lindem (acee) wrote: Hi Pete, On 8/21/17, 11:40 AM, "Pete Resnick" <presn...@qti.qualcomm.com> wrote: Reviewer: Pete Resnick Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ospf-encapsulation-cap-06 Reviewer: Pete Resnick Review Date: 2017-08-21 IETF LC End Date: 2017-08-28 IESG Telechat date: 2017-08-31 Summary: Almost Ready The content of this document is fine. However, I think the IANA registry stuff is not ready. Major issues: I think the registrations other than for Endpoint and Color are incorrect and should not be in this document. Certainly the "Reference" field for 1, 2, 5, 6, and 7 should not be "This document", given that the syntax and semantics for these values are defined in other documents. The authors can fix these. For 1, 2, 6, and 7, that's easy; the drafts defining the values can do the registrations. For 5, the reference would be to an existing RFC that doesn't do the registration. I'm not sure what to do about that; perhaps register it here and make the reference both 5640 and this document. However, when someone goes to update 5640 some day, they're going to have to put into the IANA considerations to update both the OSPF and BGP registries. I'm not sure how to keep track of that. Perhaps saying that this document "Updates: 5640"? That doesn't seem great either. I also think that having things in this registry which are also used by the BGP registry is asking for trouble: You wouldn't want the references for the two registries to get out of sync. This seems like a mess to me. Would it be possible for IANA to simply rename the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry to "BGP and OSPF Tunnel Encapsulation Attribute Sub-TLVs", and share the registry between the two protocols? Then have this (and other) document(s) add values to that registry. That way, the documents that actually define the codepoints can be put into the registry. We’ve already had a protracted discussion on the IANA registries. It is not possible as BGP advertises some of the attributes in BGP communities rather than tunnel attributes (e.g., color). Yuck. I'll try not to prolong the discussion much further, but did you consider the possibility of having some of the attributes appear twice, with one saying "For BGP communities only" and the other saying, "For OSPF tunnels only"? What a lovely mess. :-( Thanks, Acee Cheers, pr Minor issues: None. Nits/editorial comments: In section 7.1, please add: [RFC Editor: Please replace "TBD1" in section 3 with the registry value allocated by IANA, and remove this note]. That will save them from hunting. -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-ospf-encapsulation-cap-06
Reviewer: Pete Resnick Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ospf-encapsulation-cap-06 Reviewer: Pete Resnick Review Date: 2017-08-21 IETF LC End Date: 2017-08-28 IESG Telechat date: 2017-08-31 Summary: Almost Ready The content of this document is fine. However, I think the IANA registry stuff is not ready. Major issues: I think the registrations other than for Endpoint and Color are incorrect and should not be in this document. Certainly the "Reference" field for 1, 2, 5, 6, and 7 should not be "This document", given that the syntax and semantics for these values are defined in other documents. I also think that having things in this registry which are also used by the BGP registry is asking for trouble: You wouldn't want the references for the two registries to get out of sync. This seems like a mess to me. Would it be possible for IANA to simply rename the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry to "BGP and OSPF Tunnel Encapsulation Attribute Sub-TLVs", and share the registry between the two protocols? Then have this (and other) document(s) add values to that registry. That way, the documents that actually define the codepoints can be put into the registry. Minor issues: None. Nits/editorial comments: In section 7.1, please add: [RFC Editor: Please replace "TBD1" in section 3 with the registry value allocated by IANA, and remove this note]. That will save them from hunting. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-curdle-ssh-dh-group-exchange-05
Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-curdle-ssh-dh-group-exchange-05 Reviewer: Pete Resnick Review Date: 2017-07-25 IETF LC End Date: 2017-07-30 IESG Telechat date: Not scheduled for a telechat Summary: Ready. No concerns. Major issues: None. Minor issues: None. Nits/editorial comments: I am not convinced the pre-5378 boilerplate is necessary. You refer to, but have not incorporated, material from 4419. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-spring-oam-usecase-06
On 29 Jun 2017, at 2:28, ruediger.g...@telekom.de wrote: Hi Pete, thanks for proposing to make this an Applicability Statement, BCP or standard. I don't object, but if the status of this draft is supposed to be changed, my chairs and AD need to support this. Bruno and Alvaro, what's your view on Pete's proposal? We may have to invest some more time and text then. I personally don't object to "informational" as an aim, but if that means removing major parts of the content, I'd be rather unhappy. Thanks for considering this. IMO, I don't see why doing this as PS would require removing anything; lots of PSs have informational content in them. Pete, also Alvaro gave us a routing AD review on Friday, 16. June (and he had comments). Bruno's shephard review as part of the WG Last Call resulted in better structuring and definitions in the document. So far, no AD or reviewer "tends to ignore [this] Informational "use case" document". You’re the third AD to comment and ask for changes (and I recall to have had serious AD and IESG reviews with other informationals). Oh, I didn't mean to say that serious reviews of Informational docs didn't happen; it quite often does. But the bar is lower, and I know for myself (both as a participant and as an AD) that sometimes I would skip reading a particular document because I had run out of time and "it was only going for Informational", or see something that I didn't like in a Informational document and say, "Well, it's only going for Informational, so I'm not going to cause too much of a fuss". For a document that is actually a consensus specification of an IETF WG, that shouldn't be allowed to happen; everybody should be aware that this document should get the full scrutiny of a standards-track document. Regards, Ruediger Cheers, pr -Ursprüngliche Nachricht- Von: Pete Resnick [mailto:presn...@qti.qualcomm.com] Gesendet: Mittwoch, 28. Juni 2017 20:31 An: gen-art@ietf.org Cc: spr...@ietf.org; i...@ietf.org; draft-ietf-spring-oam-usecase@ietf.org Betreff: Genart last call review of draft-ietf-spring-oam-usecase-06 Reviewer: Pete Resnick Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-spring-oam-usecase-06 Reviewer: Pete Resnick Review Date: 2017-06-28 IETF LC End Date: 2017-06-30 IESG Telechat date: Not scheduled for a telechat Summary: Not Ready for publication as Informational, but might be Ready for publication as Proposed Standard Major issues: This is an admittedly unusual review. I have read through the entire document, and the technical work seems fine, but is well beyond my technical expertise, so I can't really comment on the technical correctness. However, it is absolutely clear to me that this is *not* a "use case" document at all and I don't think it's appropriate as an Informational document. This is clearly a *specification* of a path monitoring system. It gives guidances as to required, recommended, and optional parameters, and specifies how to use different protocol pieces. It is at the very least what RFC 2026 refers to as an "Applicability Statement (AS)" (see RFC 2026, sec. 3.2). It *might* be a BCP, but it is not strictly giving "common guidelines for policies and operations" (2026, sec. 5), so I don't really think that's right, and instead this should be offered for Proposed Standard. Either way, I think Informational is not correct. Importantly, I think there is a good likelihood that this document has not received the appropriate amount of review; people tend to ignore Informational "use case" documents, and there have been no Last Call comments beyond Joel's RTG Area Review. Even in IESG review, an Informational document only takes the sponsoring AD to approve; every other AD can summarily ignore the document, or even ballot ABSTAIN, and the document will still be published (though that does not normally happen). This document should have much more than that level of review. I strongly recommend to the WG and AD that this document be withdrawn as an Informational document and resubmitted for Proposed Standard and have that level of review and scrutiny applied to it. Minor issues: None. Nits/editorial comments: This document refers to RFC 4379, which has been obsoleted by RFC 8029. It seems like the references should be updated. -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-spring-oam-usecase-06
Reviewer: Pete Resnick Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-spring-oam-usecase-06 Reviewer: Pete Resnick Review Date: 2017-06-28 IETF LC End Date: 2017-06-30 IESG Telechat date: Not scheduled for a telechat Summary: Not Ready for publication as Informational, but might be Ready for publication as Proposed Standard Major issues: This is an admittedly unusual review. I have read through the entire document, and the technical work seems fine, but is well beyond my technical expertise, so I can't really comment on the technical correctness. However, it is absolutely clear to me that this is *not* a "use case" document at all and I don't think it's appropriate as an Informational document. This is clearly a *specification* of a path monitoring system. It gives guidances as to required, recommended, and optional parameters, and specifies how to use different protocol pieces. It is at the very least what RFC 2026 refers to as an "Applicability Statement (AS)" (see RFC 2026, sec. 3.2). It *might* be a BCP, but it is not strictly giving "common guidelines for policies and operations" (2026, sec. 5), so I don't really think that's right, and instead this should be offered for Proposed Standard. Either way, I think Informational is not correct. Importantly, I think there is a good likelihood that this document has not received the appropriate amount of review; people tend to ignore Informational "use case" documents, and there have been no Last Call comments beyond Joel's RTG Area Review. Even in IESG review, an Informational document only takes the sponsoring AD to approve; every other AD can summarily ignore the document, or even ballot ABSTAIN, and the document will still be published (though that does not normally happen). This document should have much more than that level of review. I strongly recommend to the WG and AD that this document be withdrawn as an Informational document and resubmitted for Proposed Standard and have that level of review and scrutiny applied to it. Minor issues: None. Nits/editorial comments: This document refers to RFC 4379, which has been obsoleted by RFC 8029. It seems like the references should be updated. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-netmod-yang-model-classification-07
Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-netmod-yang-model-classification-07 Reviewer: Pete Resnick Review Date: 2017-05-22 IETF LC End Date: 2017-05-14 IESG Telechat date: 2017-06-08 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: None Thanks for addressing my comments in the Last Call review. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-netmod-yang-model-classification-06
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-netmod-yang-model-classification-?? Reviewer: Pete Resnick Review Date: 2017-05-09 IETF LC End Date: 2017-05-14 IESG Telechat date: Not scheduled for a telechat Summary: Ready with Minor Issues/Nits To an outsider like me, this seems like a useful document and it was an interesting read. The document could use a serious edit for grammar and typos. A few specific comments below. Major issues: None. Minor issues: In section 2.1, paragraphs 4 and 5 mention "speed". The speed of what? Development of the module? It's not clear from the text. In section 3.1, it says: While there is no formal definition of what construes an SDO, a common feature is that they publish specifications along specific processes with content that reflects some sort of membership consensus. The specifications are developed for wide use among the membership or for audiences beyond that. First of all, s/construes/constitutes. But aside from that, it's not at all clear to me that a common feature is "membership consensus". For example, we don't have membership, and many other organizations use voting and not consensus. Perhaps replace the above with something simpler like: Most SDOs create specifications according to a formal process in order to produce a standard that is useful for their constituencies. Nits/editorial comments: In the Abstract and section 3.1, you use "standards-defining organization" for SDO. I've never heard that phrase used before. Elsewhere in the document, you use "standards development organization", which is the phrase I've always seen used. I suggest you change to that in both places. Throughout the document, you say things like, "the authors believe" or "we assume". This is a WG consensus document. While I generally think that using these terms is bad form in a WG document, saying "the authors believe" almost sounds like the authors believe it, but the WG might not. If the authors and the WG believe XYZ, don't say "the authors believe XYZ" or "we believe XYZ"; just say "XYZ", or at least use the passive voice. So: Section 1: OLD The intent of this document is to provide a taxonomy to simplify human communication around YANG modules. The authors acknowledge that the classification boundaries are at times blurry, but believe that this document should provide a robust starting point as the YANG community gains further experience with designing and deploying modules. To be more explicit, the authors believe that the classification criteria will change over time. NEW The intent of this document is to provide a taxonomy to simplify human communication around YANG modules. While the classification boundaries are at times blurry, this document should provide a robust starting point as the YANG community gains further experience with designing and deploying modules. To be more explicit, it is expected that the classification criteria will change over time. END Section 2: OLD For the purpose of this document we assume that both approaches (bottom-up and top-down) will be used as they both provide benefits that appeal to different groups. NEW This document considers both bottom-up and top-down approaches as they are both used and they each provide benefits that appeal to different groups. END Section 2.1: OLD For the purpose of this document we will use the term "orchestrator" to describe a system implementing such a process. NEW For the purpose of this document, the term "orchestrator" is used to describe a system implementing such a process. Section 2.2: OLD Although the [RFC7950], [RFC7950] doesn't explain the relationship of the terms '(YANG) data model' and '(YANG) module', the authors understand there is a 1:1 relationship between a data model and a YANG module, but a data model may also be expressed using a collection of YANG modules (and submodules). (This one's not even grammatical. Here's my best guess as to what you meant) NEW Although [RFC7950] doesn't explain the relationship between the terms '(YANG) data model' and '(YANG) module', there is a 1:1 relationship between a data model and
[Gen-art] Genart last call review of draft-ietf-httpbis-encryption-encoding-08
Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-httpbis-encryption-encoding-?? Reviewer: Pete Resnick Review Date: 2017-04-05 IETF LC End Date: 2017-04-06 IESG Telechat date: 2017-04-13 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: Looks fine from a non-security-expert's perspective. It is my duty to ask about keyid in section 2.1: 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 include "might need to be typed in by someone", correct? The former is easy; the latter probably requires a bit more text. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-ipsecme-rfc4307bis-17
Reviewer: Pete Resnick Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ipsecme-rfc4307bis-17 Reviewer: Pete Resnick Review Date: 2017-03-15 IETF LC End Date: 2017-01-31 IESG Telechat date: 2017-03-16 Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: While using MUST, SHOULD, and MAY as nouns and adjectives causes me a twitch, this document is just fine. There's a typo in the first paragraph of 1.2. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Review of draft-ietf-ccamp-flexible-grid-ospf-ext-08
[Trimming down] On 12 Feb 2017, at 19:22, Zhenghaomian wrote: 3.2: Hence, in order to support all possible applications and implementations the following information should be advertised for a flexi-grid DWDM link: Is that "should" in there meant to be normative? That is, do bad things happen if I don't advertise one of those items? Or do you just mean "the following information is advertised..."? [Haomian] I feel weird if replace 'should be' with 'is', as you cannot support some application/implementation (rather than do bad things) if you don't advertise... How about following change? OLD Hence, in order to support all possible applications and implementations the following information should be advertised for a flexi-grid DWDM link: NEW Hence, in order to support all possible applications and implementations the following information is required to be advertised for a flexi-grid DWDM link: Well, that's starting to feel like a SHOULD or a MUST. That is to say, some applications/implementations will not work if you don't advertise these things, so if you're not going to advertise one or more of them, you'd better know what you're doing and understand the consequences. That's the 2119 definition of SHOULD. On the other hand, if it's really always required because you really have to support all of those applications/implementations, and there are no good reasons to fail to advertise any of these things, then that's a MUST. As I said before, I'm someone who doesn't like putting in MUSTs and SHOULDs (I've even written protocol documents where they never appear), but if you really mean "required" or "required unless you know what you're doing", I see no harm in putting them in. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-ccamp-flexible-grid-ospf-ext-08
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ccamp-flexible-grid-ospf-ext-08 Reviewer: Pete Resnick Review Date: 2017-02-10 IETF LC End Date: 2017-01-31 IESG Telechat date: 2017-02-16 Summary: Ready with Nits A couple of nits that I mentioned in my earlier review that you might want to address, but none of them are essential. (You may have decided that I was wrong; that's OK too.) I didn't bother Cc'ing the IETF list on this, since they're both very minor. Major issues: None Minor issues: None Nits/editorial comments: 3.1: A set of non-overlapping available frequency ranges MUST be disseminated in order to allow efficient resource management of flexi-grid DWDM links and RSA procedures which are described in Section 4.8 of [RFC7698]. Those MUSTs look weird to me. I think instead of "MUST be" you mean "are", since it doesn't look like an implementation really has a choice here. 3.2: Hence, in order to support all possible applications and implementations the following information should be advertised for a flexi-grid DWDM link: Is that "should" in there meant to be normative? That is, do bad things happen if I don't advertise one of those items? Or do you just mean "the following information is advertised..."? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Review of draft-ietf-ccamp-flexible-grid-ospf-ext-07
If that's what you mean, let me suggest simplifying:
OLD
At least one priority
level MUST be advertised that, unless overridden by local policy,
SHALL be at priority level 0.
NEW
At least one priority
level MUST be advertised. If only one priority level is advertised,
it MUST be at priority level 0.
Thanks for the extended discussion of this. It all looks fine.
pr
On 8 Feb 2017, at 4:14, Daniele Ceccarelli wrote:
Hi Pete,
This is an “inheritance” from GMPLS, where supporting a single
priority equals not supporting priorities. If you don’t want to
support priorities you don’t want your traffic to be
preempted…hence priority 0.
Well, it doesn't say that shouldn't be done, but it probably doesn't
need to say anything about local configurations.
For me it’s ok not to say anything on that.
Thanks
Daniele
From: Pete Resnick [mailto:presn...@qti.qualcomm.com]
Sent: martedì 7 febbraio 2017 18:05
To: Daniele Ceccarelli <daniele.ceccare...@ericsson.com>
Cc: Jari Arkko <jari.ar...@piuha.net>; gen-art@ietf.org;
draft-ietf-ccamp-flexible-grid-ospf-ext@ietf.org; cc...@ietf.org;
i...@ietf.org
Subject: Re: [Gen-art] Review of
draft-ietf-ccamp-flexible-grid-ospf-ext-07
Hi Daniele,
Thanks for addressing everything. There's only one issue left in
section 4.1.1 on Priority, below. I've trimmed out all the rest.
On 7 Feb 2017, at 3:36, Daniele Ceccarelli wrote:
I get that part ("At least one priority level MUST be advertised").
It's the end I don't understand: "that, unless overridden by local
policy, SHALL be at priority level 0." What does that mean?
[DC] It means that if only one priority is supported it has to be
priority 0.
So, let me see if I have this right: It's OK to have 0110 but not
0100 or 0010? If so, why is that?
For any particular administrative purpose it could be possible to set
it to a different value, but that shouldn’t be done.
Well, it doesn't say that shouldn't be done, but it probably doesn't
need to say anything about local configurations.
pr
--
Pete Resnick
http://www.qualcomm.com/~presnick/<http://www.qualcomm.com/%7Epresnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Review of draft-ietf-ccamp-flexible-grid-ospf-ext-07
Hi Daniele,
Thanks for addressing everything. There's only one issue left in section
4.1.1 on Priority, below. I've trimmed out all the rest.
On 7 Feb 2017, at 3:36, Daniele Ceccarelli wrote:
I get that part ("At least one priority level MUST be advertised").
It's the end I don't understand: "that, unless overridden by local
policy, SHALL be at priority level 0." What does that mean?
[DC] It means that if only one priority is supported it has to be
priority 0.
So, let me see if I have this right: It's OK to have 0110 but not
0100 or 0010? If so, why is that?
For any particular administrative purpose it could be possible to set
it to a different value, but that shouldn’t be done.
Well, it doesn't say that shouldn't be done, but it probably doesn't
need to say anything about local configurations.
pr
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Review of draft-ietf-ccamp-flexible-grid-ospf-ext-07
On 6 Feb 2017, at 7:36, Daniele Ceccarelli wrote:
Hi Jari, Pete,
First of all thanks for the accurate review.
All the nits/editorial comments are correct and will be fixed.
Regarding the minor issue:
4.1.1:
The figure is a bit confusing: There might not exist a "Max Slot
Width at Priority
7" if bit 7 is clear in the Priority field, correct?
Perhaps it would be better to just show that as "..." or "Max Slot
Width at
Priority n". The thing is, it might only be a single value, followed
by the
padding, so having the second value in there might be misleading.
(Perhaps
similar constructs are used in other MPLS docs and people will
understand. But
it took me a while to figure it out.)
it was difficult to express in the figure the fact that only some of
the priorities are advertised. As you said it could be one, two or any
number up to 8.
What about a single field (with ~ on the borders to indicate that it
can have variable length) saying "Max Slot Width at Prio n" and then
say that 16 bits are used for each prio and when an odd number of
priorities is used the field is padded to line up with multiples of 32
bits?
Yes, I think that would make more sense to me.
The discussion of Priority was very confusing for me. In the third
sentence, do
you mean, "A bit is set (1) corresponding to each priority
represented in the
sub-TLV, and clear (0) for each priority not represented in the
sub-TLV"? I don't
understand the MUST/MUST NOT as you had it. And I don't understand
the
last sentence at all. Are you trying to say, "The leftmost bit
(priority level 0)
MUST be set, and priority level 0 MUST be advertised in the
sub-TLV."?
Otherwise, I don't get it.
It means that if the priority field is set to e.g. 10010010 in the
following you would find 4 fields indicating respectively: Max Slot
Width at Priority 0, Max Slot Width at Priority 3, Max Slot Width at
Priority 6 and since they are 3 a 16 bits padding to 32 bits.
OK, then I think my sentence is clearer for that: "A bit is set (1)
corresponding to each priority represented in the sub-TLV, and clear (0)
for each priority not represented in the sub-TLV."
It also means that at least one priority must be advertised (i.e.
priority is not allowed).
I get that part ("At least one priority level MUST be advertised"). It's
the end I don't understand: "that, unless overridden by local policy,
SHALL be at priority level 0." What does that mean?
I don't understand the MAY in the last sentence. Does that mean that
I MAY
also set it to the highest possible nominal central frequency
supported by the
link? I don't understand what that sentence is trying to tell me.
An example is provided in section 4.1.2, where the available range
goes from -2 to +8 but the range supported by the link goes from -9 to
+11. The sentence means that even if not available it could be
possible to indicate also n=-9 to indicate the starting point of the
range supported by the link.
" In this example, it is assumed that the lowest nominal central
frequency supported is n= -9 and the highest is n=11. Note they
cannot be used as a nominal central frequency for setting up a LSP,
but merely as the way to express the supported frequency range."
I'm ok with dropping the sentence.
I think dropping the sentence would make the most sense.
Thank you
Daniele
Thanks for considering my suggested changes.
pr
-Original Message-
From: Jari Arkko [mailto:jari.ar...@piuha.net]
Sent: lunedì 6 febbraio 2017 12:32
To: Pete Resnick <presn...@qti.qualcomm.com>
Cc: gen-art@ietf.org;
draft-ietf-ccamp-flexible-grid-ospf-ext@ietf.org;
cc...@ietf.org; i...@ietf.org
Subject: Re: [Gen-art] Review of
draft-ietf-ccamp-flexible-grid-ospf-ext-07
Thanks for your review, Pete. Authors, any comments?
Jari
--
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-ccamp-flexible-grid-ospf-ext-07
Reviewer: Pete Resnick Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ccamp-flexible-grid-ospf-ext-07 Reviewer: Pete Resnick Review Date: 2017-02-03 IETF LC End Date: 2017-01-31 IESG Telechat date: 2017-02-16 Summary: Looks good from a non-expert point of view. A few things I found ambiguous or confusing that should be easily clarified, but nothing that should stop the document from moving forward. Major issues: None. Minor issues: 4.1.1: The figure is a bit confusing: There might not exist a "Max Slot Width at Priority 7" if bit 7 is clear in the Priority field, correct? Perhaps it would be better to just show that as "..." or "Max Slot Width at Priority n". The thing is, it might only be a single value, followed by the padding, so having the second value in there might be misleading. (Perhaps similar constructs are used in other MPLS docs and people will understand. But it took me a while to figure it out.) The discussion of Priority was very confusing for me. In the third sentence, do you mean, "A bit is set (1) corresponding to each priority represented in the sub-TLV, and clear (0) for each priority not represented in the sub-TLV"? I don't understand the MUST/MUST NOT as you had it. And I don't understand the last sentence at all. Are you trying to say, "The leftmost bit (priority level 0) MUST be set, and priority level 0 MUST be advertised in the sub-TLV."? Otherwise, I don't get it. I don't understand the MAY in the last sentence. Does that mean that I MAY also set it to the highest possible nominal central frequency supported by the link? I don't understand what that sentence is trying to tell me. Nits/editorial comments: 3, last paragraph: OLD That is, the additional information NEW That is, this section defines the additional information END As it is, it is ungrammatical. 3.1: On a DWDM link, the allocated or in-use frequency slots must not overlap with each other. I think perhaps it's clearer to simply say "frequency slots do not overlap each other", assuming that's what you mean. I don't think you're trying to say something normative there; it's just a fact. But people often read "must" (whether it's uppercased or not) to be imposing a requirement. I don't think that's what you're doing here, so better to make it clear. (As you may know, I'm not a fan of overuse of MUSTs and SHOULDs, but I do like it when documents are clear.) As an opposite example: Hence, in order to clearly show which LSPs can be supported and what frequency slots are unavailable, the available frequency ranges MUST be advertised by the routing protocol for the flexi-grid DWDM links. A set of non-overlapping available frequency ranges MUST be disseminated in order to allow efficient resource management of flexi-grid DWDM links and RSA procedures which are described in Section 4.8 of [RFC7698]. Those MUSTs look weird to me. I think instead of "MUST be" you mean "are", since it doesn't look like an implementation really has a choice here. 3.2: Hence, in order to support all possible applications and implementations the following information should be advertised for a flexi-grid DWDM link: Is that "should" in there meant to be normative? That is, do bad things happen if I don't advertise one of those items? Or do you just mean "the following information is advertised..."? 3.3: For this reason, the available frequency slot/ranges need to be advertised for a flexi-grid DWDM link instead of the specific "wavelengths" points that are sufficient for a fixed-grid link. Where you say "needs to be advertised", are you making a normative statement, or are you just describing, in which case "are advertised" would be clearer? (By the way: Typo in the following sentence. Change "thus" to "this".) 4.1: When Switching Capability and Encoding fields are set to values as stated above, the Interface Switching Capability Descriptor MUST be interpreted as in [RFC4203] with the optional inclusion of one or more Switching Capability Specific Information sub-TLVs. Same question as earlier about "MUST be" vs. "is". 4.1.1: The technology specific part of the Flexi-grid ISCD should include Same question as earlier about "should include" vs. "includes". Length (16 bits): The length of the value field of this sub-TLV. Perhaps obvious to an MPLS person, but is this the length i
[Gen-art] Review of draft-ietf-ipsecme-rfc4307bis-15
Reviewer: Pete Resnick Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. (Apologies for the late submission.) For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ipsecme-rfc4307bis-?? Reviewer: Pete Resnick Review Date: 2017-02-02 IETF LC End Date: 2017-01-31 IESG Telechat date: 2017-02-16 Summary: This document is basically ready, but there are a large number of nits, so many that I would think additional review would be desired. Major issues: None Minor issues: None Nits/editorial comments: [Note: I do not see any particular technical problems with the document, but I don't have expertise in this area. I have listed below many clarifications and fixes to typographical and grammatical errors. (I did not note all of the punctuation errors as none of them left ambiguity.) Normally, I would simply list these as nits/editorial comments and leave it at that. But there are so many of these that I'm a bit concerned that the document did not receive sufficient technical review, given that it went through 15 versions and nobody fixed all of these editorial issues. That said, that is an issue between the AD and the WG.] It seems like section 2 should be moved up above section 1 since these specialized conventions are used in section 1. 1: The second to last sentence is ungrammatical and hard to read. Try this: OLD This document describes the parameters of the IKE protocol and updates the IKEv2 specification because it changes the mandatory to implement authentication algorithms of the section 4 of the RFC7296 by saying RSA key lengths of less than 2048 are SHOULD NOT. NEW This document describes the parameters of the IKE protocol. It also updates the IKEv2 specification because it changes the mandatory to implement authentication algorithms of section 4 of RFC 7296 by saying RSA key lengths of less than 2048 SHOULD NOT be used. END 1.1, first sentence: s/then/than 1.1, last sentence: s/in a separate document/in this separate document. 1.2: The last sentence of the third paragraph repeats what is in the last paragraph of 1.2 and therefore redundant. You can strike it. 2: I suggest adding a sentence after the first paragraph for clarification: "When used in the tables in this document, these terms indicate that the listed algorithm MUST, MUST NOT, SHOULD, SHOULD NOT or MAY be implemented as part of an IKEv2 implementation." 4307 never said that specifically, and I've always found it weird. 3.1, first paragraph: s/an integrity algorithms in Section 3.3/one of the integrity algorithms in Section 3.3 3.1, third paragraph: s/CRFG/the Crypto Forum Research Group (CFRG) of the IRTF (You not only didn't define it, you got the acronym backwards.) 3.1, third from last paragraph: s/on those cases/in those cases 3.1, second from last paragraph: s/implementation/implementations 3.1, last paragraph: s/of-the-shelves/off-the-shelf ; s/therefor/therefore 3.3, last paragraph: s/status ware/statuses were 3.4, third paragraph: s/were/was 3.4, fourth paragraph: s/vulnerable to be broken/vulnerable to being broken 3.4, last paragraph: s/thater/that; s/academia have/academia has 4: s/concerned on/concerned with 4.1, first paragraph: OLD RSA Digital Signature is not recommended for keys smaller then 2048, but since these signatures only have value in real-time, and need no future protection, smaller keys was kept at SHOULD NOT instead of MUST NOT. NEW See section 4.1.1 for a discussion of key length recommendations for use in RSA Digital Signature. END (If you want, include some of the original text in 4.1.1. 4.1, third paragraph: s/it does not/they do not 4.2, paragraphs 1, 2, & 3: s/When Digital Signature authentication/When a Digital Signature authentication ; also, strike the word "then" in the first two paragraphs. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review for draft-ietf-lisp-crypto-09
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Document: draft-ietf-lisp-crypto-09 Reviewer: Pete Resnick Review Date: 2016-10-12 IETF LC End Date: 2016-10-04 IESG Telechat date: 2016-10-13 Summary: This draft is ready for publication as an Experimental RFC Though this is not an area of expertise for me, the document is clearly written, I reviewed the data structures and they appear correct, and the document seems ready to go forward. (I do find it dicey that this is an Experimental document. I understand there is history here, but this is a full-fledged protocol document and the fact that it is only required to be subjected to a cursory review for Experimental status and can pass IESG review with one "YES" and everyone else "ABSTAIN"ing seems kinda ridiculous. But that's not a reason to stop this document.) Major issues: None Minor issues: None Nits/editorial comments: Section 9, second to last paragraph: "Otherwise, the packet has been tampered with and is discarded." The "tampered with" is probably overstating the case. I would simply say "invalid". -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08
On 9 Sep 2016, at 4:33, Suresh Krishnan wrote: Hi Tiru, On 09/07/2016 10:50 PM, Tirumaleswar Reddy (tireddy) wrote: [TR] I propose the following text to avoid the confusion: If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation in case of no IP address change, it will send a Refresh Request as described in Section 7.1 of [RFC5766] and MUST NOT include a MOBILITY-TICKET attribute. If the client wants to retain the existing allocation in case of IP address change, it will include the MOBILITY-TICKET attribute received in the Allocate Success response in the Refresh Request. I have no issues with this new text. Please check with Pete if it resolves his concerns. Wait, now I'm even more confused. The second sentence says that you *are allowed* to include the MOBILITY-TICKET attribute in a Refresh Request if you want to retain the allocation, even though the first sentence says you MUST NOT. Is this because the Refresh Request with the MOBILITY-TICKET attribute will only be rejected if the IP address is the same? If so, perhaps this is what you meant: If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it sends a Refresh Request as described in Section 7.1 of [RFC5766]. If IP address of the client has changed and the client wants to retain the existing allocation, the client includes the MOBILITY-TICKET attribute received in the Allocate Success response in the Refresh Request. If there has been no IP address change, the client MUST NOT include a MOBILITY-TICKET attribute, as this will be rejected by the server and the client would need to retransmit the Refresh Request. If that's not what you meant, you should probably clarify. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08
Stephen, As per my reply to Suresh: It is often the case that the gratuitous use of "MUST"s hides ambiguities in meaning that need to be fixed anyway. And for the sake of keeping things the same as they were when I was on the IESG, I say to you, with great affection: :-b pr On 7 Sep 2016, at 2:24, Stephen Farrell wrote: Hi Pete, On 06/09/16 16:55, Pete Resnick wrote: However, I believe Suresh was incorrect in suggesting the first "MUST", and it should be removed. There is no harm being prevented here. "If a client wants X, it MUST send Y" is absolutely no different protocol-wise from "If a client wants X, it will send Y". The "MUST" is a misuse. I believe that this change should be undone before publication. This is something we rehearsed at length and fairly regularly (if only occasionally) when one Mr. Resnick was on the IESG:-) My impression of those discussions is that we ended up with a draw: Pete continues to not like when such gratuitous MUST statements are included, and is strictly correct that they aren't needed. However, authors do do that and the sky does not fall in, so others (incl. me) feel that the IESG badgering authors on this topic is counter-productive. IOW, I don't think the change needs to be undone. But I don't care if that happens or not in this case. If the IESG were to extrapolate from that to suggesting that Pete's preferred approach MUST be followed, then I would have a problem with that. (But I hope we're not going there:-) S. -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08
[Trimming down a bit] On 6 Sep 2016, at 22:57, Suresh Krishnan wrote: OLD: If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it will send a Refresh Request as described in Section 7.1 of [RFC5766] NEW: If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it MUST send a Refresh Request as described in Section 7.1 of [RFC5766] and MUST NOT include a MOBILITY-TICKET attribute. I will try to explain my line of reasoning. Let me know where you disagree. If the client includes a MOBILTY-TICKET attribute in the refresh method, the refresh will fail. So, the MUST NOT is aimed at preventing the client from sending a useless packet that will be rejected anyway. "Useless" seems not a good reason for a "MUST NOT". Perhaps Tiru's explanation of "will cause an extra retransmission" is a better reason. But as I said, this isn't one that I will complain too vociferously about: What this says is "don't include the attribute; it will be rejected and you'll have to retransmit"; if you want a "MUST NOT" for that, so be it. But: The MUST stresses that the original Refresh procedure from RFC5766 needs to be used instead of the Refresh procedure with the MOBILITY-TICKET described in this one. Ah! If that's was meant, that's not what was said. It sounds like you're saying that the client *can't* refresh a request by simply sending an allocate request with the old MOBILITY-TICKET. And then I get a bit confused about the MUST NOT: The next sentence after this bit says: If the client wants to retain the existing allocation in case of IP change, it will include the MOBILITY-TICKET attribute received in the Allocate Success response. The previous sentence says that you MUST NOT include the attribute. This sentence says that you do include it. I suspect that what was intended was, "If you *just* want to refresh to retain the existing allocation in case of an IP change, you can send an allocate request including the old MOBILITY-TICKET attribute. If you need to update time-to-expiry or delete the allocation, then you *can't* just send a new allocate request with the attribute; that will get rejected. You instead *have to* use the refresh request in 5766." Do I have that right? If so, the paragraph could use a rewrite; it's not the MUST and the MUST NOT that are the problem. Anyway, I am not wedded to keeping the MUST as long as the MUST NOT prevents the sending of a packet that is certain to be rejected. Ack. See above. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08
Greetings, I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other participants comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-tram-turn-mobility-03 Reviewer: Pete Resnick Review Date: 2016-09-06 IESG Telechat date: 2016-09-01 Summary: This is an odd post-telechat review, but I think the draft has gone from "Ready" to "Ready with an issue" because of an IESG Eval change. Details: I did not get to my post-Last Call GenART review of draft-ietf-tram-turn-mobility until after the telechat. Had I done so, which would have been on version -05, I would have said "Looks fine to me". However, I happened to look at the latest version, figuring I would just confirm. I found that a change was made in response to an IESG Evaluation comment from Suresh <https://mailarchive.ietf.org/arch/msg/tram/SYVAXc1dF6xUcm0OQ9xyuaknJco>: -- COMMENT: -- * Section 3.2.1 The section on sending a Refresh when the IP address does not change needs a little bit more tightening. Given that the server would reject the request with a mobility ticket in this case, it would be good to put in an explicit restriction to not add the mobility ticket in the following statement OLD: If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it will send a Refresh Request as described in Section 7.1 of [RFC5766] NEW: If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it MUST send a Refresh Request as described in Section 7.1 of [RFC5766] and MUST NOT include a MOBILITY-TICKET attribute. I'm not sure if the "MUST NOT" in the latter part of the sentence is correct: Since the server will reject it anyway, I don't see the harm in including the attribute that the "MUST NOT" implies, but perhaps this is belt-and-braces protocol description. On this point, I can't complain too much. However, I believe Suresh was incorrect in suggesting the first "MUST", and it should be removed. There is no harm being prevented here. "If a client wants X, it MUST send Y" is absolutely no different protocol-wise from "If a client wants X, it will send Y". The "MUST" is a misuse. I believe that this change should be undone before publication. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-tram-turn-mobility-03
Thanks for the response Tiru. Trimming down to the one open issue below; everything else looks perfect: On 8 Aug 2016, at 23:50, Tirumaleswar Reddy (tireddy) wrote: 3.1.2 - Change "MUST" to "will" both times in the second paragraph. I presume you're OK with those changes? The last sentence of the section I don't understand; it doesn't seem to have any interoperability implications, and I don't see why the client can't examine the ticket in any way it wants. Either justify the sentence or delete it. [TR] Even if the client examines the ticket there is no guarantee that it will be able decode its fields. This line is added to suggest that there is no need for the client to examine the ticket. Well, "no need" is very different than "MUST NOT". If you really want to keep the sentence (and I still think you could just delete it), I would suggest simply changing it to something like: "Note: There is no guarantee that the fields in the ticket are going to be decodable to a client, and therefore attempts by a client to examine the ticket are unlikely to be useful." pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART LC review of draft-ietf-tram-turn-mobility-03
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-tram-turn-mobility-03 Reviewer: Pete Resnick Review Date: 2016-08-08 IETF LC End Date: 2016-08-11 IESG Telechat date: Unknown Summary: This draft is basically ready for publication, but has some minor issues and nits that should be fixed before publication. Major issues: None Minor issues: 3.1.2 - Change "MUST" to "will" both times in the second paragraph. The last sentence of the section I don't understand; it doesn't seem to have any interoperability implications, and I don't see why the client can't examine the ticket in any way it wants. Either justify the sentence or delete it. 3.2.2 - Change "may" to "MAY" in the sixth paragraph. That *is* a protocol option being described there. Nits/editorial comments: 3.1.4 - Change "MAY" to "can" in the second paragraph. I'd also split that sentence into two sentences as the first half has nothing to do with the second half. 3.2.1 - The last sentence of 3.2.1 is confusing until you read 3.2.2 and 3.2.3. I would simply delete the sentence. I don't think it adds anything. 3.4 - Put the "TBD" in there so that the RFC Editor can update. 4 - Put a note to the RFC Editor here to update sections 3.1.4 and 3.4 with the error number. That will make sure it gets updated properly. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04
Sorry for not replying sooner: Check with the WG chair and the AD. My comments are to be treated like anyone else in the WG or during Last Call who made comments on the document. pr On 20 Apr 2016, at 13:49, Sriram, Kotikalapudi (Fed) wrote: Pete, I am working on the revision. When I am done making the changes, should I upload a new version using the IETF submission tool or should I simply email the .txt or .xml only to you/Gen-art team? Thanks. Sriram -Original Message- From: Sriram, Kotikalapudi (Fed) Sent: Wednesday, March 30, 2016 6:02 PM To: Pete Resnick <presn...@qti.qualcomm.com>; General Area Review Team <gen-art@ietf.org> Subject: RE: Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04 Pete, Thank you for your review and comments. I'll be happy to incorporate all the changes you've suggested. I've been a bit swamped. What is a reasonable turnaround time for these? OK if I get this done within the next week or two? When I am done making the changes, should I upload a version -05 or should I email the .txt or .xml only to you/Gen-art team? Sriram --- From: Pete Resnick [mailto:presn...@qti.qualcomm.com] Sent: Monday, March 21, 2016 12:28 PM To: General Area Review Team <gen-art@ietf.org>; a...@ietf.org; draft-ietf-grow-route-leak-problem-definition@ietf.org; IETF discussion list <i...@ietf.org> Subject: Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04 I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Document: draft-ietf-grow-route-leak-problem-definition-04 Reviewer: Pete Resnick Review Date: 2016-03-21 IETF LC End Date: 2016-03-28 Summary: This draft is on the right track but has open issues, described in this review. Major issues: None. Minor issues: * Figure 1, along with the discussion of it in section 3, was confusing to me. First of all, am I correct that the example displays two leaks? That is, there's the leak from AS3 to ISP2, and then there are the propagated leaks from ISP2 to the rest of the world. Also, "(P)" seems to be used as both a leaked prefix (from ISP1 through AS3 to ISP2 and then propagated from there) as well as what looks to be a normal prefix update between ISP1 and ISP2. Are all of the occurrences of "(P)" in Figure 1 identical? Or is the prefix update between ISP1 and ISP2 also a leak? What leaks is Figure 1 intended to show? * In 3.1: "The leak often succeeds because...". Do you really means "succeeds" and not "occurs"? If so, what does "succeeds" mean in this context? * The description in section 3.5, starting from "However", really needs a complete rewrite. It's ungrammatical to the point that I'm not really sure I understand what it is trying to say. Nits/editorial comments: * I've mentioned before that I find the "academic research paper" style a bit jarring in IETF documents. I particularly don't like the use of "we" and "us", since it's not clear whether "we" is the authors (which is how it's used in academic papers, but is inappropriate for an IETF document), the WG, the IETF, etc. Instead, I would replace all instances of "we" with "this document", or simply re-word into the passive, since a subject is rarely needed for these sentences. For example, the abstract could be rewritten as such: A systemic vulnerability of the Border Gateway Protocol routing system, known as 'route leaks', has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled "route leaks", but to date a common definition of the term has been lacking. This document provides a working definition of route leaks, keeping in mind the real occurrences that have received significant attention. Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to Internet user community as well as the network operator community. Please do similar edits throughout. Similarly, the referencing of authors by name seems like bad form for an IETF document. OLD This document builds on and extends earlier work in the IETF by Dickson [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route- leak-reqts]. NEW This document builds on and extends earlier work in the IETF [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route-leak- reqts]. END OLD Mauch [Mauch] o
[Gen-art] Gen-ART LC review of draft-ietf-ospf-sbfd-discriminator-04
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-ospf-sbfd-discriminator-04 Reviewer: Pete Resnick Review Date: 2016-04-18 IETF LC End Date: 2016-04-26 IESG Telechat date: 2016-05-05 Summary: This draft is ready for publication as a Proposed Standard RFC. Major issues: None Minor issues: None Nits/editorial comments: Two clarifications, one typo: 2.1: OLD Type - S-BFD Discriminator TLV Type NEW Type - S-BFD Discriminator TLV Type (TBD [to be filled in by IANA]) END OLD Length - Total length of the discriminator (Value field) in octets, not including the optional padding. The Length is a multiple of 4 octets, and consequently specifies how many Discriminators are included in the TLV. NEW Length - Total length of the discriminator(s) that appear in the Value field, in octets. Each discriminator is 4 octets, so the Length is 4 times the number of Discriminators included in the TLV. There is no optional padding for this field. END 2.2: OLD Note that the S-BFD session may be required to pan multiple areas NEW Note that the S-BFD session may be required to span multiple areas END -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Last Call review of draft-bradner-rfc3979bis-08
On 29 Mar 2016, at 20:57, Brian E Carpenter wrote: > I see your point, though. Would you buy something like this? > > "...see [RFC6701] for details of the sanctions defined in > various existing Best Current Practice documents". Sure, no objection to that if it makes you more comfortable. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Last Call review of draft-bradner-rfc3979bis-08
On 26 Mar 2016, at 15:28, Brian E Carpenter wrote: 6. Failure to Disclose This paragraph has been over-pruned; it now makes no sense: In addition to any remedies the IESG may consider other actions. See [RFC6701] for details. Do you mean: In addition to any remedies available outside the IETF, the IESG may consider other actions. See [RFC6701] for details. I think that's fine, but it needn't even refer to the IESG: In addition to any remedies available outside the IETF, actions may be taken inside the IETF to address violations of IPR disclosure policies; see [RFC6701] for details. 6701 points out that actions can be taken by chairs, ADs, the IESG, or the IETF as a whole. But I'm fine with either of the above. I'm made a little nervous by the fact that RFC 6701 is Informational, and the text you have removed would give the IESG specific authority (by BCP) to impose penalties. So I think you have actually pruned too much. I would prefer that authority to be included, so maybe: I strongly disagree. Quoting 6701: This document discusses these issues and provides a suite of potential actions that can be taken within the IETF community in cases related to patents. All of these sanctions are currently available in IETF processes, and at least two instances of violation of the IPR policy have been handled using some of the sanctions listed. 6701 didn't change the sanctions available to the IETF, and this document doesn't and shouldn't either. So I disagree that this should to be added to this document. And on the specific suggestion: In addition to any remedies available outside the IETF, the IESG may, when it in good faith concludes that such a violation has occurred, impose penalties including, but not limited to, suspending the posting/participation rights of the offending individual, suspending the posting/participation rights of other individuals employed by the same company as the offending individual, amending, withdrawing or superseding the relevant IETF Documents, and publicly announcing the facts surrounding such violation, including the name of the offending individual and his or her employer or sponsor. See [RFC6701] for details. Part of what I didn't like about the -06 version was that it, like you did in the above, only pointed out the most harsh sanctions discussed in 6701, implying that those are the ones that should be used and not the others. A perfectly reasonable sanction, in some cases, is: a. A private discussion between the working group chair or area director and the individual to understand what went wrong and how it can be prevented in the future. Please, leave it short, with either the short correction at the top from either Brian or myself. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-grow-route-leak-problem-definition-04 Reviewer: Pete Resnick Review Date: 2016-03-21 IETF LC End Date: 2016-03-28 Summary: This draft is on the right track but has open issues, described in this review. Major issues: None. Minor issues: - Figure 1, along with the discussion of it in section 3, was confusing to me. First of all, am I correct that the example displays *two* leaks? That is, there's the leak from AS3 to ISP2, and then there are the propagated leaks from ISP2 to the rest of the world. Also, "(P)" seems to be used as both a leaked prefix (from ISP1 through AS3 to ISP2 and then propagated from there) as well as what looks to be a normal prefix update between ISP1 and ISP2. Are all of the occurrences of "(P)" in Figure 1 identical? Or is the prefix update between ISP1 and ISP2 also a leak? What leaks is Figure 1 intended to show? - In 3.1: "The leak often succeeds because...". Do you really means "succeeds" and not "occurs"? If so, what does "succeeds" mean in this context? - The description in section 3.5, starting from "However", really needs a complete rewrite. It's ungrammatical to the point that I'm not really sure I understand what it is trying to say. Nits/editorial comments: - I've mentioned before that I find the "academic research paper" style a bit jarring in IETF documents. I particularly don't like the use of "we" and "us", since it's not clear whether "we" is the authors (which is how it's used in academic papers, but is inappropriate for an IETF document), the WG, the IETF, etc. Instead, I would replace all instances of "we" with "this document", or simply re-word into the passive, since a subject is rarely needed for these sentences. For example, the abstract could be rewritten as such: A systemic vulnerability of the Border Gateway Protocol routing system, known as 'route leaks', has received significant attention in recent years. Frequent incidents that result in significant disruptions to Internet routing are labeled "route leaks", but to date a common definition of the term has been lacking. This document provides a working definition of route leaks, keeping in mind the real occurrences that have received significant attention. Further, this document attempts to enumerate (though not exhaustively) different types of route leaks based on observed events on the Internet. The aim is to provide a taxonomy that covers several forms of route leaks that have been observed and are of concern to Internet user community as well as the network operator community. Please do similar edits throughout. Similarly, the referencing of authors by name seems like bad form for an IETF document. OLD This document builds on and extends earlier work in the IETF by Dickson [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route- leak-reqts]. NEW This document builds on and extends earlier work in the IETF [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route-leak- reqts]. END OLD Mauch [Mauch] observes that these are anomalies and potentially route leaks because very large ISPs such as ATT, Sprint, Verizon, and Globalcrossing do not in general buy transit services from each other. However, he also notes that there are exceptions when one very large ISP does indeed buy transit from another very large ISP, and accordingly exceptions are made in his detection algorithm for known cases. NEW [Mauch] observes that these are anomalies and potentially route leaks because very large ISPs such as ATT, Sprint, Verizon, and Globalcrossing do not in general buy transit services from each other. However, it also notes that there are exceptions when one very large ISP does indeed buy transit from another very large ISP, and accordingly exceptions are made in its detection algorithm for known cases. END - Last paragraph in section 2: I'm left wondering what sorts of things that other folks might consider leaks *aren't* covered by the definition. Perhaps you want to mention that? - In 3.6, when you say "more specifics", are you using that as a noun to mean "more specific prefixes"? It's very hard to read in its current form. - Section 5 is superfluous. I'd delete it. - On a side note, I must say that the writing style of the &quo
Re: [Gen-art] [aqm] Gen-ART LC review: draft-ietf-aqm-fq-implementation-02
You missed the Zhang reference in 2.2.5. Otherwise fine. pr On 22 Oct 2015, at 11:45, Fred Baker (fred) wrote: See attached. Sorry for the oversight. On Oct 22, 2015, at 12:09 PM, Pete Resnick <presn...@qti.qualcomm.com> wrote: All of the changes you made look fine. You changed the reference to Brisoce, but didn't change McKenny, Shreedar, or Zhang. I still think you should. You missed the nit in section 4, paragraph 2 (s/a mark/mark). There's still no explanation of why this is likely to be a useful document in the future (which may be more for the shepherd writeup than for the document itself, and given that the IESG is already doing their work, may be moot). pr On 22 Oct 2015, at 10:47, Fred Baker (fred) wrote: Thanks Pete. I had updated the draft on October 12 in response to working group comments, so the diff I'm sending is against -02 (which you reviewed) and includes those changes. I have attached a -04 version, which I plan to post when the repository opens. If you have other comments or are not satisfied with the changes, it still has room to change. On Oct 6, 2015, at 6:06 PM, Pete Resnick presn...@qti.qualcomm.com <mailto:presn...@qti.qualcomm.com> wrote: I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-aqm-fq-implementation-02 Reviewer: Pete Resnick Review Date: 2015-10-6 IETF LC End Date: 2015-10-15 IESG Telechat date: 2015-10-22 Summary: This document is in fine shape and is generally ready for publication (caveat some minor things below); no major issues at all. One overall question though: Neither the document nor the shepherd writeup explain why this document will be useful for future work. It may very well be (I'm no expert in the area), but it's at least not obvious to me that it is. You've already pulled the lever to start an IETF-wide Last Call, but before it goes to the IESG for them to work on, perhaps it would be good to say why the WG thinks this is useful as a permanent publication in the RFC series as against just a working reference document for the WG. Is some future WG likely to want to refer to this document when doing queue management work? Presuming it is desirable to publish, here are the remainder of my comments. Some of them are right on the line between "minor issue" and "editorial" (they're editorial, but did cause some confusion for me), so I just grouped them all together here. Minor issues and nits/editorial comments: In 2.1.3, calling out any author by name is a bit weird in an IETF document, but in this case the reference is to RFC 7141, an IETF BCP. While I know Bob's a smart guy and I'm sure he contributed substantially to that document, I don't think calling out a just one author of an IETF consensus document is appropriate. (I think it's stylistically a little weird to use author names in general in IETF documents, but at least in two of the other cases, it's a single author of a non-IETF document; calling out Shreedhar and not Varghese is still weird to me, though I understand it is common practice in academic literature. If it were me, I'd reference the title, not the author. That said, you're going to have to fight it out with the RFC Editor regarding whether those URLs are "stable references".) In 2.2, second sentence: The algorithm isn't empty or not empty, the queue is empty or not empty. This had me really confused for a bit. Please fix the sentence. In 2.2.1ff: Instead of "a method, called 'enqueue'", say "an enqueue method". Personally, I'd prefer "function" or "operation" instead of "method" throughout, but that's your choice really. (Using "a method, called 'enqueue'" implies an actual implementation in a particular kind of programming language.) Whichever terminology you choose, pick one and stick to it throughout the document. Right now you switch. (Obviously the same comment for "a method, called 'dequeue'".) In 2.2.2 and 2.2.3, each in the 3rd paragraph, the verb "removes" does not have a subject. I think you need to say "the dequeue function" somewhere in each sentence. In 2.2.2, your reference to using a hash as a classifier threw me. I figured out what you meant, but it was an unfamiliar concept to me. But I'm also not sure why it's useful to call out a particular kind of classifier in the first place. I'd think it would be better to
Re: [Gen-art] Gen-ART LC review: draft-ietf-aqm-fq-implementation-02
All of the changes you made look fine. You changed the reference to Brisoce, but didn't change McKenny, Shreedar, or Zhang. I still think you should. You missed the nit in section 4, paragraph 2 (s/a mark/mark). There's still no explanation of why this is likely to be a useful document in the future (which may be more for the shepherd writeup than for the document itself, and given that the IESG is already doing their work, may be moot). pr On 22 Oct 2015, at 10:47, Fred Baker (fred) wrote: Thanks Pete. I had updated the draft on October 12 in response to working group comments, so the diff I'm sending is against -02 (which you reviewed) and includes those changes. I have attached a -04 version, which I plan to post when the repository opens. If you have other comments or are not satisfied with the changes, it still has room to change. On Oct 6, 2015, at 6:06 PM, Pete Resnick <presn...@qti.qualcomm.com> wrote: I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-aqm-fq-implementation-02 Reviewer: Pete Resnick Review Date: 2015-10-6 IETF LC End Date: 2015-10-15 IESG Telechat date: 2015-10-22 Summary: This document is in fine shape and is generally ready for publication (caveat some minor things below); no major issues at all. One overall question though: Neither the document nor the shepherd writeup explain why this document will be useful for future work. It may very well be (I'm no expert in the area), but it's at least not obvious to me that it is. You've already pulled the lever to start an IETF-wide Last Call, but before it goes to the IESG for them to work on, perhaps it would be good to say why the WG thinks this is useful as a permanent publication in the RFC series as against just a working reference document for the WG. Is some future WG likely to want to refer to this document when doing queue management work? Presuming it is desirable to publish, here are the remainder of my comments. Some of them are right on the line between "minor issue" and "editorial" (they're editorial, but did cause some confusion for me), so I just grouped them all together here. Minor issues and nits/editorial comments: In 2.1.3, calling out any author by name is a bit weird in an IETF document, but in this case the reference is to RFC 7141, an IETF BCP. While I know Bob's a smart guy and I'm sure he contributed substantially to that document, I don't think calling out a just one author of an IETF consensus document is appropriate. (I think it's stylistically a little weird to use author names in general in IETF documents, but at least in two of the other cases, it's a single author of a non-IETF document; calling out Shreedhar and not Varghese is still weird to me, though I understand it is common practice in academic literature. If it were me, I'd reference the title, not the author. That said, you're going to have to fight it out with the RFC Editor regarding whether those URLs are "stable references".) In 2.2, second sentence: The algorithm isn't empty or not empty, the queue is empty or not empty. This had me really confused for a bit. Please fix the sentence. In 2.2.1ff: Instead of "a method, called 'enqueue'", say "an enqueue method". Personally, I'd prefer "function" or "operation" instead of "method" throughout, but that's your choice really. (Using "a method, called 'enqueue'" implies an actual implementation in a particular kind of programming language.) Whichever terminology you choose, pick one and stick to it throughout the document. Right now you switch. (Obviously the same comment for "a method, called 'dequeue'".) In 2.2.2 and 2.2.3, each in the 3rd paragraph, the verb "removes" does not have a subject. I think you need to say "the dequeue function" somewhere in each sentence. In 2.2.2, your reference to using a hash as a classifier threw me. I figured out what you meant, but it was an unfamiliar concept to me. But I'm also not sure why it's useful to call out a particular kind of classifier in the first place. I'd think it would be better to just describe generally how a classifier can be used to put data into different queues. (And shouldn't this be part of the enqueue paragraph? Are classifiers used to dequeue?) In 2.2.4, last paragraph: WRR is not defined. Did you mean DRR? In 4, paragraph 2, s/a mark/mark I hope that's helpful. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies,
[Gen-art] Gen-ART LC review: draft-ietf-aqm-fq-implementation-02
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-aqm-fq-implementation-02 Reviewer: Pete Resnick Review Date: 2015-10-6 IETF LC End Date: 2015-10-15 IESG Telechat date: 2015-10-22 Summary: This document is in fine shape and is generally ready for publication (caveat some minor things below); no major issues at all. One overall question though: Neither the document nor the shepherd writeup explain why this document will be useful for future work. It may very well be (I'm no expert in the area), but it's at least not obvious to me that it is. You've already pulled the lever to start an IETF-wide Last Call, but before it goes to the IESG for them to work on, perhaps it would be good to say why the WG thinks this is useful as a permanent publication in the RFC series as against just a working reference document for the WG. Is some future WG likely to want to refer to this document when doing queue management work? Presuming it is desirable to publish, here are the remainder of my comments. Some of them are right on the line between "minor issue" and "editorial" (they're editorial, but did cause some confusion for me), so I just grouped them all together here. Minor issues and nits/editorial comments: In 2.1.3, calling out any author by name is a bit weird in an IETF document, but in this case the reference is to RFC 7141, an IETF BCP. While I know Bob's a smart guy and I'm sure he contributed substantially to that document, I don't think calling out a just one author of an IETF consensus document is appropriate. (I think it's stylistically a little weird to use author names in general in IETF documents, but at least in two of the other cases, it's a single author of a non-IETF document; calling out Shreedhar and not Varghese is still weird to me, though I understand it is common practice in academic literature. If it were me, I'd reference the title, not the author. That said, you're going to have to fight it out with the RFC Editor regarding whether those URLs are "stable references".) In 2.2, second sentence: The *algorithm* isn't empty or not empty, the *queue* is empty or not empty. This had me really confused for a bit. Please fix the sentence. In 2.2.1ff: Instead of "a method, called 'enqueue'", say "an enqueue method". Personally, I'd prefer "function" or "operation" instead of "method" throughout, but that's your choice really. (Using "a method, called 'enqueue'" implies an actual implementation in a particular kind of programming language.) Whichever terminology you choose, pick one and stick to it throughout the document. Right now you switch. (Obviously the same comment for "a method, called 'dequeue'".) In 2.2.2 and 2.2.3, each in the 3rd paragraph, the verb "removes" does not have a subject. I think you need to say "the dequeue function" somewhere in each sentence. In 2.2.2, your reference to using a hash as a classifier threw me. I figured out what you meant, but it was an unfamiliar concept to me. But I'm also not sure why it's useful to call out a particular kind of classifier in the first place. I'd think it would be better to just describe generally how a classifier can be used to put data into different queues. (And shouldn't this be part of the enqueue paragraph? Are classifiers used to dequeue?) In 2.2.4, last paragraph: WRR is not defined. Did you mean DRR? In 4, paragraph 2, s/a mark/mark I hope that's helpful. pr -- Pete Resnick <http://www.qualcomm.com/~presnick/> Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09
On 12/5/14 4:38 PM, Barry Leiba wrote: Hi, David. One note on your review: idnits didn't like the reference to RFC 20 for ASCII: ** Downref: Normative reference to an Unknown state RFC: RFC 20 RFC 5234 (ABNF) uses this, which looks like a better reference: [US-ASCII] American National Standards Institute, Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4, 1986. Except that (1) many IETF documents do use RFC 20 and (2) the RFC 20 reference is not for ASCII: it's for RS, the Record Separator character, which is explained in RFC 20, Section 5.2. And as per BCP97, RFC 3967, section 3, this downref was specifically called out in the Last Call for this document. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-art telechat review: draft-mcdonald-ipps-uri-scheme-17
On 12/2/14 11:20 AM, Barry Leiba wrote: When you suggest saying more, are you suggesting saying more in the document? I mostly meant the writeup - I expect there will be IESG folks with the same questions I had. I can do that, sure. This document updates: ... c) IEEE-ISTO PWG IPP Version 2.0 Second Edition [PWG5100.12], by extending section 4 'IPP Standards' and section 10 'Security Considerations'. This RFC-to-be is updating an IEEE-ISTO PWG document, and that seems exceptional enough to warrant mention about how the organizations are coordinating that update. I'd think that's for PWG to address on their side, no? If they accept that they can have an IETF RFC formally updating one of their documents, that's their process, not ours, no? This is to be an IETF document. If the PWG wants to say in one of their documents that PWG5100.12 is updated by this IETF document, that's their business. But *we* can't say in *our* document that we're updating their document. If you need a note, it could say: Note: IEEE-ISTO PWG has indicated that they intend to use this document as an update to their IPP Version 2.0 Second Edition [PWG5100.12], by extending section 4 'IPP Standards' and section 10 'Security Considerations'. But (c) should go. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Jcardcal] Genart LC review: draft-ietf-jcardcal-jcal-09
On 3/20/14 5:20 PM, Robert Sparks wrote: (This may be more than a nit): In the ABNF in section 3.6.5, where is the implementer supposed to go to find the definition of 'zone'? (Or the other production names?) I think _this_ chunk of ABNF (as opposed to that compiled in the appendix) is intended to be normative, yes? FWIW, it's not reflected in Appendix B. Indeed, there are some shortcomings here. For the year/month/day/hour/minute/second production names I can add an explicit reference to ISO.8601.2004 Section 2.2. The zone designator is only marginally mentioned in ISO.8601.2004 Section 4.3.2. The exact date format is not reflected in Appendix B because the Appendix does not intend to capture the structure of each different property type. As the two jcardcal drafts are my first rfc documents, I am not quite sure when its a good idea to make the ABNF normative. I could probably declare it informative by virtue of the reference to ISO 8601 and RFC5545. The ABNF was added in draft 08, in alignment with the changes we've made in jcard (rfc7095). There was a lot of discussion on the jcardcal list on the date formats and it became clear that the specific variations of ISO 8601 2001 and 2004 used in iCalendar and vCard make it hard to grasp. By explicitly mentioning the date format I wanted to counteract. I'd appreciate some feedback on how to further handle this issue. Please work with your AD on this one. It's a little detail, not a big problem, but we do need to be clear about what the grammar actually is. HmmI wonder why neither RFC 5545 nor this document reference RFC 3339 instead of ISO 8601? That would get you all of the ABNF you need. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Review of draft-resnick-on-consensus-05
On 10/11/13 11:27 AM, Russ Housley wrote: Major issues: Section 4 says: ... members of any given working group ... Working groups do not have members; they have participants. Please reword to avoid confusion on this point. Done. Minor issues: Section 4 says that humming should be the start of a conversation, not the end. However, it can be either. Using the document's example, the chair could ask, Hum now if you cannot live with choice A. Silence confirms that rough consensus has been reached. There was a line hidden in there about this, but I've clarified. Section 6 tells about some pitfalls to avoid, but the hum can still be a very valuable tool to help a chair determine if the group has reached consensus. It can be (and I've added some text along these lines), but it gets misused for these purposes all too often, which is a major theme of the document. Further, a hum in a BOF is different. As I said in my reply to Ted, I've made some attempt to address this, but also pointed out the downsides. Nits: In section 2, the document says ... not appealing to some others. When I read it the firs time, the RFC 2026 definition of appeal jumped into my mind. That is not the intent here. Maybe it is just me. Please consider rewording, especially since the RFC 2026 meaning is used in Section 3. I'll see if I can drum up a better synonym. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-repute-model-07
As per a suggestion in another thread: Would you also say that this draft is ready for publication as a Proposed Standard? This is more architectural overview than protocol per-se, but I do think it is necessary to the understanding of the other protocol documents (hence it is a normative reference), and I think it can progress with the rest. (I haven't seen an objection to doing so in the other Last Call thread, so unless there is a good reason not to, I'm inclined to re-initiate the Last Call for Proposed Standard instead.) pr On 8/21/13 8:27 AM, Roni Even 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 with any other Last Call comments you may receive. Document: draft-ietf-repute-model-07 Reviewer: Roni Even Review Date:2013--8--20 IETF LC End Date: 2013-8--29 IESG Telechat date: Summary: This draft is ready for publication as an Informational RFC. Major issues: Minor issues: I was wondering why the Further Discussion section 9.3 is part of the security section. I think it should be a separate section. Nits/editorial comments: Section 3 the end of 2^nd paragraph mechansisms to mechanisms -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
