[Gen-art] Genart last call review of draft-ietf-bmwg-benchmarking-stateful-06

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-bmwg-benchmarking-stateful-06

Reviewer: Robert Sparks
Review Date: 2024-05-22
IETF LC End Date: 2024-05-22
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as an Informational RFC with nits

Nits/editorial comments:

There are places in the text that say "The authors are aware" - the
construction seems out of place for a consensus IETF stream document - I'm not
sure if this was the resolution of an argument, or just text that could be
further changed to "Note that" or something similar.

I support the concerns Michael raised in his tsvart review.

Please consider reaching out to the RFC-Editor early for how to best represent
the small block of pseudocode in the xml for the document.


___
Gen-art mailing list -- gen-art@ietf.org
To unsubscribe send an email to gen-art-le...@ietf.org

[Gen-art] Genart last call review of draft-ietf-opsawg-tsvwg-udp-ipfix-08

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-opsawg-tsvwg-udp-ipfix-08
Reviewer: Robert Sparks
Review Date: 2024-05-03
IETF LC End Date: 2024-05-10
IESG Telechat date: Not scheduled for a telechat

Summary: 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

.

Document: draft-ietf-opsawg-tsvwg-udp-ipfix-18
Reviewer: Robert Sparks
Review Date: 2024-05-03
IETF LC End Date: 2024-05-10
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with nits

Consider discussing, or point to existing considerations about, what should
happen when you are exporting very large udp options (perhaps constructed
maliciously to be as large as possible) and you are carrying the exported
values over UDP (Section 10.3 of RFC7011) and run out of room.

There are several references by section number into I-D.ietf-tsvwg-udp-options
that have become stale. For instance the pointer to section 22 in the security
considerations should be pointing to section 24.



___
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-over-tls13-03

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-netconf-over-tls13-03


Reviewer: Robert Sparks
Review Date: 2023-10-26
IETF LC End Date: 2023-11-13
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC

This is an excellently distilled document.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-cbor-time-tag-11

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-cbor-time-tag-11
Reviewer: Robert Sparks
Review Date: 2023-10-23
IETF LC End Date: 2023-10-21
IESG Telechat date: 2023-10-26

Summary: Ready for publication as a Proposed Standard RFC

My review was hurried, and the result is late. Apologies. I found no issues 
that need addressing.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-extra-jmapaccess-04

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-extra-jmapaccess-04
Reviewer: Robert Sparks
Review Date: 2023-08-22
IETF LC End Date: 2023-08-28
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a proposed standard RFC

Nits/editorial comments:

At:
   A few IMAP client maintainers have asked for ways to use features
   that are available in JMAP without having to drop their expensively
   tested IMAP code.

Why does this need to be in the document at all? It will not age well. Consider 
just removing it.


___
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-sedate-datetime-extended-08

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-sedate-datetime-extended-08
Reviewer: Robert Sparks
Review Date: 2023-06-13
IETF LC End Date: 2023-06-15
IESG Telechat date: Not scheduled for a telechat

Summary: Essentially ready for publication as a Proposed Standard RFC, but with
issue to consider before full IESG review (Ready with Issues)

Issue:

The ABNF for suffix-key allow productions like "_", "a---", and "ab".
I'm guessing at intent, but my guess is that you essentially wanted the same
production you allow for the suffix values, but you want to restrict that to
the set of values that start with either _ or [a-z]. If my guess is correct, I
can help construct alternate ABNF.

I have a similar question about time-zone-part where you in a comment rule out
the two productions "." and "..". Should you say anything about 14 dots? Or
".-.+..+.-."?

And to make sure - you want to allow more than one / in the time-zone-name
production, such as America/Chicago/Canaryville?

Editorial Nits:

At scope, you say "way to attach any additional information". I suggest "way to
attach additional information" is enough.

The definition of UTC has a a short bit of history in it that is interesting,
but unnecessary for this document. Consider removing from "From 1972" to the
end of the first paragraph of the definition. (If you want to point to history,
choose a rich informational reference perhaps).

At the definition of timestamp, I quibble with using "unambiguous". This
document isn't attempting to address disambiguating which 1:30 am you mean when
there were two of them on a DST end day. How would the document suffer if you
simply dropped the word from the definition?

In the second paragraph of section 2 - I get lost in "former" and "latter" (I'm
not sure the text is pointing where it intends to point). Please consider just
directly stating the convention you are talking about instead.

The section heading names under section 3 are not particularly helpful, and the
text doesn't quite follow the intended structure that I think inspired them.
It's not really clear that the section does everything that the first sentence
of section 3 says it will. Please consider a gentle restructuring of the
outline into something like "Format of extended information","Registering
extended information tags", "Requirements for producing extension tags",
"Requirements for consuming extension tags".



___
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-lsr-rfc8919bis-01

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-lsr-rfc8919bis-01
Reviewer: Robert Sparks
Review Date: 2023-04-27
IETF LC End Date: 2023-05-03
IESG Telechat date: Not scheduled for a telechat

Summary:
Ready for publication as a proposed standard rfc but with nits to consider
before publication.

Nits:
1) It would be nice to explain when/how the registries got renamed?

2) Please reconsider the link to the mailarchive in the RFC. Put it in the
shepherd writeup or in the history in the datatracker as a comment (chairs can
do this). Otherwise it adds to the list of URLs that we have to keep alive
forever.



___
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-add-encrypted-dns-09

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-opsawg-add-encrypted-dns-09
Reviewer: Robert Sparks
Review Date: 2023-02-17
IETF LC End Date: 2023-02-23
IESG Telechat date: Not scheduled for a telechat

Summary: After addressing an issue, this will be ready for publication as a
Proposed Standard RFC

Issue: draft-ietf-add-dnr needs to be a normative reference, or some other
mechanic needs to be used to ensure draft-ietf-add-dnr is published as an RFC
before IANA follows the instructions in this document.

Nit: The discussion in paragraph 3 of section 3 and the note that follows are
currently ambiguous. When it calls out that 2865 limits the size of DHCP
options and that 7499 and 7930 relaxes the limit, is it only trying to inform
where the recommendation of supporting 65535 bytes came from? Or is it trying
to constrain the size of any DHCP option added to the the attributes defined
here to 4096?



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-billon-expires-08

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-billon-expires-08
Reviewer: Robert Sparks
Review Date: 2022-12-16
IETF LC End Date: 2022-12-27
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a proposed standard RFC

The last call discussion of this document is surprisingly voluminous, but my
individual opinion is that no further change is needed.

To me the document is clear and at least one implementation exists.

It's interesting to note that as of -08 there are only two non-boilerplate
sentences using BCP 14 keywords:

*  Message creators **MUST NOT** include more than one Expires header field in
the message they send. *  If there is more than one Expires header field then
message readers **SHOULD** act as if no Expires header field is present.

(unless the software I have that extracts those has a bug).



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-oauth-rar-15

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-oauth-rar-??
Reviewer: Robert Sparks
Review Date: 2022-11-17
IETF LC End Date: 2022-11-17
IESG Telechat date: Not scheduled for a telechat

Summary:

Major issues:

Minor issues:

Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-lamps-5g-nftypes-05

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-lamps-5g-nftypes-05
Reviewer: Robert Sparks
Review Date: 2022-10-13
IETF LC End Date: 2022-10-27
IESG Telechat date: Not scheduled for a telechat

Summary: Ready (maybe) for publication as a Proposed Standard RFC, but with
issues to consider before this gets to IESG Evaluation.

Major Issue:

(Apologies if I'm forgetting a well known reason this isn't an issue):

Doesn't IA5String allow all of 0-127 in ascii? Do you want NUL through SP and
DEL in NF Type names?

Minor Issue:
The document says operators need to not use colliding names but then explicitly
declaires on how an operator would know if a name is already in use is out of
scope. Surely there was a discussion about a registry, and the IESG is
certainly going to ask. It would save some time if you could add something to
the shepherd writeup explaining why a registry wasn't pursued in this document?

Nits:

At:

"The 49 NF types that are defined for 3GPP Release 17 listed in Table
6.1.6.3.3-1 of [TS29.510], and each NF type is identified by a short ASCII
string."

the sentence doesn't parse. Do you mean "are listed" or "There are 49 NF types"
or something else?

At:

"The NFTypes MUST contain only an ASCII string, MUST contain at least one ASCII
character, and MUST NOT contain more than 32 ASCII characters."

I suggest "Each NFType MUST"

At:

"The mechanism for an operator to determine whether an ASCII string associate
with a NF Type is unique across operators is outside the scope of this document"

I suggest "string associate with" -> "string is associated with"



___
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-quic-version-negotiation-10

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-quic-version-negotiation-10
Reviewer: Robert Sparks
Review Date: 2022-10-08
IETF LC End Date: 2022-10-11
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC

Please consider further framing the security analysis that is still needed.




___
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-ipv6-deployment-07

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-v6ops-ipv6-deployment-07
Reviewer: Robert Sparks
Review Date: 2022-09-24
IETF LC End Date: 2022-09-26
IESG Telechat date: Not scheduled for a telechat

Summary: Mostly ready for publication as an Informational RFC, but with nits to
address before publication.

I appreciate that this document represents a significant amount of discussion,
and agree that obsoleting RFC6036 is the right thing to do.

However, it is unclear who this document is for. It doesn't feel like it's for
people working on standardization or regulation, nor does it feel like a
roadmap into other work or sources of information. Parts of it _begin_ to feel
like it's intended to help people who are managing networks going through
transition, but the language in those sections is not addressed to them. Is it
primarily a guide to the narrative IPv6 evangelists could use when approaching
other audiences?

I don't object to publishing this in its current form (but suggest addressing
the below nits), but I really wonder if it would be more useful to reconsider
the audience(s) and goals and write more explicitly to them.

It's hard to tell what in this document is repetition of results from other
sources, and what is new synthesis and analysis.

There is language that should be adjusted to reflect being published in
archival series. Example: "This document intends to"

I recognize that this is a matter of style, but I find the use of phrases like
"it may be interesting to", "it is worth mentioning", and similar to be
distracting. Please consider removing the phrases - the point of the sentences
will become stronger.

There are a few sentences that could be adjusted to make them easier for
non-native english speakers to translate. Places like "Their actions cannot be
objected, ". It would be good to scrub these before they get to the rfc-editor.

The document is acronym-heavy, and some acronyms are used so few times that
expanding them on _every_ use is better than just on first use. Example: FBB.

It is uncomfortable to see "It is important to say that IPv6 is not more or
less secure than IPv4". First - are you telling the readers that it is
important for them to say this? Or stating that it's important for this
document to say it? Second, the rest of the document doesn't support the
statement. Instead, it almost directly contradicts it, by pointing to the
relative maturity of implementations, the larger potential attack surface, etc.
Why is this sentence (at the beginning of 5.4.1) in the document? Could the
statement simply be removed?

Has potential selection bias been considered in the analysis of the survey in
appendix A? Perhaps it would be more accurate to title section 3.2 "IPv6 among
Internet Service Providers in Europe"?

At "theoretical ratio", I suggest instead of using that phrase, you explain why
you needed to say it. I suggest something like: "This is not a claim that each
person uses this many addresses", or simply talking about the ratio without
this disclaimer - the readers will already be familiar with the characteristics
of per-capita metrics.

In 3.3, last sentence of the first paragraph - it's not clear that you actually
state otherwise in the text that follows. If you do, stating otherwise needs to
be done more clearly. If you don't, you don't need this sentence.

Micro-nit in figure 3: Wolrdwide -> Worldwide


___
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-add-ddr-08

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-add-ddr-08
Reviewer: Robert Sparks
Review Date: 2022-07-08
IETF LC End Date: 2022-07-08
IESG Telechat date: 2022-07-14

Summary: Has issues to address before publication as a Proposed Standard RFC

(Note: I reviewed -07, and noticed -08 while entering this review. I've read
the diffs, and believe all the below to still be relevant).

Issues:

RFC 6761 requires explicit discussion of seven categories of consumers of a new
SUDN. This document does not yet provide that discussion.

There's a lack of discussion of issues around certificate revocation throughout
the document. The end of section 4.1.1, for example, cuts off an mitigation
opportunity should control of a certificate used by the Designated Resolver be
lost.

Please add an explanation for _why_ the requirement in the last sentence of the
first paragraph of 4.2 exists. As written, it seems out of context, and
underspecified (which SVBC result, obtained when, should the client consider
the TTL from?).

The discussion of providing differentiated behavior over unencrypted DNS is
good to call out, but needs more depth. There are many other fields an attacker
might modify, even outside the DNS part of the datagram (say, the source IP
address) that could give the attacker an advantage if the returned results
varied.

Nits:

In the introduction, please reconsider "claims ownership over the IP
addresses". It would be better to simply say "contains the IP addresses in the
SubjectAltName.

There is tension between the normative SHOULD NOT and SHOULD in the first
paragraph of 4.1.1 and the SHOULD in the first paragraph of 4.2. Please clarify
the wording in one place or the other so that an implementer isn't forced to
violate one of those normative requirements to satisfy the other.

The last sentence of the first paragraph of 4.3 is imprecise. It would address
my discomfort to replace "cannot be confirmed" with "cannot be safely
confirmed", or add a pointer to a description somewhere else about why trying
to include such addresses in a certificate is an unworkable idea.

At the end of the second paragraph of 4.3, consider future protocols that might
use something other than TLS as the security layer. The sentence as is takes a
shortcut past the point your are really trying to make.

The use of SHOULD in the second paragraph of section 5 is strange. Do you mean
"are expected to be"? The other side of this coin (that records are NOT
expected to be present) isn't obvious to find in section 4.

Consider explicitly calling out what the implementation MUST do if the
validation in the 4th paragraph of section 7 fails.

(Feel free to ignore this, but): At the 5th paragraph of section 7, consider
discussing the risks of an operator running an Unencrypted Resolver at a given
IP and _not_ running a Designated Resolver there. This adds an attack point for
an adversary to gain enough access to run their own Designated Resolver there,
even if they can't gain enough privilege to affect the Unencrypted Resolver.

Micro-Nits:

Section 3 3rd to last paragraph: s/use others records/use other records/



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-oauth-jwk-thumbprint-uri-01

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-oauth-jwk-thumbprint-uri-01
Reviewer: Robert Sparks
Review Date: 2022-05-03
IETF LC End Date: 2022-05-09
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-faltstrom-base45-10

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-faltstrom-base45-10
Reviewer: Robert Sparks
Review Date: 2022-02-23
IETF LC End Date: 2022-03-02
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as an Informational RFC

Note that I have not tried to find a copy of ISO18004:2015. It doesn't seem
necessary to read that to build an encoder/decoder as described here.

This seems straightforward and appears to have several existing implementations.

Should Section 4.1 be titled "When not to use Base45"?



___
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-telemetry-19

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-dots-telemetry-19
Reviewer: Robert Sparks
Review Date: 2022-01-21
IETF LC End Date: 2022-01-24
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC, but with issues and
nits to consider before publication

Issues:
---

This document relies heavily on the requirements in the DOTS signal and data
channel specifications (RFC9132 and RFC8783) saying authenticated encryption
MUST be used. Explicitly calling that out in this document's security section
would be worthwhile.

I am not a YANG Doctor. This document seems to make a reasonable but unusual
use of YANG. I would really like to see YANG Doctor review of -19. I wonder if
it would be possible to factor some of the more generic enums out into
something that could be reused elsewhere. Why do you stop at discouraging
rather than forbidding server deviations? The point of a specification like
this is interoperability.

I'm a little uncomfortable with the passively stated requirement to use
ietf-dots-rehoming (at "clients are assumed to follow") while that document is
an Informative reference.

In 6.1.2, I'm confused by the requirement that "'tsid' values MUST increase
monotonically when a new PUT is generated" combined with "If the dot server
finds the 'tsid' parameter value conveyed in the PUT request in its
configuration data and (it) has accepted the updated configuration parameters,
a 2.04 (Changed) MUST be returned". What am I missing that would allow a PUT
with a tsid that's already in the server's configuration data? Is there perhaps
leftover tension here from earlier designs that were changed?

At the end of 7.1, there is a MUST NOT level requirement against repeating
attack-descriptions that have been previously sent to a peer. Is it always the
case that when these descriptions are sent, the message they are contained in
is acknowledged? If not, consider adding discussion of how/whether a peer can
ask for a description when it gets an attack-id it doesn't have a description
for.

In 7.2, you require a freshly rebooted client to send a GET request to retrieve
active 'tmid' values. Why? Why not let it just send a DELETE with no 'tmid'
right away if that's what it would do after receiving the response to the GET
anyhow?

In 7.3 at "The PUT request MUST be maintained in an active state", you mean the
configuration that the PUT established must be kept. The PUT request itself has
no state beyond its response. Consider saying something like "The
pre-or-ongoing mitigation requests MUST be considered active" instead.

In the yang module, there's a reference at page 79 that points to "Section
4.4.2 of RFC ." This is the only occurrence of  in the document, and if
it's meant to be replaced with 'this RFC', this document has no section 4.4.2.

Nits:
---

Last paragraph of introduction at "Nevertheless, when..". That sentence is
particularly hard to parse, please simplify it.

Curious that you called out TCP port 80 in the discussion in 3.3. Why not 443?

At 4.1, where you say "that truly require reliable delivery", I think you mean
something more like "that are important to deliver". Nothing here is trying to
guarantee reliable delivery and the statement misleads the reader to look for
reliable delivery mechanisms.

In 4.5 at "The reason for not including these keys...". That sentence does not
parse. Please simplify.

In 4.6, the second paragraph is about validating messages, not examples. It's
not clear the paragraph is useful as a roadmap through the document. Consider
deleting it.

The outline structure of section 4 is odd. There are several Considerations
subsections including "Generic Considerations" (which is jarring), and several
subsections that are not considerations sections. Having them under a section
titled "Design Overview" doesn't help pull them together. Perhaps a mild
restructure/reorder would bring more clarity?

At 6.1, consider replacing "(with suitable default)." with ". Default values
are defined later in this section."

In 6.1 you claim clients can negotiate configuration parameters with server. I
don't find a negotiation protocol specified here. I think you mean clients can
configure parameters at a servers, and servers can configure parameters at a
client. There's not really a mechanism for a peer to say "no, I don't the
percentile config you're trying to set and I won't do that".

The introduction of "a third-party DOTS server" in the narrative after Figure
13 is surprising. For the paragraph to make sense, the messages in the
discussion before Figure 13 

[Gen-art] Genart last call review of draft-ietf-dispatch-javascript-mjs-10

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-dispatch-javascript-mjs-10
Reviewer: Robert Sparks
Review Date: 2021-11-11
IETF LC End Date: 2021-11-15
IESG Telechat date: Not scheduled for a telechat

Summary: Ready (but with nits) for publication as an Informational RFC

The number of messages in the archive about the draft are impressive, if not
daunting. Apologies if any of my nits tread old ground.

I'm glad this has seen attention from many people better with i18n than I am.

I'm curious why the registrations choose to declare the .mjs extension in
anything but the now preferred type. If they're in all the obsoleted type
registrations because they're used in the wild with those types, fine. But if
it was a template replication process that put them there, maybe reconsider?

I agree with Mark that the form and repetition of variants of 'not part of this
document' is unusual. Consider saying it less, and maybe consolidating what you
do need to say.

There are a few places where the document says implementations or scripts MUST
consider something. Neither of those things can consider. Please consider
rephrasing those to speak of the implementers or script creators. This is also
not a great use of 2119/8174 terms. Think about using plain words instead.

The last sentence of the second paragraph of section 3 doesn't fit with the
first. Perhaps it should stand alone.

Please point explicitly to the types registry in the text of the document.

Micro-nit: search for timin`g



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-cbor-network-addresses-08

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-cbor-network-addresses-08
Reviewer: Robert Sparks
Review Date: 2021-09-19
IETF LC End Date: 2021-09-22
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC

Should the IANA registry (and/or the document) say something more about what
one can do if one wanted to represent an Ethernet address? 260 allowed that but
you are deprecating it - are you only deprecating it for v4 and v6 use, or do
you hope its use goes away completely?


___
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-bier-te-arch-10

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-bier-te-arch-10
Reviewer: Robert Sparks
Review Date: 2021-08-07
IETF LC End Date: 2021-08-11
IESG Telechat date: Not scheduled for a telechat

Summary: Essentially ready for publication as a Proposed Standard RFC, but with
nits, and possibly a minor issue, to address before publication.

Possible minor issue:

The Security Considerations section of this document could discuss an
exponential amplification attack by way of misconfiguration using the DNC bit.
If you have the following configuration (best read in a fixed-width font):

BFRA: p1 -> forward_connected(DNC) BFRC
  p2 -> forward_connected(DNC) BFRD
  p3 -> local_decap

BFRB: p1 -> forward_connected(DNC) BFRC
  p2 -> forward_connected(DNC) BFRD
  p3 -> local_decap

BFRC: p1 -> forward_connected(DNC) BFRA
  p2 -> forward_connected(DNC) BFRB
  p3 -> local_decap

BFRD: p1 -> forward_connected(DNC) BFRA
  p2 -> forward_connected(DNC) BFRB
  p3 -> local_decap

A single packet with bits (p1,p2,p3) introduced to any of the 4 BFR will
produce an exponentially increasing amount of internal traffic, and traffic
sent to whatever the local_decaped packets is configured for.

 p3  p3
BFRA p1  p1 BFRC
  \ /
   \   /
 X
   /   \
  / \
BFRB p2  p2 BFRD
 p3  p3

This may be easy to achieve accidentally if following the suggestion for
creating a bidirectional ring described in section 5.1.6.

Larger Nits:

The first example uses terms defined later in the document (like local_decap).
It would help the reader to say that right before the example.

Section 2.3 list 2 item 2. What is a "reference option"? This first sentence of
this item should be simplified, possibly by breaking it into two or more.

The first sentence of section 2.4 does not parse. Perhaps "BIER-TE forwarding
is designed to make it easy to build or program common forwarding hardware."
but I'm lost at "with BIER". Please clarify.

In section 3.2, there is a nested list that is introduced as "functionality"
but later referred to as "steps". Please provide a clearer description, and
make it obvious that these are the steps that the subsections (such as 3.2.1)
refer to.Is the outer list the steps 3.2.1 refers to?

Section 3.2 list item 2, sublist item 3. "Install state on the BFIR to
imposition the desired BIER packet header(s) for packets of the overlay flow"
does not parse. Please clarify.

Please clarify the last sentence (starting "See also") of 3.2.1.2. I don't know
what you are really trying to say but "solution describes interaction" doesn't
make sense.

At 3.2.1.4, what does "out-of-scope FRR procedures" mean? I suggest just
dropping "out-of-scope". If that's not right, more clarification is needed.

Section 3.4 second paragraph last sentence: Did you mean "BIER specific
routing" rather than "BFER specific routing"?

Section 4.1, Check that you really meant BFR-id = SI * 2^BSL + BP in paragraph
three.

Section 5.1, second paragraph: The list of sections '(4.1, ... 4.8)' didn't
track a document change. I think you mean to point to '(5.1.1, ...'. But the
list is unnecessary - I suggest deleting it.

In section 5.1.6, I think you are using L3 to mean different things in the
first paragraph and in the example.

Section 5.1.9 after Figure 17, you point to figure 20, but I think you really
meant figure 17. (It's interesting that figure 17 and 20 are essentially the
same, perhaps the document could be simplified).

Section 5.3.5: Where did this 20%..80% range come from? The last sentence is
unclear.

Section 5.3.6.2: paragraph 3. The sentence starting "This is much worse" is
complex. Please break it into several.

Section 5.3.7 First paragraph. This long sentence fails to parse. Please
simplify it.

Section 7 paragraph 6 (beginning "For additional,"): This sentence is very hard
to parse. Please simplify it.

Smaller Nits:

Overview: Expand BIFT on first use.

The Overview claims that the reader is expected to be familiar with both
RFC8279 and RFC 8296, but only lists the first as a normative reference.
Consider making RFC 8296 normative, or adjusting the introduction text.

First bullet in overview: "reference forwarding examples" -> "forwarding
examples"

Last bullet in overview: "sections of document" -> "sections of the document"

In 2.1, "To send in addition to BFR6 via BFR4 also a copy to BFR3" is hard to
parse. Perhaps: "To send a copy to BFR3 in addition to BFR6 via BFR4".

Section 3.2.1: Why is "Notwithstanding other option," 

[Gen-art] Genart early review of draft-ietf-masque-ip-proxy-reqs-02

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: On the Right Track

This is an early genart review of draft-ietf-masque-ip-proxy-reqs-02.
Comments here should be processed the same as any other feedback given for the
document.

I think I see some conflicts in the requirements that I think would be good to
resolve more clearly to help inform actual mechanism discussions.

There is pressure to limit MASQUE-related state, but the document already
proposes quite a bit of state - in particular keeping routes. More discussion
of whether that's necessary state would probably help find spots of
disagreement.

If it's the intent to limit MASQUE to support only VPN-like traffic, say so
more explicitly. As written, it looks like there might be intent for MASQUE to
provide an arbitrary IP transport layer, over which other routing protocols
could be run (as opposed to only allowing the posited configured routing the
document currently discusses). It would help to more clearly discuss if there
are limits on what can be built on top of MASQUE and if there are none,
reconsider configuring routes as a requirement on the base protocol in favor of
that being something that uses this protocol does once it's in place.

At 2.1, you note that in consumer VPN environments, "hidden information" is
available to the VPN service provider. While true, why is that important for
this document/group? Is there an intent to build something that could replace a
consumer-VPN service that treats such hidden information differently? If so,
there are some requirements that would be worth explicitly exploring.

At 3.6, you require carrying an identity, but punt on authenticating it. It
would help more to discuss why. The security considerations section could talk
about the tradeoff, and discuss what properties the identifier might need to
have beyond possibly being authenticatable. Do you anticipate, for example,
that they need to be hard to guess? Are there collision concerns? Or are such
things all up to whatever application might get built on top of this protocol?
Should the requirements for realizing VPN-like applications be pulled up a
layer?

Please look more closely at whether you can/should discuss _requirements_ on
the mechanism's security in this document's security consideration section.

Nits:

Provide a reference for TUN.

3.5 is titled "Route Negotiation", but there is no negotiation proposed, only
configuration.



___
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-ipv6-ehs-packet-drops-05

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-v6ops-ipv6-ehs-packet-drops-05
Reviewer: Robert Sparks
Review Date: 2021-02-19
IETF LC End Date: 2021-02-25
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as an Informational RFC



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-extra-imap4rev2-24

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-extra-imap4rev2-24
Reviewer: Robert Sparks
Review Date: 2021-01-14
IETF LC End Date: 2021-01-20
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC

I approached reviewing this document first by diffing it with RFC3501, then
doing a linear read-through. Errata seem appropriately handled. This looks like
it was a huge effort - it is very well done. I sent the few nits I could find
directly to the editors.


___
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-ipsecme-ipv6-ipv4-codes-05

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-ipsecme-ipv6-ipv4-codes-05
Reviewer: Robert Sparks
Review Date: 2020-11-14
IETF LC End Date: 2020-12-01
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-lpwan-schc-over-lorawan-10

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-lpwan-schc-over-lorawan-10
Reviewer: Robert Sparks
Review Date: 2020-10-02
IETF LC End Date: 2020-10-02
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a proposed standard but with nits to consider
before publication

Nits/editorial comments:

The abstract says "This is called a profile." It would be better to say
something like "This document specifies a profile of RFC8724."

What does "other Internet networks" mean? Please replace the phrase with
something more descriptive.

The word "efficient" in the last sentence of the introduction is puzzling.
Could it simply be removed?

As the shepherd report notes, there are figures that need to be reworked to
satisfy column constraints.



___
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-na-flags-05

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-bess-evpn-na-flags-05
Reviewer: Robert Sparks
Review Date: 2020-08-18
IETF LC End Date: 2020-08-28
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC but with nits to
address before publication

The protocol being defined seems fine, and the IANA considerations are well
constructed. I have a nagging feeling that there are new security concerns this
introduces, but haven't been able to identify anything specific. I appreciate
that the document discusses what happens when a bad-actor introduces
intentionally mis-configured flags.

Editorial Issues:

The Abstract is full of acronyms that are not universally understood, and it
buries the point of the document. Please consider rewriting to focus more
specifically on the goal of the draft (see the introduction in the shepherd's
writeup), keeping in mind that the abstract should make sense to people who
don't know yet what PE stands for. Much of what you currently have in the
Abstract can be left to the Introduction. I expect a  shorter (two or three
sentence) abstract will suit the document better.

In section 3.2: The list of three things in the list under "R and O Flags
processing" are all processing steps. But the list of 6 things under "I Flag
processing" are not all processing steps. Please change the list to only
include processing steps, and move the examples and commentary to regular
paragraphs after the processing has been specified.

Consider moving the third top-level bullet in 3.2 ("MUST be ignored") to be the
first bullet, and after that bullet say "otherwise".

Editorial Nits:

I suggest deleting "refers to" in the terminology sentences. In all cases you
mean "is" and you don't need to say "is".

The last phrase in the description of Bit 4 at the end of section 2 was
difficult to read. Consider breaking the sentence into two or more.

At the end of section 3.1, "does not have any impact on" is confusing. I think
you mean "does not change"? At ", including" the sentence becomes awkward. I
suggest breaking that into a separate sentence. Perhaps "Specifically the
procedures for advertising ... are not changed."



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart telechat review of draft-ietf-secevent-http-poll-11

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-secevent-http-poll-11
Reviewer: Robert Sparks
Review Date: 2020-06-22
IETF LC End Date: 2020-05-13
IESG Telechat date: 2020-06-25

Summary: Ready for publication as a Proposed Standard

My concerns have been addressed.

I am a little worried about the Appendix A content of -push - it could be
misconstrued to say sending SETs over unencrypted channels is supported by the
proposed standard. It would ease my worry if you made this change (again to the
-push document): OLD:
If SETs are transmitted over unencrypted channels
New:
If SETs were allowed to be transmitted over unencrypted channels



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-pce-stateful-pce-lsp-scheduling-13

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-pce-stateful-pce-lsp-scheduling-13
Reviewer: Robert Sparks
Review Date: 2020-06-09
IETF LC End Date: 2020-06-12
IESG Telechat date: Not scheduled for a telechat

Summary: Essentially ready for publication as a Proposed Standard RFC, but with
issues to consider before progressing

Minor Issues:

Section 4.2.2: It's not clear when the computation for a path satisfying the
constraint happens. Is this done once when the periodical LSP arrives, or at
each scheduled interval? If the former, what happens if there is no path
solution for only one of the multiple intervals?

Section 4.4, second paragraph, last sentence: If the path cannot be set, is the
previous LSP left in effect? Or does the failure result in no there being no
scheduled LSPs in effect?

Section 5.1 first paragraph: Why is TCP called out here?

You should be explicit about whether it's ok to have both grace periods and
elastic bounds at the same time. The TLV allows that to happen. I'm not sure
what it would mean, and I suspect it's unlikely that you would have two
implementers compute the consequences the same way.

Section 5.2.1, definition of the R bit: You should call out that relative time
is in seconds (I think?) when the R bit is 1, and you need a discussion
somewhere about the necessity of synchronized clocks and potential problems
with transmission delay when the R bit is 1.

Section 5.2.1, definition of Start-Time: Why must a value of 0 not be used? Is
this true for both R=1 and R=0? For R=1, a start time value of 1 vs a start
time value of 0 may, in practice, be indistinguishable (because of transmission
or processing delay).

In section 5.2.2 at the definition of Repeat-time-length: Please be explicit
about whether this is the interval between the start time of two repetitions or
the interval between the end-time of one repetition and the start of the next
repetition. I think you mean the former.

At section 5.2.1 you say this TLV SHOULD NOT be included unless both PCEP peers
have set the B bit. But in section 6.6, you say MUST NOT. Please choose one. I
think you want both places to say MUST NOT.

Nits:

Introduction, paragraph 3, second sentence: This is hard to read. I suggest
trying to break it into more than one sentence.

Introduction, paragraph 4, third sentence: This is hard to read. Please
simplify.

The document uses both "database" and "data base". Please pick one.

Top of page 7: "In case of former" does not parse. Please clarify.

Section 4.2.2, second paragraph, first sentence: Does not parse. I think it is
missing more than articles.

Section 4.3 at "In both modes": It's not clear what "modes" means here.

It would be worth calling out in section 5.1 that setting PD requires setting B
as specified in 5.2.2.

It would be helpful in 5.2.2 at the definition of Opt: to point forward to the
registry you are creating for its values. It would also be good to be explicit
about what to do if an element receives a TLV with a value here it does not
understand yet.

Section 9.1 ignores leap-years and leap-seconds. It's worth explicitly noting
that.



___
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-secevent-http-poll-09

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-secevent-http-poll-09
Reviewer: Robert Sparks
Review Date: 2020-05-08
IETF LC End Date: 2020-05-13
IESG Telechat date: Not scheduled for a telechat

Summary: Essentially ready but with some issues to consider before publishing
as a Proposed Standard RFC

This document is well-written and easy to follow.

I have a couple of edge-case issues that I think should be considered though:

This document allows, and anticipates, deployments where Recipients are not
well authenticated. See, for example, the first sentence of section 4.1. There
is also an unstated expectation in the document that the jti of each SET is
hard to guess.  If it's reasonably easy to guess jti values, a malicious
Recipient could ack SETs it has never received and the Transmitter will remove
that state, preventing a valid Recipient from ever receiving that SET.

If that's an explicit requirement in the jwt or SET base documents for the jti
to be hard to guess, please point me to it? If there's not, perhaps a short
discussion in the security considerations requiring this property would be
worthwhile?

Is there a discussion somewhere of how long the transmitter is required
to hold a given SET for a Recipient? Forever seems unreasonable.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-sidrops-ov-egress-01

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-sidrops-ov-egress-01
Reviewer: Robert Sparks
Review Date: 2020-03-13
IETF LC End Date: 2020-03-18
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard RFC

Very minor nit - feel free to ignore -

This sentence slowed me down when reading:

   As the origin AS may be modified by outbound policy, policy semantics
   based on RPKI Origin Validation state MUST be able to be applied
   separately on distribution into BGP and on egress.

I suggest something like:

  As the origin AS may be modified by outbound policy, a BGP speaker 
  MUST be able to apply policy semantics based on RPKI Origin Validation 
  state separately on distribution into BGP and on egress.


___
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-calext-jscalendar-25

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-calext-jscalendar-25
Reviewer: Robert Sparks
Review Date: 2020-03-03
IETF LC End Date: 2020-03-09
IESG Telechat date: Not scheduled for a telechat

Summary: This document has minor issues to address before being published as a
Proposed Standard RFC.

Caveats: I did not carefully verify that the initial registry values (of which
there are many) matched the document text.

Minor issues:

ABNF is used, but there is no reference to RFC 5234. The document shepherd
report implies that the ABNF has not been verified (see item 19 in that report).

The first registry in section 8.4.3 should be explicit that it is a registry
for values of the "@type" property. Right now the reader has to infer that.

It's not stated clearly whether a patch should succeed or fail if the resulting
object doesn't meet this specification's requirements. Side question: if a
patch changes 'updated' (4.1.6) in an object that didn't already have a
'created' (4.1.5), should it fail if it doesn't also result in an object that
has a 'created'? Or is it ok to lose the original creation time information?

The security consideration section only points to section 7 of RFC 3986 for
potential issues related to the URIs that can be carried in this
representation. I don't think that's sufficient. There should be some
discussion (or a pointer to discussions) about the potential for malicious
construction of jscalendar objects containing potentially very large numbers of
URIs in, say, as Link objects (4.2.7). Is there an opportunity for amplified
attacks here? (Especially if these URLs might be automatically referenced by
any client, and even more so if the object is sent from a calendar with a large
number of subscribers.)

Have you considered any tighter integrity checking for (4.2.7) links? Maybe a
checksum property?

It doesn't look like application/jscalendar+json has had a media type review.

Nits:

Introduction, second sentence: "It" is ambiguous. As written, it could point to
"This document" or "a data model". You sort of mean the later, but I think you
really mean the JSON representation (especially when you say "process"), but
you don't talk about that here.

Introduction, design considerations list, last bullet: This bullet is currently
written as description of the end result, not as a design consideration. Please
restate it to match the rest of the elements in the list.

Last full paragraph on page 2: "unlike most common JSON data representations"
is asserted without data. The document doesn't really need it. I suggest simply
deleting the phrase from the sentence.

I don't expect anything to change at this point, but I do have to point to the
dissonance in the conventions A[] and A[B]. It would have been far less
confusing for A have the same semantic in both cases (preferably value), than
the current situation where it means value for A[], but key for A[B].

1.4.3 last paragraph: You don't need to use MUST in this example - it's not a
requirement on the protocol. I suggest replacing "MUST be" with "is correctly".

In 4.2.5 at 'locationTypes', it would be better to point to the actual registry
(https://www.iana.org/assignments/location-type-registry/location-type-registry.xhtml)
than only to RFC4589.

Do you want to say anything about what should happen if the size of a resource
(as represented by 'size' in 4.2.7) doesn't match the actual fully decoded
size? I think you mean for this property to be an informational estimate, and
you should explicitly say the actual size could be quite different.

In 4.2.10, 'american-football""' should be 'american-football"' (one fewer ")

In 4.3.2 at 'byDay', why do you have * symbols around 'An *NDay* object'?

In 4.4.5 at 'scheduleUpdated', do you really want to couple this so tightly to
iTIP? Perhaps you should say "the last time this participant provided an
update" and point to iTIP as how these are typically provided?

Major issues:

Minor issues:

Nits/editorial comments:



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-dnssd-prireq-04

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Ready with Nits

This is a combined genart and secdir last-call review.
Please treat these comments just like any other last call comments.

Document: draft-ietf-dnssd-prireq-04
Reviewer: Robert Sparks
Review Date: 2020-02-07
IETF LC End Date: 2020-02-12
IESG Telechat date: Not scheduled for a telechat

Summary: Ready (but with nits) for publication as an Informational RFC

This document provides a set of high-level requirements for a DNS-SD
privacy exptension, and discussion motivating those requirements.

Comment:
It might be good to call out in the discussion that while it is intended
to be thorough, it's not possible to be exhaustive.

Nits (editorial, in document order):

The last sentence of the first paragraph of the introduction is complex.
Consider breaking it apart.

In the introduction at "When analyzing these scenarios in Section 3.2",
did you mean Section 3.1?

In the first sentence of 3.2 at "the scenarios in Section 2", did you
mean Section 3.1?

At the first sentence in 3.4.4, at "online" did you mean "on-link"?

The statement in the second paragraph of section 4 is perhaps too strong.
Consider changing "will lead" to "are intended to lead".

The item numbering in sections 4.1 and 4.2 are messsed up.

The intent of the next to last paragraph in 4.1 and the last paragraph in 4.2
could be made more clear. I suggest something like: "When listing and resolving
services in current DNS-SD deployments".



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart telechat review of draft-ietf-cellar-ebml-14

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please 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

.

Document: draft-ietf-cellar-ebml-14
Reviewer: Robert Sparks
Review Date: 2019-12-06
IETF LC End Date: 2019-11-07
IESG Telechat date: 2019-12-19

This is just a copy of my LC review of -13 (to which I received no response):

Summary: Not ready for publication as a Proposed Standard

I had previously reviewed version -09 of this document. Thanks for addressing
many of the issues I had raised at that time. My re-review has focused mainly 
on the diff between -09 and -13. It was surprisingly hard to make useful diffs 
between these versions, but it was possible to do so by separating out some 
reordered sections and comparing them separately.

I still find this document difficult to comprehend.

While not all of the issues I raised were addressed, I don't feel strongly
enough about them to repeat them. However, there is one major issue still
outstanding that is something the AD should handle.

(Attention Alexey) : It's not clear that this group is chartered to produce a
general purpose binary equivalent to XML. Instead, it appears to be chartered
to document FFV1 and Matroska. EBML as it is currently used for those things
needs to be documented, but rather than try to make it into a format that other
things besides the work of this group appears out of scope. If I'm correct,
then this document shouldn't need to create an IANA registry - it need only
document what the group needs (and if the group needs more later, it can update
this document). The abstract and introduction would need to be adjusted to
scope the purpose of the format to supporting the work of this group. My review
assumes a scope of "documenting these existing formats" rather than providing a
general purpose markup language. If I'm wrong and this group is chartered to
produce an alternative for other protocols to use, this needs review from
people who are more expert in that kind of representational design than me.






___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-nottingham-rfc7320bis-02

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-nottingham-rfc7320bis-02
Reviewer: Robert Sparks
Review Date: 2019-11-26
IETF LC End Date: 2019-12-16
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a BCP but with nits to consider during the
approval process

Nits:

Neither the document nor the shepherds write-up acknowledge or explain the
replacement of RFC6838 with RFC3986 for a reference for specifying fragment
identifier syntax and semantics (hence dropping the reference to 6838). It
would be nice to have something captured in the record that supports/explains
this change.

Near that change, there is a typo, currently saying "fragment identiers'
syntax" (should be "identifiers'")

It might be good to capture in the "Note to Readers" that the RFC Editor should
also remove Section 6.3 (URIs) since all the references to them will be removed
with the removal of this Note.


___
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-cellar-ebml-13

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Not Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-cellar-ebml-13
Reviewer: Robert Sparks
Review Date: 2019-11-04
IETF LC End Date: 2019-11-07
IESG Telechat date: Not scheduled for a telechat

Summary: Not ready for publication as a Proposed Standard

I had previously reviewed version -09 of this document. Thanks for addressing
many of the issues I had raised at that time. My re-review has focused mainly 
on the diff between -09 and -13. It was surprisingly hard to make useful diffs 
between these versions, but it was possible to do so by separating out some 
reordered sections and comparing them separately.

I still find this document difficult to comprehend.

While not all of the issues I raised were addressed, I don't feel strongly
enough about them to repeat them. However, there is one major issue still
outstanding that is something the AD should handle.

(Attention Alexey) : It's not clear that this group is chartered to produce a
general purpose binary equivalent to XML. Instead, it appears to be chartered
to document FFV1 and Matroska. EBML as it is currently used for those things
needs to be documented, but rather than try to make it into a format that other
things besides the work of this group appears out of scope. If I'm correct,
then this document shouldn't need to create an IANA registry - it need only
document what the group needs (and if the group needs more later, it can update
this document). The abstract and introduction would need to be adjusted to
scope the purpose of the format to supporting the work of this group. My review
assumes a scope of "documenting these existing formats" rather than providing a
general purpose markup language. If I'm wrong and this group is chartered to
produce an alternative for other protocols to use, this needs review from
people who are more expert in that kind of representational design than me.




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart early review of draft-ietf-rift-rift-08

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Not Ready

Summary: Not ready for publication as a Proposed Standard

I found this document very difficult to read. On my first past through, I was
fairly certain it didn't specify the protocol well enough to actually implement
it, until I got deep into the appendices. Even after a second pass, I am not
comfortable that a implementation could be produced without having guess at
some behavior, which will lead to interoperability problems.

I strongly suggest restructuring the draft to pull the actual definition of the
protocol from the appendix and into the early part of the document text. You
may also want to use the new v3 format so that you can take advantage of its
support for SVG to help convey your state diagrams.

At the very least, the document needs a strong editorial scrub. There are many
sentences that are missing important articles. There are many sentences that
are very complex and would be better written as two or three sentences. There
are many sections that too deeply assume the reader already understands the
problem space.

In the remainder of the review, I'm not going to call out each overly-complex
sentence individually, but will attempt to point at a few that also had other
issues.

Some high-level points before going into a document-order set of comments:

** The IANA considerations section does not provide a clear set of instructions
for IANA to follow.

* The notion of a "three-way adjacency" is not made clear in the document. It
really takes looking at a rendering of the dot for the state machines before
this term becomes well-defined.

* There are a few places where there are internal references in the document
that are not clear. These center around the word "Paragraph". For instance, in
Req4, there is a reference to "Paragraph 17". Does that mean "Req 17"?  

* K_LEAF suddently appears without support or definition in 5.1.2. That and
the other K_ terms should be discussed in the terminology section.

* It's unclear whether HH symbol means one or two RJ45 jacks. The diagrams
appear to use the symbol inconsistently.


=== Issues in document order ===

In the introduction:

"The incumbent protocols precondition normally extensive configuration or
provisioning during bring up and re-dimensioning which is only viable for a set
of organizations with according networking operations skills and budgets." did
not parse for me until my second read-through, where I realized "precondition
normally" was intended to mean "normally require". "bring up" and
"re-dimensioning" are almost jargon in this context.

In the Terminology section:

It would be good to introduce S-TIE and N-TIE as top level terms in this
section.

The words for Adjacency are not really a definition, but taken as such they are
circular.

The definition for Metric is not useful.

In the first paragraph of 5.1.1, The construction of 'never ... (we'll talk
about exceptions later)' is awkward. It's also unclear where the the "later" is
pointing. The last sentence is grammatically incorrect ("We omit ... out"), and
talks of omimitting discussion "for the moment". Please make it clear where you
return to the discussion.

The third paragraph of 5.1.2 does not parse. I suspect there is a missing word
somewhere in "the introduced Section 3.1".

The nested numbered lists in section 5.2.3.9 are perhaps not the best tool for
describing the algorithms you want to convey. On page 46, steps 4.3.3 and 4.4
are comments, not actions. Numbering them as you number actions is confusing.

The last Step 7 in section 5.2.3.9 speaks of "sine flooding reduction". What is
that?

The reference in 5.2.7.2's first paragraph to [EUI64] looks like a normative
reference to me. 

Something is wrong at the bottom of page 68. One branch of the sentence reduces
to "we have to decide whether node Y is ... at the same level as Y".

In 5.3.4.1 rule 1, you only consider nodes to which the reciever has a
bi-directional adjacency. As opposed to what? Does this mean adjacencies in
TwoWay or ThreeWay state? Or something else?

There is a dangling reference to [PGP reference] at the end of 5.3.11.

Section 7.3 is really not useful for the protocol specification. Consider
removing it.

In section 8.4 the sentence "The attack vector packet number present is
relatively benign." does not parse.

It's particularly unclear what you are trying to achive with the
"DirectionMaxValue" registry entry defined in 9.2.11.1 Are you trying to say
the registry is not allowed any more values? If so, just say that in the
instructions to IANA. I don't see where the codepoint is used by the protocol,
so I suggest it not be added to the registry.

It's a leap to get from the description of Sequence Number Binary Arithmetic in
Appendix A to the "rollover" mechanic the paragraphs that reference Appendix A
are looking for. Please clarify. 

Also in Appendix A, I question the sentence "The >: relationship is symmetric
but not transitive". Symmetric says "if 

[Gen-art] Genart last call review of draft-ietf-core-senml-etch-05

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-core-senml-etch-05
Reviewer: Robert Sparks
Review Date: 2019-08-29
IETF LC End Date: 2019-09-02
IESG Telechat date: 2019-09-05

Summary: Ready for publication as a Proposed Standard RFC, but with nits to
consider before publication

Nits:

Since the string "-etch-" is in the media type, it might be nice to say in the
document where it came from.

I think the text in the interoperability considerations sections of the
registrations could be improved. You mean to talk about unrecognized keys, not
unrecognized key-value pairs. I also think the body of the RFC should have a
very short extensibility section that explicitly says you're doing a similar
thing as 8424 section 4.4 and point to that section.

I am a little uncomfortable with the "Fragment Identification" section (4) of
this document - it feels like a "do what we mean" statement. I don't have text
to suggest. It may well be that it will be dead-obvious to an implementer what
to do, but it makes me uneasy.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart telechat review of draft-ietf-lamps-cms-mix-with-psk-06

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-lamps-cms-mix-with-psk-06
Reviewer: Robert Sparks
Review Date: 2019-08-16
IETF LC End Date: None
IESG Telechat date: 2019-08-22

Summary: Ready for publication as a Proposed Standard RFC


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart telechat review of draft-ietf-dnssd-push-23

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-dnssd-push-23
Reviewer: Robert Sparks
Review Date: 2019-08-02
IETF LC End Date: None
IESG Telechat date: 2019-08-08

Summary: Ready for publication as a Proposed Standard RFC

Thanks for addressing all of the concerns in my previous review.





___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-lamps-cms-mix-with-psk-05

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-lamps-cms-mix-with-psk-05
Reviewer: Robert Sparks
Review Date: 2019-07-30
IETF LC End Date: 2019-08-06
IESG Telechat date: Not scheduled for a telechat

Summary: Essentially ready for publication as a Proposed Standard, but with an
issue to address before publication.

Issue: The instructions for IANA are unclear. IANA has to infer what to add to
the registries. I think they _can_ infer what to do for the IANA-MOD registry.
It's harder (though still possible) to guess what to do for IANA-SMIME. They
also have to infer the structure of the new registry this document intends to
create. Explicit would be better. Also, the document anticipates the currently
non-existing anchor to the new registry in the references (security-smime-13).
That generally should also be a tbd to be filled by IANA when the anchor is
actually created.

Nits/editorial comments:

Section 5, 1st paragraph, last sentence: "make use fo" should be "makes use of"

Section 9, 1st sentence : "in the Section 5" should be "in Section 6". (That's
two changes - the removal of a word, and a correction to the section number).

Micronit: In the introduction, you say "can be invulnerable to an attacker".
"invulnerable" is maybe stronger than you mean?


___
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-mile-jsoniodef-09

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-mile-jsoniodef-09
Reviewer: Robert Sparks
Review Date: 2019-07-16
IETF LC End Date: 2019-08-01
IESG Telechat date: Not scheduled for a telechat

Summary: Almost ready for publication as a proposed standard RFC, but with
minor issues and nits to address before publication

I skimmed the various formal definitions. I have not verified they are complete
or correct. If someone in the working group hasn't found a tool to do that,
then the chairs should wrangle some intense volunteer labor to make sure these
things are what you intend them to be.

Minor Issues:

* Section 2.2.5 says "base64 ... should be used for encoding". Why is this (a
  lower case) should? What happens if something doesn't base64 encode embedded
  raw data?

* In the table in section 3.1 (and I suspect the corresponding cddl and json
  schema, but I haven't verified that), in the block for 'Incident',
  'Indictator' is marked with a *. Looking at RFC7970, I think it should be
  marked with a ?. (0..1 instead of 0..*).

* There are places in the prose of RFC7970 that add restrictions to conformant
  XML documents that aren't captured in the schema. See "An instance of one of
  these children MUST be present." in section 3.11 of that document for example.
  That constraint is not present in this document (or did I miss it)? 

* In section 3.2, the 7th bullet is likely an artifact of an earlier idea that
  was replaced by the one in the 8th bullet. I suggest deleting the 7th bullet
  (The one that says "Record class is replaced by RecordData class, and
  RecordData class is renamed to Record class."

Nits:

* I suggest removing 'abstract' from 'abstract IODEF JSON' in section 2.

* Section 3.2 uses "CBOR/JSON IODEF" in some places (see the title and several
  bullets). The Introduction introduces this as just "JSON IODEF". I suggest
  removing the "CBOR/" wherever it occurs.

* The example in Figure 6 is broken at the end. There is a BulkObservable list
  that says it is supposed to consist of ipv6-addr objects, but the list
  consists of one e-mail object.  (Same happens in Figure 7 of course).


___
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-dnssd-push-20

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-dnssd-push-20
Reviewer: Robert Sparks
Review Date: 2019-06-28
IETF LC End Date: 2019-07-05
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a Proposed Standard but with an Issue to
consider before publication,

Issue:

The discussion of recursive resolvers in section 6.1 may need additional
consideration. In particular, the recommendation to pass a received error code
along to a client has, I think, some unintended consequences for the client. If
the recursive server receives a NOTIMP, for example, passing that to the client
tells the client the wrong thing about the server it is connected to. Perhaps
it would be better for the recursive server to return SERVFAIL in this
circumstance? (Similar to what it would do if it couldn't connect to the next
server as described at the bottom of page 10).

Nits:

Page 5, Section 3, 3rd paragraph, last sentence: NOT REQUIRED is not a
2119/8174 keyword. I suggest using lowercase 'not required' in this sentence.

Page 7, Section 4, 3rd paragraph: The first sentence alludes to concerns about
anonymous subscriptions, saying TCP alleviates those concerns. As written this
is pretty vague. Can you expand on what you mean by an anonymous subscription
in this context?

Page 10, Section 6.1, first sentence: Suggest s/first step in DNS Push/first
step in a DNS Push/

Page 15, last paragraph: Why MUST the server immediately terminate a connection
in this situation? Just accepting the request seems safe - having subscription
requests show up for the same name seems nearly idempotent, and only one PUSH
would result from having multiple such subscriptions. Is this close an attempt
to avoid resource denial attacks buy some node subscribing many times to the
same thing? That feels extreme, especially since tearing down the connection
would cancel other subscriptions the client already has established on that
connection.

Page 16, second paragraph: I suggest replacing the second sentence with
something like "A name in a SUBSCRIBE message that matches only a literal CNAME
in the zone will only receive notifications of changes to the CNAME (assuming
the subscription asks for that type), and nothing else."

Page 23, top of page: Since section 4 restricts this protocol to TLS over TCP,
the "(or equivalent for other protocols)" phrase should be removed.


___
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-ip-06

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-acme-ip-06
Reviewer: Robert Sparks
Review Date: 2019-06-03
IETF LC End Date: 2019-06-12
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a proposed standard rfc.

One minor nit: The security considerations section reads oddly. I'm not sure
what it means for an extension to deviate from a threat model. I think you want
to say "does not add to" rather than "does not deviate"?


___
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-restconf-notif-13

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-netconf-restconf-notif-13
Reviewer: Robert Sparks
Review Date: 2019-04-10
IETF LC End Date: 2019-04-12
IESG Telechat date: Not scheduled for a telechat

Summary: Ready for publication as a proposed standard

Nits/editorial comments:

The abstract is quite terse. Please consider expanding it to something that
stands better by itself.

The sentence that starts "Driving these requirements" in the introduction does
not follow where it sits in the paragraph. There is no antecedent for "these
requirements". I suggest replacing the sentence with "Requirements for these
mechanisms are captured in [RFC7923].

The second sentence in the first paragraph of section 3 is a run-on. I suggest
s/2.4, the/2.4. The/


___
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-iasa2-consolidated-upd-07

[Robert Sparks via Datatracker]

Reviewer: Robert Sparks
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

.

Document: draft-ietf-iasa2-consolidated-upd-07
Reviewer: Robert Sparks
Review Date: 2019-03-14
IETF LC End Date: 2019-04-01
IESG Telechat date: 2019-04-11

Summary: Ready for publication as a BCP


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art