[Gen-art] Genart last call review of draft-ietf-lamps-cms-sha3-hash-03
Reviewer: Dale Worley 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-lamps-cms-sha3-hash-03 Reviewer: Dale R. Worley Review Date: 2024-04-27 IETF LC End Date: 2024-05-03 IESG Telechat date: [not known] Summary: This draft is basically ready for publication, but has a nit that should be fixed before publication. I assume that the ASN.1 module has been reviewed by someone with the necessary expertise. (I do not have that expertise.) Nits/editorial comments: 5.2. KMAC128-KDF and KMAC256-KDF The following is probably clearer if one is familiar with these algorithms. The text states The parameters are: and follows with a list of four parameter values. But later it says When the id-kmac128 or id-kmac256 is used as part of an algorithm identifier, the parameters field MUST be absent if no customization label is used for S. If any other value is used for S, then parameters field MUST be present and contain the value of S, encoded as Customization. Some differentiation should be made between the two senses of "parameters". In particular, it would help to state here where the K, X, and L "parameters" are put, since they aren't put in the "parameters field". Also, the phrase "if no customization label is used for S" is not quite correct, as it implies that something else could be "used for S". I think the correct wording is "if there is no customization label S", which reflects that S has been stated to be "optional". [END] ___ 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-ace-revoked-token-notification-06
Reviewer: Dale Worley 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-ace-revoked-token-notification-06 Reviewer: Dale R. Worley Review Date: 2024-04-03 IETF LC End Date: 2024-04-05 IESG Telechat date: not known Summary: This draft is on the right track but has open issues, described in the review. ** Technical issues: * Section 5.1 includes: For each requester, the AS maintains an update collection of maximum MAX_N series items, where MAX_N is a pre-defined, constant positive integer. The AS MUST keep track of the MAX_N most recent updates to the subset of the TRL that pertains to each requester. This suggests that that the AS needs to maintain either separate collections for each requester or engage in some rather complicated bookkeeping to tell when an item can be reaped (since sometimes the oldest item cannot be reaped but some newer item can be). Is this what is intended? * The Observe mechanism requires that the AS maintain per-observer state for current subscriptions. There are some complications: - Is there a limitation to one subscription per registered client? - The notifications sent for a subscription depend on the parameters of the GET which establishes the subscription. Additionally, the URL to which notifications are to be sent must be recorded. I suspect that these questions are answered (explicitly or implicitly) by the specification of the CoAP Observe mechanism. But I notice that the data that the AS must store to support subscriptions is not stated in Appendix B. - More subtly, a subscription with Cursor implicitly saves the "cursor" value sent with a notification to be used as the implicit input "cursor" value used to construct the payload of the next notification. This processing is "obvious" but I didn't notice it being specified anywhere. And it likely isn't implicit in the general CoAP Observe specification because it isn't data from the GET that is stored to be used as input for generating each successive notification. So it seems that some additional specification is needed. Also, Appendix B doesn't specify this as part of the AS state. * If I were writing this specification, I would replace MAX_INDEX with "INDEX_LIMIT", defined as MAX_INDEX + 1. That is, instead of the constraint "index <= MAX_INDEX" would be "index < INDEX_LIMIT". Then the numerous places where "MAX_INDEX + 1" is used could be changed to just "INDEX_LIMIT": The AS defines INDEX_LIMIT <= (2^64). If i_X is the value of 'index' associated with a series item X, then the following series item Y will take 'index' with value i_Y = (i_X + 1) % INDEX_LIMIT. - ( i_B = INDEX_LIMIT - 2, i_C = INDEX_LIMIT -1, i_D = 0 ) a value (not less than)/(greater than or equal to) INDEX_LIMIT Although then there are a number of places where "MAX_INDEX" is now used that would have to be revised to "INDEX_LIMIT - 1". * Section 3, "Token Hash" specifies two alternative ways of constructing HASH_INPUT from an access token, depending on whether the token value is a byte string or a text string. If the token is a byte string, HASH_INPUT is the CBOR serialization of the byte string, but if the token is a (UTF-8) text string, HASH_INPUT is the text string itself. The document does not describe the motivation for this construction. It cannot be to restrict the bytes in HASH_INPUT to a particular set, because the CBOR serialization of a byte string can contain any byte values. I suspect that the motivation is to ensure that the hash of a byte string is never the same as the hash of a character string. However, this differentiation is not accomplished by the described process. For example, the byte sequence 0x41 0x41 is both the character string "AA" as well as a CBOR serialization of the single-byte string 0x41. For that matter, the byte sequence 0x40 is both the character string "@" as well as the most common CBOR serialization of the null byte string. In addition, for the overall processing to work, a receiver must be able to recognize when a hash matches a token that it possesses. But the CBOR serialization of a byte string is not unique. In the example in section 3, the first byte of the encoding could be 58, 59, 5a, or 5b (corresponding to using a 1-, 2-, 4, or 8-byte extended count) or 5f (corresponding to using an indefinite length encoding). Indeed, since an indefinite-length byte string encoding may contain zero-length chunks, there are an infinite number of val
[Gen-art] Genart last call review of draft-ietf-cose-typ-header-parameter-02
Reviewer: Dale Worley 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-cose-typ-header-parameter-02 Reviewer: Dale R. Worley Review Date: 2024-02-18 IETF LC End Date: 2024-02-26 IESG Telechat date: [not known] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Nits/editorial comments: Abstract This would be clearer if the first uses of "COSE" and "JOSE" were expanded. (https://www.rfc-editor.org/materials/abbrev.expansion.txt does not mark either as "well-known".) 1. Introduction The security benefits of having typ (type) are described in the JSON Web Token Best Current Practices [RFC8725], which recommends its use for "explicit typing" -- [...] I would recommend expanding the reference to note that this is in section 3.11 of RFC 8725. Similar considerations apply to section 3. 2. COSE "typ" (type) header parameter The typ (type) header parameter is used by COSE applications to declare the type of this complete COSE object. The situation would be clearer for me if this was extended with "(As compared to the content type header, which declares the type of the COSE payload.)". [END] ___ 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-netconf-crypto-types-28
Reviewer: Dale Worley
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: review-draft-ietf-netconf-crypto-types-28
Reviewer: Dale R. Worley
Review Date: 2024-01-22
IETF LC End Date: 2024-01-24
IESG Telechat date: [not known]
Summary:
This draft is basically ready for publication, but has nits that
should be fixed before publication.
Nits/editorial comments:
Editorial Note (To be removed by RFC Editor)
Tree-diagrams in this draft may use the '/' line-folding mode defined
in RFC 8792. However, nicer-to-the-eye is when the '//' line-folding
mode is used. The AD suggested suggested putting a request here for
the RFC Editor to help convert "ugly" '/' folded examples to use the
'//' folding mode. "Help convert" may be interpreted as, identify
what looks ugly and ask the authors to make the adjustment.
Throughout this paragraph, slash '/' should be replaced by backslash
'\'.
1.1. Relation to other RFCs
The dependency relationship between the primary YANG groupings
defined in the various RFCs is presented in the below diagram.
Perhaps there is a convention that I am not aware of, but when I see
in the figure e.g.
crypto-types
^ ^
/\
/ \
truststore keystore
does that mean that crypto-types contains a reference to truststore,
or does it mean that truststore contains a reference to crypto-types?
The usual convention is that arrows point from referencer to
referenced, but also the usual convention is that the referenced thing
is written physically below the referencer. Perhaps add an
explanatory sentence.
Table 1: Label to RFC Mapping
In -28, this caption appears visually to be the caption of both the
dependency diagram at the top of page 5 and the label-to-RFC mapping
table at the bottom of page 5, and so probably should be amended to
describe both of them together.
1.4. Conventions
Various examples used in this document use a placeholder value for
binary data that has been base64 encoded (e.g., "BASE64VALUE=").
This would be clearer if it stated directly that the (only)
placeholder value used is "BASE64VALUE=". Perhaps
Various examples in this document use "BASE64VALUE=" as a
placeholder value for (usually binary) data has has been base64
encoded.
2.1.2. Identities
+-- csr-format
+-- p10-csr-format {p10-csr-format?}
This construct ends with "?}", whereas a number of other constructs
end with "}?". Are all of these correct?
2.1.3. Typedefs
* Additionally, all the typedefs define a type for encoding an ASN.1
[ITU.X680.2021] structure using DER [ITU.X690.2021].
It seems like it would be useful to have a typedef "asn-1-der" that
extends "binary", to be used specifically for DER-encoded ASN.1 data,
and which in turn is extended here. E.g.
binary
+-- asn-1-der
+-- csr-info
+-- csr
+-- x509
| +-- trust-anchor-cert-x509
...
Unfortunately, what would make such an extended type valuable is that
DER-encoded ASH.1 strings are used in a number of RFCs, which means
that this document might not be the best place to introduce such an
extended type.
2.3. YANG Module
I am no expert on Yang, so my examination of the module itself was
superficial. The Datatracker says that Yang doctors looked at -18 on
2021-01-12, which presumably means that -19 reflected their report.
The differences between the module in -19 and -28 appear to me to to
be minor.
3.5. Strength of Keys Conveyed
... it is desireable ...
Wiktionary describes "desireable" as "an archaic form of desirable".
The RFC Editor's opinion on this should probably be sought.
3.10. The "ietf-crypto-types" YANG Module
The title of this section seems to be uninformative given that 'The
"ietf-crypto-types" YANG Module' is the subject of the entire
document. Is this title what was intended?
Some of the readable data nodes defined in this YANG module may be
considered sensitive or vulnerable in some network environments. It
is thus important to control read access (e.g., via get, get-config,
or notification) to these data nodes. These are the subtrees and
data nodes and their sensitivity/vulnerability:
The use of "These" in the last sentence does not have an unambiguous
referent as I read it. Perhaps "These subt
[Gen-art] Genart last call review of draft-ietf-ccamp-layer1-types-16
Reviewer: Dale Worley
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-ccamp-layer1-types-16
Reviewer: Dale R. Worley
Review Date: 2023-11-16
IETF LC End Date: 2023-11-21
IESG Telechat date: [not known]
Summary:
This draft is basically ready for publication, but has nits that
should be fixed before publication.
I recommend the Yang Doctors check the Yang module again. The last
Yang Doctor check was done on the -04 version, this is the -16
version, and the Yang has changed considerably since then.
Nits/editorial comments:
Different parts of the text disagree on whether (1) this module is
applicable to all layer 1 networks, but is primarily expected to be
used for OTN layer 1 networks, or (2) is applicable to OTN layer
networks. E.g. the two sentences of the Abstract seem to take
opposite approaches, sec. 4.1 seems to be OTN-specific. Presumably
the intention is agreed upon; the text needs to be made consistent
with the intention.
3. Prefix in Data Node Names
+-+---+--+
| Prefix | YANG module | Reference|
+-+---+--+
| l1-types| ietf-layer1-types | This Document|
+-+---+--+
Table 1: Prefixes and Corresponding YANG Modules
RFC Editor Note: Please replace with the number assigned to the
RFC once this draft becomes an RFC.
Should "This Document" be replaced by "RFC "?
6. YANG Code for Layer1 Types
identity ODU0 {
base odu-type;
description
"ODU0 type (1.24Gb/s).";
For "description" values that are not full sentences, there is
inconsistency whether the value ends with a period or not. There is
also inconsistency in values that are full sentences. (Perhaps this
is a matter for the Editor.)
Appendix A. Examples of OTN Label Ranges
There are several instances of
"//not-present tsg": "",
I suspect they are intended to be
"// not-present tsg": "",
[END]
___
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-rfc7042bis-09
Reviewer: Dale Worley 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-rfc7042bis-09 Reviewer: Dale R. Worley Review Date: 2023-10-06 IETF LC End Date: 2023-10-12 IESG Telechat date: [unknown] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Nits/editorial comments: In section 3. Ethernet Protocol Parameters, it says Using this EtherType, a frame body can begin with 88-B7-yy-yy-yy-zz-zz where yy-yy-yy and zz-zz have the same meaning as in the SNAP format described above. Since the previous paragraph notes for another format "The five-octet length for such OUI-based protocol identifiers results ... in the preservation of 16-bit alignment.", it might be worth stating explicitly that the EtherType 88B7 format does not preserve 16-bit alignment. The largest item is the handling of the references to the various registries, which seem to be inconsistent. It's possible that the variations in how they are referenced is based on some references being defining/authoritative and others not, but I did not spot any consistent pattern. Looking for "web page", "registry", "address family", and "table" gets 40+ hits, most of which are references to specific IANA registries. My current opinion is that these ideally should be proper references in the document, with the reference giving the canonical registry name and the full IANA URL, e.g. "SNAP Protocol Numbers, https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#ethernet-numbers-6;. Currently, only two registries are given full references: [EthernetNum] IANA, "Ethernet Numbers", <http://www.iana.org/assignments/ethernet-numbers>. [PPPNum] IANA, "PPP Numbers", <http://www.iana.org/assignments/ppp-numbers>. But perhaps there are too many registries mentioned to make that workable. [END] ___ 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-wish-whip-09
Reviewer: Dale Worley 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-wish-whip-09 Reviewer: Dale R. Worley Review Date: 2023-08-08 IETF LC End Date: 2023-08-08 IESG Telechat date: [not known] Summary: This draft is on the right track but has open issues, described in the review. The exposition could be clarified in several places. A few of the clarifications could be considered technical issues. I list the issues in textual order, with an initial summary of the most important issues. * Summary of the major issue: A very important aspect of this document is that it defines the usage of "ICE via SDP via HTTP", equivalently, "supporting ICE offer/answer over HTTP" (as opposed to the original "ICE via SDP via SIP"). That definition likely will have broader usage than just WHIP. But the document suffers from the "expert's disease", in that the authors clearly have deep knowledge of ICE and consequently only document the details of the ICE processing without providing any of the framework. This leaves naive readers to reconstruct the big picture. I was going to add "As far as I can tell, all of the needed details are listed somewhere in section 4", but as you can see below, once I wrote an outline of what is needed, there are a few points that don't seem to be specified, at least not to the point that I recognized it.) I suggest that section 4 be organized by: - stating that it is defining "supporting ICE offer/answer over HTTP" (so that it can be clearly referenced by later specifications) - specifying the abstract operations involved (with the mapping to specific operations listed either in this list or a later list): - - starting the ICE negotiation (via POST carrying application/sdp) - - updating the ICE when trickling (via PATCH carrying application/trickle-ice-sdpfrag) - - restarting ICE (via PATCH carrying (via PATCH carrying application/trickle-ice-sdpfrag, but it's not clear how this is distinguished, RFC 8840 does not specify it; perhaps because it carries ice-ufrag/ice-pwd attributes (see section 4.1)?) - - termination (via DELETE from the client; not clear how from the server) - specifying how WHIP constrains the ICE abstraction (Media server MUST not do trickle ICE updates, not clear if Media server MAY do ICE restarts, Media server MAY not support trickle ICE or ICE restart, etc.) - discussion of how out-of-order requests may arise (which isn't at all clear to me, as requests seem to be generated only by the server, and carried by TCP, so they seem to be inherently serialized) - discussion of how ETags MAY/MUST be handled, as that is comprehensible only when one looks at the serialization needs of all of the operations together - specifying the particular features of each of the operations, including any particulars of request and response fields and what response codes are to be used for what error situations * Summary of minor issues that might have technical content: At various points in section 4 the text refers to a device sending a request or generating a response but in many of them, the text doesn't state whether the device is on the client or server end, or might be both. I assume that the nature of the operation implies what devices might perform it based on text elsewhere, but it's hard to fully understand on the first reading pass. If possible, each sentence should make this clear. -- Then again, if section 4 is reorganized to describe generic ICE/SDP/HTTP usage, attention should be paid that the generic usage may define how e.g. the server does an operation, even if WHIP servers may not do that operation. Section 4 lists a collection of 4xx and 5xx response codes to be used in certain situations. Are these set due to the specific semantics of the codes or just to ensure that the recipient can tell what the cause of the error was? (HTTP suffers from having a large number of error responses but all of them have vague semantics. Unfortunately, there doesn't seem to be an HTTP response header that can carry codes defined for ICE usage specifically.) Section 4 requires the WHIP server to reject certain specific request methods, but no others. Verify that you intend this specific limitation. Section 4.1 references sections 6.6.2, 2.3, and 3.1 of RFC 9110. All of these references appear to be incorrect, in that those sections do not discuss the topics at hand. Section 4.3 references section 6.4.7 of RFC 9110, which does not exist. Some of these appear to be referencing sections in RFC 7231, whi
[Gen-art] Genart last call review of draft-ietf-dnssd-update-lease-07
Reviewer: Dale Worley 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-dnssd-update-lease-07 Reviewer: Dale R. Worley Review Date: 2023-06-07 IETF LC End Date: 2023-06-13 IESG Telechat date: [unknown] Summary: This draft is ready for publication as a Standards Track RFC. [END] ___ 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-taps-impl-15
Reviewer: Dale Worley 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-taps-impl-15 Reviewer: Dale R. Worley Review Date: 2023-04-13 IETF LC End Date: 2023-04-14 IESG Telechat date: [unknown] Summary: This draft is on the right track but has open issues, described in the review. Major issues: I find only one major issue, but it applies to the entire document. It's not at all clear to me whether this is a request to just be more careful about wording in various places, a request to be more explicit about the normative status of various statements, or a concern about the overall structure of the draft-ietf-taps-* documents. That is, the problems I observe could be anything from a minor wording issue to evidence that the API definition has omitted specifying some important aspect of the API. The authors will have to assess that. My assumption is that if there is an "interface" document and an "implementation" document, then one can write an application that uses the API without referring to the implementation document. E.g. if one had previously wanted to "establish a TCP connection to the server", one would use the TAPS API to "establish a reliable, bidirectional, byte-stream connection to the server", and this would work reliably with any TAPS implementation that supports TCP in any environment where such a TCP connection can be made. Also, regardless of the implementation, the API would work in the same way as seen by the application, as given by the API definition. More subtly, also, the API behavior is unchanged by the implementation choices TAPS makes for a particular connection, as long as the connection is within the requirements presented by the application. E.g. if in providing a "reliable, bidirectional, byte-stream connection" an SCTP stream is also a possibility, and the application has not forbidden the use of SCTP, the implementation might choose to use an SCTP stream, but since the connection is "a reliable, bidirectional, byte-stream connection", the application would not have to adjust its use of the API nor would it see different behavior in the API. To distinguish how the implementation was handling the connection, the application would have to explicitly query the Connection object. I take these as requirements for good design of the TAPS system. Reading the text, I find more modal/conditional/subjunctive words than I expect, given that what the application can discern by interacting with the API is fixed by the API definition, and the implementation is allowed all variations which do not violate the API definition. A quick script gives this census: can: 127 could: 13 may: 68 should: 92 would: 10 Consider, for example, this statement in section 2: Once a Preconnection has been used to create an outbound Connection or a Listener, the implementation should ensure that the copy of the properties held by the Connection or Listener cannot be mutated by the application making changes to the original Preconnection object. First, since "should" is not a proper key word, its normative status is unclear. But given that these behaviors are directly observable by the application, I would expect this property to be a behavior that is required by the API definition: "Once a Connection or Listener is created from a Preconnection, its properties MUST NOT be affected by changes to the properties of the Preconnection." Or, given that the underlying protocol system may make adhering to that impossible, it is likely that the API definition would use "SHOULD NOT". Let me repeat that: I expect such a requirement in the API definition, and the implementation document would discuss the consequences of the requirement. And I expect the wording in the implementation document to make it clear that it is discussing how to implement a requirement in the API definition. (In this case, probably all that is needed is to change "should" to "SHOULD", but of course that word would be copied from the requirement statement in the API document.) So to fix this, I recommend that the authors go through the text looking for modal words, and for each one, verify that what the text is discussing is not actually a requirement of the API that is missing from the API definition, and then that the discussion in this document correctly reflects the requirement in the API definition. The smaller issues that I have specific comments about are listed below. Minor/editorial/nit issues: Abstract This document serves
[Gen-art] Genart last call review of draft-ietf-sidrops-roa-considerations-07
Reviewer: Dale Worley 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-sidrops-roa-considerations-07 Reviewer: Dale R. Worley Review Date: 2023-02-19 IETF LC End Date: 2023-02-24 IESG Telechat date: [unknown] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Nits/editorial comments: I recommend the following minor changes in wording to maximize the clarity of the exposition. 3. Problem Statement Currently, no guidance was offered in existing RFCs to recommend what kinds of ROA are issued: one per prefix, or one ROA for multiple routing announcements. The problem of fate-sharing was not discussed or addressed. The use of "Currently" with "was offered" is non-parallel. There are multiple possibilities for making this parallel; given that section 1 uses the formulation "Prior to this document, there was ...", the formulation "Prior to this document, no guidance was offered ..." seems best. But the Editor may have a better idea. As there is a single expiration time for the entire ROA, expiration will affect all prefixes in the ROA. If the ROA is not reissued in a timely manner, the whole set of IP prefixes will be affected. Had these prefixes been in separately issued ROAs, the validity interval would be unique to each ROA, and invalidity would only affected by re-issuance of the specific parent CA certificate which issued them. This is not as clear as is desirable, I think. The first two sentences seem to be about the problem of the issuer of the ROA forgetting to re-issue it before expiration of the previous ROA. The third sentence seems to propose that instead of issuing a single ROA, multiple ROAs could be issued. But the problems caused by the issuer forgetting to re-issue the ROAs appears to be the same. I think you want to emphasize that using a single ROA for multiple prefixes requires that updates for all the prefixes must be synchronized in time, which could lead to complications (as discussed in the next paragraph). Perhaps, As there is a single expiration time for the entire ROA, expiration will affect all prefixes in the ROA. Thus, any changes to the ROA for any of the prefixes must be synchronized with any changes to other prefixes, especially time-limitations on authorization for a prefix. -- ... if each change in asID or routes for a given prefix reflects changes to discrete ROA ... I think you want to say "is reflected in a change to a discrete ROA". The current wording suggests that changes in the ROA cause changes in the asID or route, but since this section discusses human intentions rather than implementation processing, that's backwards. 4. Recommendations ... it is not recommended to aggregate multiple announced prefixes into one ROA by adjusting prefix length ([RFC9319] Section 5: Recommendations about Minimal ROAs and maxLength). Instead, each specific announced prefix should have its own ROA. You probably want "NOT RECOMMENDED" and "SHOULD" here. [END] ___ 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-shmoo-online-meeting-04
Reviewer: Dale Worley 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-shmoo-online-meeting-04 Reviewer: Dale R. Worley Review Date: 2022-12-06 IETF LC End Date: 2022-12-13 IESG Telechat date: [unknown] Summary: This draft is ready for publication as an informational RFC, with the possible exception of the possible nits listed below. Nits/editorial comments: 2. Some History participants later indicated in mailing discussion that the period of "mailing discussion" is an unusual phrase. Perhaps "mail discussion" was intended? intensive interims had a greater impact on their calendar than a single plenary meeting week, and in some meeting. The final "in some meeting" seems to be incomplete and (given the context) may be omitting something important. 3.3. Session/Break Length The longer breaks, while extending the day, provided adequate time for "hallway" conversations using online tools, exercise, and meals. Probably would be clearer as "... adequate time for meals, exercise, and "hallway" conversations using online tools." 4.1. Full vs. limited agenda (and interim meetings) This section heading and the one for section 4.2 are capitalized differently from the rest. But I expect the Editor will deal with that. 4.2. Flexibility of time usage Hackathon for fully online only meetings is usually held in the week "fully online only" has two modifiers with the same meaning. 4.4. Experiments Furthermore, the IESG SHOULD announce any such experiment in advance, so people can adjust to changes and potentially provide feedback. I would intensify this as "announce ... well in advance". 6.2. Informative References [_107-FEEDBACK] I see that there are a number of references with citation tags that have this unusual format. Verify this is the intended format rather than a formatting malfunction. [END] ___ 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-rcd-22
Reviewer: Dale Worley 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-stir-passport-rcd-22 Reviewer: Dale R. Worley Review Date: 2022-10-20 IETF LC End Date: 2022-10-20 IESG Telechat date: (not known) Summary: This draft is on the right track but has open issues, described in the review. Major issues: The document needs to decide on what background is needed to read it. As I read it, it requires a thorough understanding of the Passport mechanism as well as JWT. But the document doesn't state at the beginning what background is required for understanding it. >From my point of view, it would be helpful to provide an example showing all the moving parts, e.g. how a SIP INVITE message is assembled using this mechanism, as well as describing the roles of all the parties (caller, callee, Authentication Service, Verification Service) and their actions. There also is a "certificate" involved, but what parties deal with that and how it is involved is not clear. Compare to RFC 8224 section 5.1. Section 9.3 gives some valuable examples of the Json data structure that is built but nothing about how it is embedded in the larger communication. It would also be very valuable to provide a terminology section that introduced the various special terms involved. The writing should be carefully revised, especially with regard to these points: - Checking for forward references and clarifying them. E.g. some of section 11 discusses "information about the call itself which may derive from analytics", but that only makes sense in the context of section 12, which speaks of parties other than the caller adding Passport information to a call. - Cleaning up various phrasing errors and unclear phrasing. E.g. "externally referenced" or "externally referenced content" is used to describe external data that is referenced by the Passport, even though this isn't correct usage; the phrase means that something external does the referencing. You want "referenced external content", content that is external and which is referenced by the Jcard. - Various data items have various relationships that aren't specified clearly at the beginning of the sections about the data items. Often these are described later in the section but not in a succinct way. Better phrasing would be e.g. "jcd" or "jcl" MAY appear once, but they are mutually exclusive. "rcdi" and "rcd" MAY each appear once, but if one appears the other must also. - Use RFC 8174 words whenever their meaning is intended. E.g. there are places in the document where the subjunctive mood is used to indicate RECOMMENDED. This is one use of the subjunctive mood in English, but clarity demands that 8174 words be used when they would suffice. E.g. "would recommend xxx" becomes "xxx is RECOMMENDED". "xxx would be discouraged" becomes "xxx is NOT RECOMMENDED". - Use only one term for each concept. A particularly confusing example are these, which seem to me to be intended to have the same meaning, but are all different, and only one has a non-trivial word to describe the relationship between "ppt" and "rcd": a "ppt" value of "rcd" a "ppt" for "rcd" a "ppt" of "rcd" "ppt" does contain an "rcd" A "Terminology" section helps ensure that there is a set term for each concept. This document is referenced 18 times in the 33-page document but the Datatracker says it expired on 2022-09-08: [I-D.ietf-sipcore-callinfo-rcd] Wendt, C. and J. Peterson, "SIP Call-Info Parameters for Rich Call Data", Work in Progress, Internet-Draft, draft- ietf-sipcore-callinfo-rcd-04, 7 March 2022, <https://www.ietf.org/archive/id/draft-ietf-sipcore- callinfo-rcd-04.txt>. This statement is in the document: The candidate of designated expert should be like the same designated expert for PASSporT extensions registry which happens to be the first listed author of this document. The phrasing is poor, but more importantly, how do this nomination of a designated expert, the future approval of the document, and the IANA processes interact? The document is mostly normative text, although "MUST" is used rarely. This is intermixed with discussion of typical use cases, possible extensions, and other non-normative text in
[Gen-art] Genart last call review of draft-ietf-ccamp-gmpls-otn-b100g-applicability-12
Reviewer: Dale Worley 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-ccamp-gmpls-otn-b100g-applicability-12 Reviewer: Dale R. Worley Review Date: 2022-10-06 IETF LC End Date: 2022-10-06 IESG Telechat date: [not known] Summary: This draft is essentially ready for publication if the target audience is people who are familiar with optical transport networking, GMPLS, and how GMPLS is used to manage OTN. Otherwise, the provided background information needs to be expanded. I was left with uncertainty as to the intended audience of this document. The Abstract reads This document examines the applicability of using existing GMPLS routing and signalling mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of G.709. The document implicitly decides that GMPLS is applicable to ODUCn links, and provides certain details of how GMPLS management of early versions of G.709 optical networking would be extended to support ODUCn links. To a considerable degree, the document assumes the reader is familiar with Optical Transport Networking, GMPLS, and how GMPLS is used in an OTN context. It does give a significant amount of information about ODUCn networking, but despite that I know a considerable amount about non-optical networking, I found that part hard going. Very little background is given about GMPLS. The authors need to decide who the target audience is, and expand on the background information if the target audience can't be assumed to know it already. The applicability assessment itself consists of only 3 pages, and comparing to RFC 7139 (which I skimmed), I found nothing missing. Indeed, the entirety seems to be noting that the OTN-TDM Switching Type Generalized Label in RFC 7139 can be widened in the obvious way to support ODUCn transports. There are two minor points which I found very irritating and request the authors to fix even if they target a narrow audience: 1. The "fixed multiple" mentioned here: * ODUflex: Optical Data Unit - flexible rate. An ODUflex has the same frame structure as a "generic" ODU, but with rate that is a fixed multiple of the bitrate of the client signal it encapsulates. Naively, I assume that a "fixed multiple" is "an integer multiple greater than 1". However, the multiple is fixed by OTN as 239/237, which is not integral and is only slightly larger than 1, viz. 1.00843+. 2. TPNs are limited to half the number of TDM slots in the transport signal: The range of tributary port number (TPN) is 10*n instead of 20*n [...] Could some explanation be provided of why this is so? Naively this appears to be an arbitrary constriction of the number of TPNs that can be used for a link. The remainder of this review regards how to clarify the exposition of OTUCn networking for readers unfamiliar with OTN. I have no recommendation how to provide an exposition of GMPLS. 1. Introduction This document focuses on the use of existing GMPLS mechanisms to set up ODUk (e.g., ODUflex) Label Switched Paths (LSPs) over ODUCn links, independently from how these links have been set up. It seems to be understood but clearly not stated that each ODUCn link is contained within one OTUCn link, and similarly that the "payload space" in the ODUCn framing/data structure is called/considered an OPUCn. Thus discussions of the three things are highly parallel. Generally, each OTUCn is an interleaving of n OTUC1s, each contained ODUCn is an interleaving/multiplexing of n OTUD1s, and each contained OPUCn is an interleaving of n OPUC1s. But this is only partially stated. Figure 2 (at the end of section 3) provided an extremely helpful picture of how the various protocols are layered. It should be early in the introduction or terminology. 2. OTN terminology used in this document * LSP: Label Switched Path. This document mainly focuses on the label switched paths which traverse Time-Division Multiplex Capable (TDM) interfaces defined in [RFC3471]. This sentence is not a part of the definition of LSP but is rather a limitation on the applicability of the whole document, and should be promoted to a prominent position in the document. * ODUCn: Optical Data Unit-Cn; Cn indicates the bit rate of approximately n*100G. This frame structure consists of "n" synchronous instances of the ODUC signal, each of which has the format defined in Figure 12-1 of [ITU-T_G709_2020]. I think you want the phrase "inter
[Gen-art] Genart last call review of draft-ietf-lamps-documentsigning-eku-04
Reviewer: Dale Worley
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-lamps-documentsigning-eku-04
Reviewer: Dale R. Worley
Review Date: 2022-08-07
IETF LC End Date: 2022-08-11
IESG Telechat date: (none)
Summary:
This draft is basically ready for publication, but has nits that
should be fixed before publication.
The technical content of the draft is quite good, but there is an
editorially critical issue regarding the allocation of the
identifiers. There are three places where "to be done" identifiers
are specified:
3.1. Including the Extended Key Purpose for Document Signing in
id-kp-documentSigning OBJECT IDENTIFIER ::= { id-kp XX }
8.2. Informative References
Appendix A. ASN.1 Module
DocSignEKU { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-docsign-eku(TBD1) }
id-kp-documentSigning OBJECT IDENTIFIER ::= { id-kp TBD2 }
However, section 7 "IANA Considerations" does not explicitly mention
any of these substitutions. Compare with
e.g. draft-ietf-curdle-cms-chacha20-poly10305. Section 7 does say
that assignments need to be made to the appropriate registries but
provides no reference or "Note to the Editor" what substitutions need
to be made in the text. Also, "XX" must be the same as "TBD2", but
that is not specified.
There is also a redundant specification at the end of section 7,
No further action is necessary by IANA.
Given that the previous sentences in the paragraph state that there
are two actions and then enumerate them, adding a statement that there
are no others is redundant.
[END]
___
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-opsawg-l2nm-15
Reviewer: Dale Worley 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-opsawg-l2nm-15 Reviewer: Dale R. Worley Review Date: 2022-05-10 IETF LC End Date: 2022-05-13 IESG Telechat date: [not known] I have not checked the Yang module itself, as the Yang Doctors will do a better job than I can. Similarly, I have assumed that the specific information required for configuring VPNs has been set correctly by the members of the working group. I have reviewed it from the point of view that I am qualified to, a reader with beginning knowledge about VPNs and Yang learning more about the subject. Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Nits/editorial comments: 2. Terminology Clarifying the wording here so as to make clear the relationships between these concepts would ease the learning curve for the inexperienced. For example, VPN node: Is an abstraction that represents a set of policies applied on a PE and belonging to a single VPN service. This is likely known in the VPN community, but I'm having a problem following it: What exactly is a PE, or rather, what is its conceptual scope? A "Customer Edge-to-Provider Edge attachment circuit" is clear to the naive, because it's the tangible thing that connects the customer to the service provider. That suggests that the CE is the logical entity on the customer end of the attachment, and similarly the PE. But is the PE unique to the attachment circuit, and thus the VPN has a lot of PEs that it interconnects, or is there a single PE in the VPN? Also, is there only one VPN node that is applied to any one PE, or can there be many? This determines whether VPN nodes are one-to-one with PEs or whether they may have a wider scope. It seems to be known that a VPN can have multiple VPN nodes, but that isn't stated in the definition either. VPN network access: [...] A reference to the bearer is maintained to allow keeping the link between the L2SM and the L2NM when both data models are used in a given deployment. This sentence is correct, but it doesn't seem to belong in this location, as it seems to describe an aspect of the data concerning an attachment circuit, whereas "VPN network access" is an abstraction of just one end of an attachment circuit. Or does the conceptual model not have an abstraction of the other end of attachment circuits, thus allowing the network interface and the attachment circuit to be conflated, and thus the reference to the bearer can be considered to be a property of the VPN network access? 4. Reference Architecture In Figure 1, some of the module names are missing the initial "ietf-". The bottom section of Figure 1 is: +--+ Bearer+--+ +--+ +--+ | CE A + -- + PE A + + PE B + --- + CE B | +--+ Connection +--+ +--+ +--+ Site A Site B Shouldn't there be some indication of connection between PE A and PE B? Also, it's not clear why this set of boxes is integrated with the rest of Figure 1, as the lines in the figure don't seem to show any particular connection between these four boxes and the boxes above them. This segment seems to be a generic VPN between two sites, but "Site A" and "Site B" don't seem to be referenced elsewhere. If the intention is that "Network" embraces all 4 of these boxes, then the ends of the dashed line above "Network" need to be aligned with the left and right edges of the sites, and possibly some "|" added to show the various interconnections, perhaps in this style: +++ | | | Config | | | | Manager | | | +++ | | || | | NETCONF/CLI.. || | +-+ |Network | +--+ Bearer+--+ +--+ +--+ | CE A + -- + PE A +==+ PE B + --- + CE B | +--+ Connection +--+ +--+ +--+ Site A Site B But if you want to emphasize that L2NM only describes the part of the network between the PE's, you could do something
[Gen-art] Genart last call review of draft-ietf-raw-ldacs-10
Reviewer: Dale Worley 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-raw-ldacs-10 Reviewer: Dale R. Worley Review Date: 2022-03-31 IETF LC End Date: 2022-04-04 IESG Telechat date: not known Summary: This draft is basically ready for publication, but it seems to me to have open issues, depending on the intended scope of the document. Issues: There are a number of minor editorial issues listed below. But the one issue that might be significant is the lack of detail about how LDACS is expected to utilize the IP infrastructure as defined by the IETF. Strictly speaking, this document is an informational document about a particular data-link layer, and in that sense, layer 3 is out of scope, but what the IETF audience would be most informed by would be how the data-link layer integrates with IPv6 and existing IPv6 protocols. 3. Motivation and Use Cases It refers to the mostly proprietary exchange of data between the aircraft of the airline, its operation centers, and its service partners. Not being in the airline industry, my initial reading of this was that aircraft had operation centers and service partners. Perhaps this could be clarified for the naive as It refers to the mostly proprietary exchange of data between the aircraft of the airline and the airline's operation centers and service partners. 3.1. Voice Communications Today Voice links are used for Air/Ground (A/G) and Air/Air (A/A) communications. The communications equipment is either ground-based working in the High Frequency (HF) or VHF frequency band or satellite-based. By comparison, 5.2.2 states that A/A communication is only considered as a possible extension for LDACS, which seemed surprising to read at that point. This could be clarified if 3.1 noted that LDACS is not currently planned to implement A/A communication, even for voice. 5.2. Application (sending Ground Based Augmentation System (GBAS) correction data) Naively, this reads as "data to correct GBAS data". Perhaps clearer as "Ground Based Augmentation System (GBAS) data to correct GNSS" or even just "GNSS correction data" as is used in 5.2.3. 7. Characteristics Achieving the stringent continuity, availability, and integrity requirements defined in [DO350A] will require the specification of layer 3 and above mechanisms (e.g. reliable crossover at the IP layer). Fault management mechanisms are similarly undefined. This limitation seems to be strictly correct, given that this document is only scoped to the data link layer. But it would be useful to the reader to give an outline of how IP interacts with the data link layer. In particular, are the packets sent over the link IPv6 packets (perhaps encoded in some special way)? What is the general IP addressing architecture of the LDACS sub-network (i.e. AS, GS, and AR)? Similarly, what existing protocols (if any) are expected to reach the AS? These latter points are the ones that most directly intersect the IETF's business. 7.3. LDACS Protocol Stack The last entity resides within the sub-network layer: the Sub-Network Protocol (SNP). Given the context of this sentence, "the last entity" could refer to either functional block five, or to item (4) in the immediately preceding list (the LME). This would be less ambiguous as "The fifth block ...". The LDACS network is externally connected to voice units, radio control units, and the ATN network layer. How does this mesh with the architecture shown in Figure 1 of 7.1, which shows only the connection of LDACS to ATN? -- Figure 2 doesn't show the positioning of the VI functional block. 8.2. Layer 1 and 2 The figures in this section have very little information for a diagram of a frame structure. E.g. the length of an SF is specified (240ms = 2000 symbols), but the lengths of MF, BCCH, and RACH are not specified. Similarly, the lengths of the divisions of the MF aren't specified. The layout and size of the transmission time slots aren't discussed. FL and RL boundaries are aligned in time (from the GS perspective) Given that a cell can be as large as 200 nautical miles, which is 1235 microseconds at light-speed, and a symbol is 120 microseconds, while the FL and RL frame structures are synchronized at the GS, they can be desynchronized by ~20 symbols at the AS. This seems to be handled by propagation guard times but it would be useful to describe the guard time placements in the frame structures. 8.3. Beyond Layer 2 This means proliferating the number of terrestrial g
[Gen-art] Genart last call review of draft-ietf-teas-gmpls-signaling-smp-10
Reviewer: Dale Worley 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-teas-gmpls-signaling-smp-10 Reviewer: Dale R. Worley Review Date: 2020-02-02 IETF LC End Date: 2020-02-03 IESG Telechat date: not known Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Minor technical issue: These end nodes, in case of a failure of the working LSP, MUST avoid trying to switch the traffic to these protection LSPs that have been configured to use the shared resources and try switching the traffic to other protection LSPs, if available. It seems like this behavior is guaranteed without this specific requirement: The node that detects the resource failure will signal "Shared resources unavailable" to the end nodes of any lower-priority LSPs that use the failed resources. Thus, the end nodes will not try to switch the traffic of the working LSP to any of "these LSPs" (lower-priority LSPs). And consequently, they will try to switch the traffic to other protection LSPs. Indeed, it seems like the intermediate node should signal "Shared resources unavailable" to the end nodes of all protecting LSPs that use the failed resource, regardless of the LSPs' priorities -- all of them are non-functional. I suspect there is some complexity here that I do not understand. It may be worth describing that more explicitly. Nits/editorial comments: 1. Introduction The recovery resources for the protecting LSPs are pre-reserved during the provisioning phase, and explicit restoration signaling is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP instantiated during the provisioning phase. At first, I misunderstood this to have the final "during the provisioning phase" modify "explicit restoration signaling is required". After re-reading it, I think that cannot be grammatically correct, and "during the provisioning phase" is part of "instantiated during the provisioning phase". But my confusion could have been avoided if the text was amended to "... a specific protecting LSP *that* was instantiated during the provisioning phase." o updates the definition of the 16-bit Reserved field [RFC4873] of the PROTECTION object to take the new SMP type into account (see Section 6.3). At first sight, this doesn't make sense -- how does adding SMP change how the bits of an unused field are used? The concept is that SMP signaling *uses* that field. So it would be clearer to say e.g. o updates the definition of the 16-bit Reserved field [RFC4873] of the PROTECTION object to allocate 8 bits to signal the SMP preemption priority (see Section 6.3). 2. Conventions Used in This Document In addition, the reader is assumed to be familiar with the terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372 [RFC6372]. presumably for consistency you want to say In addition, the reader is assumed to be familiar with the terminology used in RFC 4872 [RFC4872], RFC 4426 [RFC4426], and RFC 6372 [RFC6372]. Although there seems to be a style question, as the forms "RFC xyzw [RFCxyzw]" and "[RFCxyzw]" (both as nouns) are both used frequently in this document. Resolving this is probably something the Editor can handle best. 3. SMP Definition Pre-configuring but not activating a protecting LSP allows the common link and node resources in the protecting LSP to be shared by multiple working LSPs that are physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.) disjoint. If I understand this correctly, the point is that multiple working LSPs may have protecting LSPs that are not disjoint, on the assumption that only one of the protecting LSPs will be active at a time. But this wording doesn't seem to mean that to me. Perhaps: Pre-configuring but not activating protecting LSPs allows link and node resources to be shared by the protecting LSPs of multiple working LSPs (that are physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.) disjoint and thus unlikely to fail simultaneously). Perhaps that could be simplified to: Pre-configuring but not activating protecting LSPs allows link and node resources to be shared by the protecting LSPs of multiple working LSPs (that are themselves disjoint and thus unlikely to fail simultaneously). 4. Operation of SMP with GMPLS Signaling Extension At the end of section 4, it seems desirable to further describe
[Gen-art] Genart last call review of draft-ietf-i2nsf-nsf-monitoring-data-model-12
Reviewer: Dale Worley 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-i2nsf-nsf-monitoring-data-model-12 Reviewer: Dale R. Worley Review Date: 2021-11-28 IETF LC End Date: 2021-12-01 IESG Telechat date: not known Summary: This draft is on the right track but has open issues, described in the review. It is clear that all of these issues can be fixed appropriately, but they need to be fixed before publication. Major issues: This document presents a data model for data being passed between various I2NSF entities. It appears that the author has a thorough understanding of the I2NSF architecture and so has made various references to it in the document. But since the data model definition does not depend on the overall architecture, the document should be revised to either (1) remove unnecessary references to the overall architecture, (2) segregate them in ways that show they are not needed to understand the data model, or (3) carefully referenced back to the documents that define them. There are also a few points where there seems to be technical issues regarding the definitions of specific data items. Details: 1. Introduction Why do we have both "administrative entities" and "Security Controller" here, and "NSF data collector" in section 3? Naively, I would expect that in regard to the definition of the data model presented by the "server side", all "client side" processes would be considered an amorphous group covered by one generic term. 2. Terminology This document uses the terminology described in [RFC8329]. Given that RFC 8329 doesn't define the terminology, it would be better to expand on this to "This document uses the terminology described in [RFC8329], much of which is defined in the I2NSF terminology document [I2NSF-TERMS]." Indeed, since I2NSF-TERMS is draft-ietf-i2nsf-terminology-05, presumably part of the same effort as this document, why is RFC 8329 being mentioned? -- There seems to be trouble with terms used in this document. Some of them are mentioned in section 2.2 of RFC 8329, which simply refers to I2NSF-TERMS. Others (e.g. "I2NSF Record") seem like they should be listed in RFC 8329, but aren't, and seem to be entirely undefined. Some of those terms appear in text that may as well be omitted from this document. Ideally, the specialized vocabulary in this document should be listed in this section and proper definitions or references provided for them. 3. Use Cases for NSF Monitoring Data * The security administrator with I2NSF User can configure a policy "I2NSF User" is not listed in RFC 8329. Also, the placement of "with I2NSF User" suggests that that phrase is some aspect of "security administrator", and you might want to say "The I2NSF User that is the security administrator ...". OTOH, if "with I2NSF User" is some aspect of "can configure", it should probably be placed after "can configure". (Is an I2NSF User a type of "user", as that word is normally used?) 4. Classification of NSF Monitoring Data This enables security administrators to assess the state of the networks and in a timely fashion. Likely should delete "and". In essence, these types of monitoring data can be leveraged to Probably can be simplified to "This monitoring data ...". As with I2NSF components, every generic system entity can include a set of capabilities that creates information about some context with monitoring data (i.e., monitoring information), composition, configuration, state or behavior of that system entity. I am sure this could be clarified if it was simplified. I think the meaning is "Every system entity creates information about some context with defined I2NSF monitoring data, and so every entity can be an I2NSF component." This information is intended to be provided to other consumers of information and in the scope of this document, which deals with NSF monitoring data in an automated fashion. I think this means "This information is can be consumed by other I2NSF components." 4.1. Retention and Emission I2NSF Event: I2NSF Event is defined as an important occurrence over time, This should be "an important occurrence at a particular time,". "over time" means that there is an extended period of time over which the event occurs, but I'm sure that I2NSF Events specify only a single instant for "when it happened". Records can be
[Gen-art] Genart last call review of draft-ietf-kitten-tls-channel-bindings-for-tls13-09
Reviewer: Dale Worley 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-kitten-tls-channel-bindings-for-tls13-09 Reviewer: Dale R. Worley Review Date: 2021-10-14 IETF LC End Date: 2021-10-15 IESG Telechat date: (not known) Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Nits/editorial comments: 1. Introduction The "unique" channel binding types defined in [RFC5929] were found to Given that this is the introduction and RFC 5929 is referenced without its title, it would help the naive reader to change "channel binding types" to "channel binding types for TLS". The use of "unique" seems to refer to both (1) the names of the channel binding types contain the word "unique" and (2) they are "unique" channel bindings in the terminology of RFC 5056. It seems like this sentence should be expanded to make both references clear, or at least to point to RFC 5056 as well. Furthermore, this document updates [RFC5929] by adding an additional unique channel binding type that replaces some usage of "tls-unique". It seems worthwhile to provide the name of the new binding type here. (And notice that it is "unique" in the sense of RFC 5056 but does not contain "unique" in its name. I'm a little surprised you didn't name it "tls-unique-exporter" to maintain the parallelism.) 2. The 'tls-exporter' Channel Binding Type Context value: Empty context value. Since RFC 5705 allows the context value to be absent, and also to be a byte string of arbitrary length including 0, it might be less ambiguous to say "Zero-length string". SCRAM [RFC5802] and GSS-API over SASL [RFC5801] define "tls-unique" as the default channel binding to use over TLS. As "tls-unique" is not defined for TLS 1.3 (and greater), this document updates [RFC5801] and [RFC5802] to use "tls-exporter" as the default channel binding over TLS 1.3 (and greater). It seems like this paragraph should be promoted to be its own section with an extremely descriptive title like "TLS 1.3 with SCRAM and with GSS-API over SASL". 3. Security Considerations Implementations MUST NOT use the channel binding to protect secret information. It's not clear to me that channel binding has any purpose other than "to protect secret information". I suspect that you mean something like "the channel binding data MUST NOT be used as a key to protect secret information". And that statement is essentially the same as the last sentence of section 3.1; indeed perhaps that sentence should be moved to section 3 to replace the existing sentence. 3.1. Use with Legacy TLS extra precaution must be taken to ensure that the chosen cipher suites always result in unique master secrets. The appearance of this paragraph in this section suggests (but does not assert) that in TLS 1.3, the cipher negotiation always results in unique master secrets. Indeed, it would be extremely convenient if (standard-conformant) use of TLS 1.3 always did so, and if so, it would be convenient to inform the user by asserting that at the end of section 2 (after moving the current last paragraph to a different section). [END] ___ 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-svcb-https-07
Reviewer: Dale Worley 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-dnsop-svcb-https-07 Reviewer: Dale R. Worley Review Date: 2021-08-14 IETF LC End Date: 2021-08-19 IESG Telechat date: unknown Summary: The document is generally in quite good shape and is almost ready for publication, but it has a technical point that should be reviewed and some editorial issues. Technical issues: Whereas SRV records have both a priority and weight field, SVCB records have only a priority field. (This point is not addressed in section C.1.) This point should be reviewed to ensure that is what we want. It may be that the weight field has not proven useful in practice, but my concern is that people may mistakenly think that implementing weight is complex and left it out of SVCB because of that. In fact, SRV records processed in the following way produce results with the specified statistical properties: - Assign each record effective_weight = - weight * log(uniform_random(0, 1)) - Sort the records first by priority in ascending order then by effective_weight in descending order. You may want to add a requirement that all SVCB-compatible RR types have presentation formats that are identical to SVCB (except for the RR type name). (see comments on section 8) Major editorial issue: While I am sure the details of the relationship between SVCB and HTTPS are given correctly, the text isn't as clear as it should be regarding the meaning and requirements of "SVCB-compatible RR types". It would be an improvement to: - Add a section that lays out the rules for SVCB-compatible RR types. - Move/copy the 4th and 5th paragraphs of the Introduction to the new section. - Clarify that the term "SVCB" is used to mean (1) the SVCB RR type, (2) collectively, SVCB and all SVCB-compatible RR types (via the sentence "All behaviors described as applying to the SVCB RR also apply to the HTTPS RR unless explicitly stated otherwise."), and (3) the SVCB conceptual structure (e.g. App. B "a non-normative summary of the HTTP mapping for SVCB"). This should probably be done in the Terminology section, where oddly "SVCB" is mentioned but not specifically listed as a defined term. - "SVCB-compatible" should be listed as a defined term. - Instead of defining "SVCB-compatible" by the example of HTTPS, identify the statements about HTTPS that are applicable to all SVCB-compatible records and state them as such. In particular, revise "All behaviors described as applying to the SVCB RR also apply to the HTTPS RR unless explicitly stated otherwise." - Add a note that when the mapping is first established for a protocol, a choice must be made whether it uses SVCB RRs or a new SVCB-compatible RRs. But once that choice is made, it is impossible (or very difficult) to change it in an upward-compatible way. The current document reads as if HTTPS was devised well into the process based on its ability to reduce the number of DNS queries, and then late in the process it was realized that HTTPS can be generalized to SVCB-compatible, but the document wasn't edited to fully describe "SVCB-compatible". Minor editorial issues: 1. Introduction Some of the text here regarding SVCB-compatible records as a whole seems to be normative (in that it is not stated anywhere else). But that has been covered in the editorial point above. It's may worth mentioning here that while the document defines SVCB and then derives HTTPS from it, the document defines only the mapping for the http: and https: schemes, and defines them as using the HTTPS record. So there are at this point no schemes with mappings for SVCB proper. 1.1. Goals of the SVCB RR This is important, as DNS does not provide any way to tie together multiple RRs for the same name. This is ambiguous, as of course DNS ties together all of the RRs for the same name. Perhaps: This is important, as DNS does not provide any way to specify multiple groups of RRs for the same name. 1.4. Terminology This is usually section 2, which clarifies that it is normative, in that the definitions are needed to understand the normative statements in the rest of the document. 2.2. RDATA wire format When the list of SvcParams is non-empty (ServiceMode) Actually, an AliasMode record can have a non-empty SvcParams, it simply SHOULD NOT. The subtle case is whether an AliasMode
[Gen-art] Genart last call review of draft-ietf-httpbis-semantics-16
Reviewer: Dale Worley 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: review-draft-ietf-httpbis-semantics-16 Reviewer: Dale R. Worley Review Date: 2021-06-09 IETF LC End Date: 2021-06-10 IESG Telechat date: 2021-06-17 Summary: This draft is basically ready for publication, but has editorial nits that should be fixed before publication. Nits/editorial comments: 4. Identifiers in HTTP The single sentence under section 4 seems to apply only to section 4.1. It probably should be moved to 4.1 and combined with its current first sentence. 4.1. URI References Unless otherwise indicated, URI references are parsed relative to the target URI (Section 7.1). Possibly worth amplifying to "... the target URI of the request". (Which is unambiguous because every protocol element is within either a request or a response, and each response is associated with a single request.) 4.3.3. https origins A server might be unwilling to serve as the origin for some hosts even when they have the authority to do so. This seems badly phrased. Perhaps this was intended: A server might be unwilling to serve requests for a particular origin even if it has the authority to do so. -- Note, however, that the above is not the only means for obtaining an authoritative response, nor does it imply that an authoritative response is always necessary (see [Caching]). You probably intend to add here that also, the server MAY not respond to such a TCP connection. That is, the above "MAY" permits the client to attempt a TCP connection but does not require the server to respond to it (especially if it is HTTP/3-only). 4.3.4. https certificate verification rather than one matching the dynamic URI's origin server identifier. I think "dynamic URI's" is not quite what is intended. I think the meaning is that the presented certificate will not match "the address and hostname of the server" (which is configured into the client in some special way, rather than being determined from the request URI). In that case, better text would be rather than one matching the server's address and hostname. -- If the certificate is not valid for the URI's origin server, a user agent MUST either notify the user (user agents MAY give the user an ... This largely duplicates the last paragraph of section 3.5. Would it be possible to simply reference that section? Or to split off the last paragraph as its own section 3.5.1? Or perhaps reduce this paragraph to If the certificate is not valid for the URI's origin server, a user agent MUST either notify the user, terminate the connection with a bad certificate error, or take steps described in section 3.5. That is, give the "naive summary" here and refer to the carefully qualified alternatives in section 3.5. 5.2. Field Lines and Combined Field Value The field value for "Example- Field" is a list with three members: "Foo", "Bar", and "Baz". This isn't quite correct, as the preceding text doesn't speak of generating a "list" in the sense of a programming language datatype, but rather it speaks of generating a character string which is the combined field value, which has the syntax "list". So the proper wording is The field value for "Example-Field" is "Foo, Bar,Baz". Note also that the first comma is followed by a space, as that is how it is presented in the first field line, while the second comma is not, as it comes from the processing "field line values ... concatenated in order, with each field line value separated by a comma". (Of course, that distinction is irrelevant, as the semantics of list-based fields is constructed so that OWS after commas is insignificant, but that design principle of httpbis-semantics hasn't been introduced yet, so the discussion at this point should not depend on it if that can be avoided.) 5.3. Field Order For consistency, use comma SP. Better to clarify, For consistency, using comma SP is RECOMMENDED. 5.6.1.2. Recipient Requirements Then the following are valid values for example-list (not including the double quotes, which are present for delimitation only): "foo,bar" "foo ,bar," "foo , ,bar,charlie" Given the distinction between what a sender is permitted to generate and a recipient is required to accept, "valid" is not clearly defined here. It could be clarified: A sender may only generate the first of the following values, but a r
[Gen-art] Genart last call review of draft-ietf-dmarc-psd-11
Reviewer: Dale Worley 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: review-draft-ietf-dmarc-psd-08 Reviewer: Dale R. Worley Review Date: 2020-04-05 IETF LC End Date: 2020-04-05 IESG Telechat date: not known Summary: This draft is ready for publication as a Experimental RFC The -11 version is far clearer (to the naive) than the -08 version. [END] ___ 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-dots-rfc8782-bis-05
Reviewer: Dale Worley 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-dots-rfc8782-bis-05 Reviewer: Dale R. Worley Review Date: 2021-03-22 IETF LC End Date: 2021-03-22 IESG Telechat date: unknown Summary: This draft is on the right track but has open issues, described in the review. I've provided a long list of minor editorial issues, and a short list of technical issues. I suspect that the technical issues have been resolved in the practices of the community and that their apparent status as problems stems from not getting the wording properly aligned with practice. Major issues: The condition of two DOTS mitigation requests overlapping depends on addresses (and alternatives to them) but as defined in section 4.4.1, does NOT depend on port numbers. However, other parts of the text seem to presume that port numbers are involved in testing for overlapping. The correct choice needs to be established and the text made consistent. Does the requesting of a mitigation only withdraw overlapping mitigations that were requested using the same signal channel, or is the effect global? If a mitigation request with trigger-mitigation = false is activated by ending of a signal channel, does reestablishing the channel withdraw it? (Naively I thought it would, but that isn't stated.) If so, how are the former and the current signal channels correlated, given that cuid collisions can prevent them from using the same common identifiers? Indeed, the text does not make it clear how a mitigation that is triggered by the ending of a signal channel can be withdrawn, other than by the expiration of its timer. Minor issues: The 4.09 response is used to report cuid conflicts, but also various other conflicts. Given that cuid conflicts require specific processing, and can happen when other conflicts could also be reported, it seems to me that for cuid conflicts, you want that the response MUST include conflict-information. In section 4.4.1 there is a discussion of a configuration where a client communicates through two different gateways to one same server using a different certificate to communicate with each gateway. The text discusses a configuration where we want the two transaction streams to be treated as one by the client and server. It seems to me that this is an unusual situation which can only succeed if both the client and server have specific configuration for it. As a consequence, the situation doesn't need to be discussed in this document. Conversely, the default result of this topology is that the client and server treat both transactions streams separately (and perhaps neither of them is aware of the overall topology). It seems like this case should work correctly without any special considerations, and so does not need to be documented specifically, either. The overall framework for signal channel configuration is not clear. By default, I assume that the client sets the channel configuration, constrained by the limits on parameter values imposed by the server, and that these values apply to communication in both directions (when applicable). The text in 4.5 and 4.5.1 is consistent with this model. However text in 4.5.2 talks about "agents" changing configuration values, which implies it's possible for the server to set channel configuration. There is discussion in section 4.5.3 of a server sending "a validity time with a configuration it sends", which makes no sense if only the client can change the configuration -- the configuration won't change until the client changes it. Also "the update of the configuration data if a change occurs at the DOTS server side". The model needs to be established, and the text aligned with it. Nits/editorial comments: Global editorial issues: There is a lot of special terminology, and it would help if definitions were gathered in section 2. Additionally, this would help reveal where the text uses undefined synonyms of defined terms, several cases of which I have spotted. There are issues involving "Observe". One is at the start of section 4.4, where the text refers to "subscribe", but that is not the term used in CoAP, indeed CoAP deliberately avoids that term. Also, unless one is familiar with CoAP, one thinks GET has no side-effects, and thus cannot possibly establish a subscription. There are related issues in sections 4.4.2.1 and 4.4.2.2 that left me wondering for which GET requests Observe was mandatory and/or permitted and what values (0 and/or 1) were permitted. I think it would help to start 4.4.2.1 with an overview discussion of the
[Gen-art] Genart last call review of draft-crocker-inreply-react-07
Reviewer: Dale Worley
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-crocker-inreply-react-07
Reviewer: Dale R. Worley
Review Date: 2021-01-27
IETF LC End Date: 2021-02-12
IESG Telechat date: [unknown]
Summary:
This draft is basically ready for publication, but has nits that
should be fixed before publication.
Nits/editorial comments:
1. Introduction
by marking basic emoji graphics
Probably intended to be "by marking with basic emoji graphics".
Normative language, per [RFC8174]:
In most drafts, this material is placed in a separate section from the
Introduction. Also, this draft contains a much longer version of this
boilerplate than is common.
2. Reaction Content-Disposition
If such a field is specified the content-type of the part MUST be:
Probably should be capitalized as "Content-Type".
The rule emoji_sequence is inherited from [Emoji-Seq]. It permits
one or more bytes to form a single presentation image.
I haven't traced the definition of emoji_sequence, but it seems to be
essentially a set of Unicode characters that have one or another of
certain attributes. That is perfectly sensible. But if I understand
correctly, "emoji_sequence" is a sequence of characters, and you want
to say "In the UTF-8 encoding, some of these characters may be encoded
as multiple bytes." or something like that.
The emoji(s) express a recipient's summary reaction to the specific
message referenced by the accompanying In-Reply-To header field.
[Mail-Fmt].
This is not specific as to where the In-Reply-To header is. I assume
you want to say that it is a header of the parent multipart component
of "Reaction" part. Or perhaps this should be forward-referenced to
the discussion in section 3.
Reference to unallocated code points SHOULD NOT be treated as an
error; associated bytes SHOULD be processed using the system default
method for denoting an unallocated or undisplayable code point.
Code points that do not have the requisite attributes to qualify as
part of an emoji_sequence should also not be treated as an error,
although you probably want to allow the system to alternatively
display them normally (rather than as an unallocated or undisplayable
code point).
4.1. Example Message
with a thumbs-up, affirmative response of:
To: aut...@example.com
From: recipi...@example.com
Date: Today, 29 February 2021 00:00:10 -800
Message-id: 12...@example.com
Subject: Meeting
Mime-Version: 1.0 (1.0)
Content-Type: text/plain; charset=utf-8
Content-Disposition: Reaction
{U+1F44E}
This example does contain an In-Reply-To header, contrary to the
specification.
4.2. Example Display
Message:A complete message is often displayed with a tailored
section for header-fields, enhancing the format and showing only
selected header fields. It might include one for reactions, again
showing the symbol and a count.
I think it would be more accurate to expand "It might include one for
reactions ..." to "It might include a quasi-header summarizing the
reactions that have been received ...". Then again, perhaps "one"
meant "a tailored section", which would be clarified differently.
5. Security Considerations
This specification defines a distinct label for specialized message
content.
Perhaps s/label/Content-Disposition/.
6. IANA Considerations
The React MIME Content-Disposition parameter is registered, per
[RFC2183]
I think s/React/Reaction/ is intended.
Comparing with
https://www.iana.org/assignments/cont-disp/cont-disp.xhtml, it would
be
The Reaction MIME Content-Disposition value is registered, per [RFC2183]
Content Disposition value: Reaction
Allowable parameters for this value:(none)
7. Experimental Goals
o Does the presence of the Reaction capability demonstrate
additional security issues?
Perhaps s/demonstrate/create/.
[END]
___
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-tls-ticketrequests-06
Reviewer: Dale Worley 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-tls-ticketrequests-06 Reviewer: Dale R. Worley Review Date: 2020-11-27 IETF LC End Date: 2020-12-03 IESG Telechat date: Not known Summary: This draft is ready for publication as a Standards Track RFC. Editorial comments: 2. Use Cases * Parallel HTTP connections: To minimize ticket reuse while still improving performance, it may be useful to use multiple, distinct tickets when opening parallel connections. To the naive reader, the ordering of the phrases doesn't seem to match the logical ordering of the concepts. Perhaps * Parallel HTTP connections: To improve performance, a client may open parallel connections. To avoid ticket reuse, the client may use multiple, distinct tickets on each connection. -- * Decline resumption: Clients can indicate they have no intention of resuming connections by sending a ticket request with count of zero. "have no intention" seems to me to suggest a decision that will not change. Since the future cannot be guaranteed, perhaps better wording is "do not intend to resume", suggesting a current state that might possibly change in the future. new_session_count The number of tickets desired by the client when the server chooses to negotiate a new connection. resumption_count The number of tickets desired by the client when the server is willing to resume using a ticket presented in this ClientHello. If I understand the processing which is suggested correctly, when the client sends a ClientHello, the server can choose to either negotiate a new connection, or (if a ticket is present in the ClientHello) the server can choose to resume the previous connection represented by the ticket. These two parameters provide the requested ticket count for the two situations. Assuming the above is correct, I would recommend changing the wording slightly, as "when" suggests a fact which is true over an extended period of time, whereas the provided counts are applicable in just this one instance: new_session_count The number of tickets desired by the client if the server chooses to negotiate a new connection. resumption_count The number of tickets desired by the client if the server chooses to resume (using the ticket presented in this ClientHello). (Change "the" to "a" in the last sentence if the ClientHello can present more than one ticket among which the server can choose.) [END] ___ 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-idr-flow-spec-v6-17
Reviewer: Dale Worley 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-idr-flow-spec-v6-17 Reviewer: Dale R. Worley Review Date: 2020-10-25 IETF LC End Date: 2020-10-21 IESG Telechat date: 2020-11-05 Summary: This draft is ready for publication as a Standards Track RFC. Nits/editorial comments: 3.1. Type 1 - Destination IPv6 Prefix 3.2. Type 2 - Source IPv6 Prefix Unlike IPv4, it is plausible that a set of flows could be determined by two contiguous sections of an address, e.g., an initial prefix and a subset of bits within an embedded IPv4 address. By draft-ietf-idr-rfc5575bis-26 section 4.2, an IPv6 flow specification may not contain two Destination IPv6 Prefix or two Source IPv6 Prefix components, so this type of selection cannot be specified. 4. Ordering of Flow Specifications If the offsets are not equal, the lowest offset has precedence, as this flow matches the most significant bit. "as this flow" should be "as this flow specification" 5. Validation Procedure a) A destination prefix component with offset=0 is embedded in the Flow Specification I note that this requirement has no functional effect, as a destination prefix with length = 0 can always be added to a flow specification without effect. However, this observation also applies to IPv4 flow specifications, so I assume it has been given due consideration. [END] ___ 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-slaac-renum-03
Reviewer: Dale Worley 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-v6ops-slaac-renum-03 Reviewer: Dale R. Worley Review Date: IETF LC End Date: 2020-09-09 IESG Telechat date: [not set] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Overall, the draft is fine, but there are various places where the wording could be amplified or improved to make matters clearer to the less-well-prepared reader (like me). Minor issues: There is one technical aspect that doesn't seem to be addressed explicitly: Given that a router should never advertise a prefix via SLAAC that extends beyond the lease time it has received via DHCP, even if the router is restarted and it receives a new prefix via DHCP, the old prefix remains delegated to the network for the remainder of its lease time, and in a way, it remains *valid* for the hosts to use addresses derived from the old prefix for the remainder of the lifetime they received from SLAAC. The existence of this document shows that such usage does not work well, but perhaps there is some place early in the discussion where it can be made clear that validity is not sufficient in practice. Nits/editorial comments: 1. Introduction [...] but will normally retain and actively employ the addresses configured for the previously-advertised prefix, since their associated Preferred Lifetime and Valid Lifetime allow them to do so. Naively, it seems like the new prefix will almost always have longer lifetime values than the old prefix, and given that this seems to be how orderly renumbering causes hosts to transition from using the old prefix to the new prefix, it's not clear how hosts "will normally ... actively employ the addresses configured for the previously-advertised prefix". Naively, hosts only seem to be permitted to employ the old prefix, but the preferred behavior would be to use the new prefix whenever possible. o During the planned network renumbering, a router may be configured to send an RA with the Preferred Lifetime for the "old" Prefix Information Option (PIO) set to zero and the new PIO having non- zero Preferred Lifetime. This sentence reminds me: There are a number of places where PIO is mentioned. My understanding from here is that PIO is only used in RA, so for simplicity/clarity, mentions of PIO should always include that they are within RAs, so that the reader remember that all prefix announcements are either RAs or SLAAC. Conversely, if PIOs are used both by SLAAC and RAs, that should be emphasized early on, so the reader knows that later mentions of PIOs apply to both protocols equally. Then again, perhaps RAs are messages within SLAAC, in which case that should be made clear. In any case, the document should state the relationship between SLAAC, RA, and PIO. o Automated device config management system performs periodic config pushes to network devices. If such a push results in changing the subnet configured on a particular network, hosts attached to that network would not get notified about the subnet change, and their addresses from the "old" prefix will not be deprecated. Naively it seems than when a router receives such a config push, it would as a matter of course tell the attached hosts that the prefix it gave to the hosts is no longer configured, as indeed, that prefix is no longer configured. I think you want to add some statement that when routers receive config pushes they often(?) simply immediately forget their previous configuration, rather than withdrawing it gracefully. In various places, "timely" and derived words are used. In some places, the text asserts that certain intervals are not timely (in an absolute sense) without any discussion about what the standard of timeliness is. It seems that some such discussion needs to be made, or a statement made that such a discussion needs to be undertaken as part of the work. Some devices have implemented ad-hoc mechanisms to address this problem, such as sending RAs to invalidate apparently-stale prefixes [...] This seems to contradict the statement in section 2.3 that an RA cannot effectively reduce the Valid Lifetime of a prefix (as maintained by a host) to zero: "Item e) [...] specifies that an RA may never reduce the "RemainingLifetime" to less than two hours." Indeed, a crux of this document is that there is no way for a router to immediately invalidate the use of a prefix on a network whose addressing it configures. So t
[Gen-art] Genart last call review of draft-ietf-idr-rfc8203bis-06
Reviewer: Dale Worley 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-idr-rfc8203bis-06 Reviewer: Dale R. Worley Review Date: 2020-07-13 IETF LC End Date: 2020-07-14 IESG Telechat date: not known Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. * Minor issues: 3. Operational Considerations See the comments about Appendix B. Appendix B. Changes to RFC 8203 xThis appendix should describe upward-compatibility considerations. The body says that the Communication should be limited to 128 octets if feasible. But there could be situations where the sender sends a longer Communication without knowing that the receiver implements 8203bis, and the receiver in fact does not. How to recover from that situation? E.g., will the NOTIFICATION be rejected with a specific error message? Can the sender detect the problem by the subsequent behavior of the receiver? Is it even well-defined that the receiver will reject the message? Can the situation be compensated by immediately sending another NOTIFICATION without the Communication? Indeed these considerations probably should be put in section 3. * Nits/editorial comments: Abstract It seems like it would be useful to note here "This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication >>>of up to 255 octets<<< to improve communication using multibyte character sets." since the length extension is the only significant change this document introduces. 1. Introduction via offline methods such email or telephone calls. This document Insert "such >>>as<<< email". 2. Shutdown Communication This field is not NULL terminated. The best phrasing is "NUL terminated", as the name of the character is NUL. (See RFC 20.) However, it is common to say "null terminated", which is valid because "null" is a common adjective (i.e., not a proper adjective) that describes the variety of termination. But "NULL terminated", though not infrequently used, isn't reallly correct. (Unless the RFC Editor says otherwise!) 6. Security Considerations UTF-8 "Shortest Form" encoding is REQUIRED to guard against the technical issues outlined in [UTR36]. It might be useful to repeat this restriction in the description of the Communication field in section 2. [END] ___ 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-rpc-tls-07
Reviewer: Dale Worley 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-nfsv4-rpc-tls-07 Reviewer: Dale R. Worley Review Date: 2020-05-24 IETF LC End Date: 2020-05-27 IESG Telechat date: unknown Summary: Note that I am not familiar with the operations of TLS, so I have not reviewed issues that are specific to security implementations. I assume the SECDIR review has adequately covered those. This draft is quite solid and nearly ready for publication, but has nits that should be fixed before publication. Nits: 4.1. Discovering Server-side TLS Support Somewhere in this section you need to specify the semi-obvious: In principle, RPC is transport-agnostic. In the context of RPC-Over-TLS, the initial request MUST be sent using either TCP or UDP. If an initial TCP request is successful, a TLS connection is established. If an initial UDP request is successful, a DTLS association is established. -- If the Reply's reply_stat is MSG_ACCEPTED but the verifier does not contain the "STARTTLS" token, or if the Reply's reply_stat is MSG_DENIED, the RPC client MUST NOT send a "ClientHello" message. Strictly, this should list the three tests required by the preceding paragraph: If the Reply's reply_stat is not MSG_ACCEPTED, if its verifier is not an AUTH_NONE, or if its verifier's contents are not "STARTTLS", the RPC client MUST NOT send a "ClientHello" message. 5. TLS Requirements If the server responds incorrectly, the client MUST NOT establish a TLS session for use with RPC on this connection. I think the condition can be made more specific as "If the "ServerHello" message does not conform to the above requirement, ...". 5.1.1. Protected Operation on TCP The server does not attempt to establish a TLS session on a TCP connection for backchannel operation. I think "... does not attempt to establish a separate TLS session ..." is clearer. I can't find any discussion of "backchannel operation" in RFC 5531. Might this need an additional reference? 5.2.1. X.509 Certificates Using PKIX trust o For services accessed by their network identifiers (netids) and universal network addresses (uaddr), the iPAddress subjectAltName SHOULD be present in the certificate and must exactly match the address represented by universal address. I suspect that "iPAddress" is not capitalized correctly. "universal address" probably should be either "universal network address" or "uaddr". 5.2.2. X.509 Certificates Using Fingerprints Implementations MUST support SHA-256 [FIPS.180-4] or stronger as the hash algorithm for the fingerprint. Perhaps there is a usage in security, but it seems to me that "stronger" is not well-defined. I expect that it means that the hash algorithm must produce output of at least 256 bits, but that criterion makes no allowances that over time algorithms might be deprecated. Is there a list of accepted "strong" hash algorithms that can be referenced here to make this unambiguous and track best practice over time? Also -- here I'm assuming that one peer presents a certificate to the other, and the second peer first hashes the certificate to create a fingerprint and then checks the fingerprint against a list -- this sentence does not require the peer to *use* an algorithm that meets this criterion. The text needs to be something like Implementations MUST use SHA-256 [FIPS.180-4] or stronger as the hash algorithm for the fingerprint. 7.1. Limitations of an Opportunistic Approach Implementations of the mechanism described in the current document must take care to accurately represent to all RPC consumers the level of security that is actually in effect, ... I think you want s/must/MUST/. There's also an unstated requirement that the RPC consumers have some way of accessing this information. 7.3. Security Considerations for AUTH_SYS on TLS Using a TLS-protected transport when the AUTH_SYS authentication flavor is in use addresses several longstanding weaknesses (as detailed in Appendix A). For clarity "... several longstanding weaknesses in AUTH_SYS (detailed in Appendix A)." TLS guards against the insertion or deletion of messages, thus also ensuring the integrity of the message stream between RPC client and server. This statement needs to be weakened somewhat for DTLS. o When using RPCSEC_GSS, GSS/Kerberos provides adequate host authentication and a policy that requires G
[Gen-art] Genart last call review of draft-ietf-dmarc-psd-08
Reviewer: Dale Worley 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: review-draft-ietf-dmarc-psd-08 Reviewer: Dale R. Worley Review Date: 2020-04-05 IETF LC End Date: 2020-04-08 IESG Telechat date: not known * Summary: This draft is on the right track but has open issues, described in the review. * Major issues: The privacy concerns described in section 4 are written as if there is no certainty that the mechanisms described in the document properly mitigate them. So the document appears to be incomplete. OTOH, since this is an Experimental RFC, such mitigation isn't necessary if there is commitment to do so later. In that case, the section should explicitly state that these are open issues and that there is an intention of revising the document to mitigate them. The text suggests that a mail receiver(?) that does DMARC processing has knowledge of all PSDs. This seems a priori unlikely and even impossible to implement. So this ought to be either explained at the appropriate place or resolved technically. * Minor issues: The document has the (common) editorial problem that it is written by people who are deeply familiar with the subject, and it's difficult to read if one doesn't share that familiarity. This is particularly significant because DMARC is an e-mail facility that (ideally) will affect all e-mail that is sent, so the target audience really should be anyone who has a basic understanding of e-mail. Three particular elements of this are: - It would be very helpful if the Introduction could state, in a few sentences, the purpose and operation of DMARC, thus informing the reader of the framework whose deficiencies this document attempts to address. In particular, one shouldn't have to read the DMARC RFCs to be able to read this document and understand its general import. - The "experiment" appendixes are unclear about what the experiments actually are: what questions they are to answer, what actions will be taken, how the results will be evaluated. Starting each appendix with an overview paragraph would be helpful. - Forward references should be minimized so that a reader can understand the document in one pass. As a derivative of the first of these elements, the terminology used for the properties of domain names is not clearly defined. In particular, where does a registration "occur"? The only term for which I think the general audience possesses an unambiguous definition is "the registered domain name", e.g. ietf.org. Now I *think* its PSD is ".org", but it might be "ietf.org", and I don't know whether the registration of ietf.org "occurs" at ietf.org or .org. Further points I didn't understand are pointed out in the review of the Abstract and Introduction. * Nits/editorial comments: Abstract I'm having quite a bit of difficulty figuring out exactly what the Abstract means. I'm sure that the working group clearly understands what is meant, but the writing is just loose enough that I can't fix the meaning. To raise the immediate questions: DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling. This sentence is quite good, as it introduces what DMARC is all about. The design of DMARC presumes that domain names represent either nodes in the tree below which registrations occur, or nodes where registrations have occurred; it does not permit a domain name to have both of these properties simultaneously. You want to make clear here that "registration" means "domain name ownership registration" (which is what section 2.2 says). Otherwise it leaves open that there is some sort of DMARC registration that you might intend, until the reader gets to section 2.2. There's an ambiguity regarding "where" a registration happens. E.g., does the registration of "ietf.org" "occur at" "ietf.org" or "occur at" "org"? It's possible that this could be simplified/disambiguated by not using this term, but instead phrasing this in terms of domain names that "are registered", and the allowed relationships between them. And it appears certain that there are DNS nodes where registrations are only done *above* that node, e.g. "datatracker.ietf.org", which this sentence (if taken literally) sa
[Gen-art] Genart last call review of draft-ietf-lamps-5480-ku-clarifications-00
Reviewer: Dale Worley 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-lamps-5480-ku-clarifications-00 Reviewer: Dale R. Worley Review Date: 2020-02-18 IETF LC End Date: 2020-02-07 IESG Telechat date: [unknown] Summary: This draft is on the right track but has open issues, described in the review. The text is difficult to follow in places. I believe that the WG has a clear understanding of what is intended, but a few small editorial errors have unfortunately rendered the text incorrect and contradictory to RFC 5480. Note that I am unfamiliar with the details of PKI certificates; this review is based largely on what I have learned from RFC 5480 and this I-D. >From the discussion it appears that id-ecDH and id-ecMQV are "key agreement algorithms" and that, as such, they should not be used with keyEncipherment or dataEncipherment. [this draft, section 3] Conversely, id-ecPublicKey is not a "key agreement algorithm". [RFC 5480, section 2.1.2, para. 1, sentence 1] 1. Introduction This document corrects this omission, by updating Section 3 of [RFC5480] to make it clear that neither keyEncipherment nor the dataEncipherment key usage bits are set for key agreement algorithms. This could be clearer by replacing or augmenting "key agreement algorithms" with a description of which of these algorithms are key agreement algorithms, viz., id-ecDH and id-ecMQV. Otherwise, one must first have read RFC 5480 to understand this introduction correctly. 3. Updates to Section 3 If the keyUsage extension is present in a certificate that indicates id-ecPublicKey as algorithm of AlgorithmIdentifier [RFC2986] in SubjectPublicKeyInfo, then following values MUST NOT be present: keyEncipherment; and dataEncipherment. If the keyUsage extension is present in a certificate that indicates id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following values also MUST NOT be present: keyEncipherment; and dataEncipherment. The structure of this section is peculiar, since it presents almost the same text about "id-ecPublicKey" and about "id-ecDH or id-ecMQV". If the intention is to say the same thing about all three, these should be folded together. It is also not clear why the first paragraph refers to AlgorithmIdentifier but the second paragraph uses SubjectPublicKeyInfo to refer to essentially the same thing. But this text appears to contradict the statement in [RFC 5480] that the usage of id-ecPublicKey is "unrestricted" and is not a key agreement algorithm, in which case the first paragraph should say "the following values MAY be present". (In which case, the "also" in the 2nd paragraph should be omitted.) [END] ___ 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-deprecate-interdomain-asm-05
Reviewer: Dale Worley 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-mboned-deprecate-interdomain-asm-05 Reviewer: Dale R. Worley Review Date: 2019-12-21 IETF LC End Date: 2019-12-23 IESG Telechat date: not set * Summary: This draft is basically ready for publication, but has some nits that should be fixed before publication. * Major issues: None * Minor issues: None of the recommendations are phrased with SHOULD, which I think would be natural for a BCP. The word "recommends" is used, and replacing it with "RECOMMENDS" seems natural, but the RFC 2119 word is "RECOMMENDED". I guess you use the passive construction "It is RECOMMENDED ...". But perhaps the convention is not to use RFC 2119 words in BCPs. * Nits/editorial comments: Requirements Language and Terminology This section should be updated from RFC 2119 to RFC 8174. 1. Introduction ... there has been no strong recommendation made by the IETF on the appropriateness of those models to certain scenarios, even though vendors and federations have often made such recommendations. This document addresses this gap by making a BCP-level recommendation ... This isn't phrased correctly; it reads as if it is important for the IETF "to make a strong recommendation" per se, and that is the primary motivation for this document. Instead, something like: It has become known that SSM is significantly superior to ASM in interdomain multicast uses, so this document changes the situation by making a BCP-level recommendation to deprecate the use of ASM for interdomain multicast, leaving SSM as the recommended mode of interdomain multicast. 2.1. Multicast service models Source discovery in SSM is handled by some out-of-band mechanism (ie, the application layer), ... s/ie/i.e./ 3.1. Observations on ASM and SSM deployments Some of these issues include complex flooding RPF rules, state attack protection, and filtering of undesired sources. I assume "RPF" means "Reverse Path Forwarding" here. Support for IGMPv3 and MLDv2 has become widespread in common OSes for several years (Windows, MacOS, Linux/Android) and is no longer an impediment to SSM deployment. It's probably worth stating that the large router vendors also support these protocols. 3.2.2. No network wide IP multicast group-address management receive each others IP multicast traffic. s/others/other's/ (Or is that "others'"? Have to check with the Editor!) 4. Recommendations The more inclusive interpretation of this recommendation is that it also extends to the case where PIM may only be operated in a single operator domain, but where user hosts or non-PIM network edge devices are under different operator control. The use of "inclusive" is a bit ambiguous, as it's not clear whether the intention is to expand what is deprecated or to expand what is approved. I think this can be solved by changing "extends to" to "also deprecates": The more inclusive interpretation of this recommendation is that it also deprecates the case where PIM is operated in a single operator domain, but where ... 4.4. Developing application guidance: SSM, ASM, service discovery Applications with many-to-many communication patterns can create more (S,G) state than feasible for networks, whether the source discovery is done by ASM with PIM-SM or at the application level and SSM/PIM- SM. This is unclear to me. I think you want "at the application level with SSM/PIM-SM" for parallelism. But it's also not clear what "more state feasible for networks" means. I think it means "more state than is feasible for networks to manage", but that doesn't seem to mesh with "... or at the application level". Perhaps the meaning is "more state than is feasible to manage". Unfortunately, today many applications simply use ASM for service discovery. Probably better to say "many applications use ASM solely for service discovery", as "simply" could be read in a number of ways. 4.5. Preferring SSM applications intradomain If feasible, it is recommended for applications to use SSM even if they are initially only meant to be used in intradomain environments supporting ASM. It seems like the words "If feasible" are reduendant given the meaning of "recommended" (or at least the meaning of "RECOMMENDED"). 4.8. Not precluding Intradomain ASM In the
[Gen-art] Genart last call review of draft-ietf-ippm-stamp-07
Reviewer: Dale Worley Review result: Ready with Issues Network Working Group G. Mirsky Internet-Draft ZTE Corp. Intended status: Standards Track G. Jun Expires: February 13, 2020 ZTE Corporation H. Nydell Accedian Networks R. Foote Nokia August 12, 2019 Simple Two-way Active Measurement Protocol draft-ietf-ippm-stamp-07 Abstract This document describes a Simple Two-way Active Measurement Protocol which enables the measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 13, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Mirsky, et al. Expires February 13, 2020 [Page 1] Internet-DraftSTAMP August 2019 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions used in this document . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. Softwarization of Performance Measurement . . . . . . . . . . 3 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4 4.1. Session-Sender Behavior and Packet Format . . . . . . . . 5 4.1.1. Session-Sender Packet Format in Unauthenticated Mode5 4.1.2. Session-Sender Packet Format in Authenticated Mode . 6 4.2. Session-Reflector Behavior and Packet Format . . . . . . 7 4.2.1. Session-Reflector Packet Format in Unauthenticated Mode . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Session-Reflector Packet Format in Authenticated Mode 9 4.3. Integrity and Confidentiality Protection in STAMP . . . . 10 4.4. Interoperability with TWAMP Light . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction Development and deployment of Two-Way Active Measurement Protocol (TWAMP) [RFC5357] and its extensions, e.g., [RFC6038] that defined features such as Reflect Octets and Symmetrical Size for TWAMP provided invaluable experience. Several independent implementations exist, have been deployed and provide important operational performance measurements. At the same time, there has been noticeable interest in using a more straightforward mechanism for active performance monitoring that can provide deterministic behavior and inherit separation of control (vendor-specific configuration or orchestration) and test functions. One of such is Performance Measurement from IP Edge to Customer Equipment u
[Gen-art] Genart last call review of draft-ietf-lamps-cms-hash-sig-08
Reviewer: Dale Worley 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-lamps-cms-hash-sig-08 Reviewer: Dale R. Worley Review Date: 2019-07-17 IETF LC End Date: 2019-08-01 IESG Telechat date: not known Summary: This draft is in great shape and ready for publication as a proposed standard RFC, with only a few editorial nits. Nits/editorial comments: 2.2. Leighton-Micali Signature (LMS) The [HASHSIG] specification supports five tree sizes: LMS_SHA256_M32_H5; LMS_SHA256_M32_H10; LMS_SHA256_M32_H15; LMS_SHA256_M32_H20; and LMS_SHA256_M32_H25. This text seems redundant with the description in the preceding paragraph. The LMS public key is the string consists of four elements: the Perhaps "An LMS public key consists of ...". u32str(lms_algorithm_type) || u32str(otstype) || I || T[1] The notation "T[1]" seems to be undefined (although the intended value is described clearly in the preceding paragraph). 2.3. Leighton-Micali One-time Signature Algorithm (LM-OTS) n - The number of bytes associated with the hash function. [HASHSIG] supports only SHA-256 [SHS], with n=32. "associated" seems to me to be vague. Perhaps "The length in bytes of the output of the hash function." ls - The number of left-shift bits used in the checksum function, which is defined in Section 4.4 of [HASHSIG]. "The number of left-shift bits" is not quite right. Perhaps "The number of bits of left-shifting used in ..." or "The amount/size of the left-shift used in ...". 5. Signed-data Conventions This paragraph has to be a number of minor wording issues, which I have described interline: As specified in [CMS], the digital signature is produced from the message digest and the signer's private key. The signature is computed over different value depending on whether signed attributes s/value/values/ are absent or present. When signed attributes are absent, the HSS/LMS signature is computed over the content. When signed It might help the reader to put a paragraph break before "When signed attributes are present..." attributes are present, a hash is computed over the content using the same hash function that is used in the HSS/LMS tree, and then a message-digest attribute is constructed with the resulting hash I would replace "with" with "containing" or "whose value is" value, and then DER encode the set of signed attributes, which MUST For parallelism, this clause should start with a subject and a passive verb. Perhaps "the DER encoding is constructed of ...". include a content-type attribute and a message-digest attribute, and It might be clearer if the clause "which MUST ... attribute" was put in parentheses. then the HSS/LMS signature is computed over the output of the DER- encode operation. In summary: You can probably change "the output of the DER-encode operation" with "the DER encoding". The paragraph contains four clauses joined by three successive "and then". You probably want to change that, perhaps breaking it out as a numbered/bulleted list. (What does the Editor recommend?) And in this computation: IF (signed attributes are absent) THEN HSS_LMS_Sign(content) ELSE message-digest attribute = Hash(content); I think you want to add a hyphen: s/message-digest attribute/message-digest-attribute/ HSS_LMS_Sign(DER(SignedAttributes)) [END] ___ 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-iftunnel-04
Reviewer: Dale Worley
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-softwire-iftunnel-04
Reviewer: Dale R. Worley
Review Date: 2019-05-05
IETF LC End Date: 2019-05-07
IESG Telechat date: [not known]
Summary:
This draft is ready for publication as a Standards Track RFC.
Nits/editorial comments:
Editorial Note (To be removed by RFC Editor)
This section is a great idea. I haven't seen this usage before.
Please update the "revision" date of the YANG modules.
This sentence doesn't say what to update the revision date to.
1. Introduction
This document specifies the initial version of the iana-tunnel-type
YANG module identifying tunnel interface types.
This could be made more specific, e.g.,
This document specifies the initial version of the iana-tunnel-type
YANG module containing a collection of IANA maintained YANG
identities identifying tunnel interface types.
--
2. IANA Tunnel Type YANG Module
The initial version of the module includes tunnels types defined in
[RFC4087], [RFC7856], [RFC7870], and [RFC6346].
s/tunnels types/tunnel types/
Should this mention the provenance of IP-HTTPS, which is in none of
these RFCs?
identity iphttps {
base ift:tunnel;
description
"IP over HTTPS (IP-HTTPS) Tunneling Protocol.";
reference
"Microsoft Corporation, IP over HTTPS (IP-HTTPS) Tunneling
Protocol Specification,
https://msdn.microsoft.com/en-us/library/dd358571.aspx;;
}
This type's reference doesn't appear in the list of references.
3. Security Considerations
These identies are intended to be
referenced by other YANG modules, and by themselves do not expose any
nodes which are writable, contain read-only state, or RPCs.
Logically, this is correct, but I think it would read better if
s/contain read-only state/contain readable state/.
4.1. YANG Module
The name of the "identity" is the same as the corresponding
enumeration in the IANAifType-MIB (i.e., IANAtunnelType).
This should be "... is the lower-case of the corresponding enumeration
".
"base":Contains the name assigned to the tunnel type, in
lowercase.
The description of this item should be "Contains 'ift:tunnel'.".
6.2. Informative References
[TUNNELTYPE-IANA-REGISTRY]
Internet Assigned Numbers Authority, "tunnelType
Definitions", <https://www.iana.org/assignments/smi-
numbers/smi-numbers.xhtml#smi-numbers-6>.
Given that this document specifies substantial interaction with this
registry, this reference should be normative.
The title of this reference cannot be "tunnelType Definitions",
because that text does not appear in either the referenced URL or the
IANA assigned numbers index (https://www.iana.org/protocols). The
title of the entire web page is "Structure of Management Information
(SMI) Numbers (MIB Module Registrations)"; the title of the section
that is referenced is "Internet-standard MIB -
mib-2.interface.ifTable.ifEntry.ifType.tunnelType", which is a
subsection of the section titled "ifType definitions". There is no
reference to the section from the IANA assigned numbers index.
Comparing with this passage from section 4.1
They must instead be respectively added to the
"tunnelType" sub-registry (under the "ifType definitions"
registry).
suggests the title "ifType definitions: tunnelType" may be in
informal use.
[END]
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-6lo-deadline-time-04
Reviewer: Dale Worley 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-6lo-deadline-time-04 Reviewer: Dale R. Worley Review Date: 2019-05-05 IETF LC End Date: 2018-12-24 IESG Telechat date: 2019-05-16 Summary: This draft is on the right track but has open issues, described in the review. There are a number of comments about the exposition that are listed below. I'm sure these can be resolved by the authors. But there is a serious problem with the last 5 paragraphs of section 8, "Synchronization Aspects": they seem to assume that the time representation for the Deadline Time and Origination Time values will wrap around, that is, that the representation is the absolute value modulo the size of the field. In addition, there is a lack of clarity how the new epoch point will be chosen after the value wraps around. This seems to contradict the earlier sections of the document which speak of the values as if they are always to be considered as absolute values on a time scale selected by the TU field, viz., either the NTP time scale (in seconds) or the network's ASN numbering. It's possible that four of these paragraphs are intended to only apply to the use of TU = 00, the NTP time scale, and perhaps that usage of the header is understood not to be completely specified yet. However, the final paragraph discusses TU = 10 (the ASN time scale), and claims that wrapping of the DT value is intended. This is relevant to current implementations. Some sort of resolution of this is needed; as the document stands it is self-inconsistent. One possible resolution would be to omit these paragraphs. Nits/editorial comments: 3. 6LoRHE Generic Format 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ |1|0|1| Length | Type | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ <-- length --> Figure 1: 6LoRHE format o Length: Length of the 6LoRHE expressed in bytes, excluding the first 2 bytes. This enables a node to skip a 6LoRHE if the Type is not recognized/supported. o Type (variable length): Type of the 6LoRHE (see Section 7) There is a detail of this description which I don't like, and the problem seems to be inherited from draft-ietf-roll-routing-dispatch, viz., there is a variable-length field in the 6LoRHE, but it's not named or described as such in that figure. The correct way to describe the header is: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ |1|0|1| Length | Type | ... data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ <-- length --> Figure 1: 6LoRHE format o Length: Length of the 6LoRHE expressed in bytes, excluding the first 2 bytes. This enables a node to skip a 6LoRHE if the Type is not recognized/supported. o Type: Type of the 6LoRHE (see Section 7) o Data (Length bytes): Additional data. -- 4. Deadline-6LoRHE Since the OTD is a delta the length of the OTD field (i.e., OTL) will require fewer bits than the length of the DT field (i.e., DTL). Strictly speaking, it will usually require fewer bits. OTOH, it will often require far fewer bits. Also, given the placement of "(i.e., OTL)" there is an awkwardness regarding whether "OTL" is an abbreviation for "the length of the OTD field" or an abbreviation for "the OTD field". Conveniently, even a difference of 1 in the length fields is significant, since they are in units of 4 bits. So perhaps a better wording is: Since the OTD is a delta, the length (i.e., OTL) of the OTD field will often be less than the length (i.e., DTL) of the DT field. -- 5. Deadline-6LoRHE Format o TU (2 bits) : Indicates the time units for DT and OTD fields. The encoding for the DT and OTD fields MUST always use the same time units and precision. * 00 : Time represented in seconds and fractional seconds * 01 : Reserved * 10 : Network ASN * 11 : Reserved I think these could be made more explicit: o TU (2 bits) : Indicates the time unit and zero point for DT and OTD fields. The encoding for the DT an
[Gen-art] Genart last call review of draft-ietf-manet-dlep-pause-extension-05
Reviewer: Dale Worley 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-manet-dlep-pause-extension-05 Reviewer: Dale R. Worley Review Date: 2019-03-20 IETF LC End Date: 2019-04-03 IESG Telechat date: [not scheduled] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. There are a number of issues with technical content, but they appear to stem from editorial issues, rather than being unsettled technical decisions. * Technical issues: I notice that the Pause Extension cannot be used by a router to tell a modem to not send. I assume that the WG has considered this and has a good reason for this asymmetry. 3.1.1. Queue Parameter Sub Data Item There need not be a Sub Data Item for a particular queue index. Such a queue has no declared size. OTOH, it has no DSCPs, and so no traffic can be sent for it, either. Queue Parameter Sub Data Items are an unordered list composed of sub data items with a common format. The first sub data item is assigned a Queue Index value of 1, and subsequent data items are numbered incrementally. The format of the Queue Parameter Sub Data Item is ... Queue Index: An 8-bit field indicating the queue index of the queue parameter represented in the sub data item. These passages are contradictory. Either the Sub Data Items are an ordered list and indexes are assigned to them sequentially, they are unordered and the indexes are given in the Queue Index subfield, or the Sub Data Items are required to be in order by their Queue Index fields. DS Field Qn: The data item contains a sequence of 8 bit DS Fields. The position in the sequence identifies the associated queue index. The number of DS Fields present MUST equal the sum of all Num DSCPs field values. This doesn't seem to match the defined format of the Sub Data Items. The "DS Field Qn" fields contain exactly as many DS Fields as the value of the Num DSCPs Qn field by definition. And all of them are associated with the one Queue Index in the Sub Data Item containing the DS Field Qn. I note that the Sub Data Items are not padded to a multiple of 4 octets. I assume this is intended. 3.3. Restart The sending of this data item parallels the Pause Data Item, see the previous section, and follows the same rules. This includes that to indicate that transmission can resume to all destinations, a modem MUST send the Restart Data Item in a Session Update Message. It also includes that to indicate that transmission can resume to a particular destination a modem MUST send the Pause Restart Item in a Destination Update Message. Read literally, this means that there is a pause/transmit bit for each destination/DSCP combination, and that the various messages (pause vs. restart * Session Update vs. Destination Update * queue index vs. 255) set some subset of the bits to "pause" or "transmit". This is opposed to the model where (to simplify) there is an overall pause/transmit bit for all traffic and an independent pause/transmit bit for each destination, and traffic may be sent for a destination only if both the overall bit and the destination bit are "transmit". * Editorial issues: 1. Introduction The extension also optionally supports DSCP (differentiated services codepoint) aware, see [RFC2475], flow control. The phrasing of this sentence is awkward because of the number of interpolated phrases. I suggest something like: The extension also optionally supports flow control that is DSCP (differentiated services codepoint) aware (see [RFC2475]). Also, it seems that recent RFCs have tended to capitalize the phrase "Differentiated Services Code Point". (Probably check this point with the Editor.) Note that this mechanism only controls traffic that is to be transmitted on the modem's attached data channel and not to DLEP control messages themselves. The parallelism is not correct here, as it would read "this mechanism controls ... to DLEP". Perhaps change to: "this mechanism only applies to traffic ...". 2. Extension Usage and Identification To indicate that the Control Plane Based Pause Extension is to be used, an implementation MUST include the Control Plane Based Pause Extension Type Value in the Extensions Supported Data Item. If I am reading RFC 8175 correctly, this is not exactly true. Sending the Value does not compel the peer device to use the Extension. Instead, "To indicate
[Gen-art] Genart last call review of draft-ietf-pim-igmp-mld-yang-10
Reviewer: Dale Worley 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-pim-igmp-mld-yang-10 Reviewer: Dale R. Worley Review Date: 2019-02-05 IETF LC End Date: 2019-02-08 IESG Telechat date: not known Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. I do not have the expertise to review the contents of the Yang module itself. Fortunately, the Yang Doctor can review that. Minor issues: This draft has a number of exposition issues that should be fixed. Abstract This document defines a YANG data model that can be used to configure and manage Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) devices. Both here and in the Introduction, it would be better to say "devices that implement IGMP and MLD" or something like that, since IGMP and MLD are protocols, not classes of devices. Table of Contents 2. Design of Data model. 4 2.1. Scope of model . 4 2.2. Optional capabilities .. 4 2.3. Position of address family in hierarchy 5 3. Module Structure 5 3.1. IGMP Configuration and Operational state ... 5 3.2. MLD Configuration and Operational State 8 It looks like the current style would capitalize "model", "capabilities", "state", etc. 1. Introduction This model will support the core IGMP and MLD protocols, as well as many other features mentioned in separate IGMP and MLD RFCs. "will support" needs clarifying. Does the model defined by this document "support many other features", or is this a prediction that the model will eventually be extended to do so? Indeed, the Introduction should make a clear statement of what is and is not supported by this version of the model. 1.3. Prefixes in Data Node Names Otherwise, names are prefixed using the standard prefix associated with the The tail of this sentence is missing. 2. Design of Data model 2.1. Scope of model The model covers IGMPv1 [RFC1112], IGMPv2 [RFC2236], IGMPv3 [RFC3376] and MLDv1 [RFC2710], MLDv2 [RFC3810]. This should be stated in the Introduction as well. The configuration of IGMP and MLD features, and the operational state fields and RPC definitions are not all included in this document of the data model. As written, this says that the model covers some unspecified subset of IGMP and MLD features. Is it possible to characterize what is included and what is not? Otherwise, the reader would have to work through the model to check on every specific item they were interested in. This model can be extended, though the structure of what has been written may be taken as representative of the structure of the whole model. What does this mean? Like any Yang model, this model can be extended, by anyone who chooses to do so. But how does "what has been written" represent or constrain the structure of an extended model? 2.2. Optional capabilities The main design goals of this document are that any major now-existing implementation may be said to support the basic model, [...] Probably more correct to say "[...] may be said to support the facilities described by the basic model [...]". There is also value in widely-supported features being standardized, to save work for individual vendors, [...] And probably more importantly, so that the features can be accessed in a standardized way. 2.3. Position of address family in hierarchy The current document contains IGMP and MLD as separate schema branches in the structure. The reason for this is to make it easier for implementations which may optionally choose to support specific address families. And the names of objects may be different between the IPv4 (IGMP) and IPv6 (MLD) address families. It seems like the qualification of IGMP == IPv4 and MLD == IPv6 should be done in the first sentence rather than the last. 3.1. IGMP Configuration and Operational state It seems like this section has a first part which applies to IGMP and MLD equally (though it only talks about IGMP), and a second part which is a summary of the IGMP module. Perhaps they should be split into two sections? Interface-global: Only including configuration data nodes that IGMP configuration attributes are applicable to all the interfaces whose interface-level correspo
[Gen-art] Genart last call review of draft-ietf-6lo-deadline-time-03
Reviewer: Dale Worley 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-deadline-time-03 Reviewer: Dale R. Worley Review Date: IETF LC End Date: 2018-12-24 IESG Telechat date: unknown Summary: This draft is on the right track but has open issues, described in the review. Major issues: 1. In regard to the TU field of the header: TU (2 bits) : Indicates the time units for DT and OT fields 00 : Time represented in microseconds 01 : Time represented in seconds 10 : Network ASN 11 : Reserved Note that to define DT and OT, we need to specify not only a time unit, but the instant of zero time. Network ASN has a zero time defined by the network, but for the other two choices, the zero time is not specified by this document. Perhaps it is intended that any "time-synchronized network" necessarily defines a zero time and that is being referenced here. If that is so, it should probably be made explicit. Indeed, it is probably worth going farther: The 10 value is only meaningful in 6TiSCH networks. So really, the interpretation of TU is scoped to the underlying network technology and the definition(s) of time it provides. The defintion of TU in this document should be something like this: TU (2 bits) : Indicates the time scale for DT and OT fields Values depend on the underlying network technology. For 6TiSCH networks: 00 : Reserved 01 : Reserved 10 : Network ASN 11 : Reserved Values in other networks are out of scope of this document. 2. I'm surprised that the OT value is represented as an absolute value from the time-base used for the particular Deadline-6LoRHE, rather than as an offset before the DT. The difference DT - OT will typically be much smaller than OT itself, so if O = 1 and OT is present, using a difference would usually shorten the header. This change clearly isn't necessary for correctness, but it seems like a significant efficiency gain, as after 1 year, a 10 msec ASN with have values nearing 2^32, but DT - OT may remain less than 2^8. Nits/editorial comments: Abstract The deadline time enables forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks. It's not clear to me how much "over constrained networks and operate within time-synchronized networks" adds to this sentence. True, this header requires that nodes have a common sense of time, but does that require a "time-synchronized network"? (OTOH, perhaps that is what "time-synchronized network" *means*, but I don't know that.) And while 6LoWPAN is expected to be operated across a constrained network, a constrained network isn't a requirement for its use. OTOH, perhaps what you mean is that the header is designed for use over constrained networks, i.e., it is bit-efficient. In that case, I'd relocate the phrase to "... delivery deadline time for data packets, designed for use over constrained networks." 1. Introduction ... compression schemes for RPL routing (source routing) operation [RFC6554], ... It might be helpful to define "RPL". I think better wording would be "compression schemes for [RFC6554] RPL routing", or "compression schemes for RPL routing using [RFC6554]". The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN Routing Header (6LoRH), compression schemes for RPL routing (source routing) operation [RFC6554], header compression of RPL Packet Information [RFC6553], and IP-in-IP encapsulation. This document specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1, so that the deadline time of data packets can be included within the 6LoWPAN routing header. I think these two sentences could be clarified along these lines: This document specifies a new Deadline-6LoRHE type for the Elective 6LoWPAN Routing Header Type, so that the deadline time of data packets can be included within the 6LoWPAN routing header. RFC 8138 [formerly ietf-roll-routing-dispatch] specifies the 6LoWPAN Routing Header (6LoRH), compression schemes for RPL routing (source routing) operation [RFC6554], header compression of RPL Packet Information [RFC6553], and IP-in-IP encapsulation. -- This document also specifies handling of the deadline time when packets traverse through time-synchronized networks operating in different timezones or distinct reference clocks. Perhaps s/traverse through/traverse betwee
[Gen-art] Genart telechat review of draft-murchison-tzdist-tzif-15
Reviewer: Dale Worley 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-murchison-tzdist-tzif-15 Reviewer: Dale R. Worley Review Date: 2018-10-24 IETF LC End Date: 2018-10-09 IESG Telechat date: 2018-10-25 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. There are two remaining nits: The semantics of the various data items -- what they mean and how they are to be used in processing -- is only hinted at. I suspect that the draft is targeted at members of the community who already thoroughly understand the semantics of the data items (based on their names), but this is not stated. There is a reference: see "Sources for Time Zone and Daylight Saving Time Data" [tz-link] for more-detailed information about civil timekeeping data and practice but it does not positively assert that [tz-link] provides the specification of the data items in TZif. It's very likely that this is Not A Problem within the community that would use this specification, but that needs to be positively ascertained, as there is no definitive statement in the draft itself. 3.2. TZif Data Block time zone designations: A series of octets constituting an array of NUL-terminated (0x00) time zone designation strings. [...] The character encoding of time zone designation strings is not specified; however, see Section 4 of this document. I think this should be expanded to "The character encoding of time zone designation strings is not specified, other than that encoded characters MUST NOT contain a NUL (0x00) octet. However, see Section 4 of this document." This is because some important multi-octet encodings generate NUL octets, and while the TZif format does not fix the encoding, certain encodings (o rather certain encoded characters) MUST be forbidden. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-murchison-tzdist-tzif-14
Reviewer: Dale Worley 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-murchison-tzdist-tzif-14 Reviewer: Dale R. Worley Review Date: 2018-09-30 IETF LC End Date: 2018-10-09 IESG Telechat date: unknown Summary: This draft is on the right track but has open issues, described in the review. Major issues: 1. The draft does not specify the versioning and compatibility principles governing TZif files and their processors. Certain passages suggest that processors are expected to *not* examine the version number in a file, but instead, extensions to the file format are made by adding further data blocks to the end of the file, and later-version processors handle earlier-version files by noticing that latter data blocks are missing. This approach implies that processors based on earlier versions to not notice that there appears to be trailing garbage in the file. But silent acceptance of trailing garbage is not specified, and this strategy is different from most IETF standards. 2. The semantics of the various data items -- what they mean and how they are to be used in processing -- is only hinted at. I suspect that the draft is targeted at members of the community who already thoroughly understand the semantics of the data items (based on their names), but this is not stated, nor is any reference given to where one might learn this information. OTOH, the glossary (in section 2) gives definitions of several terms that suggest the document is attempting to define the semantics, but the definitions given are nowhere near sufficient to specify those semantics. 3. Apparently (see comments on section 4), characters outside the ASCII set are allowed in time zone designations. If so, their encoding needs to be specified. Minor issues: Nits/editorial comments: 1. Introduction This specification does not define the source of leap second information, nor does it define the source the time zone data, metadata, identifiers, aliases, localized names, or versions as defined in Section 3 of [RFC7808]. One such source is the IANA- hosted time zone database [RFC6557]. The sequence "nor does it define the source the time zone data" is gramatically incorrect. I would suggest it should be "... the source of ...", but making that change leaves the semantically heterogenous list "the time zone data, metadata, identifiers, aliases, localized names, or versions". Also, it's not clear how "as defined in Section 3 of [RFC7808]" attaches to the sentence, since the closest item in the list, "versions", is defined in section 3 and not RFC 7808. I suspect that some part of the wording was accidentally deleted. 2. Conventions Used in This Document Daylight Saving Time (DST): The time according to a location's law or practice, adjusted as necessary from standard time. The adjustment may be positive, negative, or zero. This seems to read that "Daylight Saving Time" is not "standard time" plus the summer time offset, but standard time, adjusted by whatever summer time offset might be in effect at the moment. But that is not not the definition of DST, at least, not as commonly used in the US. What exactly is meant here? I would prefer a much more careful explanation of how the various terms are used. 2. a change in whether standard or daylight saving time is in use Is this intended to include the regular transition between summer time and winter time, or only when a locality starts or stops the practice of using summer time each year or the schedule of transitions? UNIX Leap Time: [...] Similarly, if the second leap second record occurs at 1972-12-31 23:59:60 UTC, its UNIX leap time would be 94694401; the second occurrence accounts for the first leap second. I think this would be clearer as: Similarly, if the second leap second record occurs at 1972-12-31 23:59:60 UTC, the UNIX leap time of 1972-12-31 23:59:60 UTC would be 94694401 and the UNIX leap time of 1973-01-01 00:00:00 UTC would be 94694402. -- If a TZif file specifies no leap second records, UNIX leap time is equivalent to UNIX time. I think s/equivalent to/equal to/ reads better here. Wall Time: The time as shown on a clock set according to a location's law or practice. In what way does this differ from "Local Time"? After reading further in the document, I suspect that the structure you are intending is: There is a "standard time" which is derived from UTC, and a "daylight savings time&qu
[Gen-art] Genart last call review of draft-ietf-acme-acme-13
Reviewer: Dale Worley 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://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>. Document: draft-ietf-acme-acme-13 Reviewer: Dale R. Worley Review Date: 2018-08-05 IETF LC End Date: 2018-08-08 IESG Telechat date: [not scheduled] Summary: This draft is ready for publication as a standards-track RFC. [END] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-richer-vectors-of-trust-11
Reviewer: Dale Worley Review result: Ready with Nits Network Working Group J. Richer, Ed. Internet-Draft Bespoke Engineering Intended status: Standards TrackL. Johansson Expires: November 19, 2018Swedish University Network May 18, 2018 Vectors of Trust draft-richer-vectors-of-trust-11 Abstract This document defines a mechanism for describing and signaling several aspects of a digital identity transaction and its participants. These aspects are used to determine the amount of trust to be placed in that transaction. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 19, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Richer & Johansson Expires November 19, 2018 [Page 1] Internet-Draft vectors-of-trustMay 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. An Identity Model . . . . . . . . . . . . . . . . . . . . 5 1.3. Component Architecture . . . . . . . . . . . . . . . . . 5 2. Component Definitions . . . . . . . . . . . . . . . . . . . . 6 2.1. Identity Proofing (P) . . . . . . . . . . . . . . . . . . 7 2.2. Primary Credential Usage (C) . . . . . . . . . . . . . . 7 2.3. Primary Credential Management (M) . . . . . . . . . . . . 8 2.4. Assertion Presentation (A) . . . . . . . . . . . . . . . 8 3. Communicating Vector Values to RPs . . . . . . . . . . . . . 8 3.1. On the Wire Representation . . . . . . . . . . . . . . . 9 3.2. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 10 4. Requesting Vector Values . . . . . . . . . . . . . . . . . . 11 4.1. In OpenID Connect . . . . . . . . . . . . . . . . . . . . 11 5. Trustmarks . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Defining New Vector Values . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8.1. Vector Of Trust Components Registry . . . . . . . . . . . 13 8.1.1. Registration Template . . . . . . . . . . . . . . . . 14 8.1.2. Initial Registry Contents . . . . . . . . . . . . . . 14 8.2. Additions to the OAuth Parameters Registry . . . . . . . 15 8.3. Additions to JWT Claims Registry . . . . . . . . . . . . 15 8.4. Additions to OAuth Token Introspection Response . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Vectors of Trust Default
[Gen-art] Genart last call review of draft-ietf-extra-imap-list-myrights-05
Reviewer: Dale Worley 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://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>. Document: draft-ietf-extra-imap-list-myrights-05 Reviewer: Dale R. Worley Review Date: 2018-05-06 IETF LC End Date: 2018-05-14 IESG Telechat date: [not scheduled] Summary: This draft is ready for publication as a standards-track RFC, with some very minor (AUTH48-level) wording nits. 3. MYRIGHTS Return Option to LIST Command The ordering of the responses is significant only in that the server MUST NOT send a MYRIGHTS response for a given mailbox before it sends the LIST response for that mailbox. It's clear what this means, but I think the wording is not quite correct. Perhaps: The ordering of the responses is constrained only in that ... or The ordering of the responses is not significant and is constrained only in that ... (In regard to the substance of this constraint, it's not clear to me why it exists, but I assume that the authors know of a reason for it.) -- Clients SHOULD use a suitable match pattern and/or selection option to limit the set of mailboxes returned to only those whose rights in which they are interested. I *think* the syntax of the final clause is not quite correct, and I *think* this is the corrected version: Clients SHOULD use a suitable match pattern and/or selection option to limit the set of mailboxes returned to only those in whose rights they are interested. But you may want to check with the RFC Editor. 4. Examples In this example the LIST reply for the "foo" mailbox is returned ... This should start "In the following example..." or "In the next example...", because if the screen cuts off the text just below this paragraph, the description appears to apply to the preceding example, which does not match this text. [END] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-acme-acme-12
Reviewer: Dale Worley 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://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>. Document: draft-ietf-acme-acme-12 Reviewer: Dale R. Worley Review Date: 2018-05-06 IETF LC End Date: 2018-04-18 IESG Telechat date: [not scheduled] Summary: This draft is ready for publication as a standards-track RFC. [END] ___ 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-acme-11
Reviewer: Dale Worley 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://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>. Document: draft-ietf-acme-acme-11 Reviewer: Dale R. Worley Review Date: 2018-04-18 IETF LC End Date: 2018-04-18 IESG Telechat date: 2018-05-10 Summary: This draft is on the right track but has open issues, described in the review. This draft is much better than the version (-08) that I previously was the assigned Gen-ART reviewer for. The overall work and exposition are quite solid, though there are some open technical issues that need to be resolved. * Technical issues What is the versioning and extensibility system? -- It seems that the natural approach is that structures returned by fetches of Acme resources may contain elements that are not defined in this document, and a client should ignore them if it doesn't understand them. This allows plenty of flexibility for extending the Acme protocol; in particular, by adding further resources to the directory object. The handling of "terms of service agreement" seems to be insufficient, in that none of the information passed around says *what* agreement the client has agreed to. The client only sends "termsOfServiceAgreed:true" in a request, leaving what has been agreed to unspecified -- and unauditable. One possibility is to add an argument for the client to provide the URL from which it fetched the ToS (so the server knows what agreement the client is referring to) and the hash of the ToS document (so the client must attest to what the agreement text was). 6.6.1. Subproblems What error type should be used in a problem document when there are subproblem documents? It seems that in this situation, the intention is that the top-level problem document is not intended to carry error information itself, so you want to define a "subproblems" error type, to use when there is no natural overall error type. * Editorial issues 7.1. Resources The position of "newNonce" in the diagram is strange. Does it have a different relationship to the directory resource than newAccount, etc.? Similarly for the "finalize" and "cert" URLs of an order object. -- Reading further in the draft suggests that the graphical difference indicates that that these values are optional in the respective objects, although the text doesn't identify that. 7.1.2. Account Objects contact (optional, array of string): An array of URLs that the server can use to contact the client for issues related to this account. For example, the server may wish to notify the client about server-initiated revocation or certificate expiration. I mentioned this in my review of -08, but it hasn't been fixed: Strictly, you want "URIs" here, as tel:, sip:, and mailto: URIs are not URLs [RFC 6068]. 7.3.5. External Account Binding To enable ACME account binding, a CA needs to provide the ACME client with a MAC key and a key identifier, using some mechanism outside of ACME. The key identifier MUST be an ASCII string. The MAC key SHOULD be provided in base64url-encoded form, to maximize compatibility between non-ACME provisioning systems and ACME clients. I *think* what this means is that the service providing the external account provides the ACME client with a MAC key and a key identifier, which the client then uses in constructing its request to the ACME server. If that is correct, this text is not making clear (to me) the distinction between the CA that operates the ACME server (which I take as the default meaning of "CA" in this document) and the service that provides the "external account". I think two different terms are needed for the two services so as to make the processing described in this section clear. 7.4. Applying for Certificate Issuance This section seems to describe both the process of creating an order and the process of finalizing an order. The initial paragraphs regard creating an order, but the text starting with "Once the client believes it has fulfilled the server's requirements..." it talks about finalization. The text continues to discuss finalization until it gets to this confusing item: o "ready": The server agrees that the requirements have been fulfilled, and is awaiting finalization. Submit a finalization request. I *think* what is going on is that the text from "The status of the order will indicate..." through the 5 following items are a *general* description of the status field which is limited to neither the order creation step nor the order finalization step. It
[Gen-art] Genart telechat review of draft-ietf-mmusic-trickle-ice-sip-14
Reviewer: Dale Worley 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. Document: draft-ietf-mmusic-trickle-ice-sip-14 Reviewer: Dale R. Worley Review Date: 2018-04-01 IETF LC End Date: 2018-01-26 IESG Telechat date: 2018-04-05 Summary: This draft is ready for publication as a Proposed Standard RFC. [END] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-tram-stunbis-16
Reviewer: Dale Worley 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://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>. Document: draft-ietf-tram-stunbis-16 Reviewer: Dale R. Worley Review Date: 2018-03-29 IETF LC End Date: 2018-02-20 IESG Telechat date: 2018-04-19 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. The only interesting item concerns section 17.1, where the assignment of meanings to bits in the "security feature set" value is different from the assignment in -16. This is either non-upward-compatible with -16, or there is an error in either -16 or -17. -- There is an issue that shows up in several places: The NAT may forward the request using an IP family that is different from the IP family that it received the request using. This means that the "source IP family of the request" may depend on whether one is speaking of the client or the server. The draft is cognizant of this, and mentions its consequences in sections 6.3.3 and 12. But this also has consequences for ALTERNATE-SERVER: Section 14.15 says "The IP address family MUST be identical to that of the source IP address of the request." even though that family might not be usable by the client. The draft doesn't seem to explicitly say that this comes from address-switching by the NAT. It would help if there was a higher-level discussion of this matter, pointing to the various consequences. 3. Terminology This section needs to be updated to reference RFC 8174, including updating the paragraph (especially the final two lines) to read as specified in RFC 8174: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 6.2.2. Sending over TCP or TLS-over-TCP o if multiplexing other application protocols over that port, has finished using that other protocol, and The two clauses don't match in grammatical number. This should be either o if multiplexing other application protocols over that port, has finished using those other protocols, and or o if multiplexing another application protocol over that port, has finished using that other protocol, and 9.2.4. Receiving a Request * If the request contains neither PASSWORD-ALGORITHMS nor PASSWORD- ALGORITHM, then the request is processed as though PASSWORD- ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS attribute did not contain MD5, this will result in a 400 Bad Request in a later step below). There are two places where s/PASSWORD- ALGORITHM/PASSWORD-ALGORITHM/. 14.3. USERNAME The value of USERNAME is a variable-length value containing the authentication username. It MUST contain a UTF-8 [RFC3629] encoded sequence of less than 509 bytes, and MUST have been processed using the OpaqueString profile [RFC8265]. A compliant implementation MUST be able to parse UTF-8 encoded sequence of less than 763. The final "763" is grammatically incorrect. I think you intend s/763/763 bytes/, to parallel other items. 14.4. USERHASH userhash = SHA-256(Opaque(username) ":" Opaque(realm)) I believe that this should be userhash = SHA-256(OpaqueString(username) ":" OpaqueString(realm)) 14.5. MESSAGE-INTEGRITY Petit-Huguenin, et al. Expires September 6, 2018 [Page 40] Internet-Draft Session Traversal Utilities for NAT (STUN) March 2018 This bit of text appears as body text in the middle of page 40. 14.6. MESSAGE-INTEGRITY-SHA256 The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA256 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY-SHA256 attribute can be present in any STUN message type. The MESSAGE- INTEGRITY-SHA256 attribute contains an initial portion of the HMAC- SHA-256 [RFC2104] of the STUN message. The value will be at most 32 bytes and MUST be a positive multiple of 4 bytes. The HMAC MUST NOT be truncated below a minimum size of 16 bytes. The value must be the full 32 bytes unless the STUN Usage explicitly specifies that truncation is allowed. STUN Usages may specify a minimum length longer than 4 bytes. This seems
[Gen-art] Genart last call review of draft-ietf-tls-tls13-24
Reviewer: Dale Worley 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://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>. Document: draft-ietf-tls-tls13-24 Reviewer: Dale R. Worley Review Date: 2018-03-02 IETF LC End Date: 2018-03-02 IESG Telechat date: 2018-03-08 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This review only covers the general properties of the proposed protocol and the exposition, as I am unqualified to assess its security properties. There are various places where the exposition could be made clearer, especially to readers not immersed in security matters. In many places, it is mostly a matter of making clearer the connections between different points in the exposition. In a few places, there seems to be ambiguity regarding the specification that has technical significance. In particular: - There is inexactness about "transcript", "handshake context", and "context". - When a server receives ClientHello, is it obligated to promptly send not just the ServerHello, but all first-flight messages from ServerHello through Finished? (section 4.2.11.3) I ask this because the client is only obligated/permitted to send EndOfEarlyData when it receives the server's Finished. - It seems inconsistent that the client can send an empty Certificate message, but the server cannot, even though the server can omit sending the Certificate message. (section 4.4.2.4) - Comparing sections 4.2.10 and 4.6.1, when a PSK was established in an earlier connection, exactly what are the limitations on the cryptographic parameters that can be used when the PSK is used in a resumption connection? 4.2.10 suggests that the following must be the same in both connections: TLS version, cipher suite, ALPN. But 4.6.1 suggests that different cipher suites can be used, as long as they use the same hash algorithm. - In regard to section 4.6.1, it seems to require that a client MAY NOT resume a connection using a ticket issued during a connection in which the server did not present a certificate for itself, because in the handshake of the resumption connection, the client is required to verify that the SNI is compatible with the certificate the server presented in the original connection. But that constraint isn't stated in section 2.2, despite being a global constraint on the structure of sessions. - Presumably implementations MUST NOT send zero-length fragments of alert messages for the same reasons that they cannot send zero-length fragments of handshake messages (whatever those reasons are). - There are about 28 error codes but nearly 150 places where the text require the connection to be aborted with an error -- and hence, nearly 150 distinct constraints that can be violated. There are 19 alone for "illegal_parameter". I would like to see an "alert extension value" which assigns a distinct "minor" code to each statement in the text that requires an error response (with implementations being allowed to be a bit sloppy in providing the correct minor code). - I take it that there is no "close read side" operation. (If that existed, TLS could generate the "broken pipe" error.) There are a number of issues which span the whole text: The interaction of this draft with extensions defined for previous versions of TLS is not laid out clearly. It seems safe enough for this draft to import data structures from earlier extensions with only a reference to the earlier RFC, but if an extension defines behavior (e.g., a negotiation process), exactly what is the specification of that behavior in TLS 1.3, given that the referenced RFC only defines its use in TLS 1.2 or earlier? At the least, there should be an explicit statement that the behaviors are carried forward in the "obvious way". It's also not clear exactly which previously defined extensions are brought forward into TLS 1.3. I suspect that they are all listed in section 4.2, but is it clearly stated that those, and only those, are grandfathered in? Presumably, for any referenced extension, the placement of values in messages in TLS 1.2 has a "natural" analog in TLS 1.3 that at most involves moving the value from one field to another in certain messages. But it would be reassuring to have a clear statement of this, and an enumeration of any more complex cases. There are about 28 error codes but nearly 150 places where the text require the connection to be aborted with an error. There are 19 alone for "illegal_parameter".
[Gen-art] Genart last call review of draft-ietf-tram-stunbis-15
Reviewer: Dale Worley 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. Document: draft-ietf-tram-stunbis-15 Reviewer: Dale R. Worley Review Date: 2018-02-19 IETF LC End Date: 2018-02-20 IESG Telechat date: [unknown] Summary: This draft is on the right track but has open issues, described in the review. Overall, the draft is quite well organized and well written. But there are a number of open issues that have substantial technical content. I suspect that the intended design does not have these issues, and the issues that I see are just where the text hasn't been fully updated to match the intended design. Dale -- There is an issue that shows up in several places: The NAT may forward the request using an IP family that is different from the IP family that it received the request using. This means that the "source IP family of the request" may depend on whether one is speaking of the client or the server. The draft is cognizant of this, and mentions its consequences in sections 6.3.3 and 12. But this also has consequences for ALTERNATE-SERVER: Section 14.15 says "The IP address family MUST be identical to that of the source IP address of the request." even though that family might not be usable by the client. The draft doesn't seem to explicitly say that this comes from address-switching by the NAT. It would help if there was a higher-level discussion of this matter, pointing to the various consequences. The text contains these references to SHA algorithms (that it does not itself define). Some should be corrected: HMAC-SHA1 HMAC-SHA-1 should be HMAC-SHA1 per RFC 2104 HMAC-SHA256 HMAC-SHA-256 should be HMAC-SHA256 per RFC 6151, but HMAC-SHA-256 per RFC 6151! SHA1 SHA-1 It appears that the proper name of this function is SHA-1. SHA256 SHA-256 NIST calls this algorithm SHA-256. 3. Terminology This section needs to be updated to reference RFC 8174. 4. Definitions Although the definitions of STUN Client and STUN Server mention that they receive responses and requests (respectively), they don't mention that they also receive indications. 5. STUN Message Structure All STUN messages MUST start with a 20-byte header followed by zero or more Attributes. It would be clearer, I think, to say "All STUN messages comprise a 20-byte header followed by zero or more Attributes." 6.2.2. Sending over TCP or TLS-over-TCP The client MAY send multiple transactions over a single TCP (or TLS- over-TCP) connection, and it MAY send another request before receiving a response to the previous. s/the previous./the previous request./ This section should also state whether or not a server is allowed to provide responses in a different order than it received the requests, if it receives further requests before sending a response. o if multiplexing other application protocols over that port, has finished using that other application, and s/that other application/that other protocol/ 6.3.4. Processing an Error Response o If the error code is 300 through 399, the client SHOULD consider the transaction as failed unless the ALTERNATE-SERVER extension is being used. See Section 10. This syntax binds "section 10" to the entire preceding sentence, whose topic is error codes 300-399, whereas "section 10" only applies to ALTERNATE-SERVER. A better syntax would be o If the error code is 300 through 399, the client SHOULD consider the transaction as failed unless the ALTERNATE-SERVER extension (Section 10) is being used. 9.2. Long-Term Credential Mechanism Note that the long-term credential mechanism cannot be used to protect indications, since indications cannot be challenged. Usages utilizing indications must either use a short-term credential or omit authentication and message integrity for them. Alternatively, if there has been a recent request transaction between the client and the server, then a nonce have been established, and an indication can be sent securely using the long-term mechanism. (Although there is no mechanism for signaling if the nonce has become stale.) It seems to me plausible that some usage may wish to exploit this possibility. 9.2.1. Bid Down Attack Prevention To indicate that it supports this specification, a server MUST prepend the NONCE attribute value with the character string composed of "obMatJos2" concatenated with the Base64 [RFC4648] encoding of the 24 bit STUN Security Features as defined in Section 17.1. It might be informative to note that the encoding of the security features is
[Gen-art] Genart last call review of draft-ietf-mmusic-trickle-ice-sip-12
Reviewer: Dale Worley 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. Document: draft-ietf-mmusic-trickle-ice-sip-12 Reviewer: Dale R. Worley Review Date: 2018-01-23 IETF LC End Date: 2018-01-26 IESG Telechat date: [unknown] Summary: This draft is on the right track but has open issues, described in the review. This draft is technically quite good, and except for various nits, quite well written. But there are some significant technical issues that need to be properly settled before the protocol is well-defined with good advice on robust usage. I don't think settling these issues will be difficult. ** Global/major issues: * The tokens "end-of-candidate" and "end-of-candidates" seem to be used equivalently in this document, with the following number of uses: 11 end-of-candidate 19 end-of-candidates Which is the correct form? * The definition of application/trickle-ice-sdpfrag describes the use of "a=charset" as an attribute, but the grammar of sdpfrag in section 9 does not permit that attribute. * Deployment considerations (section 11) It might be worth mentioning here what happens if a middlebox deletes Trickle ICE INFO requests because it does not understand them, but does not delete "Supported: trickle-ice" headers. It seems to me that in order to be robust in this situation, a UA should provide a globally routable address in the m= lines of the initial offer or answer, or if Trickle ICE INFO requests fail, eventually amend the addresses to be globally routable addresses. But the WG may have more knowledge about this situation. * There are various locations where the language has usages that seem to me to be excessively informal or prolix. Cases I've noticed are: 2. Terminology It is assumed that the reader will be familiar with the terminology from both documents. Probably s/will be/is/. 3.1. Discovery issues Such Offers and Answers can only be handled meaningfully by agents that actually support incremental candidate provisioning, which implies the need to confirm such support before actually using it. It's probably best to omit "actually" here and elsewhere. There is also a use of "right from the first Offer". And in some places "would" is used where it is not needed or could be replaced by "do"; "would" should (IMO) be restricted to situations that are counter-factual. There is also a use of "like for example" instead of "for example". I expect the RFC Editor can give guidance on this subject. ** Detailed/editorial/nits: A Session Initiation Protocol (SIP) usage for Trickle ICE draft-ietf-mmusic-trickle-ice-sip-12 The current practice is to capitalize "usage" in this situation. (I expect the RFC Editor can give guidance on the current capitalization style for RFCs.) Abstract This document defines usage semantics for Trickle ICE with the Session Initiation Protocol (SIP) and defines a new SIP Info Package. Perhaps /a new SIP Info Package/a new SIP Info Package to support this usage/. Table of Contents The capitalization of section titles seems to be inconsistent. 1. Introduction It describes how ICE candidates are to be exchanged incrementally with SIP INFO requests [RFC6086] Probably s/exchanged incrementally with/exchanged incrementally using/, as "with" can be read to mean that the SIP INFO requests are one party which is exchanging. 4. Incremental Signaling of ICE candidates The following sections provide further details on how Trickle ICE Agents perform the initial Offers/Answers exchange (Section 4.1), perform subsequent Offers/Answers exchanges (Section 4.2) and establish the INVITE dialog usage (Section 4.3) such that they can incrementally trickle candidates (Section 4.4). I think you want to change "Offers/Answers" to "Offer/Answer". 4.3.1. Establishing dialog state through reliable Offer/Answer delivery It was stated in section 4.1, "Trickle ICE Agents MUST indicate support for Trickle ICE by including the SIP option-tag 'trickle-ice' in a SIP Supported: header field within all SIP INVITE requests and responses.", but it would be helpful to remind the reader in figure 3 by showing the Supported: headers: Alice Bob || | INVITE (Offer) | | Supported: trickle-ice | |--->| | 183 (Answer) | | Supported: trickle-
[Gen-art] Genart last call review of draft-ietf-slim-negotiating-human-language-19
Reviewer: Dale Worley 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://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>. Document: draft-ietf-slim-negotiating-human-language-19 Reviewer: Dale R. Worley Review Date: 2017-12-23 IETF LC End Date: 2017-12-22 IESG Telechat date: [unknown] Summary: This draft is ready for publication as a Standards Track RFC. No issues. [END] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-acme-acme-07
Reviewer: Dale Worley 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://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>. Document: draft-ietf-acme-acme-07 Reviewer: Dale R. Worley Review Date: 2017-10-24 IETF LC End Date: 2017-09-14 IESG Telechat date: 2017-10-26 Summary: This draft is on the right track but has open issues, described in the review. My general impression is that this is a sound piece of work, and apparently one that satisfies a serious practical need. But this draft has a large number of open issues, and really needs a careful, thorough clean-up pass. And until that's done, it's not clear what genuine problems might be lurking. I haven't put in the time I would have liked to, so some of the issues I've detected might prove to be nonexistent. A lot of these issues are simply English usage. The structure of the exposition needs to be improved, including pulling the specialized vocabulary into a glossary, providing overviews of processes whose multiple details are discussed, etc. Some issues are technical slips, like missing required fields in HTTP messages. Some seem to be more substantial technical issues -- What is the versioning and extensibility system? What are the requirements on POST operations that effectively carry no more information than that the operation happens? And one question -- the terms of service agreement -- seems to brush into legal territory. The number and variety of these minor problems suggests that the whole work needs to be thought through more carefully before being frozen. Within that context, I will not attempt to sort these items into categories or rate them on importance, but just list them in order by parts of the text that they relate to. And note that a number of these items are mentioned relative to only one of several places in the text they apply to. -- There's a lot of talk about accounts, but no overview of the lifecycle of an account. Compare to the presentation of the overview of the lifecycle of a certificate request. There should be blanket policies on whether and where non-standard fields can be included by both client and server. Also, there ought to be versioning of Acme itself. Abstract Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. I'm no expert here, but it seems to me that "the authentication of domain names" is not correct -- only actors can be authenticated. I think the accurate phrasing is "the authentication of servers (TLS, HTTPS, etc.) which act on behalf of domain names". (This would be a minor matter in the body, especially if this elision was universally used in the field, but an abstract should require little context.) Ditto for the first paragraph of section 1. DISCLAIMER: This is a work in progress draft of ACME and has not yet had a thorough security analysis. I assume that this is going to be removed once this document is published as an RFC. If the RFC hadn't had a thorough security analysis, there would be no value in publishing it as an RFC. However there is no attached statement indicating when this statement is to be removed. What is actually going on here? Table of Contents 6.4. Replay protection 6.4.2. "nonce" (Nonce) JWS header parameter 6.5. Rate limits These section titles aren't capitalized the same way as the other section titles. 1. Introduction Existing Web PKI certificate authorities tend to run on a set of ad hoc protocols for certificate issuance and identity verification. s/run on/use/? a typical user experience is something like: I think you want to broaden this to "a typical protocol is". That doesn't change things much, because the user is one endpoint of the protocol. But you don't want to de-emphasize what the CA does, either. (I reflexively think of this as a protocol problem, whereas the authors probably reflexively think of this as a user experience problem.) * Put a CA-provided challenge at a DNS location corresponding to the target domain. What does "corresponding to" mean? I think you want "in a DNS record for the target domain". * Receive CA challenge at a (hopefully) administrator-controlled email address corresponding to the domain and then respond to it on the CA's web page. s/CA challenge/CA-provided challenge/ for parallelism. s/corresponding to the domain/within the domain/? It seems that there should be an item between the third a
[Gen-art] Genart last call review of draft-ietf-tcpinc-tcpcrypt-07
Reviewer: Dale Worley 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://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>. Document: review-draft-ietf-tcpinc-tcpcrypt-07 Reviewer: Dale R. Worley Review Date: 2017-10-18 IETF LC End Date: 2017-10-19 IESG Telechat date: 2017-10-26 Summary: This draft is basically ready for publication, but has nits that should be addressed before publication. * Major/global items: 1. The construction _phrase_ is used in many places. The construction "phrase" is also used frequently. It's not clear if these have specific semantics, though _..._ seems to be used for defining instances of a term, and "..." seems to be used around mathematical notation. What syntax(es) are intended to be used in the RFC, and with what meaning(s)? The RFC Editor can probably make recommendations here. 2. Section 1 should be updated to use the language of BCP 14 (RFC 8174) section 2. 3. The term "key agreement scheme" doesn't seem to be used consistently. In a narrow sense, it seems to be used for the initial phases of the encryption. In a broad sense, it seems to be used for the set of algorithm selections, key lengths, and magic numbers that are used by the tcpcrypt algorithm, a set identified by a particular TEP identifier. The two can be confused, because it seems that only a few items in the set can be varied using the 4 defined TEP identifiers. But I reflexively assume that all of these parameters can be varied within the overall scheme of "tcpcrypt". Is it the intention that the TEP identifier *only* specifies the key agreement scheme in the narrow sense, and we are *committing* to never varying the other parameters? Or are we taking the more natural path that the TEP identifier specifies all of these parameters, but the currently defined values all specify the same values for all but one parameter? In either case, we need to make the overall scheme clear early on and use the terminology consistently. 4. The positioning of the tables seems to be poor relative to the sections which refer to them. Presumably the RFC Editor will clean that up. 5. Does draft-ietf-tcpinc-tcpeno require that the application can query the stack to find out whether encryption was established vs. the connection has fallen back to being unencrypted? 6. It might be worth adjusting the rules for how the A and B roles are carried forward during session resumption. Of course, each host should compute the resumption identifier that it expects to receive based on the role it had in the previous session. But it's not clear to me why a host that used k_ab for encryption (i.e., had the A role) in the previous session must also use k_ab for encryption in the resumed session, since the two sequences of k_ab/k_ba are generated from the different session keys of the two sessions. If you made the choice of k_ab/k_ba be dependent on the A/B roles established by TCP-ENO for *this* session, it seems like the specification of the protocol would be a bit simpler. 7. In the encryption frame, it seems to me that the (unencrypted) control byte could be eliminated and the rekey flag put into the (encrypted) flags byte, if we define that rekey=1 means that rekeying takes effect on the *next* frame rather than the current one. However, that would eliminate the 7 reserved unencrypted flags the frame format now has, which might be useful in the future. (I suspect that the usefulness of an unencrypted field in the frame is something that cryptographers understand but I don't.) * Minor/editorial items: Table of Contents 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 The names of these three sections aren't capitalized like those of other section. 3.1. Cryptographic algorithms o A _collision-resistant pseudo-random function (CPRF)_ is used to generate multiple cryptographic keys from a pseudo-random key, typically the output of the extract function. The CPRF is defined to produce an arbitrary amount of Output Keying Material (OKM), and we use the notation CPRF(K, CONST, L) to designate the first L bytes of the OKM produced by the pseudo-random function identified by key K on CONST. It is unclear what "the pseudo-random function identified by key K" means, as only three functions have been identified to this point, and none of them seem to have identifiers. It sounds like CPRF is defined to produce an endless stream of OKM based on two inputs, K and CONST -- T(1) | T
[Gen-art] Genart telechat review of draft-ietf-bess-evpn-etree-13
Reviewer: Dale Worley 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-bess-evpn-etree-13 Reviewer: Dale R. Worley Review Date: 2017-09-12 IETF LC End Date: 2017-08-09 IESG Telechat date: 2017-09-12 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. There are a few matters that I would like to see amplified in the Introduction to improve the exposition for readers who aren't familiar with this area. 1. Relationship to RFC 7432. The Introduction now states "Since this document specifies a solution based on [RFC7432], it requires the readers to have the knowledge of [RFC7432] as prerequisite." This is a significant improvement, but I still find this unsatisfyingly vague regarding the relationship between the two documents. Is RFC 7432 only background knowledge, or is this document an extension/modification of RFC 7432, in which case, some parts of the technique described in this document are actually defined in RFC 7432? It seems a minor change of wording of this sentence could make this clear. 2. Management: The document doesn't describe how the EVPN structure will be set up (e.g., how endpoints are added or deleted from the structure, what MPLS labels will be used), nor how choice of the many technology alternatives will be communicated (e.g., 2.1 vs. 2.2 vs. 2.3; approach A vs. approach B). I suspect that this is normal for documents defining VPN techniques, but it seems peculiar for me, as the areas I'm familiar with (SIP and data-center networking) try to minimize the amount of "configuration" that needs to be done. It might help the reader to list in the Introduction what aspects of set-up are out of scope for the document, and conversely, what aspects you've arranged for the control plane to handle automatically (which are benefits of the technique). 3. Efficiency: The Abstract and the final paragraph of the Introduction mention that this technique is more efficient than that of RFC 7796, and of course that is a major motivation for this work. But the nature of the improved efficiency is only detailed in section 3.1. It would help the reader, I think, to mention the nature of the improved efficiency in the Introduction, and perhaps to mention the specific traffic patterns where this improved efficiency is particularly effective. This helps the reader know when reading the document will be particularly valuable. There are a few nits I noticed: Abstract solution based on RFC7432, BGP MPLS Based Ethernet VPN (EVPN), with some extensions and how such a solution can offer a more efficient implementation of these functions than that of RFC7796, E-Tree Support in Virtual Private LAN Service (VPLS). This document makes In the same way as you quote the title of RFC 76387, it would be more readable if you quoted the titles of the other two RFCs. 1 Introduction Attachment Circuits (AC) (e.g., an Ethernet tag but may also be represented by a MAC address) is labeled as either a Root or a Leaf I assume "tag" means 802.1q VLAN tag, but it would be helpful to spell that out. 1.2 Terminology Ethernet Segment Identifier (ESI): A unique non-zero identifier that identifies an Ethernet segment is called an 'Ethernet Segment Identifier'. What universe is the ESI is unique over? [END] ___ 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-homenet-dot-12
Reviewer: Dale Worley 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://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>. Document: draft-ietf-homenet-dot-12 Reviewer: Dale R. Worley Review Date: 2017-08-24 IETF LC End Date: 2017-08-25 IESG Telechat date: 2017-08-31 Summary: This draft is ready for publication as a Standards Track RFC. It has some nits that should be considered before publication. 4. Domain Name Reservation Considerations 3. Name resolution APIs MUST send queries for such names to a recursive DNS server that is configured to be authoritative for the 'home.arpa.' zone appropriate to the homenet. If I understand the terminology correctly, this rules out sending the query to a DNS server that recursively sends the query to a server that is authoritative for home.arpa. If that is intended and there are technical reasons for making this prescription, that's OK, but I want to check that that is intended, as this rule is stricter than the similar rule in the second paragraph of item 4, which is qualified "Unless configured otherwise". 4. Domain Name Reservation Considerations There are 5 paragraphs under item 4. It might be worth giving them separate numbers, or if they truly form a unified topic, giving them sub-numbers 4a, 4b, etc. 6. Security Considerations Therefore, the only delegation that will allow names under 'home.arpa.' to be resolved is an insecure delegation, as in [RFC6303] section 7. In context what this means is clear, but its literal meaning is sufficiently incorrect that I think it could be clarified, perhaps to Therefore, the only delegation that will allow names under 'home.arpa.' to be resolved by a validating resolver that is not aware of the local meaning is an insecure delegation, as in [RFC6303] section 7. [EOF] ___ 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-etree-12
Reviewer: Dale Worley
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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-bess-evpn-etree-12
Reviewer: Dale R. Worley
Review Date: 2017-08-07
IETF LC End Date: 2017-08-09
IESG Telechat date: 2017-08-17
Summary:
This draft is on the right track but has open issues, described in the
review. A few of the issues are directly technical.
Reading this draft, I have the sense that it isn't so much a
specification as the description of an idea, which is that EVPN can be
used to implement E-Tree functionality. It reads as if someone who is
extremely knowledgeable about EVPN is outlining the idea to someone
similar, given that various details don't seem to be worked out
completely and that in several places there are alternative
implementation methods that are mentioned but do not seem to be
rigorously enumerated. The document seems to more describe *class* of
ways of implementing E-Trees, and not a rigidly delimited class.
As far as I can tell, the idea works, but I suspect that an
implementor would not just be following the specification but
completing it in many respects. Given that the document seems to
extend the mechanisms of RFC 7432, I suspect that an implementor would
have to carefully work out the details of all the BGP announcements,
and that not all implementations would interoperate. E.g., "This Leaf
label is advertised to other PE devices, using the E-TREE Extended
Community" sounds to me like it's very under-specified.
The way forward seems to be clear: The draft needs to be edited
carefully, filling in the missing details and making more explicit and
rigid the various implementation alternatives. It might be worth
enumerating all of the mentioned implementation choices in one place,
as successful interoperation requires that all devices in a VPN are
using the same choices. And I think interoperation needs to be
emphasized -- two devices that implement this draft should
interoperate if they are configured to have the same choices of the
implementation choices enumerated in the draft. Otherwise, this draft
is just the outline for a dozen vendors' similar-but-not-interoperable
proprietary products.
Abstract
This document
discusses how those functional requirements can be easily met with
Ethernet VPN (EVPN) and how EVPN offers a more efficient
implementation of these functions.
"More efficient" than what? The abstract reads as if this document is
an alternative method of implementing E-Tree, but I read well into the
draft before it became clear that this draft is an alternative to RFC
7387, rather than that this draft and RFC 7387 are an alternative to
something else. The abstract does not specifically state all of the
relationships between the specifications it mentions.
And although this mechanism is described as "more efficient", there
doesn't seem to be any discussion of how it is more efficient. You
don't need a lot of detail for this, but it would be helpful if there
was at least a brief description of what way it is more efficient and
some indication of the degree.
Also, what is relationship between "EVPN" and this document? Is EVPN
a widely-known technology whose name need not be footnoted? Is it
something defined in this document? Importantly, is the usage in this
document a subset within some defined EVPN specification, or is it a
modification/extension of EVPN?
This document makes use of the
most significant bit of the scope governed by the IANA registry
created by RFC7385, and hence updates RFC7385 accordingly.
The use of "scope" is peculiar here. Generally, "scope" refers to a
region of some sort of space, so one would say "scope value" or "scope
value field" to refer to a group of bits that designate a scope. But
checking with RFC 7385 and the IANA registry page for "Border Gateway
Protocol (BGP) Parameters", I am unable to find any occurrence of the
word "scope". And other than a very similar passage in section 1,
"scope" only appears in this document in the phrase "scope of this
document". Perhaps "scope" should be "tunnel type"?
Table of Contents
What is the capitalization rule you're using for section titles?
E.g., sections 3.2.{1,2,3,4} are capitalized in a decidedly different
way that other sections.
1 Introduction
The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
Ethernet service known as Ethernet Tree (E-Tree) [MEF6.1]. In an E-
Tree service, Attachment Circuits (ACs) are labeled as either Root or
Leaf ACs. Root AC
[Gen-art] Genart last call review of draft-ietf-pce-pceps-14
Reviewer: Dale Worley 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-pce-pceps-14 Reviewer: Dale R. Worley Review Date: 2017-07-11 IETF LC End Date: 2017-07-12 IESG Telechat date: 2017-08-03 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Nits/editorial comments: A few of these may rise to the level of minor technical issues, especially: section 3.2: whether error TBA2/2 is distinct from error 1/1 section 3.2: the receipt of an PCErr during the failure of TLS establishment section 3.3: the distinction between StartTLSWait and OpenWait section 5: a full discussion of backward compatibility considerations section 8.2: MIB extension 1. Introduction This document describes a security container for the transport of PCEP messages, and therefore they do not affect the flexibility and extensibility of PCEP. There is no plural antecedent for "they" to reference. I think you could use "it", but the Editor may have better suggestions. 3.2. Initiating the TLS Procedures with a PCErr message with Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure) It seems that we shouldn't use this Error-Type to object to the use of a message other than Open and StartTLS as an initial message, as that error isn't a misuse of StartTLS per se and is only incidentally related to StartTLS. Indeed, isn't there already an Error-Type for this error (unexpected initial message), since two RFC 5440 implementations can commit/detect it? Looking at RFC 5440 section 7.15, I see: Error-TypeMeaning 1 PCEP session establishment failure Error-value=1: reception of an invalid Open message or a non Open message. It seems to me that this document is adjusting the meaning of error 1/1, rather than defining a new error situation. If the PCEP speaker that does not support PCEPS, receives a StartTLS message, it MUST behave according to the existing error mechanism described in section 6.2 of [RFC5440] (in case message is received prior to an Open message) or section 6.9 of [RFC5440] (for the case of reception of unknown message). I think you want s/MUST/will/, since the described behavior isn't specified by this document, but rather by RFC 5440. In any case, this paragraph might want to reference the backward-compatibility consideration that I would expect to appear in section 5 -- How does the PCEPS-supporting element deal with the non-PCEPS-supporting element after the connection attempt with StartTLS fails? After the exchange of startTLS messages, if a PCEP speaker cannot establish a TLS connection for some reason (e.g. the required mechanisms for certificate revocation checking are not available), it MUST return a PCErr message (in clear) with Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure) and Error-value set to: s/startTLS/StartTLS/ Is there a well-defined way for a participant in a TLS connection start to receive *either* a PCErr message in the clear *or* whatever comes next in TLS setup -- and know which case has happened? Is there a way to use popular modular TLS libraries and have the application above the library receive such a PCErr message? I don't understand TLS nearly well enough to know the answer to this, but it would probably help implementors if answers were given to these questions. The peer MAY choose to re-establish the PCEP session without TLS next. I think you mean "The peer that initiated the connection MAY choose to re-establish ...". As written, "the peer" seems to refer to the peer that generated the PCErr, but if it was the receiving peer that generated the PCErr, you probably don't want it to attempt to re-establish the session but rather wait for the initiating peer to do so. Given the asymmetric nature of TLS for connection establishment it is relevant to identify the roles of each of the PCEP peers in it. The PCC SHALL act as TLS client, and the PCE SHALL act as TLS server, according to [RFC5246]. See comments re section 4 about terminology. I think you need to have terms for the element that is initiating the connection (either a PCC or a PCE) and the element that is receiving the connection (always a PCE). 3.3. The StartTLS Message Once the TCP connection has been successfully established and the StartTLS message sent, the sender MUST start a timer called StartTLSWait timer, after the expiration of which, if no StartTLS message has been recei
[Gen-art] Genart last call review of draft-ietf-trill-arp-optimization-08
Reviewer: Dale Worley 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. Document: draft-ietf-trill-arp-optimization-08 Reviewer: Dale R. Worley Review Date: 2017-06-28 IETF LC End Date: 2017-06-29 IESG Telechat date: unknown Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Abstract This document describes mechanisms to optimize the ARP (Address Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL campus. s/in TRILL campus/in a TRILL campus/ Perhaps summarize what the optimizations are: Each edge RBridge maintains a cache of IP/MAC address/Data Label bindings that are learned from ARP/ND requests and responses that pass through it. This cache allows it to avoid flooding an ARP/ND request by either responding to it directly or by encapsulating it and unicasting it to the location where it is in use. 2 ARP/ND Optimization Requirement and Solution (including DHCP or gratuitous ARP_messages). s/_// and should allow an end station to detect duplicate IP addresses. Unless this is a well-known phrase, it would be best if it was clear whether the end station is detecting that its own IP address is duplicated, or whether it is detecting that some other station's IP address is duplicated. TRILL already provides an option to disable data-plane learning from the source MAC address of end-station frames on a per port basis (see Section 5.3 of [RFC6325]). Given how this section is written, shouldn't this option be considered an option to *enable* data-plane learning? And in particular, doesn't that imply that TRILL already includes a solution to suppress ARP flooding? Also, what is the meaning of "learning from the source MAC address"? It seems like you'd want to specify what the learning is *of*, and then perhaps what it is learned *from*. Or is this particular learning of MAC addresses alone, and not of IP/MAC bindings? If so, then isn't this feature orthogonal to ARP/ND optimization? As a design matter, I'm curious why an RBridge can't learn IP/MAC bindings by snooping data packets, and only by snooping ARP packets. I suspect there are good reasons for it, but the naive reader (me) is left wondering... 4.1 SEND Considerations Secure SEND messages require knowledge of cryptographic keys. Methods of communicating such keys to RBridges for use in SEND are beyond the scope of this document. Thus, using the optimizations in this document, RBridges do not attempt to construct SEND messages and are generally transparent to them. RBridges only construct ARP, RARP, or insecure ND messages, as appropriate. This doesn't flow quite correctly. The second sentence suggests that there are known mechanisms for distributing keys to RBridges, but that this document doesn't describe them. The reader then expects that the third sentence will say that if RBridges are provisioned with keys in an environment, they can generate SEND responses. But instead, the real meaning of the second sentence seems to be that there are no such ways of distributing keys to RBridges and therefore they can't generate SEND responses. That suggests that the second sentence should be rephrased: There are no methods of communicating such keys to RBridges for use in SEND, and thus RBridges cannot construct SEND messages and must be generally transparent to them. Or perhaps "SEND forbids communicating such keys to RBridges, and thus...". 4.3 Get Sender's IP/MAC Mapping Information for Non-zero IP What is "non-zero IP"? Is this the case discussed in section 4.4 item (d)? (If so, it also includes "a Neighbor Solicitation for DAD ... which has the unspecified source address".) Perhaps the property being described is "Get Sender's IP/MAC Mapping Information from Non-Address Probe ARP/ND Queries". 4.4 Determine How to Reply to ARP/ND It is not essential that all RBridges use the same strategy for which option to select for a particular ARP/ND query. It is up to the implementation. It appears that the division between options (a), (b), (c), and (d) are fixed by the draft, so this statement is rather confusing. Also, "It is up to the implementation." is a bit awkward. Perhaps: Within each item, it is an implementation decision which strategies to use for any particular ARP/ND query falling under that item. -- Because the edge RBridge might not have an IPv6 address, the source IP address for such an ND response MUST be that of the target end station. Wouldn't the source IP address for such an ARP response also be that of the target end station, g
[Gen-art] Genart telechat review of draft-ietf-grow-bgp-reject-08
Reviewer: Dale Worley 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-grow-bgp-reject-08 Reviewer: Dale R. Worley Review Date: 2017-06-01 IETF LC End Date: 2017-04-18 IESG Telechat date: 2017-06-08 Summary: This draft is ready for publication as a Standards Track RFC. [END] ___ 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-reject-07
Reviewer: Dale Worley 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-grow-bgp-reject-07 Reviewer: Dale R. Worley Review Date: 2017-05-19 IETF LC End Date: 2017-04-18 IESG Telechat date: 2017-06-08 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. My knowledge of BGP is quite limited, so I cannot review the desirability of this solution. I assume that the routing and operations community has fully considered that question. 1. Introduction BGP routing security issues need to be addressed in order to make the Internet more stable. Route leaks [RFC7908] are part of the problem, but software defects or operator misconfiguration can contribute too. This document updates [RFC4271] in order to improve the default level of Internet routing security. This paragraph is a good introduction, but it isn't very cohesive. I suggest revising the third sentence to something like: This document updates [RFC4271] so that routes are neither imported nor exported unless specifically enabled by configuration, thus reducing route leaks, and so improving the default level of Internet routing security. Then again, considering section 5 paragraph 1, perhaps this update reduces all three causes (route leaks, software defects, and operator misconfigurations), in which case you could say This document updates [RFC4271] so that routes are neither imported nor exported unless specifically enabled by configuration, thus reducing the consequences of these problems, and so improving the default level of Internet routing security. -- BGP speakers following this specification do not use or send routes on EBGP sessions, unless configured to do otherwise. This sentence seems to be correct as written, but somehow it reads awkwardly to me. I think the problem is that "do otherwise" is used, when the "otherwise" is "do not use ...". I think it would read more smoothly to say: BGP speakers following this specification do not use or send routes on EBGP sessions, unless specifically configured to do so. Perhaps the Editor should be consulted about this. -- 2. Terminology [RFC4271] describes a Policy Information Base (PIB) which contains local policies that can be applied to the information in the Routing Information Base (RIB). This document distinguishes the type of policy based on its application. Here, you want to say "the type of a policy" or "the type of a particular policy", because "policy" refers to a specific policy within a set of policies, rather than being a mass noun. 3. Changes to RFC4271 This section describes the Updates to [RFC4271] that define the default behavior of a BGP speaker when there are no Import or Export Policies associated with a particular EBGP session. Of course, there is no need to capitalize "Updates". The wording "describes the updates" is awkward. Really, it lists or specifies the updates, rather than describing them. Also, the use of "updates ... that ..." suggests that there is a larger set of updates from which "the updates that define the default behavior" are selected, and that smaller set will be described in this section. Instead, there are updates, and those updates define the default behavior. So I think a better wording is: This section updates [RFC4271] to change the default behavior ...". It's probably worth consulting the Edtior to see if a better wording is possible. -- The following paragraph is added to Section 9.1 (Decision Process) after the fifth paragraph ending in "route aggregation and route information reduction": Strictly, this says that there are five paragraphs which end in "route aggregation and route information reduction", and the fifth of them is being discussed. The correct wording is 'the fifth paragraph, which ends in "route aggregation and route information reduction"'. The following paragraph is added to Section 9.1.3 (Phase 3: Route Dissemination) after the third paragraph ending in "by means of an UPDATE message (see 9.2).": Similarly, this should be 'the third paragraph, which ends in "by means of an UPDATE message (see 9.2)."' 5. Security Considerations Permissive default routing policies can result in inadvertent effects such as route leaks [RFC7908], in gen
[Gen-art] Genart telechat review of draft-ietf-i2nsf-problem-and-use-cases-15
Reviewer: Dale Worley 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. Document: draft-ietf-i2nsf-problem-and-use-cases-15 Reviewer: Dale R. Worley Review Date: 2017-05-09 IETF LC End Date: 2017-03-22 IESG Telechat date: 2017-05-11 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. There is one remaining nit: 2. Terminology Security Service Provider:A provider of security services to the customers (end-users or enterprises) using NSF equipment purchased from vendors or created by the service provider. Per my discussion with the authors, the intended style is to not specifically capitalize the term "security service provider". Hence, this entry headword should be "Security service provider". [END] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-i2nsf-problem-and-use-cases-12
Reviewer: Dale Worley 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. Document: draft-ietf-i2nsf-problem-and-use-cases-12 Reviewer: Dale R. Worley Review Date: 2017-04-23 IETF LC End Date: 2017-03-22 IESG Telechat date: 2017-04-27 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. All of these nits are editorial. 3.1.1. Diverse Types of Security Functions Security gateways and VPN concentrators:Examples of these functions are; IPsec gateways, Secure VPN concentrators that handle bridging secure VPNs, and secure VPN controllers for data flows. Unless "Secure VPN" is a name in itself, "secure" shouldn't be capitalized. (Between -11 and -12, one instance of this was fixed, but the other one remains.) 3.1.2. Diverse Interfaces to Control and Monitor NSFs A challenge for monitoring prior to mitigation of a security intrusion is that an NSF cannot monitor what it cannot view. Therefore, enabling a security function to mitigate an intrusion (e.g., firewall [I-D.ietf-opsawg-firewalls]) does not mean that a network is protected if there is no monitoring feedback. As such, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs. This paragraph still seems to have problems. What the second sentence seems to mean (though it doesn't say it) is that if you enable a security function, you don't *know* that the network is protected if you don't have any monitoring feedback. (The sentence is stated in terms of whether the network *is* protected, which it might well be, even if you don't have monitoring.) It seems that you need to replace "does not mean that a network is protected" with something that is more literally correct. The third sentence is constructed "... to have a mechanism to monitor and provide execution status of NSFs to ...". There's an awkwardness that "monitor" isn't connected to "security and compliance management tools", whereas "provide ... status ... to" *is* connected; there's a problem that the "monitor" and "provide" are written as if they're parallel, but they're not. I think the wording is less confusing this way: As such, it is necessary to have a mechanism to monitor NSFs and provide their execution status to security and compliance management tools. -- There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting, but an industry standard interface could provide monitoring across a variety of NSFs. I think it's easier to read "vendor-specific network security monitoring interfaces". 3.1.4. More Demand to Control NSFs Dynamically The Security Service Providers ... The capitalization of "security service providers" is inconsistent. Some times all three words are capitalized (in 3.1.2, 3.1.4, and 4), and some times they're not (two places in 3). 3.2.2. Today's Control Requests are Vendor Specific Managing by scripts de-jour:The current practices rely upon the use of scripts that generate other scripts which automatically run to upload or download configuration changes, log information and other things. These scripts have to be adjusted each time an implementation from a different vendor technology is enabled by a provider side. What is "a provider side"? I suspect it means "the provider side of an XXX", but I'm not familiar enough with the subject to know what XXX is. [END] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-i2nsf-problem-and-use-cases-11
Reviewer: Dale Worley 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. Document: draft-ietf-i2nsf-problem-and-use-cases-11 Reviewer: Dale R. Worley Review Date: 2017-03-14 IETF LC End Date: 2017-03-22 IESG Telechat date: [unknown] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. All of these nits are editorial. 1. Introduction This document describes the problem statement for Interface to Network Security Functions (I2NSF) as well as some I2NSF use cases. A summary of the state of the art in the industry and IETF which is relevant to I2NSF work is documented in [I-D.hares-i2nsf-gap-analysis]. The content of these sentences is very good, but the construction seems to be peculiar. The document doesn't *describe* the problem statement, the document *is* a statement. Similarly, hares-i2nsf-gap-analysis *is* a summary of the state of the art. So I would use This document is the problem statement for Interface to Network Security Functions (I2NSF) as well as some I2NSF use cases. A summary of the state of the art in the industry and IETF which is relevant to I2NSF work is [I-D.hares-i2nsf-gap-analysis]. But maybe you'll prefer to ask the RFC Editor. This document also briefly describes the following use cases summarized by [I-D.pastor-i2nsf-merged-use-cases]: This sentence should start a new paragraph, as it's not connected to the sentences before it. 3. Problem Space The following sub-section describes ... s/sub-section describes/sub-sections describe/ 3.1.1. Diverse Types of Security Functions NSFs by different vendors can have different features and have different interfaces. It might be worth mentioning somewhere what seems to be a convention: the document (or at least, section 3.1) is largely oriented toward "service providers" who sell comprehensive network services (including security functions) to "customers", but who in turn buy security functions from "vendors". Perhaps this could be entered as terminology in section 2. The reason I mention this is that my background is as an end-user (which is common in the IETF), so the term "service provider" triggers in my mind the idea "someone I buy something from". And the term "vendor" triggers the *same* idea. But in this draft, the default reader is a "service provider" and "vendor" is *not* the same thing. This point started to confuse me at the beginning of section 3.1.6. Security Functions in a Demilitarized Zone (DMZ): Examples of this function are firewall/ACLs, IDS/IPS, one or all of AAA services NAT, forwarding proxies, and application filtering. The phrase "one or all of AAA services NAT" seems to be incorrect. I suspect there's supposed to be a comma before NAT. Security gateways and VPN concentrators:Examples of these functions are; IPsec gateways, Secure VPN concentrators that handle bridging secure VPNs, and Secure VPN controllers for data flows. Unless "Secure VPN" is a name in itself, "secure" shouldn't be capitalized. 3.1.2. Diverse Interfaces to Control and Monitor NSFs A challenge for monitoring is that an NSF cannot monitor what it cannot view. Therefore, enabling a security function (e.g., firewall [I-D.ietf-opsawg-firewalls]) does not mean that a network is protected. As such, it is necessary to have a mechanism to monitor and provide execution status of NSFs to security and compliance management tools. There exist various network security monitoring vendor-specific interfaces for forensics and troubleshooting. This paragraph seems awkward. Each sentence is reasonable, but the connection between them is not clear to me. Perhaps the third sentence has the meaning "... it is necesary to have a mechanism ...to verify that the NSF is seeing the traffic that is intended". The last sentence contains "network security monitoring vendor-specific interfaces" which is awkward. Perhaps There exist various vendor-specific interfaces for network security monitoring, forensics, and troubleshooting. 3.1.4. More Demand to Control NSFs Dynamically The Security Service Providers ... The capitalization of "security service providers" is inconsistent. Some times all three words are capitalized, and some times they're not. 3.1.5. Demand for Multi-Tenancy to Control and Monitor NSFs Service providers may need several operational units to control and monitor the NSFs, especially when NSFs become distributed and virtualized. You may want to explain wh
[Gen-art] Review of draft-ietf-dane-smime-15
Reviewer: Dale Worley
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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-dane-smime-15
Reviewer: Dale R. Worley
Review Date: 2017-02-26
IETF LC End Date: 2017-03-03
IESG Telechat date: 2017-03-16
Summary: This draft is basically ready for publication, but has nits
that should be fixed before publication.
* Technical points
1. I assume that in parallel with RFC 6698, DNAME records must be
followed during SMIMEA resolution. It's not clear to me whether
CNAME
records must also be followed or how, given that SNAMEA records are
not for host names, but their grandparent node is a host name.
2. Presumably it was deliberate not to have the first label for an
SNAMEA record be the canonical UTF-8 string for the local-part, even
though the DNS architecture (RFC 1035) seems to admit binary labels.
3. Presumably it was deliberate to hash using SHA2-256 truncated to
224
bits rather than use SHA-224.
4. Is it worth suggesting that some mechanism might be devised for
annotating an e-mail message with the canonical form of the sender's
local-part that is intended to be used to authenticate the message?
The last sentence of the 1st paragraph of section 1 suggests that
this
is deliberately out of scope for this document, but it might be worth
suggesting experimentation regarding this in section 4, which seems
to
be entirely about further experimentation.
* Editorial/Nits
Should there be an explicit statement that the resolver must follow
CNAME and DNAME records? That seems to be required by RFC 6698
section A.2.1, but that requirement is buried rather deeply. Also,
is
CNAME following required? My vague understanding is that CNAME can
only be used to alias host names, and SMIMEA records are not for host
names (contrasting with the DANE records for TLS) -- though the
grandparent node of any SNAMEA is a host name.
Also, some adjustments of the resolution process of RFC 6698 re CNAME
records were made in RFC 7671, but this draft only mentions 7671 in
passing, in the introduction. It seems that it should be noted that
7671 contains a lot of operational information about DANE.
1. Introduction
There are other requirements on the MUA, such as
associating the identity in the certificate with that of the
message,
that are out of scope for this document.
"that of the message" isn't quite right, as "that" is parallel to
"the
identity", and the message doesn't itself have an identity. More
accurate would be "the purported sender of the message", as was used
in 3rd sentence of the paragraph.
2. The SMIMEA Resource Record
... the semantics are also the same except
where RFC 6698 talks about TLS at the target protocol for the
certificate information.
s/TLS at/TLS as/
3. Location of the SMIMEA Record
The DNS does not allow the use of all characters that are
supported
in the "local-part" of email addresses as defined in [RFC5322] and
[RFC6530].
I don't have the full background on this. My memory ends at RFC
1035:
Although labels can contain any 8 bit values in octets that make
up a
label, it is strongly recommended that labels follow the
preferred
syntax described elsewhere in this memo, which is compatible with
existing host naming conventions.
I suspect there is by now a defined way to have "UTF-8 labels".
Given
that this draft doesn't use such a mechanism, there's probably a
discussion out there why just using a UTF-8 string as a label doesn't
work. It would be helpful to put a reference to that discussion
here,
because the mechanism in the draft is doing a lot of work to avoid
the
seemingly obvious mechanism.
2. The local-part is first canonicalized using the following
rules.
If the local-part is unquoted, any whitespace (CFWS) around
dots
(".") is removed. Any enclosing double quotes are removed.
Any
literal quoting is removed.
I think this could be more exactly expressed along the following
lines. Given the costs of not having this implemented exactly the
same way in all implementations, it's probably worth the extra words.
2. The local-part is first canonicalized using the following
rules. If the local-part is unquoted, any whitespace (CFWS)
around dots (".") is removed. If the local-part is quoted,
the
enclosing double quotes, contained FWS, and the initial
backslashes of quoted-pairs are removed. (The obsolete
local-part format obs-local-part is canonicalized similarly:
CFWS around dots is removed and any word component that is a
quoted-string i
[Gen-art] Review of draft-ietf-slim-negotiating-human-language-06
Reviewer: Dale Worley 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-slim-negotiating-human-language-06 Reviewer: Dale R. Worley Review Date: 2017-02-17 IETF LC End Date: 2017-02-20 IESG Telechat date: [unknown] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. * Technical comments A. Call failure If a call fails due to no available language match, in what way(s) does it fail? Section 5.3 says If such an offer is received, the receiver MAY reject the media, ignore the language specified, or attempt to interpret the intent But I suspect it's also allowed for the UAS to fail the call at the SIP level. Whether or not that is allowed (or at least envisioned) should be described. And what response code(s)/warn-code(s) should be used for that? B. Audio/Video coordination 5.2. New 'humintlang-send' and 'humintlang-recv' attributes Note that while signed language tags are used with a video stream to indicate sign language, a spoken language tag for a video stream in parallel with an audio stream with the same spoken language tag indicates a request for a supplemental video stream to see the speaker. And there's a similar paragraph in 5.4: >A spoken language tag for a video stream in conjunction with an audio >stream with the same language might indicate a request for >supplemental video to see the speaker. I think this mechanism needs to be described more exactly, and in particular, it should not depend on the UA understanding which language tags are spoken language tags. It seems to me that a workable rule is that there is an audio stream and a video stream and they specify exactly the same language tag in their respective humintlang attributes. In that case, it is a request for a spoken language with simultaneous video of the speaker, and those requests should be considered satisfied only if both streams can be established. * The following three items are adjustments to the design which I'd like to know have been considered. C. "humintlang" seems long to me Given the excessive length of SDP in practice, it seems to me that a shorter attribute name would be desirable. E.g., "humlang" as was used in some previous versions. Or is there a coordinated usage with other names in the "hum*lang" pattern? D. Use the Accept-Language syntax It seems to me that it would better to use the Accept-Language syntax for the attribute values. This allows (1) specifiying the quality of language experience, allowing clear description of bilingualism, (2) a unified method of specifying whether or not arbitrary languages are acceptable, and (3) abbreviating SDP descriptions. In a way, the fact that the current proposal seems to require (but does not directly specify) the coordinated absence/presence of an asterisk on all of the repetitions of humintlang-send or humintlang-recv is a warning that the syntax doesn't represent the semantics as well as it might. E. Have an attribute to abbreviate the bidirectionally-symmetric case Note that all examples are bidirectionally symmetric, and the text says that requests and responses SHOULD be bidirectionally symmetric. So it would be a very useful abbreviation to define "humintlang=" to be equivalent to the combination of "humintlang-send=" and "humintlang-recv=". Combining proposals C, D, and E, the examples become m=audio 49170 RTP/AVP 0 a=humlang:en m=video 51372 RTP/AVP 31 32 a=humlang:ase,*;q=0.1 m=audio 49250 RTP/AVP 20 a=humlang:es,eu;q=0.9,en;q=0.8,*;q=0.1 m=text 45020 RTP/AVP 103 104 a=humlang:gr which requires about half as many characters as they have now. * Editorial comments and nits Abstract This document describes the need and a solution using new SDP stream attributes. I don't think the term "stream attribute" is used in RFC 4566. Instead, it uses "media attribute". 1. Introduction caller and callee know each other or there is contextual or out of band information from which the language(s) and media modalities can I think this context, it's preferred to hyphenate "out-of-band" to make it clearly be an adjective. This approach has a number of benefits, including that it is generic (applies to all interactive communications negotiated using SDP) and not limited to emergency calls. I think s/and not limited to/and is not limited to/ reads more smoothly. But it is clearly useful in many other cases.
[Gen-art] Review of draft-ietf-dmm-4283mnids-04
Reviewer: Dale Worley 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-dmm-4283mnids-04 Reviewer: Dale R. Worley Review Date: 31 Jan 2017 IETF LC End Date: 2 Feb 2017 IESG Telechat date: 16 Feb 2017 Summary: This draft is on the right track but has open issues, described in the review. Technical issues: 1. The Introduction states Other types of identifiers are in common use, and even referenced in RFC 4283. For the reader's sanity, some sort of accounting needs to be made of these "other types of identifiers", especially because each type of identifier needs an identifier type number. The text in 4283 is Some examples of identifiers include Network Access Identifier (NAI), Fully Qualified Domain Name (FQDN), International Mobile Station Identifier (IMSI), and Mobile Subscriber Number (MSISDN). Are there any other types "in common use"? - NAI (type 1) is defined by 4283. - Fully Qualified Domain Name (FQDN) seems not to be specified - International Mobile Station Identifier (IMSI) (type 3) is defined in this draft - Mobile Subscriber Number (MSISDN) seems not to be specified 2. Is it intended to have an IMEI identifier type? The introduction mentions an IMEI type, but there is no specification for it, nor is there an identifier type number assigned for it. ... types for IMSI [ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and GUTI [ThreeGPP-IDS]. Initially I suspected it was it was present in an earlier revision and then later deleted without this reference being updated. But all versions of draft-ietf-dmm-4283mnids and its predecessor draft-perkins-dmm-4283mnids mention IMEI in this way as one identifier type, but none specify it in any way. The only discussion I can find on the DMM mailing list of IMEI is: https://mailarchive.ietf.org/arch/msg/dmm/pNmtaq6-JOQ4RuXy_D7Zc2JgvYk/?qid=d29575f767ce67a1e67a7767008ee6af From: Marco Liebsch <marco.lieb...@neclab.eu> To: DMM Date: Wed, 10 September 2014 13:29 UTC Re: [DMM] regarding the re-chartering.. It seems the MNID is somehow overloaded to carry both, node-specific IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI. There may be value in adding the IMEI to the list of possible types of node-specific IDs. Either the presence of IMEI in this list is a simple mistake that has persisted in all versions of the draft, or specifying IMEI has always been intended but has always been overlooked. 3. The definition of identifier types for both EUI-48 and EUI-64 suggests that it might be desirable to define an identifier type for arbitrary hardware (link-level) addresses. It seems that the natural differentiator for that purpose is the "hardware type" used in ARP, so a EUI-48 address would be represented as MN identifier type (one octet) 5 (say) hardware type (two octets) 1 EUI-48 (six octets) and an EUI-64 similarly, with hardware type 27. Although with only two subtypes in common use, generalizing this might not be worth the effort. 4. Several of the identifier types can be represented as URNs: - IMEI can be represented as a URN as urn:gsma:imei:... - all of the RFID types have a URN representation (called the "pure-identity URI" in the RFID specifications), which starts urn:epc:id:... Since all URN types are ensured of being unique and persistent, it seems that we could define a MNID type for URNs generally, and then any RFID URI or an IMEI (as a URN) could be used as a value of that type. If this idea is adopted, it seems that the other 3GPP types (IMSI, P-TMSI, and GUTI) should be given defined encodings as URNs in new sub-namespaces of the "gsma" URN namespace, to parallel the encoding of IMEIs defined in RFC 7254. This consolidation could be significantly beneficial. It allows MNID to use any URN scheme as an identifier. It reduces the three different RFID representations to one. It incorporates any future expansion of RFID schemes (because all schemes will have a pure-identity URN representation). A disadvantage is that the URN encodings are long, but the security considerations section states that MNIDs are used only on the first registration at the home agent, so there isn't much need for brevity. Similarly, this approach incorporates any future expansion of mobile identifiers that GSMA decides to define, as long as GSMA provides a URN representation for it. The most significant disadvantage is that some URN schemes allow several character strings to "mean" the same URN. In most URN schemes,
[Gen-art] Review of draft-ietf-teas-gmpls-resource-sharing-proc-08
Reviewer: Dale Worley 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-teas-gmpls-resource-sharing-proc-08 Reviewer: Dale R. Worley Review Date: 29 Jan 2017 IETF LC End Date: 17 Jan 2017 IESG Telechat date: 2 Feb 2017 Summary: This draft is ready for publication as an Informational RFC. [END] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-teas-gmpls-resource-sharing-proc-07
Reviewer: Dale Worley 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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-teas-gmpls-resource-sharing-proc-07 Reviewer: Dale R. Worley Review Date: 23 Jan 2017 IETF LC End Date: 17 Jan 2017 IESG Telechat date: 2 Feb 2017 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. There remain a few editorial items: 2. Conventions Used in This Document The reader is assumed to be familiar with the terminology in [RFC3209], [RFC3473], [RFC4872], [RFC4873] and [RFC4427]. That is a significant help to the reader, but it's also rather intimidating! Is there a way to point out that 4427 is specific to recovery? 3.1.1. 1+R Restoration Unlike a protecting LSP which is set up before the failure, a restoration LSP is set up per need basis, after the failure. Probably better to change "per need basis" to "when needed". 3.2. Resource Sharing By Restoration LSP "By" generally should not be capitalized in titles, as it is a preposition. +-+ +-+ | F +--+ G ++ +--+--+ +-+| || || +-++-+ +--+--+ +-+ +--+--+ | A ++ B +-+ C +--X---+ D +-+ E | +-++-+ +-+ +-+ +-+ Figure 3: Resource Sharing in 1+R Recovery Scheme [...] Nodes A and B reconfigure the resources to set up the restoration LSP by sending cross-connection command to the data plane. In the recovery scheme employing revertive behavior, after the failure is repaired, the resources on nodes A and B need to be reconfigured to set up the working LSP. The traffic is then reverted back to the original working LSP. It's not clear to me why nodes A and B are reconfigured and/or do the reconfiguring. Any "global" reconfiguring would be driven by the head-end A alone, I think. Any "local" reconfiguring would be done by C and possibly E. Though perhaps there is reconfiguring that must be done along the entire path, but that would be attributed to A, B, C, F, G, and E together. I suspect there is a trivial editorial error here... [END] ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-teas-gmpls-resource-sharing-proc-06
Reviewer: Dale Worley
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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-teas-gmpls-resource-sharing-proc-06
Reviewer: Dale R. Worley
Review Date: 12 Jan 2017
IETF LC End Date: 17 Jan 2017
IESG Telechat date: 2 Feb 2017
Summary:
This draft is basically ready for publication, but has nits
that should be fixed before publication.
There are various places where the wording of the draft is unclear.
The draft would benefit from a careful editing for clarity.
Particularly, there are a considerable number of places where the use
of "the" and "a" and of plurals is not standard or leaves the text
somewhat uncertain.
There are various references to ASSOCIATION objects,
SESSION_ATTRIBUTE
objects, etc. The text leaves it unclear where these objects live;
it
talks as if they exist in an abstract sense. I think I managed to
track down what is going on in RFC 4872, which is that the Path
message that sets up an LSP contains an array of objects and all of
the objects described are parts of the respective LSP setup Path
messages.
I also suspect that the Path message objects are retained by the
various nodes as permanent information about the LSPs that they have
configured, so one can speak unambiguously of "the ASSOCIATION object
of the LSP" long after the LSP is set up.
If all of this is correct, it would help the naive reader if this was
spelled out at the beginning of the document and/or the wording was
changed in places provide this context. E.g.,
GMPLS LSPs can share resources during LSP setup if they have
Shared
Explicit (SE) flag set in their SESSION_ATTRIBUTE objects and:
could be clarified as
GMPLS LSPs can share resources during LSP setup if they have
Shared
Explicit (SE) flag set in the SESSION_ATTRIBUTE objects in the
Path
messages that create them and:
There are a number of terms that are unclear to me. It's possible
that they have very standard meanings in GMPLS or traffic
engineering,
though. Is there a terminology section in a referenced RFC that
could
be pointed to to define these various words?
1. Introduction
to setup Label Switched Paths (LSPs) in non-packet transport
The form "set up" is a verb, whereas "setup" is a noun (naming an
instance of the action of setting up) or an adjective (specifying
that
something has to do with setting up). So in this instance, the
wording should be "set up". Other uses of "setup/set up" should be
checked also.
As described in [RFC6689], an ASSOCIATION object can be
used to identify the LSPs for restoration using Association Type
set
to "Recovery" [RFC4872] and also identify the LSPs for resource
sharing using Association Type set to "Resource Sharing" [RFC4873].
The ordering of the phrases in this sentence is somewhat confusing
because "using Association Type set to xxx" is a qualifier of "an
ASSOCIATION object", yet the phrase "can be used to yyy" is between
them. Clearer to say:
As described in [RFC6689], an ASSOCIATION object with Association
Type "Recovery" [RFC4872] can be used to identify the LSPs for
restoration. Also, an ASSOCIATION object with Association Type
"Resource Sharing" [RFC4873] can be used to identify the LSPs for
resource sharing.
--
Generally GMPLS end-to-end recovery schemes have the restoration
LSP
signaled after the failure has been detected and notified on the
working LSP.
Is "signaled" used here in a standard way for GMPLS? It seems that
"the LSP is signaled" is to mean "the LSP is set up", but it took me
some time to realize that. I am used to "X is signaled" meaning "a
signal is sent to X". (There are many instances of this usage.)
It would also be useful for the reader to know the difference between
"protection", "restoration", and "recovery". I think that
"protection" is anti-failure paths set up *before* any failure,
"restoration" is anti-failure paths set up *after* a failure, and
"recovery" includes both "protection" and "restoration". Is this
standard terminology withing GMPLS, or should the reader be warned
about it?
In non-packet transport networks, as
working LSPs are typically signaled over a nominal path,
What is the meaning of "nominal" here? ("nominal" has a number of
meanings, some of which are largely contradictory.)
can be reverted to the nominal path when the failure is
[Gen-art] Review of draft-ietf-sidr-bgpsec-pki-profiles-19
Reviewer: Dale Worley 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. Document: draft-ietf-sidr-bgpsec-pki-profiles-19 Reviewer: Dale R. Worley Review Date: 3 Jan 2017 IETF LC End Date: 19 Dec 2016 IESG Telechat date: 5 Jan 2017 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. The draft is much improved relative to the Gen-ART review of -18, but a few items remain. 3.1.1. Subject However, each certificate issued by an individual CA MUST contain a Subject name that is unique to that CA context. E-mail from Sean Turner on 22 Dec 2016 says: I think this is just a case of a missing "CA" in front of the word "context" so tweaking it to: " that is unique to that CA context". The certs only need to be unique on a per CA basis the subject name does not need to be unique across the whole of the RPKI. The combination of issuer+subject+serial # plus all the parent certs provides the uniqueness. However, there doesn't seem to be a standard meaning of the phrase "CA context". I can't find any occurrences in any RFC or in any I-D other than draft-ietf-trans-threat-analysis-NN. It seems to me that the best solution is to put a cleaned-up version of Sean's statement "The combination of issuer+subject+serial # plus all parent certs provides the uniqueness." into the draft, as that is admirably clear. (Unless, of course, there is a standard PKI phrase for that requirement, in which case that could be used.) For instance: However, the combination of subject name, serial number, issuer, and certification path must be globally unique. 3.3. BGPsec Router Certificate Validation The validation procedure used for BGPsec Router Certificates is identical to the validation procedure described in Section 7 of [RFC6487] (and any RFC that updates this procedure), as modified below. For example, in step 3: "The certificate contains all field that must be present" - refers to the fields that are required by this specification. This picks up the changes from Sean Turner's e-mail of 22 Dec 2016 except it omits changing "that updates this procedure" to "that updates that procedure", which seems to me to necessary to make the wording correct. step 3: "The certificate contains all field that must be present" This doesn't match the text in RFC 6487, despite claiming to be quoted: s/all field/all fields/ and s/must/MUST/. 7. IANA Considerations No IANA allocations are request of IANA, ... I think this should be "No IANA allocations are requested of IANA", or probably better "No allocations are requested of IANA". E-mail from Sean Turner on 22 Dec 2016 says "Alvaro had a similar comment on the IANA considerations and he suggested the first option.", but no change has been made. Dale ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-sidr-bgpsec-pki-profiles-18
Reviewer: Dale Worley 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. Document: draft-ietf-sidr-bgpsec-pki-profiles-18 Reviewer: Dale R. Worley Review Date: 12 Dec 2016 IETF LC End Date: 19 Dec 2016 IESG Telechat date: unknown Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Some of these items appear to be technical, but I suspect that the intended meanings are clear to people well-versed in PKI and are known to work. However, they are unclear to a naive reader. 2. Describing Resources in Certificates The RIR, in turn, issues a CA certificate to an Internet Service Providers (ISP). s/Providers/Provider/ The CA also generate. The CA also generates Certificate Revocation Lists (CRLs). The first "The CA also generate." is extraneous. 3.1 BGPsec Router Certificate Fields A BGPsec Router Certificate is a valid X.509 public key certificate, consistent with the PKIX profile [RFC5280], containing the fields listed in this section. This profile is also based on [RFC6487] and only the differences between this profile and the profile in [RFC6487] are specified below. I suspect this paragraph is going to cause implementers some trouble. What, exactly, are the constraints on the BGPsec Router Certificate? It looks like the certificate must conform to: - X.509 - RFC 5280 - RFC 6487 as modified by "below" and I see that RFC 6487 requires that certificates conform to RFC 5280. So it seems that the first two items are directly required by this document and transitively required by RFC 6487. I suggest changing the first two items to be required only by transitivity, only mentioning X.509 and RFC 5280 as explanatory: A BGPsec Router Certificate is consistent with the profile in [RFC6487] as modified by the specifications in this section. As such, it must be a valid X.509 public key certificate and consistent with the PKIX profile [RFC5280]. Also, "below" is vague. I suspect you mean "The differences between this profile and the profile in [RFC6487] are specified in this section." 3.1.1.1. Subject However, each certificate issued by an individual CA MUST contain a Subject name that is unique within that context. What is "that context"? Do you mean: However, the certificates issued by an individual CA MUST contain unique Subject names. However that has difficulties when it comes time for the CA to issue new certificates with later validity times. Why there is a constraint based on "issued by an individual CA" is not clear, given that there is no constraint regarding which CA issues certificates to which routers. Merely aggregating the work of multiple CAs into one CA could require changing the subject names in the next revision of issued certificates, whereas splitting the work of one CA into multiple CAs would loosen this requirement. In addition, the definition of "an individual CA" is not clear. Is there really an operational requirement for this uniqueness constraint? More to the point, is the combination of common name (i.e. AS number) and serial number (router ID) required to be globally unique or not? That seems to be the only question that can be operationally significant. I suspect that someone well-versed in PKI knows these answers, but for the naive, what is required and why seems confusing. 3.2. BGPsec Router Certificate Request Profile o The SubjectPublicKeyInfo and PublicKey fields are specified in [ID.sidr-bgpsec-algs]. There is no "PublicKey field" discussed in ID.sidr-bgpsec-algs. Is "subjectPublicKey" intended? If so, "subjectPublicKey" seems to be a sub-field of SubjectPublicKeyInfo (per ID.sidr-bgpsec-algs section 3.1), which is also listed here, so it is not clear why it is mentioned individually here. 3.3. BGPsec Router Certificate Validation The validation procedure used for BGPsec Router Certificates is identical to the validation procedure described in Section 7 of [RFC6487] (and any RFC that updates this procedure), but using the constraints applied come from this specification. I assume you mean "and any RFC that updates the procedure of [RFC6487]". In that case, I think that "that procedure" would be required, but "the procedure of [RFC6487]" would eliminate any ambiguity. "but using the constraints applied come from this specification" is unclear. step 3: "the certificate contains all the field that must be present" This doesn't match the text in RFC 6487, despite claiming to be quoted: s/the certificate/The certif
[Gen-art] Review of draft-ietf-justfont-toplevel-05
Reviewer: Dale Worley
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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-justfont-toplevel-05
Reviewer: Dale R. Worley
Review Date: 2016-12-09
IETF LC End Date: 2016-11-09
IESG Telechat date: 2016-12-15
Summary:
This draft is on the right track but has open issues, described in the
review.
Major issue:
Section 5.3.4, Collection Font Type (font/collection)
Fragment Identifiers A string, no longer than 63 characters and
restricted to the printable ASCII subset, codes 33 - 126,
except for the 10 characters '[', ']', '(', ')', '{', '}',
'<',
'>', '/', '%'. If this string matches one of the PostScript
names (name ID=6) [ISO.14496-22.2015] in the name table, that
font is selected. For example, "#Foo-Bold" refers to the
font
with PostScript name Foo-Bold. If the name does not match,
or
if a fragment is not specified, the first font in the
collection is matched. Note that the order of fonts in
collections may change as the font is revised, so relying on
a
particular font in a collection always being first is unwise.
However, the characters '"', '#', '\', '^', '`', '|' are not
admissible in fragment identifiers, per RFC 3986.
It appears from ISO 14496-22 that those characters are allowed in font
PostScript names, so you probably want to enable the use of %-escapes
in fragment identifiers to represent those six characters.
Minor issue:
>From my correspondence with the author, I think his intention is that
the parameter values should be case-insensitive. It seems to me that
RFC 6838 section 4.3 makes the values case-sensitive by default, so if
they are intended to be case insensitive, that needs to be specified.
Dale
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
