[Gen-art] Genart last call review of draft-ietf-httpapi-rfc7807bis-04

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready

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

For more information, please see the FAQ at

.

Document: draft-ietf-httpapi-rfc7807bis-04
Reviewer: Pete Resnick
Review Date: 2022-10-27
IETF LC End Date: 2022-11-03
IESG Telechat date: Not scheduled for a telechat

Summary: Ready to go; one comment below.

Major issues: None

Minor issues: None

Nits/editorial comments:

This paragraph in section 4 struck me oddly:

   An extension member (see Section 3.2) MAY occur in the Problem field
   if its name is compatible with the syntax of Dictionary keys (see
   Section 3.2 of [STRUCTURED-FIELDS]) and if the defining problem type
   specifies a Structured Type to serialize the value into.

That almost sounds like what you want to say is:

   If an extension member (see Section 3.2) occurs in the Problem field,
   its name MUST be compatible with the syntax of Dictionary keys (see
   Section 3.2 of [STRUCTURED-FIELDS]) and the defining problem type
   MUST specify a Structured Type to serialize the value into.

I'm curious if you are making a normative statement that would get lost in the
current form. But I'm not sure what the high-order bit here is, so I leave it
to you.


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

[Gen-art] Genart last call review of draft-ietf-regext-epp-eai-10

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: On the Right Track

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

For more information, please see the FAQ at

.

Document: draft-ietf-regext-epp-eai-10
Reviewer: Pete Resnick
Review Date: 2022-06-01
IETF LC End Date: 2022-06-09
IESG Telechat date: Not scheduled for a telechat

Summary:

I think this proposal is reasonable, but I don't think enough explanation has
been given regarding the case where one side supports the protocol but the
other side doesn't.

Major issues:

The last bullet item in section 5.3.2 talks about "alternative ASCII address",
but I don't see anywhere in the document which defines how to provide an
alternative ASCII address in the data. For example, RFC 5733 implies that there
will be only one email address in the Contact Mapping; can an implementation
simply add a second? Does the server then need to distinguish these by the
presence or absence of non-ASCII characters to determine which is an EAI and
which is an alternative ASCII address? At the very least, some discussion of
this seems necessary in the document.

Minor issues:

In the bullets in section 5.3.2, there are quite a few SHOULDs with no
explanation of why one might choose to violate these. Why are these not MUSTs?
I can't think of any reason, for example, that the server would not validate
the email property, and it seems like a really bad idea not to.

Nits/editorial comments:

Abstract: Strike the word "appearing"

Section 3: Change "By applying the syntax rules of [RFC5322]" to "By applying
the syntax rules of [RFC6532]"



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

[Gen-art] Genart last call review of draft-ietf-cbor-file-magic-11

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-cbor-file-magic-11
Reviewer: Pete Resnick
Review Date: 2022-04-15
IETF LC End Date: 2022-04-15
IESG Telechat date: 2022-04-21

Summary: Some mostly nit/editorial comments that really should be taken care
of, but no showstoppers.

Major issues: None

Minor issues: None

Nits/editorial comments:

Section 1 could use a solid edit. Here are some editorial issues that stuck out
to me (as always, just suggested changes):

Paragraph 3 (this one is a content problem rather than strictly nits, but also
isn't a technical issue with the document):

OLD

 For instance, in classical MacOS, a
   resource fork was maintained that includes media type ("MIME type")
   information and therefore ideally never needs to know anything about
   the file.

NEW

 For instance, in classical MacOS, a
   resource fork was maintained separately from the file data that
   included file type information and therefore the OS ideally never
   needed to know anything about the file data contents to determine the
   media type.

No "But" is required at the beginning of paragraph 4.

Paragraph 5: Change "file" to "file contents". (For what it's worth, I disagree
with the paragraph, in that I think it's actually worse to keep the media type
information in the data portion of the file, but I don't have a problem with
you disagreeing with that in the introduction.)

Paragraph 8: Change the colon to a semicolon.

Paragraph 9: Replace "A third" with "An additional".

Swap paragraphs 9 & 10.

Paragraphs 13 & 14 seem confusing, if not contradictory.

Move paragraph 14 up after paragraph 8.

The last paragraph repeats the information in the 9th paragraph.

Section 2.1, last paragraph: Change "has already been allocated" to "is
described".

Appendix C, last paragraph before C.1: This is a repeat of the last paragraph
of section 2.3. I don't think it's necessary to repeat.



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

[Gen-art] Genart last call review of draft-carpenter-rfced-iab-charter-05

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Nits

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

For more information, please see the FAQ at

.

Document: draft-carpenter-rfced-iab-charter-05
Reviewer: Pete Resnick
Review Date: 2022-02-15
IETF LC End Date: 2022-03-07
IESG Telechat date: 2022-03-10

Summary: Looks fine, save one typo

Major issues: None

Minor issues: None

Nits/editorial comments: In section 2, change "(b) RFC Series and IANA" to "(d) 
RFC Series and IANA"



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

[Gen-art] Genart last call review of draft-ietf-pim-igmp-mld-extension-05

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-pim-igmp-mld-extension-05
Reviewer: Pete Resnick
Review Date: 2022-01-13
IETF LC End Date: 2022-01-19
IESG Telechat date: Not scheduled for a telechat

Summary: One possible minor issue and a couple of nits, but otherwise ready.

Major issues:

None.

Minor issues:

In section 3 it says,

   There is no alignment or padding.

Are you sure that implementations are going to work with this? In my old brain,
there are still memories of trying to read 16-bit values out of an odd-aligned
location caused all sorts of problems. Are you sure you don't want to at least
pad this to even lengths?

Nits/editorial comments:

In section 3, this sentence confused me for a moment:

   A previously reserved bit in the IGMPv3 and MLDv2 headers is used to
   indicate whether this extension is used.

I suggest:

   For each of the IGMPv3 and MLDv2 headers, a previously reserved bit
   is used to indicate the presence of this extension.

In section 3:

   When this extension
   mechanism is used, the number of Group Records in each Report message
   should be kept small enough that the entire message, including any
   extension TLVs can fit within the network MTU.

That "should" looks pretty interoperability-related to me. Perhaps "SHOULD"?



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

[Gen-art] Genart early review of draft-ietf-opsawg-l3sm-l3nm-14

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready

Got this review late; apologies for finishing it a few days later that it
should.

As usual for YANG reviews (not my forte), I simply looked for data items being
compared in i18n-unsafe ways or other misuses. Nothing obvious. Seems ready to
go as far as this app layer reviewer is concerned.


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

[Gen-art] Genart last call review of draft-ietf-core-new-block-10

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-core-new-block-10
Reviewer: Pete Resnick
Review Date: 2021-04-24
IETF LC End Date: 2021-04-28
IESG Telechat date: Not scheduled for a telechat

Summary:

The document looks pretty solid to me. There is one item I marked as a minor
"issue", but it may simply be an editorial item that confused me; I figured I'd
call it an issue just in case so it doesn't get left to the last minute to look
at.

Do note that I have not reviewed the examples for correctness; I simply don't
have the expertise to be convinced I'd do it right.

Major issues:

None.

Minor issues:

In section 4.4:

I find this paragraph confusing:

   The requested missing block numbers MUST have an increasing block
   number in each additional Q-Block2 Option with no duplicates.  The
   server SHOULD respond with a 4.00 (Bad Request) to requests not
   adhering to this behavior.

So, given the SHOULD in the second sentence, it appears that the MUST in the
first sentence doesn't apply to the server (i.e., to enforce this), but rather
to the client doing the request. You should probably say it that way. Also, the
SHOULD in the second sentence is not entirely clear to me: Are you saying that
the server can choose to use some other response code, or are you saying that
the server can accept the request and do something interesting with it? Below
is an attempt to fix it, but might not be correct depending on what you mean:

   The client MUST use an increasing block number in each additional
   Q-Block2 Option when requesting missing block numbers, and MUST
   request no duplicates.  The server MUST reject requests  not adhering
   to this behavior and SHOULD respond with a 4.00 (Bad Request) to such
   requests.

There are other places in the document that use MUST with regard to what needs
to be in a piece of data (see for example sections 4.5 and 4.6), but don't make
it clear who is responsible for enforcing that MUST (the client or the server).
You should read through the entire document for MUSTs (or SHOULDs) like that
and make sure it's clear from the context.

Nits/editorial comments:

In section 4.3:

In several response code definitions:

   The token used MUST be any token that was received in a request using
   the same Request-Tag.

That doesn't really parse well. I think you either mean "The token used MUST be
a token" or you mean "The token used can be any token".

Specific response codes:

   4.00 (Bad Request)

  This Response Code MUST be returned if the request does not
  include neither a Request-Tag Option nor a Size1 Option but does
  include a Q-Block1 option.

Either change "neither...nor" to "either or", or change "does not include" to
"includes".

   4.02 (Bad Option)

  Either this Response Code (in case of Confirmable request) or a
  reset message (in case of Non-confirmable request) MUST be
  returned if the server does not support the Q-Block Options.

That sort of buries a MUST requirement for the Non-confirmable case inside this
requirement for a Response Code. I suggest instead:

  This Response Code MUST be returned for a Confirmable request if
  the server does not support the Q-Block Options. (A reset message
  is sent in case of Non-confirmable request.)

In section 4.4:

The passive here is not great form, particularly because it doesn't name the
actor:

   It is permissible to set the M bit to request this...

How about instead:

   The client MAY set the M bit to request this...

Maybe that's obvious, since the client does the requesting, but I think the
non-passive form is easier to read.

In the second to last paragraph:

   If the server transmits a new body of data (e.g., a triggered Observe
   notification) with a new ETag to the same client as an additional
   response, the client should remove any partially received body held
   for a previous ETag for that resource as it is unlikely the missing
   blocks can be retrieved.

I'm ambivalent about whether that "should" ought to be uppercased, but I just
wanted to make sure you intended the lowercase.

In section 7.2:

   For the server receiving NON Q-Block1 requests, it SHOULD send back a
   2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS
   payloads to prevent the client unnecessarily delaying.  Otherwise...

When you say "Otherwise", Do you mean, "For other payloads"? Either way, you
should probably change that to make it clear.



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

[Gen-art] Genart last call review of draft-ietf-acme-authority-token-tnauthlist-07

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Nits

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

For more information, please see the FAQ at

.

Document: draft-ietf-acme-authority-token-tnauthlist-07
Reviewer: Pete Resnick
Review Date: 2021-03-15
IETF LC End Date: 2021-03-16
IESG Telechat date: Not scheduled for a telechat

Summary:

Looks fine. Some of the MUSTs look weird or superfluous to me and could
probably use a scrub, and a couple are a bit confusing, but none is so bad that
I would raise them as an "issue"; call them "nits/editorial comments".

Major issues:

None

Minor issues:

None

Nits/editorial comments:

Section 1: It's not clear to me what the purpose of the third paragraph in the
intro is. It sounds like it's just describing section 9 of RFC 8226, but it is
not distinguishing it from or comparing it to this document. Is it really
needed?

Section 3:

Instead of a reference to 7.4 of RFC 8555, perhaps a reference to section 7
generally would help, or perhaps a reference later in this section to 7.1.4.
Once I got down to the examples, I had to go look at 7.1.4 to familiarize
myself with the operation to understand what I was looking at.

Total nit, and just a personal pet peeve: It always seems silly to me to use
MUST where the meaning of that word is "MUST do what the protocol we are hereby
defining says to do". So instead of "MUST include", it could simply be
"includes", and "MUST be" could be "is" in the two places it occurs. These
three did not cause any significant confusion, whereas the ones is section 4
and 5.4 did cause some (see below). Either way, you should review all of them
in the document and decide what is truly needed.

Section 4:

Where it says, "a CA MUST use the Authority Token challenge type of "tkauth-01"
with a "tkauth-type" of "atc"", I am left to wonder what other choice the CA
might make such that you have to warn it that it MUST use these. Why is "uses"
not sufficient?

Conversely, when you say that the "token-authority" parameter is "optional"
(did you mean OPTIONAL): Is that really true? Is it that it MUST be used "in
cases where the VoIP telephone network requires the CA to identify the Token
Authority" (in which case it's not OPTIONAL), or is that simply an operational
consideration, and protocol-wise it is truly OPTIONAL? On the other hand, the
MAY and MUST at the end of the paragraph seem more appropriately to be "can"
and "can only". And the MUST in the following paragraph seems like another of
the ones in which you could change "MUST respond" to "responds".

Section 5:

The last paragraph seems superfluous.

Section 5.4:

The MUST NOT in the third bullet actually caused me a bit of confusion: I tried
to read it as a requirement of this document. I think you mean "is not" instead
of "MUST NOT be".

Section 5.5:

   The response to the POST request if successful MUST return a 200 OK
   with a JSON body that contains, at a minimum, the TNAuthList...

I think instead you mean:

   The response to the POST request if successful returns a 200 OK with
   a JSON body that MUST contain, at a minimum, the TNAuthList...

Then you won't need the "...however..." bit at the end of the next sentence.

In the last paragraph, why "SHOULD" and not "MUST"?



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

[Gen-art] Genart last call review of draft-ietf-6lo-blemesh-08

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-6lo-blemesh-08
Reviewer: Pete Resnick
Review Date: 2020-12-04
IETF LC End Date: 2020-10-21
IESG Telechat date: Not scheduled for a telechat

Summary: Looks good to me, with two items that seemed confusing enough that
they should be addressed.

Note that this review is being done well after the close of the Last Call.
Since this is not yet scheduled for a telechat, the AD asked that I go ahead
and complete the review anyway.

Major issues: None

Minor issues:

3.3.2, #4:

   Implementations of this specification MAY support
   the features described in sections 8.1 and 8.2 of RFC 6775, as
   updated by RFC 8505, unless some alternative ("substitute") from some
   other specification is supported by the implementation.

This bit confused me. I think it was the "unless". Do you mean it MAY support
the 6775/8505 features, or MAY support some substitute, or MAY support neither,
or do you mean that it MUST support either the 6775/8505 features or MUST
support some substitute? I think you want to rewrite this to make it clear
which one you mean.

3.3.3, last two paragraphs:

   When a 6LN transmits a packet, with a non-link-local source address
   that the 6LN has registered with EARO in the next-hop router for the
   indicated prefix, the source address MUST be fully elided if it is
   the latest address that the 6LN has registered for the indicated
   prefix (SAC=1, SAM=11).  If the source non-link-local address is not
   the latest registered by the 6LN, then the 64 bits of the IID SHALL
   be fully carried in-line (SAC=1, SAM=01) or if the first 48 bits of
   the IID match with the latest address registered by the 6LN, then the
   last 16 bits of the IID SHALL be carried in-line (SAC=1, SAM=10).

   When a router transmits a packet to a neighboring 6LN, with a non-
   link-local destination address, the router MUST fully elide the
   destination IPv6 address if the destination address is the latest
   registered by the 6LN with EARO for the indicated context (DAC=1,
   DAM=11).  If the destination address is a non-link-local address and
   not the latest registered, then the 6LN MUST either include the IID
   part fully in-line (DAM=01) or, if the first 48 bits of the IID match
   to the latest registered address, then elide those 48 bits (DAM=10).

Both of these were a bit confusing to me. I think you want to reverse the order
of the last two choices. Say something like (for the first paragraph), "If the
source non-link-local address is not the latest registered by the 6LN and the
first 48 bits match..., then the last 16 bits SHALL be carried in-line.
Otherwise, if first 48 bits do not match, then the 64 bits shall be carried
inline." Similarly for the second. As it is, it takes a while to figure out
what it means.

Nits/editorial comments: Do fix the reference nits noted by the nits tool; they
appear to be simple typos.


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

[Gen-art] Genart last call review of draft-ietf-extra-sieve-mailboxid-05

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-extra-sieve-mailboxid-05
Reviewer: Pete Resnick
Review Date: 2020-11-30
IETF LC End Date: 2020-12-02
IESG Telechat date: Not scheduled for a telechat

Summary: Looking good. Just one minor issue and one nit.

Major issues:

None.

Minor issues:

Section 4 says:

   If there is no such mailbox, the "fileinto" action proceeds as it
   would without the ":mailboxid" argument.

But the in the example in section 6, it shows:

   if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" {
   fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
   "INBOX.harassment";
   } else {
   fileinto "INBOX.harassment";
   }

That appears correct, but as far as I can tell, it is semantically identical to:

   fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
   "INBOX.harassment";

That is, the rule in section 4 means that fileinto already does an implicit
existence check and only uses the named mailbox if the one specified by the
mailboxid doesn't exist. It's not that the example is particularly a problem,
but it did confuse me for a few minutes while I tried to figure out what it was
trying to do. Perhaps if the example was:

   if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" {
   fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
   "this.name.will.never.be.used";
   } else {
   fileinto "INBOX.harassment";
   }

or an example that did something other than "fileinto" it would have made a bit
more sense. Certainly not absolutely necessary to fix, but a change might
improve understanding.

Nits/editorial comments:

In sections 4.1 and 4.2, you have references that appear as "[!@RFC5490]" and
"[!@RFC5879]". I assume that's some sort of markdown or other formatting tool
mistake.


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

[Gen-art] Genart last call review of draft-ietf-v6ops-cpe-slaac-renum-04

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-v6ops-cpe-slaac-renum-04
Reviewer: Pete Resnick
Review Date: 2020-09-09
IETF LC End Date: 2020-09-09
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with one process issue, and some assorted nits.

Major issues: None

Minor issues:

The shepherd writeup says:

   The document so far has been approved by the V6OPS working group
   (successful working group last call). The document does not specify
   new protocol, but rather changes to the default parameters in
   existing protocols.

However, the document is Informational, as confirmed by the shepherd writeup.
If this is actually updating default parameters in protocols, that sounds like
it should either be a Standards Track document or more likely a BCP. As 2026
says:

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations. [...]

   ...[G]ood user
   service requires that the operators and administrators of the
   Internet follow some common guidelines for policies and operations.
   While these guidelines are generally different in scope and style
   from protocol standards, their establishment needs a similar process
   for consensus building.

That sounds like what this is doing, especially with all of the 2119 language
in here. Maybe this is Informational because 7084 (and 6204 before it) were
Informational, but perhaps 7084 (and other such document) should be BCP as
well. Indeed, it sounds like all of these SLAAC operational documents could be
in one BCP together. Either way, Informational seems wrong.

Nits/editorial comments:

Throughout the document, it says, "This document RECOMMENDS..." or "This
document also RECOMMENDS" or "Additionally, this document RECOMMENDS". RFC 2119
does not use "RECOMMENDS". You can say "CE Routers SHOULD..." or "A Router
Lifetime of ND_PREFERRED_LIMIT is RECOMMENDED" or if you must "It is
RECOMMENDED that..." (blech, I hate the passive form), since SHOULD and
RECOMMENDED are equivalent in 2119, but using the "This document RECOMMENDS..."
form is weird and isn't in 2119.

In 3.3, it says:

   o  Upon changes to the advertised prefixes, and after bootstrapping,
  the CE router advertising prefix information via SLAAC SHOULD
  proceed as follows:

But then each of the things under there has a SHOULD or a MUST. The SHOULD here
is confusing. Instead, the sentence could simply be:

   o  Upon changes to the advertised prefixes, and after bootstrapping,
   the CE router advertising prefix information via SLAAC proceeds as
   follows:

Similarly:

   This document RECOMMENDS that if a CE Router provides LAN-side DHCPv6
   (address assignment or prefix delegation), the following behavior be
   implemented:

Just make the sentence:

   If a CE Router that provides LAN-side DHCPv6 (address assignment or
   prefix delegation), then:



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

[Gen-art] Genart last call review of draft-ietf-mpls-sfl-framework-08

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-mpls-sfl-framework-08
Reviewer: Pete Resnick
Review Date: 2020-06-29
IETF LC End Date: 2020-07-06
IESG Telechat date: Not scheduled for a telechat

Summary:

A couple of minor issues and a couple of *extremely* nitty nits, but overall
looks ready to go.

Major issues:

None.

Minor issues:

It is not clear to me why this is being sent for Informational instead of
Proposed Standard. The shepherd's writeup does not justify it, and in fact the
writeup refers to the document as a "specification", which is exactly what it
appears to be. It defines the use of SFLs, describes how they are processed by
the endpoints, describes how they are aggregated, etc. While the document may
not be standalone, I don't see how it's really an Informational document. I
suggest restarting the Last Call for Proposed, and if for some reason it needs
to be Informational, it can always be downgraded after Last Call.

The Security Considerations section says, "The issue noted in Section 6 is a
security consideration." I'm not sure I understand why that is.

Nits/editorial comments:

Section 1: "(see Section 3)" seems unnecessary.

Section 3: I thought the "Consider..." construction made those paragraphs
unnecessarily wordy and a bit harder to follow.


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

[Gen-art] Genart last call review of draft-gellens-lost-validation-08

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready

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

For more information, please see the FAQ at

.

Document: draft-gellens-lost-validation-08
Reviewer: Pete Resnick
Review Date: 2020-05-24
IETF LC End Date: 2020-06-18
IESG Telechat date: Not scheduled for a telechat

Summary: Looks good. Thanks for addressing my previous comments.

Major issues: None

Minor issues: None

Nits/editorial comments: None



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

[Gen-art] Genart last call review of draft-ietf-dhc-problem-statement-of-mredhcpv6-05

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Not Ready

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

For more information, please see the FAQ at

.

Document: draft-ietf-dhc-problem-statement-of-mredhcpv6-05
Reviewer: Pete Resnick
Review Date: 2020-05-20
IETF LC End Date: 2020-05-25
IESG Telechat date: Not scheduled for a telechat

Summary:

This document is not ready for publication.

Major issues:

Nowhere in the Introduction does this document explain its motivation: Why is a
survey of these mechanisms important for the IETF to publish? It claims that it
is doing "a detailed analysis" in order to "clarify the problems, design
principles, and extract and unify the design specifications to help better
solve the multi-requirement extension problems", but the rest of the document
seems to do nothing more than describe extensions, not do any real analysis of
design principles. And after reading the introduction, I still don't understand
what a "multi-requirement extension" is (the term is never defined), nor do I
know what the problem is with them. Unless the motivation for this document can
be better explained, I do not see this document as being appropriate for
publication.

Minor issues:

None.

Nits/editorial comments:

The entire document could use a good editorial scrub. There are quite a few
grammatical issues.

3.2, 4.2.2, and 4.2.4 give lists of example implementations and options. These
seem unnecessary. When particular examples are useful, of course they can be
included, but simply long lists are not useful.

The general model in 4.1 seems unnecessary; this is nothing that you wouldn't
already know if you understand DHCP.


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

[Gen-art] Genart last call review of draft-ietf-dnsop-multi-provider-dnssec-04

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready

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

For more information, please see the FAQ at

.

Document: draft-ietf-dnsop-multi-provider-dnssec-04
Reviewer: Pete Resnick
Review Date: 2020-03-31
IETF LC End Date: 2020-03-31
IESG Telechat date: 2020-04-09

Summary: Ready.

Good to go. A straightforward document easy enough for this non-expert to get.
Thanks to the shepherd for a straightforward writeup; it made the review even
easier.

Major issues: None

Minor issues: None

Nits/editorial comments:

Just two comments, neither of them should stop progress on the document in any
way:

1. I could see this document being a BCP, since the advice in here seems pretty
prescriptive. I think it will still be perfectly useful as an Informational
document, but it does seem to have important operational advice.

2. In section 3, it occurs to me that another thing you might add to the
problem list is the issue of some servers caching BAD Data. Paul Hoffman was
nice enough to point me to section 4.7 of RFC 4035. Perhaps a reference to
there from this document would be useful.

Again, take them for what they're worth. If you decide not to do either, I feel
the document could go forward as-is without a problem.


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

[Gen-art] Genart last call review of draft-gellens-lost-validation-05

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Not Ready

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

For more information, please see the FAQ at

.

Document: draft-gellens-lost-validation-05
Reviewer: Pete Resnick
Review Date: 2020-03-07
IETF LC End Date: 2020-03-31
IESG Telechat date: Not scheduled for a telechat

Summary:

Abstract, Scope, and Introduction do not accurately reflect the content of the
document, which is not simply a registration.

Major issues:

The Abstract and sections 1 & 2 (Scope and Introduction) indicate that this
document is simply an IANA registration of an S-NAPTR Application Service Tag.
However, section 3 is quite clearly new protocol, some of which changes how RFC
5222 implementations should operate if used in a particular context, and
section 4 lays out the backward compatibility of this new protocol with legacy
RFC 5222 implementations. There is the implication that the NENA i3 documents
will actually be the home of that protocol, but the current i3 document
referenced here does not do so, making this document the canonical statement of
the protocol operations necessary to implement the i3 architecture. That
doesn't seem appropriate for an Informational document that purports to simply
be a registration.

At the very least, the Abstract, Scope, and Intro would need to be updated to
reflect the actual contents of the document. I think things would be better
served by making this a Proposed Standard document so that it gets the
appropriate level of review. I understand from the Shepherd writeup that the
ECRIT WG doesn't have the energy to really work on this document. However, this
is a simple enough extension to the LoST protocol that I think it's
unproblematic to have it as an AD-sponsored standards track document.



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

[Gen-art] Genart last call review of draft-ietf-6man-icmp-limits-07

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Nits

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

For more information, please see the FAQ at

.

Document: draft-ietf-6man-icmp-limits-07
Reviewer: Pete Resnick
Review Date: 2020-02-17
IETF LC End Date: 2020-02-25
IESG Telechat date: Not scheduled for a telechat

Summary:

Nice simple document, easy to read, and pretty much ready to go. The one
"issue" I have listed below is a process nit, but one that should be taken care
of.

Major issues:

None.

Minor issues:

The tracker and the shepherd writeup say that the status of the document is
"Proposed Standard", but the header of the document says "Standard". That's why
the nits checker is complaining about downrefs; it thinks that this is going
for Full Standard. The header should either say "Standards Track" (which is
normal) or "Proposed Standard". (I hereby give Bob crap for missing that one as
shepherd, and I think he should owe me a beer. ;-) )

Nits/editorial comments:

The Abstract and 1.1 both indicate that a source host that receives such an
ICMPv6 error may be able to modify what it sends, which sounds to me like it
means "on the fly". While that might be true, it seems more likely to me that
it will be used for diagnostics to modify future behavior of either the sender
or the receiver at a later date, as mentioned in 4.2. I think it's worth
mentioning up at the top.

Section 1.3: You should probably update to the RFC 8174 text.

Section 5.1: "RECOMMENDS" isn't one of the keywords. It's not a problem in
itself, but if people search the document for the keywords (and they do),
they'll miss this one. Suggest reformulating the sentence to use RECOMMENDED.


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

[Gen-art] Genart last call review of draft-ietf-stir-passport-divert-07

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Nits

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

For more information, please see the FAQ at

.

Note that while this is labeled a Last Call review, this review comes well
after the Last Call completed. However, the author and AD felt it would be
useful anyway since the document has not yet been updated for Last Call
comments.

Document: draft-ietf-stir-passport-divert-07
Reviewer: Pete Resnick
Review Date: 2020-01-09
IETF LC End Date: 2019-12-02
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with Nits

While I found the document (and particularly section 4) very technically dense,
I think the detail will help implementers tremendously. Nothing other than a
few editorial issues.

Major issues: None

Minor issues: None

Nits/editorial comments:

Section 3, paragraph 1:

   Note that
   a new PASSporT is only necessary when the canonical form of the
   "dest" identifier (per the canonicalization procedures in [RFC8224]
   Section 8) changes due to this retargeting.  If the canonical form of
   the "dest" identifiier is not changed during retargeting, then a new
   PASSporT with a "div" claim MUST NOT be produced.

Seems to me that these two sentences should be in their own paragraph. It took
me a second to figure out that the following sentence was not related to these.

Section 4:

   ...Other using protocols of PASSporT

Don't you mean "Other protocols using PASSporT"?

Section 4.2, paragraph 2:

I think you mean "necessarily", not "necessary"


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

[Gen-art] Genart telechat review of draft-ietf-mboned-ieee802-mcast-problems-11

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: On the Right Track

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-mboned-ieee802-mcast-problems-11
Reviewer: Pete Resnick
Review Date: 2020-01-08
IETF LC End Date: None
IESG Telechat date: 2020-01-09

Summary: On the Right Track

As far as I can tell, none of the issues I raised in the Last Call GenART
review were ever addressed.

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

[Gen-art] Genart last call review of draft-ietf-pim-drlb-13

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-pim-drlb-13
Reviewer: Pete Resnick
Review Date: 2019-11-05
IETF LC End Date: 2019-11-07
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with some minor issues and nits, plus one "interesting note".

Major issues:

None.

Minor issues:

In 5.1, the SHOULDs regarding the default hash masks seem a bit odd: Usually
SHOULD means that bad things are likely to happen if you choose otherwise, but
if you know what you are doing, you might choose something different. Is there
any real harm to choosing some other hash masks, or are you simply saying that
these are perfectly reasonable? Not a big deal one way or the other, but if
there is harm, you should probably say something about that.

In 5.1: "The hash value computed will be the ordinal number of the GDR
Candidate that is acting as GDR." I'm not sure what that sentence means, but
then again, this entire document is way outside my area of expertise, so
perhaps this is obvious.

Nits/editorial comments:

The IDNITS tool reports:

  == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses
 in the document.  If these are example addresses, they should be changed.

  == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses
 in the document.  If these are example addresses, they should be changed.

Are those the addresses in 5.2.1? Are they kosher?

In 5.3.2, why is it "RECOMMENDED that the addresses are sorted in descending
order."? Is that what's mentioned in 5.4? If so, perhaps a forward reference
would be helpful.

Finally, my "interesting note":

I see in the shepherd report:



(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes, there is IPR and it has been declared with #1713.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

Yes, IPR has been declared and the WG has been notified.



That seems to indicate that nobody had any comment about the IPR declaration.
But I also see noted in the shepherd report, "Cisco has an implementation of
this protocol. No other vendors have indicated plan to implement the
specification". That leads to a pretty obvious question: Are other vendors not
implementing this because of the IPR (which you'd think would be a concern), or
are other vendors planning on implementing this in the future, or is this just
a Cisco-private extension that requires no interoperability? It seems curious
that there was no discussion at all.

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

[Gen-art] Genart last call review of draft-ietf-mboned-ieee802-mcast-problems-09

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: On the Right Track

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

For more information, please see the FAQ at

.

Document: draft-ietf-mboned-ieee802-mcast-problems-09
Reviewer: Pete Resnick
Review Date: 2019-10-14
IETF LC End Date: 2019-10-14
IESG Telechat date: Not scheduled for a telechat

Summary:

This document has good information and analysis of multicast problems and is
certainly valuable. However, there are some things in the document which could
use clarification or editing.

Major issues:

The first paragraph of section 8 really has too little useful comment. There is
no reference for 802.1ak, the reference to 802.1Q is inline instead of in the
references section, and the content of neither of these standards is explained
in this document. The paragraph doesn't really lay out what the topic of
discussion is, at least for someone like myself who is not versed in the topic.
I really think this needs to be addressed.

Minor issues:

(Some of these issues are more or less "minor".)

Section 3.1.4 seems a little thin to this non-expert. It is certainly true that
"every station has to be configured to wake up to receive the multicast", but
it seems like only a poorly designed protocol would create the situation where
"the received packet may ultimately be discarded" on any kind of regular basis.
If there are a class of packets that the receiver will ultimately discard, that
sounds like they should be on a separate multicast address, or the sender
should be determining if the packet will be discarded before sending it.
Perhaps what this section is driving at is that multicast protocols are often
designed without taking power-saving considerations into account, but then
*that's* what this section should probably talk about. As it is, it sounds like
the old joke about saying to the doctor, "My arm hurts when I do this" and the
doctor replying, "The stop doing that".

In section 3.2.1, the last paragraph is missing a bunch of information:
"It's often the first service that operators drop": What is "it"?
"Multicast snooping" is not defined.
In what scenario are devices "registering"?

Section 3.2.2: "This intensifies the impact of multicast messages that are
associated to the mobility of a node." I don't understand why. Are you simply
saying that as the number of addresses goes up, more discovery packets must be
sent?

Section 3.2.4: This seems like more of general problem than a
multicast-specific one, and as described it sounds like an attack rather than a
poor outcome of a protocol design decision like the rest of the examples.
Perhaps framing it that way would make the section clearer.

Section 4.4: Which problem in section 3 is 4.4 supposed to address?

Section 5.1: "...and sometimes the daemons just seem to stop, requiring a
restart of the daemon and causing disruption." What a strange thing to say.
Does this simply mean "and the current implementations are buggy"?

Also section 5.1: "The distribution of users on wireless networks / subnets
changes from one IETF meeting to the next". This document doesn't seem to be
about the IETF meeting network. This sentence seems inappropriately specific.
The "NAT" and "Stateful firewalls" sections are also overly specific to the
IETF meeting network. Generalizing would help.

7: This section seems quite thin, and perhaps unnecessary. The recommendations
are implicit in the previous sections.

Nits/editorial comments:

Section 3.2.4: The mention of the face-to-face (probably better: "plenary")
meeting seems unnecessary.

Section 5.1: Numbering the subsections would probably be useful.


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

[Gen-art] Genart telechat review of draft-ietf-cbor-sequence-01

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-cbor-sequence-01
Reviewer: Pete Resnick
Review Date: 2019-09-17
IETF LC End Date: None
IESG Telechat date: 2019-09-19

Summary:

Nice simple tight document. No concerns. (Having read the IESG comments, I
think Barry's clarification is nice.)

Major issues:

None.

Minor issues:

None.

Nits/editorial comments:

None.

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

[Gen-art] Genart last call review of draft-ietf-pce-stateful-path-protection-08

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready

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

For more information, please see the FAQ at

.

Document: draft-ietf-pce-stateful-path-protection-08
Reviewer: Pete Resnick
Review Date: 2019-08-28
IETF LC End Date: 2019-08-28
IESG Telechat date: Not scheduled for a telechat

Summary: Ready

No issues of substance that I can see. A few editorial suggestions below, but
nothing earth-shattering.

Major issues: None.

Minor issues: None.

Nits/editorial comments:

Purely editorial suggestions:

Section 3.1:

Delete:
   This document defines a new Association type, the "Path Protection
   Association Type", value will be assigned by IANA (TBD1).

You already say this in the first paragraph.

Section 3.2:

OLD
   The type (16 bits) of the TLV is to be assigned by IANA.  The length
   field (16 bit) has a fixed value of 4.
NEW
   The type (16 bits) of the TLV is TBD2.  The length field (16 bit)
   has a fixed value of 4.

It would probably be caught by the RFC Editor the way you had it, but this way
IANA and the RFC Editor can search and replace for anything with "TBD".

OLD
 | Type = TBD2 |  Length |
NEW
 | Type = TBD2 |  Length = 4 |

OLD
 |   PT  | Path Protection Association Flags |S|P|
NEW
 |   PT  |Unassigned |S|P|

Section 6:

At the top of the section, I suggest putting in the following:

[Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain "TBD1" through
"TBD5" those should be replaced by the values that IANA assigns. Also, Section
4.5 includes several occurrences of the phrase "(Early allocation by IANA)";
please confirm that the value mentioned there is correct and delete that phrase
from the document before publication.]

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

[Gen-art] Genart last call review of draft-ietf-lpwan-ipv6-static-context-hc-21

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-lpwan-ipv6-static-context-hc-21
Reviewer: Pete Resnick
Review Date: 2019-08-06
IETF LC End Date: 2019-07-19
IESG Telechat date: Not scheduled for a telechat

Summary:

Some minor issues, but otherwise looks good to me.

My apologies for this very late review. I hope these comments are useful, but
none of these are showstoppers in my opinion.

Major issues:

None.

Minor issues:

Section 5:

   If the SCHC
   Packet is to be fragmented, the optional SCHC Fragmentation MAY be
   applied to the SCHC Packet.

Don't you mean:

   If the SCHC Packet is to be fragmented, the OPTIONAL SCHC
   Fragmentation is applied to the SCHC Packet.

or even just:

   SCHC Fragmentation is applied if the SCHC Packet is to be fragmented.

I think it's confusing to say that using SCHC is optional if the SCHC Packet is
to be fragmented. If you're fragmenting, it's not optional, is it?

Section 7.1 or 7.3:

It took me a while to get that what you're looking for is a Rule in the list of
Rules that has a function for *all* of the header fields given the DI and FP.
It would be good to say some sort of overview thing like this explicitly,
either in 7.1 or at the top of 7.3. It's possible this is obvious to someone
versed in this topic, but it wasn't for me.

Section 7.3:

Question: Is it possible for multiple Rules to match a given packet? What
happens if you find more than one? That should probably be specified.

Section 7.5.2:

This encoding seems to use more space than needed. I assume you kept the size
in multiples of 4 to make it on nibble boundaries, but I don't understand why
you'd want 28 bits instead of 24. The larger sizes could simply be 0xFF
followed by the 16-bit value.

Nits/editorial comments:

Section 7.3:

In the last bullet of the Rule selection algorithm, it says:

   Sending an uncompressed header may require SCHC F/R.

Sending a compressed header may also require F/R, couldn't it? Seems to me this
sentence is superfluous.

Section 8.1, second paragraph:

It seems like you'd want one or both occurrences of "optional" to be
"OPTIONAL", in the 2119 sense. Is there a reason they're not?

I'm not sure I understand the last sentence of that paragraph. Do you simply
mean, "You can ignore the rest of section 8"? That seems unnecessary to say.

Section 8.2.2.2:

Change:

   o  their numbers MUST increase from 0 upward, from the start of the
  SCHC Packet to its end.

to:

   o  their numbers MUST increase by 1 from 0 upward, from the start of
  the SCHC Packet to its end.

in order to avoid someone being inordinately cute (or stupid).

8.2.4:

"The W field is optional" - Is OPTIONAL not appropriate here? If so, this
appears in many places in section 8.


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

[Gen-art] Genart last call review of draft-ietf-intarea-frag-fragile-13

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Nits

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

For more information, please see the FAQ at

.

Document: draft-ietf-intarea-frag-fragile-13
Reviewer: Pete Resnick
Review Date: 2019-07-04
IETF LC End Date: 2019-07-04
IESG Telechat date: Not scheduled for a telechat

Summary: A document so well-written that even this application-layer idiot
could follow along easily. Thanks for that. I see no significant issues with
this document going forward as a BCP; just a few editorial bits.

Major issues: None

Minor issues: None

Nits/editorial comments:

In Section 2.1 and 2.2, Instead of "set to one" and "set to zero", it would
read easier with "set to (1)" and "set to (0)", or some similar construction.

Section 3 is in an odd place. I'd say either move it up to the top, or put it
down in section 7.

4.2 mentions virtual reassembly. Virtual reassembly applies to 4.1, 4.3, and
4.4 as well. Perhaps moving the discussion of virtual reassembly up to the top
of 4 would make more sense.

In 4.5, insert "duplicate IDs resulting in" after prevent. It took me a bit to
figure out what this was referring to. Also, change "are not easily
reproducible" to "do not occur as frequently"; I think it reads better.

And just to yell into the wind: Section 7.3 seemed a little wimpy to me, but I
can't for the life of me figure out how to make it any stronger or more likely
to be listened to. End of pointless yelling.

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

[Gen-art] Genart last call review of draft-ietf-rtgwg-enterprise-pa-multihoming-08

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Almost Ready

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

For more information, please see the FAQ at

.

Document: draft-ietf-rtgwg-enterprise-pa-multihoming-08
Reviewer: Pete Resnick
Review Date: 2019-06-04
IETF LC End Date: 2019-06-04
IESG Telechat date: Not scheduled for a telechat

Summary: Almost Ready.

I found this overall to be an excellent document with clear technical
explanations that even an upper-layer knucklehead like me could understand.
However, there a couple of issues could use more discussion. I put them as
"Minor issues", in that they're not showstoppers, but I do think they're
important and hope you'll be able to address them.

Major issues:

None.

Minor issues:

Throughout, but particularly in section 5, this document refers to "hosts"
doing address selection. To be fair, so does RFC 6724, but 6724 is referring to
*default* address selection. In reality, *applications* do address selection on
a host; the host stack will only do address selection if the application
requests a default address. That works well for the scenarios in 6724, but in
this document, for example section 5.2.3, I'm not so sure. The idea that a host
would receive an ICMP destination unreachable and re-arrange its address
selection seems at least an incomplete picture: An application with a (normal,
non-multi-path) TCP connection to a remote application is not able to "try
another source address to reach the destination"; the source address is already
set for that TCP connection, so the only choice is to close the connection
entirely. If the application chooses to re-establish the connection with a
default address, yes, the host stack could then give a new default address back
to the application, but this is hardly the dynamic and quickly adjusting
process that the document seems to be envisioning.

I don't think the above invalidates the core of the document or requires some
grand rewrite. But I do think some clarification is in order, saying that the
mechanisms described help with the *default* address selection, and some short
discussion of the limitations for what applications can (and more importantly
cannot) do with these mechanisms would be useful.

My suspicion is that section 7.3 underestimates the availability (current and
future) of multipath transport. Apple is using it now in production, and Linux
already has it in their implementation. I think this is actually a reasonable
possible solution in the future, and I would be a little more optimistic than
the WG in this section.

Nits/editorial comments:

Two editorial bits in section 1:

   This document defines routing requirements for enterprise multihoming
   using provider-assigned IPv6 addresses.  We have made no attempt to
   write these requirements in a manner that is agnostic to potential
   solutions.  Instead, this document focuses on the following general
   class of solutions.

Is that second sentence right? If you are giving a general class of solutions,
that seems agnostic to the particular solution. Just a bit confusing.

   A host SHOULD be able respond dynamically...

Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems overdone.

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

[Gen-art] Genart last call review of draft-ietf-sidrops-https-tal-07

[Pete Resnick via Datatracker]

Reviewer: Pete Resnick
Review result: Ready with Issues

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

For more information, please see the FAQ at

.

Document: draft-ietf-sidrops-https-tal-07
Reviewer: Pete Resnick
Review Date: 2019-03-22
IETF LC End Date: 2019-03-18
IESG Telechat date: 2019-04-11

Summary:

I MUST say that this document is quite MUSTy. I only noted those that caused me
confusion or seemed useless. All of these are either minor issues or nits.
Either way, the document is generally ready.

Major issues:

None.

Minor issues (or might be nits):

In 2.3:

   The validity interval of this trust anchor SHOULD reflect the
   anticipated period of stability...

Are there cases where it wouldn't reflect the period of stability? If so, it
would be good to give an example. If not, then s/SHOULD reflect/reflects.

Similarly for:

   Thus, the entity that issues the trust anchor SHOULD issue a
   subordinate CA certificate that contains...

In this case, that SHOULD might even be a MUST.

In section 4, in the last full paragraph and the bullets, I'm not at all clear
why these are RECOMMENDEDs and SHOULD [NOT]s. If they're not MUSTs, it seems
like you should explain circumstances (at least in general terms) where an
implementation would choose to do deviate from these.

Nits/editorial comments:

In the introduction, the "SHOULD" seems superfluous; it doesn't indicate some
important implementation advice that someone wouldn't otherwise notice in the
protocol. But it's a nit if ever there was one.


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