[Gen-art] Genart last call review of draft-ietf-tls-external-psk-importer-05
Reviewer: Brian Carpenter
Review result: Ready with Issues
Gen-ART Last Call review of draft-ietf-tls-external-psk-importer-05
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-tls-external-psk-importer-05
Reviewer: Brian Carpenter
Review Date: 2020-10-07
IETF LC End Date: 2020-10-15
IESG Telechat date:
Summary: Ready with issues
Issues:
---
>1. Introduction
>
>Applications SHOULD provision separate PSKs for TLS 1.3 and prior
>versions when possible.
I think that "when possible" could easily be used as a loophole by a
lazy implementer. ("Impossible, because I'd have to refactor my code.")
Since presumably this rule is to avoid all risk of a "related output"
cryptanalytic vulnerability, why weaken the RFC2119 definition of SHOULD?
The formal definition of SHOULD is stronger, with "the full implications
must be understood and carefully weighed before choosing a different
course." So I suggest simply deleting "when possible".
>6. Incremental Deployment
>
> Recall that TLS 1.2 permits computing the TLS PRF with any hash
> algorithm and PSK. Thus, an EPSK may be used with the same KDF (and
> underlying HMAC hash algorithm) as TLS 1.3 with importers. However,
> critically, the derived PSK will not be the same since the importer
> differentiates the PSK via the identity and target KDF and protocol.
> Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS
> 1.2, and thereby avoid cross-protocol collisions. Note that this
> does not preclude endpoints from using non-imported PSKs for TLS 1.2.
> Indeed, this is necessary for incremental deployment.
I read this three times and I have to ask whether "TLS 1.2" is
really what you want in the penultimate line.
Nits:
-
>4.1. External PSK Diversification
...
> ImportedIdentity.target_protocol MUST be the (D)TLS protocol version
> for which the PSK is being imported. For example, TLS 1.3 [RFC8446]
> and QUICv1 [QUIC] use 0x0304.
As far as I can tell, [QUIC] doesn't specify this, but draft-ietf-quic-tls
does specify that QUICv1 uses TLS1.3. So the phrasing is a bit misleading.
Maybe:
For example, TLS 1.3 [RFC8446] uses 0x0304, which will therefore also be
used by QUICv1 [QUIC-TLS].
Are all the RFC2119 terms capitalised when required? For example, there
are lower case 'may' and 'must' in the last paragraph of section 4.1
(External PSK Diversification). I couldn't determine whether they were
intended to be normative.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-hardie-dispatch-rfc3405-update-03
Reviewer: Brian Carpenter Review result: Ready Gen-ART Last Call review of draft-hardie-dispatch-rfc3405-update-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-hardie-dispatch-rfc3405-update-03 Reviewer: Brian Carpenter Review Date: 2020-09-01 IETF LC End Date: 2020-09-24 IESG Telechat date: Summary: Ready (with micro-nit) Nits: - > 1. Introduction > >Part five of the Dynamic Delegation Discovery System (DDDS), RFC 3405 >[RFC3405], describes the registration procedures for assignments in >URI.ARPA. The document requires that registrations be in the "IETF >tree" of URI registrations. The use of URI scheme name trees was >defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395]. >Since the use of trees was discontinued, there is no way in the >current process set out in BCP 35 [RFC7595] to meet the requirement. This is indeed a nit, but I'd prefer s/the requirement/the above requirement/. The current text did make me briefly think "Which requirement?". ___ 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-mmusic-msrp-usage-data-channel-21
Reviewer: Brian Carpenter Review result: Ready with Nits Gen-ART Last Call review of draft-ietf-mmusic-msrp-usage-data-channel-21 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-mmusic-msrp-usage-data-channel-21 Reviewer: Brian Carpenter Review Date: 2020-07-13 IETF LC End Date: 2020-07-21 IESG Telechat date: Summary: Ready with nits Nits: - >> 4.1. MSRP URI >> transport /= "dc" I see that RFC7977 takes a slightly different approach to updating the ABNF: >> transport = "tcp" / "ws" / 1*ALPHANUM The advantage of listing out transport = "tcp" / "ws" / "dc" / 1*ALPHANUM would be that the reader sees the full list. >> ; Add "dc" to existing transports per [RFC4975] I suggest ; Add "dc" to existing transports per Section 9 of [RFC4975] >>4.6. Session Closing >> The SDP answerer must ensure that no dcmap or dcsa attributes are >> present in the SDP answer if no corresponding attributes are present >> in the received SDP offer. Should that be MUST? >> B2BUA Define the acronym please. >> 9.2. Subprotocol Identifier MSRP >> >> A reference to this document is added to the subprotocol identifier >> "msrp" in the "WebSocket Subprotocol Name Registry" s/this document/RFC/ >> 11. CHANGE LOG Mark this section for deletion by the RFC Editor ___ 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-snooping-yang-12
Reviewer: Brian Carpenter Review result: Ready Gen-ART Last Call review of draft-ietf-pim-igmp-mld-snooping-yang-12 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-pim-igmp-mld-snooping-yang-12 Reviewer: Brian Carpenter Review Date: 2020-06-07 IETF LC End Date: 2020-06-15 IESG Telechat date: Summary: Ready Comment: Since I am not a YANG expert, I did not check the YANG part. The text parts are very well written and I have no comments to make. ___ 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-capport-api-07
Reviewer: Brian Carpenter Review result: Ready with Nits https://www.ietf.org/id/draft-ietf-capport-api-07.html Gen-ART Last Call review of draft-ietf-capport-api-07 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-capport-api-07.html Reviewer: Brian Carpenter Review Date: 2020-05-04 IETF LC End Date: 2020-05-11 IESG Telechat date: Summary: Ready (almost...) Minor Issue: > If the client is captive (i.e. captive=true), > it can still be allowed enough access for it to perform server > authentication Section 4.1. What does "can" mean? MAY or perhaps SHOULD? Is this a local policy decision? Nit: > If the client is captive (i.e. captive=true), > it can still be allowed enough access for it to perform server > authentication Section 4.1. Missing parentheses around "Section 4.1"? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-git-using-github-05
Reviewer: Brian Carpenter Review result: Ready Gen-ART Telechat review of draft-ietf-git-using-github-05 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-git-using-github-05.txt Reviewer: Brian Carpenter Review Date: 2020-03-07 IETF LC End Date: 2020-03-03 IESG Telechat date: 2020-03-12 Summary: Ready Comments: - Thanks for dealing with my Last Call comments. ___ 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-git-using-github-04
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-git-using-github-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-git-using-github-04.txt Reviewer: Brian Carpenter Review Date: 2020-02-24 IETF LC End Date: 2020-03-03 IESG Telechat date: Summary: Ready with issue Comment: I've tracked this document since the -00 version and I think it is clear and represents WG consensus. Issues: --- Is this draft intended to become part of BCP25? I think it would be useful for the IESG to clarify this rather than leave it to the RFC Editor. Nit: > 3.4. Document Formats > > In addition to the canonical XML format [RFC7991], document editors > might choose to use a different input form for editing documents, > such as Markdown. Markdown-based formats are more accessible for new > contributors, though ultimately decisions about format is left to > document editors. s/is/are/ ___ 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-uta-tls-for-email-04
Reviewer: Brian Carpenter Review result: Ready with Nits Gen-ART Last Call review of draft-ietf-uta-tls-for-email-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-uta-tls-for-email-04.txt Reviewer: Brian Carpenter Review Date: 2020-01-25 IETF LC End Date: 2020-01-31 IESG Telechat date: Summary: Ready with nit Nit: > Abstract > > This specification updates current recommendation for... s/current/the current/ ___ 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-nsh-bgp-control-plane-12
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-bess-nsh-bgp-control-plane-12 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-bess-nsh-bgp-control-plane-12.txt Reviewer: Brian Carpenter Review Date: 2019-12-10 IETF LC End Date: 2019-12-13 IESG Telechat date: Summary: Ready with questions Comments: - I am not a BGP expert and did not check the BGP details. This is a pretty complex mechanism so I would have liked to hear of at least a lab-scale implementation. I wouldn't be shocked if this was diverted to Experimental. Minor issues: - Actually these are mainly questions: There are numerous references, starting in the Abstract, to the "Controller" but it isn't defined or described in any one place. I expected to find it in RFC8300, but no. So what is the Controller? RFC8300 requires NSH+original_packet to be encapsulated in a Transport Encapsulation. In section 2.1 we find: > Note that the presence of the NSH can make it difficult for nodes in > the underlay network to locate the fields in the original packet that > would normally be used to constrain equal cost multipath (ECMP) > forwarding. Therefore, it is recommended that the node prepending > the NSH also provide some form of entropy indicator that can be used > in the underlay network. How this indicator is generated and > supplied, and how an SFF generates a new entropy indicator when it > forwards a packet to the next SFF are out of scope of this document. I would have expected that text to state that the entropy indicator is a property of the Transport Encapsulation required by RFC8300. (Isn't the Service Function Overlay Network in fact the embodiment of the Transport Encapsulation?) In section 2.2 we find: > When choosing the next SFI in a path, the SFF uses the SPI and SI as > well as the SFT to choose among the SFIs, applying, for example, a > load balancing algorithm or direct knowledge of the underlay network > topology as described in Section 4. I'm probably missing something, but doesn't that risk a conflict with the statement above about the entropy indicator? How would this choice of path be guaranteed congruent with the choice of path by the underlay network? Or doesn't that matter? > 4.4. Classifier Operation > > As shown in Figure 1, the Classifier is a component that is used to > assign packets to an SFP. > > The Classifier is responsible for determining to which packet flow a > packet belongs (usually by inspecting the packet header),... Would it be better to state explicitly that the method of classification is out of scope for this document? There is a whole world of complexity in that "(usually...)". > 4.5. Service Function Forwarder Operation This section left me a bit puzzled. We've got the original packet, the classifier puts an NSH in front, we've got forwarding state, but we don't seem to have an IP header in front of the NSH to hand to the fowarding engine. Where's the Transport Encapsulation? Nits: - "such errors should be logged" ... "should log the event" "should either withdraw the SFPR or re-advertise it" Intentional lower case "should"? IDnits said: -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ___ 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-login-security-05
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-regext-login-security-05 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-regext-login-security-05.txt Reviewer: Brian Carpenter Review Date: 2019-11-03 IETF LC End Date: 2019-11-12 IESG Telechat date: Summary: Ready with minor issues Minor issues: - I found section 2 "Migrating to Newer Versions of This Extension" a little hard to follow. Firstly, am I correct in assuming that "a new version" means a version number higher than 1.0, e.g. "loginSec-1.1"? That is probably the intended meaning, but I think it needs to be explicit. Maybe state that this document defines "loginSec-1.0" and future documents can define other minor and major versions such as "loginSec-1.1" or "loginSec-2.0". Then "(for a temporary migration period)" is a bit vague. I think it would be useful to suggest the order of magnitude of the overlap period: days?, months?; hopefully not years. I also think a short discussion of adding & removing versions is needed in the Security Considerations, since the reason for a new version might be the discovery of a vulnerability in the current version. That's when a short migration period is desirable. FYI, there are some other extension design considerations in https://tools.ietf.org/html/rfc6709#section-4 . Nits: - "1. Introduction This document describes an Extensible Provisioning Protocol (EPP) extension for enhancing the security of the EPP login command in EPP RFC 5730. The enhancements include supporting longer passwords (or passphrases) than the 16-character maximum and providing a list of security events in the login response. The password (current and new) in EPP RFC 5730 can be overridden..." "RFC 5730" should either be in parenthesis as "(RFC 5730)" or a reference "[RFC5730]" (twice). ___ 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-data-ext-04
Reviewer: Brian Carpenter Review result: Ready with Nits Gen-ART Last Call & telechat review of draft-ietf-netmod-yang-data-ext-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 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-netmod-yang-data-ext-04.txt Reviewer: Brian Carpenter Review Date: 2019-10-20 IETF LC End Date: TBD IESG Telechat date: 2019-10-31 Summary: Ready with nits Comments: - This was accidentally put on the IESG agenda without an IETF Last Call, so this review serves both purposes. The draft seems very clear and I have no technical comments. Nits: - > Updates: 8340 (if approved) > Intended status: Standards Track RFC 8340 is a BCP, so can this really be Standards Track? Shouldn't it also be BCP, extending BCP 215? It's tricky, because it also effectively extends RFC 8040, which is Standards Track rather than BCP. Sadly it doesn't seem that a document can be both BCP and Standards Track. Also, this draft says: > The "yang-data" extension from [RFC8040] has been copied here, > renamed to "structure", and updated to be more flexible. That reads as if RFC 8040 is also updated, and it leaves the status of "yang-data" unclear. Is it now deprecated? Perhaps the sentence would be clearer like this: This document defines a new YANG extension statement called "structure", which is similar to but more flexible than the "yang-data" extension from [RFC8040]. ___ 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-serve-stale-07
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-dnsop-serve-stale-07 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-dnsop-serve-stale-07.txt Reviewer: Brian Carpenter Review Date: 2019-09-17 IETF LC End Date: 2019-09-25 IESG Telechat date: Summary: Ready with issue Major issues: - "(It [RFC2181] also has the curious suggestion that a value in the range 2147483648 to 4294967295 should be treated as zero.)" I don't see why that is "curious". That is the range of unsigned 32-bit integers that would be negative if treated as signed 32-bit integers. And in any case, the statement seems unfair to the authors of RFC2181, which actually says this: "It is hereby specified that a TTL value is an unsigned number, with a minimum value of 0, and a maximum value of 2147483647... this value shall be encoded in the less significant 31 bits..." It's not a "suggestion"; since the RFC does not use RFC2119 keywords, it's a requirement. It's unambiguous, and obviously motivated by resilience to coding errors around signed vs unsigned integers. That was a legitimate concern in 1997. As best as I can tell, in 1997 standard C did not include uint32; you needed to use unsigned long int and hope it was mapped to 32 bits. So the current draft overrides this choice made in RFC2181. Since that choice had an obvious (but unstated) motivation, how do we know that allowing TTLs above 2147483647 will not trigger long-standing coding bugs? There's an alarm bell later in the draft: "Regarding the TTL to set on stale records in the response, historically TTLs of zero seconds have been problematic for some implementations, and negative values can't effectively be communicated to existing software." You bet. If the TTL is specified as an unsigned 32 bit integer, and stored in a uint32, negative values are impossible. But if the coding is sloppy and used long int, "if ttl > 0" could go horribly wrong. Maybe it's all OK and there is no old resolver code out there with coding errors for values above 2147483647. Did the WG discuss this? I think the "curious suggestion" text above should be replaced by a brief discussion of why RFC2181 made the change that it did, and why it's now safe to reverse it. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-oauth-jwt-bcp-06
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-oauth-jwt-bcp-06 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-oauth-jwt-bcp-06.txt Reviewer: Brian Carpenter Review Date: 2019-06-14 IETF LC End Date: 2019-04-08 IESG Telechat date: 2019-06-27 Summary: Ready Comments: - Thank you for handling my Last Call comments. ___ 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-grow-wkc-behavior-03
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-grow-wkc-behavior-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-grow-wkc-behavior-03.txt Reviewer: Brian Carpenter Review Date: 2019-05-04 IETF LC End Date: 2019-05-13 IESG Telechat date: Summary: Ready, but... Minor issues: - This seems *much* more like a BCP than a standard. In both the Abstract and the 2nd paragraph of the Introduction, it might be helpful to add something like: This document recommends specific action items to limit future inconsistency. ___ 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-oauth-jwt-bcp-04
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-oauth-jwt-bcp-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-oauth-jwt-bcp-04.txt Reviewer: Brian Carpenter Review Date: 2019-03-31 IETF LC End Date: 2019-04-08 IESG Telechat date: Summary: Ready with (minor) issues Minor issues: - > 2.3. Multiplicity of JSON encodings > > Previous versions of the JSON format [RFC8259] allowed several > different character encodings: UTF-8, UTF-16 and UTF-32. This is not > the case anymore, with the latest standard only allowing UTF-8. > However older implementations may result in the JWT being > misinterpreted by its recipient. Why is that a security issue? > 3.6. Avoid Length-Dependent Encryption Inputs > ...It is > RECOMMENDED to avoid any compression of data before encryption since > such compression often reveals information about the plaintext. I'd like a citation for that, because it isn't intuitive. (And compression after encryption is pointless, of course.) > 3.10. Do Not Trust Received Claims Both the recommendations in this section seem imprecise. Maybe there should be some hints about the verification processes. ___ 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-nfsv4-mv1-msns-update-04
Reviewer: Brian Carpenter Review result: Ready Gen-ART Last Call review of draft-ietf-nfsv4-mv1-msns-update-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-nfsv4-mv1-msns-update-04.txt Reviewer: Brian Carpenter Review Date: 2019-02-26 IETF LC End Date: 2019-02-19 IESG Telechat date: 2019-03-07 Summary: Ready Comments: - I was assigned this review very late, so I have not had time to review any technical details. This document is a very major patch to be applied to RFC5661. It is apparently very carefully written with full details of which text in 5661 is changed, but even checking that aspect for correctness would be a major task, which I did not attempt. To be precise, it's a 106 page patch to a 617 page document. I assume that the WG made a conscious decision to do this rather than attempt RFC5661bis. I was a little disappointed not to see an Implementation Status section per BCP205. The writeup says "This document was a result of implementation and deployment experience" but it would increase this reviewer's confidence level if there were a few more details. ___ 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-tsvwg-le-phb-08
Reviewer: Brian Carpenter 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-tsvwg-le-phb-08 Reviewer: Brian Carpenter Review Date: 2019-02-01 IETF LC End Date: 2019-02-12 IESG Telechat date: Not scheduled for a telechat Summary: Ready Nits/editorial comments: Shepherd and AD, please note that this draft formally updates draft-ietf-tsvwg-rtcweb-qos, which is approved but waiting in the MISSREF state. That probably merits a note to the RFC Editor in due course. ___ 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-rfc8113bis-02
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-lisp-rfc8113bis-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 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-lisp-rfc8113bis-02.txt Reviewer: Brian Carpenter Review Date: 2019-01-18 IETF LC End Date: 2018-12-27 IESG Telechat date: 2019-01-24 Summary: Ready Comments: - Thank you for handling my Last Call comments. ___ 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-rfc8113bis-01
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01 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-rfc8113bis-01.txt Reviewer: Brian Carpenter Review Date: 2018-12-19 IETF LC End Date: 2018-12-27 IESG Telechat date: Summary: Ready with issues Comments: - I note that this is being raised from Experimental to the standards track. Presumably that depends on the base LISP spec becoming PS. Minor issues: - "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't explain which text is updated. This is in contrast to RFC8113, which explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't this draft claim to update rfc6830bis? I'm going to assume that is an error. In fact, why wasn't the definition of the LISP Packet Types registry moved into the base spec (rfc6830bis)? That is where it belongs. Since rfc6830bis (and rfc6833bis) are still under IESG review, anything in them that needs updating should be updated! The fact is that rfc8113bis extends rfc6830bis, which is not the same thing as "updates". If the WG thinks that implementers of 6830bis need to read 8113bis, there should be a normative reference in 6830bis to 8113bis. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-bess-mvpn-expl-track-12
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-bess-mvpn-expl-track-12 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-bess-mvpn-expl-track-12.txt Reviewer: Brian Carpenter Review Date: 2018-10-12 IETF LC End Date: 2018-10-09 IESG Telechat date: 2018-10-25 Summary: Ready Comments: - Thank you for handling my Last Call comments. ___ 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-mvpn-expl-track-10
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-bess-mvpn-expl-track-10 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-bess-mvpn-expl-track-10.txt Reviewer: Brian Carpenter Review Date: 2018-10-02 IETF LC End Date: 2018-10-09 IESG Telechat date: Summary: Ready with issues Comments: - I agree with the point raised in the Routing Area review (be explicit about the updated sections of RFC 6514, 6625, and 7524). Minor issues: - As I understand it, if a network only partially supports the new (LIR-pF) flag, it doesn't work properly. So we find at the end of section 2: the ingress node can conclude that the egress node originating that Leaf A-D route does not support the LIR-pF flag. The software at the ingress node SHOULD detect this, and should have a way of alerting the operator that the deployment is not properly configured. I don't see why this is only a SHOULD, and I don't see why the operator alert is not a MUST too. Surely the operator always needs to be alerted? ___ 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-softwire-mesh-multicast-22
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-softwire-mesh-multicast-22 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-softwire-mesh-multicast-22.txt Reviewer: Brian Carpenter Review Date: 2018-08-27 IETF LC End Date: 2018-09-06 IESG Telechat date: Summary: Ready with issues Comments: - "One of the authors (Shu Yang) stated that the Bitway company (a networking device company in China) have implemented a prototype." Note that the -00 draft was published in 2011. Not exactly fast progress in the market. Issues: --- "7.3. Fragmentation The encapsulation performed by an upstream AFBR will increase the size of packets. As a result, the outgoing I-IP link MTU may not accommodate the larger packet size. As it is not always possible for core operators to increase the MTU of every link. Fragmentation after encapsulation and reassembling of encapsulated packets MUST be supported by AFBRs [RFC5565]." This is troublesome. Firstly, a nit: the 3rd sentence is not a sentence. But more seriously, if I-IP is IPv6, how does the originator of the IPv6 packet (the AFBR) know that it needs to include a fragment header? Is there some kind of hidden PMTUD process, or is this configured? (I assume we are not so interested in the case that I-IP is IPv4, but then the issue is that the AFBR MUST NOT set the DF bit.) The reference [RFC5565] doesn't help at all, because it just says the MTU SHOULD be big enough to avoid fragmentation. "9. Softwire Mesh Multicast Encapsulation Softwire mesh multicast encapsulation does not require the use of any one particular encapsulation mechanism. Rather, it MUST accommodate a variety of different encapsulation mechanisms, and allow the use of encapsulation mechanisms mentioned in [RFC4925]. Additionally, all of the AFBRs attached to the I-IP network MUST implement the same encapsulation mechanism." It isn't clear how this is achieved. Presumably it needs to be configured in each AFBR? An operator needs to manage this somehow or other. Nits: - "(S,G) state" is a term of art that is not defined here, or in the reference [RFC7899]. I think there should be a reference to [RFC7761] where "(S,G) state" is first used; or define it in the Terminology section. ___ 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-ov-clarify-03
Reviewer: Brian Carpenter Review result: Ready with Nits Gen-ART Last Call review of draft-ietf-sidrops-ov-clarify-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-sidrops-ov-clarify-03.txt Reviewer: Brian Carpenter Review Date: 2018-07-31 IETF LC End Date: 2018-08-10 IESG Telechat date: Summary: Ready Comments: Clear & easy to understand - Nits: - Title would be more searchworthy if it read "BGP-4 Origin Validation Clarifications" Abstract: s/\"/./ ___ 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-pals-ethernet-cw-06
Reviewer: Brian Carpenter Review result: Ready with Nits Gen-ART Last Call review of draft-ietf-pals-ethernet-cw-06 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-pals-ethernet-cw-06.txt Reviewer: Brian Carpenter Review Date: 2018-06-12 IETF LC End Date: 2018-06-15 IESG Telechat date: 2018-06-21 Summary: Ready with nits Comments: - This (with RFC4928) is a wonderful example of why layer violations are a Bad Thing. Nits: - > 1. Introduction > This document recommends the use of the Ethernet pseudowire control > word in all but exceptional circumstances. That's wrong, it *mandates* this usage with a MUST (first paragraph of section 4). > 3. Background > A recent posting on the Nanog email list has highlighted this > problem: > > https://mailman.nanog.org/pipermail/nanog/2016-December/089395.html No, it's no longer recent. How about: For example, a posting on the Nanog email list highlighted this problem: > 7. Operational Considerations > > CW presence on the PW is controlled by the configuration and may be > subject to default operational mode of not being enabled. That sentence is hard to parse. Try this: A configuration switch might determine whether the CW is used on the PW. The default configuration might be to disable use of the CW. ___ 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-specialuse-important-03
Reviewer: Brian Carpenter Review result: Ready Gen-ART Last Call review of draft-ietf-extra-specialuse-important-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-extra-specialuse-important-03.txt Reviewer: Brian Carpenter Review Date: 2018-05-13 IETF LC End Date: 2018-05-14 IESG Telechat date: 2018-06-07 Summary: Ready Comments: Thanks for making the reviewer's life so easy. - Nits: - I wonder whether the special characters in the title will break some bibliographic software. Both $ and \ can have unexpected effects. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-stir-rph-03
Reviewer: Brian Carpenter Review result: Ready Gen-ART *Last Call* review of draft-ietf-stir-rph-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-stir-rph-03.txt Reviewer: Brian Carpenter Review Date: 2018-04-03 IETF LC End Date: 2018-04-06 IESG Telechat date: 2018-04-19 Summary: Ready Comments: - This is a well written draft and I have no technical comments. The draft says it extends RFC8225. Some people would say that needs an Updates: 8225 header. Nits: - 8.1. Normative References [I-D.ietf-stir-passport] Wendt, C. and J. Peterson, "Personal Assertion Token (PASSporT)", February 2017. Is now RFC8225. [I-D.ietf-stir-rfc4474bis] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", February 2017. Is now RFC8224. ___ 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-6tisch-6top-protocol-10
Reviewer: Brian Carpenter 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-6tisch-6top-protocol-10 Reviewer: Brian Carpenter Review Date: 2018-03-10 IETF LC End Date: 2018-03-26 IESG Telechat date: 2018-04-05 Summary: Ready Comment: Most of my previous comments have been fixed, thanks. I still disagree with the authors on one point, but not enough to delay the draft: In section 3.1.1 "2-step 6P Transaction" there seems to be a rare race condition if A's timeout expires while B's Response is in flight. This will be detected later as an inconsistency (section 3.4.6.2). The authors don't think it's necessary to mention this in 3.1.1. IMHO it would be useful to mention. (Similarly for section 3.1.2, 3-step transaction.) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-trill-multi-topology-05
Reviewer: Brian Carpenter Review result: Ready Gen-ART Last Call + Telechat review of draft-ietf-trill-multi-topology-05 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-trill-multi-topology-05.txt Reviewer: Brian Carpenter Review Date: 2018-03-02 IETF LC End Date: 2018-03-06 IESG Telechat date: 2018-03-08 Summary: Ready Comment: This is a rushed review for reasons outside my control. Also, only a TRILL expert could review it effectively. As far as I can tell, it's a well written document. This is a case where I wish RFC1264 still applied. I'm disappointed not to see an RFC 7942 Implementation Status section. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-6tisch-6top-protocol-09
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-6tisch-6top-protocol-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-6tisch-6top-protocol-09.txt Reviewer: Brian Carpenter Review Date: 2018-02-20 IETF LC End Date: 2018-??-?? IESG Telechat date: 2018-03-06 Summary: Ready with issues Comment: This is a Last Call review despite the subject field. When will the Last Call be started? Major issues: - In section 3.1.1 "2-step 6P Transaction" there seems to be a race condition if A's timeout expires while B's Response is in flight. Can the 6top layer prevent the L2 Ack being sent? (And similar race conditions seem to be possible in the 3-step transaction.) > 3.4.3. Concurrent 6P Transactions > > Only a single 6P Transaction between two neighbors, in a given > direction, can take place at the same time. That is, a node MUST NOT > issue a new 6P Request to a given neighbor before having received the > 6P Response for a previous request to that neighbor, except when the > previous 6P Transaction has timed out. If a node receives a 6P > Request from a given neighbor before having sent the 6P Response to > the previous 6P Request from that neighbor, it MUST send back a 6P > Response with a return code of RC_RESET (as per Figure 36). A node > receiving RC_RESET code MUST abort the transaction and consider it > never happened. It isn't clear to me whether the RC_RESET aborts the first, the second, or both transactions. Minor issues: - > 1. Introduction ... > 6P > allows a node to communicate with a neighbor to add/delete TSCH cells > to one another. This sentence is almost unintelligible because of the sequence to...to...to. Does it mean this?: 6P allows neighbours to add or delete TSCH cells in each other. > 3.4.1. Version Checking This may be a pointless worry, but is there a DOS attack of some kind by sending rubbish version numbers? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-nvo3-hpvr2nve-cp-req-15
Reviewer: Brian Carpenter 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-nvo3-hpvr2nve-cp-req-15 Reviewer: Brian Carpenter Review Date: 2018-02-12 IETF LC End Date: 2018-02-20 IESG Telechat date: 2018-02-22 Summary: Ready Comment: Thanks for handling my last call comment ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-nvo3-hpvr2nve-cp-req-13
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-pce-pcep-exp-codepoints-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-nvo3-hpvr2nve-cp-req-13.txt Reviewer: Brian Carpenter Review Date: 2018-02-07 IETF LC End Date: 2018-02-20 IESG Telechat date: 2018-02-22 Summary: Ready (with minor issue) Comment: This is a Last Call review despite the subject field. Minor issue: Req-10: The protocol MUST allow an End Device initiating a request to add, remove or update address(es) associated with a TSI instance on the external NVE. Addresses can be expressed in different formats, for example, MAC, IP or pair of IP and MAC. Here and elsewhere, it seems necessary to specify that an IP address can be in either IPv4 or IPv6 format. (This is implied in Table 1 and at the end of Appendix A, but that's quite well hidden.) I suggest clarifying this early, in Section 1.2 "Target Scenarios". ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-oauth-discovery-08
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-oauth-discovery-08 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-oauth-discovery-08.txt Reviewer: Brian Carpenter Review Date: 2017-12-29 IETF LC End Date: 2017-10-09 IESG Telechat date: 2018-01-25 Summary: Ready Comment: I'm happy with the changes since the -07 version. ___ 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-pcep-exp-codepoints-04
Reviewer: Brian Carpenter Review result: Ready Reviewer: Brian Carpenter Review Date: 2017-12-23 IETF LC End Date: 2017-12-28 IESG Telechat date: 2018-01-11 Summary: Ready Comment: fwiw, I agree with this: [RFC3692] asserts that the existence of experimental code points introduce no new security considerations. However, implementations accepting experimental codepoints need to take care in how they parse and process the messages, objects, and TLVs in case they come, accidentally, from another experiment. There are a few words in https://tools.ietf.org/html/rfc6709#section-5 that might also be relevant. An experimental code point is in effect a protocol extension with unknown security properties. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-spring-resiliency-use-cases-11
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-spring-resiliency-use-cases-11 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-spring-resiliency-use-cases-11.txt Reviewer: Brian Carpenter Review Date: 2017-11-11 IETF LC End Date: 2017-05-04 IESG Telechat date: 2017-12-14 Summary: Ready Comment: When I reviewed this for Last Call, I had two general concerns: 1) Is it useful to publish use cases now, at the end of protocol development? 2) The AD review dated 2017-04-20 pointed out that the document should be historically consistent. I'm going to assume that since the AD is bringing the draft to the IESG, he's now happy on these two points. Minor issue: I originally commented that Section 3 doesn't actually mention any specific requirements for Spring. In conversation with Stefano: >> Right, but you don't state any *requirements* for SPRING that result from >> this case, >> except the very general statement before section 3.1. Maybe that does >> translate >> into specific requirements, but I don't see how. > the generic requirement is the ability to instantiate source routed paths. > These source routed paths, in the framework of this draft, are for LFAs. I still think that Section 3 doesn't identify this requirement. Maybe it's obvious to one skilled in the art, however. So I'm going to say "Ready". ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-lime-yang-connectionless-oam-methods-09
Reviewer: Brian Carpenter
Review result: Ready with Issues
Gen-ART *Last Call* review of draft-ietf-lime-yang-connectionless-oam-methods-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-lime-yang-connectionless-oam-methods-09.txt
Reviewer: Brian Carpenter
Review Date: 2017-10-14
IETF LC End Date: 2017-10-25
IESG Telechat date: 2017-10-26
Summary: Ready with issues
Comment:
The shepherd says:
> This includes at least two different implementations of
> the model, as well as product and demos at Bits-n-Bytes.
Shouldn't WGs make routine use of BCP 205, RFC 7942 "Improving
Awareness of Running Code: The Implementation Status Section"?
Minor Issues:
-
In the following:
| +--ro min-delay-value? uint32
| +--ro max-delay-value? uint32
| +--ro average-delay-value? uint32
+--ro session-jitter-statistics
| +--ro time-resolution-value? identityref
| +--ro min-jitter-value?uint32
| +--ro max-jitter-value?uint32
| +--ro average-jitter-value?uint32
what are the units for the delay-value and jitter-value
elements, and what definition of 'jitter' is intended?
identity protocol-id-internet {
base protocol-id;
description
"Internet Protocols.";
}
It isn't clear what "Internet Protocols" means. It seems totally non-specific.
Nits:
-
identity protocol-id-propreitary {
base protocol-id;
description
"Propreitary protocol (eg.,IP SLA).";
s/propreitary/proprietary/
s/Propreitary/Proprietary/
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-grow-bgp-session-culling-05
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-grow-bgp-session-culling-05 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-grow-bgp-session-culling-05.txt Reviewer: Brian Carpenter Review Date: 2017-10-06 IETF LC End Date: 2017-09-25 IESG Telechat date: 2017-10-12 Summary: Ready Comment: Thanks for responding to my Last Call comments. (BTW, like many routing documents with an operational aspect, this assumes a lot of background knowledge. It needs careful reading.) ___ 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-oauth-discovery-07
Reviewer: Brian Carpenter Review result: Ready Gen-ART Last Call review of draft-ietf-oauth-discovery-07 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-oauth-discovery-07.txt Reviewer: Brian Carpenter Review Date: 2017-10-02 IETF LC End Date: 2017-10-09 IESG Telechat date: Summary: Ready Comment: As far as my competence goes, I have no issues with this draft. Just for fun, I checked that the JSON example works as the value of a GRASP objective (draft-ietf-anima-grasp) with the GRASP prototype code. And yes, of course it does, so we could map OAuth over the ANIMA discover/synchronize model if we wanted. FWIW there are a couple of errors in the shepherd's writeup: > This document does not request any actions by IANA. > > 18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find > useful in selecting the IANA Experts for these new registries. > > None. Wrong, there are extensive IANA considerations and a requirement for multiple Designated Experts. > There is no text in formal languages in the document. Maybe not, but there is a JSON example (which as noted above seems to be fine). -- ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-06
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-tsvwg-ecn-experimentation-06 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-tsvwg-ecn-experimentation-06.txt Reviewer: Brian Carpenter Review Date: 2017-09-25 IETF LC End Date: 2017-09-19 IESG Telechat date: 2017-09-28 Summary: Ready Comment: Thanks for handling my Last Call comments. ___ 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-grow-bgp-session-culling-04
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-grow-bgp-session-culling-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-bgp-session-culling-04.txt Reviewer: Brian Carpenter Review Date: 2017-09-19 IETF LC End Date: 2017-09-25 IESG Telechat date: Summary: Ready with issues Minor Issues: - > 3.1.1. Maintenance Considerations > > Initiators of the administrative shutdown could consider using > Graceful Shutdown [I-D.ietf-grow-bgp-gshut] to facilitate smooth > drainage of traffic prior to session tear down, and the Shutdown > Communication [I-D.ietf-idr-shutdown]... This strikes me as vague. "Could consider"? Surely if this is a BCP, they MUST use some mechanisms and perhaps SHOULD use these particular mechanisms. Otherwise the document doesn't specify anything much at all for this case. > 3.2. Involuntary BGP Session Teardown Recommendations ... > In the absence notifications from the lower layer (e.g. ethernet link > down) consistent with the planned maintenance activities in a > switched layer-2 fabric, the Caretaker of the fabric could choose to > cull BGP sessions on behalf of the Operators connected to the fabric. This seems incomplete. Firstly, I'm assuming that it should start "In the absence of notifications...". Secondly, if there are no fault indications, what causes the Caretaker to cull sessions? What's the trigger? Is the Caretaker supposed to know by magic that layer 2 maintenance is planned? ... > In this scenario, BGP Session Culling is accomplished through the > application of a combined layer-3 and layer-4 packet filter deployed > in the switched fabric itself. Please add "as described in the next sub-section" because otherwise the reader can easily be confused. > 3.2.1. Packet Filter Considerations > > The following considerations apply to the packet filter design: > > o The packet filter MUST only affect BGP traffic specific to the > layer-2 fabric, i.e. forming part of the control plane of the > system described, rather than multihop BGP traffic which merely > transits That's a goal, but it doesn't tell me how to achieve the goal. What packet signature tells me which packets are specific to the fabric? I suspect this might overlap with the last bullet - if so, you might consider re-ordering the bullets. ... > o The packet filter MUST affect all relevant Address Family > Identifiers Define "relevant". And in Appendix A, explain precisely how the example prefixes are used: what makes them relevant? Are they normally announced by BGP to all the IXP's BGP peers? -- ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-tsvwg-ecn-experimentation-05
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-tsvwg-ecn-experimentation-05 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-tsvwg-ecn-experimentation-05.txt Reviewer: Brian Carpenter Review Date: 2017-09-01 IETF LC End Date: 2017-09-14 IESG Telechat date: 2017-09-14 Summary: Ready with (minor) issues Comment: Very clear from the technical standpoint. Minor Issues: - > 3. ECN Nonce and RFC 3540 ... > o Updates RFC 3168 [RFC3168] to remove discussion of the ECN Nonce >and use of ECT(1) for that Nonce. The specific text updates are >omitted for brevity. I understand the desire for brevity, but this bothers me a bit. What is the reader to make of RFC3168 Section 20.2, for example? My feeling is that a short Appendix outlining the specific updates would be useful. There's already too much spaghetti to untangle. I see no reason why RFC3540 and RFC5622 need to be normative references (and therefore downrefs). They aren't required reading in order to understand this draft. -- ___ 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-rfc3107bis-02
Reviewer: Brian Carpenter Review result: Ready Gen-ART Last Call review of draft-ietf-mpls-rfc3107bis-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-mpls-rfc3107bis-02.txt Reviewer: Brian Carpenter Review Date: 2017-07-07 IETF LC End Date: 2017-07-12 IESG Telechat date: 2017-08-03 Summary: Ready Comment: This is a very clear document, even for somebody quite ignorant of the topic. Nits: - > This document also removes the unimplemented > "Advertising Multiple Routes to a Destination" feature,... I think it would be helpful if this said explicitly "as specified in section 4 of RFC3107". (Not a big deal, unless you have to edit the text for some other reason.) -- ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-trill-mtu-negotiation-06
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-trill-mtu-negotiation-06 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-trill-mtu-negotiation-06.txt Reviewer: Brian Carpenter Review Date: 2017-06-30 IETF LC End Date: 2017-06-28 IESG Telechat date: 2017-07-06 Summary: Ready Comment: Thanks for handling my Last Call comments. ___ 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-trill-mtu-negotiation-05
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-trill-mtu-negotiation-05 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-trill-mtu-negotiation-05.txt Reviewer: Brian Carpenter Review Date: 2017-06-24 IETF LC End Date: 2017-06-28 IESG Telechat date: 2017-07-06 Summary: Ready with issues Minor issues: - > 2. Link-Wide TRILL MTU Size ... > ...RBridges MUST support the Extended L1 Circuit-Scoped > (E-L1CS) flooding scope LSP (FS-LSP). They use that flooding to > exchange their maximally supportable value of "Lz". Where does that value come from? Is it configured, derived from the interface in some way, or discovered? > 2.1. Operations > > Lz is reported using a originatingSNPBufferSize TLV that MUST occur > in fragment zero of the RBridge's E-L1CS FS-LSP. An > originatingSNPBufferSize APPsub-TLV occurring in any other fragment > is ignored. Is that really what you mean? I thought Lz was an optional extra. So I think you mean: 2.1. Operations Lz MAY be reported using a originatingSNPBufferSize TLV that occurs in fragment zero of the RBridge's E-L1CS FS-LSP. An originatingSNPBufferSize APPsub-TLV occurring in any other fragment MUST be ignored. > 3. Link MTU Size Testing ... > Step 0: ... > b) Link MTU size is set to 1470, lowerBound is set to 1470, > upperBound is set to the link-wide Lz, linkMtuSize is set to > [(lowerBound + upperBound)/2] (Operation "[...]" returns the > fraction-rounded-up integer.). This is confusing. "linkMtuSize" was defined as a local variable. But what is "Link MTU size"? Is that another local variable? If so, how is it different from "linkMtuSize"? It is used again in part 2) of step 2 below. Also, I assume "Lz" is the value previously agreed among the nodes, but that should be made clear to the reader. Nits: - > 1. Introduction ... > topology. While in this document, a new RECOMMENDED link-wide minimum > inter-RBridge MTU size, Lz, is specified. By calculating a using Lz > as specified herein, link-scoped PDUs can be formatted greater than > the campus-wide Sz up to the link-wide minimum acceptable inter- > RBridge MTU size potentially improving the efficiency of link > utilization and speeding link state convergence. I cannot parse those two sentences. What does the "While" refer to? What does "By calculating a using Lz" mean? > 3. Link MTU Size Testing ... > b) Link MTU size is set to 1470, lowerBound is set to 1470, > upperBound is set to the link-wide Lz, linkMtuSize is set to > [(lowerBound + upperBound)/2] (Operation "[...]" returns the > fraction-rounded-up integer.). This would be easier to understand: 3. Link MTU Size Testing ... b) Link MTU size is set to 1470, lowerBound is set to 1470, upperBound is set to the link-wide Lz, linkMtuSize is set to [(lowerBound + upperBound)/2], rounded up to the nearest integer. Repeat this in the following two cases; a normal reader will not remember the rounding rule: ... 1) If RB1 fails to receive an MTU-ack from RB2 after k tries: upperBound is set to linkMtuSize and linkMtuSize is set to [(lowerBound + upperBound)/2], rounded up to the nearest integer. 2) If RB1 receives an MTU-ack to a probe of size linkMtuSize from RB2: link MTU size is set to linkMtuSize, lowerBound is set to linkMtuSize and linkMtuSize is set to [(lowerBound + upperBound)/2], rounded up to the nearest integer. -- ___ 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-pals-vpls-pim-snooping-05
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-pals-vpls-pim-snooping-05 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-pals-vpls-pim-snooping-05.txt Reviewer: Brian Carpenter Review Date: 2017-05-15 IETF LC End Date: 2017-05-19 IESG Telechat date: 2017-05-25 Summary: Ready with issues Comment: "This document isn't defining a new protocol, but rather methods to optimize the use of PIM-based multicast in a VPLS environment." [Shepherd's writeup] Also, the document uses RFC2119 terminology. So why not BCP? Major issue: > 2.11. Directly Connected Multicast Source ... > o The PE would have to do ARP snooping to determine if a source is > directly connected. What about IPv6? It may be sufficient to add Neighbor Discovery snooping, but you need to say something. Nits: - > 1. Introduction ... >o B. Replication on PWs on shared physical path. I realise this is declared out of scope a few lines later, but it's very "telegraphic" and hard to understand. I think you mean o B. Multicast traffic may be replicated when several PWs share a physical path. ... > While this document is in the context of VPLS, the procedures apply > to regular layer-2 switches interconnected by physical connections as > well, albeit this is outside of the scope of this document. In that > case, the PW related concept/procedures are not applicable and that's > all. That is rather unclear. How about: While this document is written in the context of VPLS, the procedures also apply to regular layer-2 switches interconnected by physical connections, except that the PW related concept and procedures do not apply in the case. > 2.2. General Rules for PIM Snooping in VPLS BPDU is used but not defined. > 2.2.1. Preserving Assert Trigger > > In PIM-SM/DM, there are scenarios where multiple routers could be > forwarding the same multicast traffic on a LAN. When this happens, > using PIM Assert election process by sending PIM Assert messages, > routers ensure that only the Assert winner forwards traffic on the > LAN. Either I have misunderstood the intention, or the second sentence is written half backwards. I *think* you mean In PIM-SM/DM, there are scenarios where multiple routers could be forwarding the same multicast traffic on a LAN. When this happens, these routers start the PIM Assert election process by sending PIM Assert messages, to ensure that only the Assert winner forwards future multicast traffic on the LAN. > 2.3.2. IPv6 What's so special about IPv6, or why isn't this section titled "IPv4"? Or better, stay neutral: 2.3.2. IP Versions > 2.3.3. PIM-SM (*,*,RP) > > This document does not address (*,*,RP) states in the VPLS network. > Although [PIM-SM] specifies that routers must support (*,*,RP) > states, there are very few implementations that actually support it > in actual deployments, and it is being removed from the PIM protocol > in its ongoing advancement process in IETF. Given that, this > document omits the specification relating to (*,*,RP) support. If I understand things correctly, you should say ... it has been removed from the PIM protocol [RFC7761]. > 2.4.3. When to Snoop and When to Proxy ... > Therefore, the general rule is that if Join Suppression is enabled on > CEs then proxying or relay MUST be used and if Suppression is known > to be disabled on all CEs then either snooping, relay, or proxying > MAY be used while snooping or relay SHOULD be used. I had to read this a few times. I think you mean Therefore, the general rule is that if Join Suppression is enabled on one or more CEs then proxying or relay MUST be used, but if Suppression is known to be disabled on all CEs then either snooping, relay, or proxying MAY be used while snooping or relay SHOULD be used. (as I understand it, even one CE with Join Suppression breaks snooping for the whole PE.) > 7. References As an RFC user, I find references like [IGMP-SNOOP] instead of [RFC4541] quite impractical. It wastes bits to use constructs like "RFC4541 [IGMP-SNOOP]", which the RFC Editor will change to "RFC 4541 [IGMP-SNOOP]". ___ 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-resiliency-use-cases-08
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-spring-resiliency-use-cases-08 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-spring-resiliency-use-cases-08.txt Reviewer: Brian Carpenter Review Date: 2017-05-01 IETF LC End Date: 2017-05-04 IESG Telechat date: Summary: Ready with issues Comment: I wonder about the value to the community of publishing use cases and requirements late in the standards process. They clearly have value while designing solutions, but do they really have archival value, since RFC7855 was published a year ago? (An alternative approach to use case documents is to structure them as example applications to validate the protocol design, but that would be a major rewrite.) Major issue: I agree with the AD review dated 2017-04-20; if we publish a use case document of this kind, it should be historically consistent. Minor issue: The text of section 3 doesn't explain what requirements for SPRING it generates. Really it just describes what any IGP will do anyway. How does that impact SPRING? If there is no impact, please say so! The other sections are quite clear on this aspect. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-httpbis-http2-encryption-10
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-httpbis-http2-encryption-10 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-httpbis-http2-encryption-10.txt Reviewer: Brian Carpenter Review Date: 2017-02-26 IETF LC End Date: 2017-03-06 IESG Telechat date: 2017-03-16 Summary: Ready with issues Comments: - Note: Category is Experimental. Quoting the writeup: 'The primary concern voiced by dissenters has been that widespread deployment might provide a false sense of security, slowing the adoption of "real" HTTPS or confusing users."' FWIW, I share that concern, even with the tag 'Experimental.' Major issue: The Abstract should definitely state the above concern. At the moment, it could easily mislead the reader about the value of the solution. I'd like to see the phrase "it is vulnerable to active attacks" in the Abstract. Minor issue: > 4.4. Confusion Regarding Request Scheme ... > Therefore, servers need to carefully examine the use of such signals > before deploying this specification. What does "servers" really mean here? I think it means "implementers of server code", or maybe "operators of servers"? Nits: - > 4.1. Security Indicators > > User Agents MUST NOT provide any special security indicia when an 'Indicia' is a real word, but I think it's unknown to at least 99% of English speakers. Why not 'indicators' again? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-mmusic-sctp-sdp-23
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-mmusic-sctp-sdp-23 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-mmusic-sctp-sdp-23.txt Reviewer: Brian Carpenter Review Date: 2017-02-11 IETF LC End Date: 2017-02-09 IESG Telechat date: 2017-02-16 Summary: Ready Comment: Thanks for handling my Last Call comments. Nit: Thanks for the IPv6 example. But RFC5952 recommends lower case as the canonical form: 2001:db8::a8fd ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-mmusic-sctp-sdp-22
Reviewer: Brian Carpenter Review result: Ready with Nits Gen-ART Last Call review of draft-ietf-mmusic-sctp-sdp-22 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-mmusic-sctp-sdp-22.txt Reviewer: Brian Carpenter Review Date: 2017-02-XX IETF LC End Date: 2017-02-09 IESG Telechat date: Summary: Ready with nits Comments: - Two points I noted in the writeup: "There are existing implementations of earlier versions of the document..." Excellent, but I wonder why we don't see Implementation Status sections under RFC 6982 in more Last Call drafts. "IPv6 address examples are not necessary since IP version differences are immaterial to the purpose of the specification." It's just as easy to give an IPv6 example though, and more future proof. Minor issue: (almost a nit) > 1. Introduction ... > NOTE: Due to the characteristics of TCP, usage of 'TCP/DTLS/SCTP' > will always force ordered and reliable delivery of the SCTP packets, > which limits the usage of the SCTP options. Therefore, it is > RECOMMENDED that TCP is only used in situations where UDP traffic is > blocked. Why would one choose 'TCP/DTLS/SCTP' rather than just 'TCP/TLS'? I don't object to it being specified, but since you don't support multihoming or multiple associations, what is the use case, in a few words? Nits: - > 4.4.2. SDP Media Description values > > m= line parameterparameter value(s) > -- > : "application" > : "UDP/DTLS/SCTP" or "TCP/DTLS/SCTP" > : UDP port number (for "UDP/DTLS/SCTP") > TCP port number (for ""UDP/DTLS/SCTP") I think the last line should be: TCP port number (for "TCP/DTLS/SCTP") There is some inconsistency in the use of quotation marks: "UDP/DTLS/SCTP" or 'UDP/DTLS/SCTP' ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-6tisch-minimal-19
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-6tisch-minimal-19 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-6tisch-minimal-19.txt Reviewer: Brian Carpenter Review Date: 2017-02-05 IETF LC End Date: 2016-12-20 IESG Telechat date: 2017-02-16 Summary: Ready Comment: Thanks for handling my Last Call comments. I have also reviewed the recent security-related updates. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-payload-melpe-05
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-ietf-payload-melpe-05 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-payload-melpe-05.txt Reviewer: Brian Carpenter Review Date: 2017-01-27 IETF LC End Date: 2017-01-13 IESG Telechat date: 2017-02-02 Summary: Ready Comment: Thanks for handling my Last Call comments. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-bradner-rfc3979bis-11
Reviewer: Brian Carpenter Review result: Ready with Nits Gen-ART Last CAll review of draft-bradner-rfc3979bis-11.txt 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-bradner-rfc3979bis-11.txt Reviewer: Brian Carpenter Review Date: 2017-01-26 IETF LC End Date: 2017-02-15 IESG Telechat date: Summary: Ready with nits Comment: I've been tracking this draft since the start and I'm very supportive of it. I have reviewed the changes since my previous review of -08, and I am happy them. I have made some comments on issues raised by other reviwers, but as one of them said perfection is impossible. Nits: > 7. Evaluating Alternative Technologies in IETF Working Groups ... > technology in violation if this principle if there is a very good s/if this principle/of this principle/ > 13. Changes Since RFC 3979 and RFC 4879 > 16. Changes Since RFC 3979 Should the preamble to these sections state that they are provided for informational purposes only and that in case of doubt the text of sections 1-12 prevails? Should these two sections be merged? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-mpls-tp-linear-protection-mib-11
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-mpls-tp-linear-protection-mib-11 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-mpls-tp-linear-protection-mib-11.txt Reviewer: Brian Carpenter Review Date: 2017-01-16 IETF LC End Date: 2017-01-26 IESG Telechat date: Summary: Ready with minor issues Comment: I have not reviewed most details of the MIB module itself. As usual, I trust the MIB Doctors. "We know of a handful of implementations (or intent to implement)." Good. It would have been nice to see an Implementation Status section under RFC 6982. Minor issues: - At the time of writing, Simple Network Management Protocol (SNMP) SET is no longer recommended as a way to configure MPLS networks as was described in RFC 3812 [RFC3812]. RFC3812 is explicit that it should be used for configuration: This MIB module should be used in conjunction with the companion document [RFC3813] for MPLS based traffic engineering configuration and management. RFC3812 has not been formally updated or obsoleted. Therefore, it seems to me that the present draft should formally update RFC3812 in this respect. Does the same issue apply to RFC3813, whose Abstract also states that it is used to configure an LSR? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-payload-melpe-04
Reviewer: Brian Carpenter Review result: Ready with Issues Gen-ART Last Call review of draft-ietf-6tisch-minimal-17 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-payload-melpe-04.txt Reviewer: Brian Carpenter Review Date: 2016-12-26 IETF LC End Date: 2017-01-13 IESG Telechat date: Summary: Ready with minor issues Major Issues: None - Minor issues: - > 3.1 MELPe Bitstream Definition > > The total number of bits used to describe one frame of 2400 bps > speech is 54, which fits in 7 octets (with two unused bits). For the > 1200 bps speech the total number of bits used is 81, which fits in 11 > octets (with seven unused bits). For the 600 bps speech the total > number of bits used is 54, which fits in 7 octets (with two unused > bits). Unused bits are coded as described in 3.3 in support of > dynamic bit-rate switching. It would help the reader if the last sentence said something like: Unused bits, shown below as RSVA, RSVB, etc., are coded as described in 3.3 in support of dynamic bit-rate switching. > 3.3 Multiple MELPe frames in a RTP packet ... > When dynamic bit-rate switching is used and more than one frame is > contained in a RTP packet, it is recommended to inspect the coder > rate bits contained in the last octet. If the coder bit rate > indicates a Comfort Noise frame, then inspect the third last octet > for the coder bit rate. All MELPe speech frames in the RTP packet > will be of this same coder bit rate. I agree with the AD review that this should be RECOMMENDED. > 4.2 Mapping to SDP ... > Alternative encoding name types, > "MELP2400", "MELP1200", and "MELP600", may be used in SDP to convey > fixed bit-rate configurations. I think that should be MAY. If you really want to discourage this usage, you would need to say SHOULD NOT. Lower-case "may" is unclear in this case. > 6 Packet Loss Concealment The "may" and "recommended" in this section are unclear - should they be MAY and RECOMMENDED? According to the writeup "There are existing implementations." It's a shame that there is no Implementation Status section (RFC 6982). Nits: - "declaritive" should be "declarative" (twice) > 3.4 Congestion Control Considerations > > The target bitrate of MELPe can be adjusted at any point in time, > thus allowing efficient congestion control. Furthermore, the amount I would rephrase "efficient congestion control", because at present the word "efficient" isn't really justified by the text. How about "thus allowing straightforward congestion management"? > of encoded speech or audio data encoded in a single packet can be > used for congestion control, since the transmission rate is inversely > proportional to the packet duration. Make that "the packet rate", because "transmission rate" could refer to the bit rate or the packet rate. At the moment the reader might miss that until the following sentence. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-adid-urn-02
Reviewer: Brian Carpenter Review result: Ready Gen-ART telechat review of draft-adid-urn-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 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-adid-urn-02.txt Reviewer: Brian Carpenter Review Date: 2016-12-17 IETF LC End Date: 2016-12-19 IESG Telechat date: 2017-01-05 Summary: Ready Comment: Thanks for handling my Last Call comments. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-6tisch-minimal-17
Reviewer: Brian Carpenter
Review result: Almost Ready
Gen-ART Last Call review of draft-ietf-6tisch-minimal-17
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-6tisch-minimal-17.txt
Reviewer: Brian Carpenter
Review Date: 2016-12-11
IETF LC End Date: 2016-12-20
IESG Telechat date: 2017-01-05
Summary: Almost Ready
Comment:
Although I found some issues, this is a good document which is mainly
very clear. I was not in a position to check IEEE802.15.4 details.
It's too late now, but judging by the shepherd's writeup, this draft
would have been an excellent candidate for an Implementation Status
section under RFC 6982.
Major Issues:
-
I was very confused for several pages until I went back and read this
again:
> This specification defines operational parameters and procedures
for
> a minimal mode of operation to build a 6TiSCH Network. The
802.15.4
> TSCH mode, the 6LoWPAN framework, RPL [RFC6550], and its Objective
> Function 0 (OF0) [RFC6552], are used unmodified.
Then I realised that there is some very basic information missing at
the beginning
of the Introduction. That little phrase "the 6LoWPAN framework" seems
to be the clue.
What is the 6LoWPAN framework? Which RFCs? I'm guessing it would be
RFC4944, RFC6282
and RFC6775, but maybe not. In any case, the very first sentence of
the Introduction
really needs to be a short paragraph that explains in outline, with
citations, how a
6TiSCH network provides IPv6 connectivity over NBMA. With that, the
rest of the document
makes sense.
But related to that, the Abstract is confusing in the same way:
> Abstract
>
> This document describes a minimal mode of operation for a 6TiSCH
> Network. It provides IPv6 connectivity over a Non-Broadcast
Multi-
> Access (NBMA) mesh...
"It" is confusing since it seems to refer to this document, which
hardly
mentions IPv6 connectivity. I suggest s/It/6TiSCH/.
As far as I know a Security Considerations section is still always
required. I understand
that this document discusses security in detail, but that doesn't
cancel the
requirement (https://tools.ietf.org/html/rfc3552#section-5).
Minor issues:
-
> 4.4. Timeslot Timing
...
> The RX node needs to send the first bit after the
> SFD of the MAC acknowledgment exactly tsTxAckDelay after the end
of
> the last byte of the received packet.
I don't understand "exactly". Nothing is exact - there is always clock
jitter.
Shouldn't there be a stated tolerance rather than "exactly"?
> 4.5. Frame Formats
>
> The following sections detail the RECOMMENDED format of link-layer
> frames of different types. A node MAY use a different formats
(bit
> settings, etc)...
Doesn't this create an interoperability issue for independent
implementations?
How can you mix and match implementations that use variants of the
frame format?
This seems particularly strange:
> The IEEE802.15.4 header of BEACON, DATA and ACKNOWLEDGMENT frames
> SHOULD include the Source Address field and the Destination
Address
> field.
How will it work if some nodes omit the addresses?
> 4.6. Link-Layer Security
...
> For early interoperability testing, value 36 54 69 53 43 48 20 6D
69
> 6E 69 6D 61 6C 31 35 ("6TiSCH minimal15") MAY be used for K1.
Shouldn't this also say that this value MUST NOT be used in
operational networks?
Nits:
-
> 1. Introduction
>
> A 6TiSCH Network provides IPv6 connectivity...
I would expect to see a reference to [RFC2460] right there.
Outdated reference: draft-ietf-6lo-paging-dispatch has been published
as RFC 8025
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
