[Gen-art] Re: Gen-ART Last Call review of draft-ietf-mpls-msd-yang-05

[Paul Kyzivat]

Yingzhen

On 5/28/24 7:05 PM, Yingzhen Qu wrote:

Hi Paul,

Thanks for the review and comments. Version -07 has been uploaded to 
address your comments. Detailed answers below.


Version -07 has resolved my concerns.

Thanks,
Paul


Thanks,
Yingzhen

On Mon, May 27, 2024 at 10:51 AM Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote:


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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.

Document: draft-ietf-mpls-msd-yang-05
Reviewer: Paul Kyzivat
Review Date: 2024-05-27
IETF LC End Date: 2024-06-04
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the
review.

Disclaimer:

This reviewer is "YANG challenged". Hence I have not verified the
syntax
or semantics of the YANG content. I trust there has been or will be a
separate review by a YANG expert.

ISSUES: 3
NITS: 1

1) ISSUE - General

I find the language in this document to be extremely difficult to
follow. (For instance, see the confusing language cited in the next
issue.) The main problem is that it is formally referencing and
defining
terms/entities named using sequences of words and acronyms including
spaces. (This includes YANG entities, IANA registry table names, and
the
names of entries in IANA registries.)

These terms are used in descriptions with nothing to distinguish them
from the surrounding text. Hence it becomes a struggle to parse the
text. I strongly recommend revising the document to syntactically set
off the formal names of the entities being defined and referenced from
the surrounding text. For instance: 'IGP MSD-Types'

[Yingzhen]: Please see the answer to issue #2.

2) ISSUE - Confusing language in Section 1

I can't parse: "... defines the identities for Maximum SID Depth (MSD)
Types as the IANA the IGP MSD-Types registry."

I still can't follow it even if I make the change I requested above:

"... defines the identities for Maximum SID Depth (MSD) Types as the
IANA the 'IGP MSD-Types' registry."

. I *think* you might mean:

"... defines the identities for 'Maximum SID Depth (MSD)' Types in the
IANA 'IGP MSD-Types' registry." But I am far from certain of this.

[Yingzhen]: The first paragraph of section 2.1 has been written and 
added information about the IANA registry. Hope it's clear now. If more 
clarification is needed, please kindly let us know.


3) ISSUE - Possible missing IANA action

Section 4 defines a YANG module named 'iana-msd-types'. I *think* there
is an intent to add this as a new entry in the IANA registry 'IGP
MSD-Types'. But I don't find anything that does this. (I would expect
something more in IANA Considerations.)

[Yingzhen]: No, the YANG Model types represent the existing IANA 
registry without modifying it.


4) NIT

The document heading shows "Workgroup: Internet" but shouldn't it be
the
MPLS WG?

[Yingzhen]: fixed.


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

[Gen-art] Gen-ART Last Call review of draft-ietf-mpls-msd-yang-05

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-mpls-msd-yang-05
Reviewer: Paul Kyzivat
Review Date: 2024-05-27
IETF LC End Date: 2024-06-04
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Disclaimer:

This reviewer is "YANG challenged". Hence I have not verified the syntax 
or semantics of the YANG content. I trust there has been or will be a 
separate review by a YANG expert.


ISSUES: 3
NITS: 1

1) ISSUE - General

I find the language in this document to be extremely difficult to 
follow. (For instance, see the confusing language cited in the next 
issue.) The main problem is that it is formally referencing and defining 
terms/entities named using sequences of words and acronyms including 
spaces. (This includes YANG entities, IANA registry table names, and the 
names of entries in IANA registries.)


These terms are used in descriptions with nothing to distinguish them 
from the surrounding text. Hence it becomes a struggle to parse the 
text. I strongly recommend revising the document to syntactically set 
off the formal names of the entities being defined and referenced from 
the surrounding text. For instance: 'IGP MSD-Types'


2) ISSUE - Confusing language in Section 1

I can't parse: "... defines the identities for Maximum SID Depth (MSD) 
Types as the IANA the IGP MSD-Types registry."


I still can't follow it even if I make the change I requested above:

"... defines the identities for Maximum SID Depth (MSD) Types as the 
IANA the 'IGP MSD-Types' registry."


. I *think* you might mean:

"... defines the identities for 'Maximum SID Depth (MSD)' Types in the 
IANA 'IGP MSD-Types' registry." But I am far from certain of this.


3) ISSUE - Possible missing IANA action

Section 4 defines a YANG module named 'iana-msd-types'. I *think* there 
is an intent to add this as a new entry in the IANA registry 'IGP 
MSD-Types'. But I don't find anything that does this. (I would expect 
something more in IANA Considerations.)


4) NIT

The document heading shows "Workgroup: Internet" but shouldn't it be the 
MPLS WG?


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

[Gen-art] Gen-ART Early review of draft-ietf-6lo-path-aware-semantic-addressing-05

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft.
For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-6lo-path-aware-semantic-addressing-05
Reviewer: Paul Kyzivat
Review Date: 2024-04-29
IETF LC End Date: TBD
IESG Telechat date: TBD

Summary:

This draft is on the right track but has open issues, described in the 
review.


This review was challenging for me because I know nothing of the subject 
area or any of the important references. I apologize for any stupid 
comments based on my lack of context.


Below I have not attempted to classify the severity of issues other than 
Nits vs. Issues.


ISSUES:

1) ISSUE: Router parents

In section 3 (Definition of Terms), in PASA Router:

Doesn't the router, like the host, request an address from its parent? 
If so then it should be stated.


In PASA Host:

s/to its selected parent/from its selected parent/ ???

2) ISSUE: Working of OT network domains

In section 4.4 Industrial Operational Technology Networks, regarding 
"The OT network is represented as PASA domain", I think you mean "The OT 
network is represented as *a* PASA domain".


In this domain do each of the sensors/actuators have an assigned PASA 
address so that the IPv6 nodes can address them directly?


IOW, does the PLC act as a PASA Router by assigning PASA addresses for 
each of the sensors/actuators? (Even though they don't carry out the 
steps for PASA Hosts.) It would be helpful for the document to be 
clearer about this.


3) ISSUE: Multiple Root Nodes

In section 5 (Architectural Overview) the description of PASA Root says 
"There is typically one root node in the PASA network". Using 
"typically" implies there may be exceptions where there are multiple 
root nodes. But I have the impression that this spec won't work right if 
there is more than one. Do you really want to define that?


4) ISSUE: Address Assignment

I have concerns about address assignment as described in section 5 
(Architectural Overview):


  ...  Each node acquiring a PASA address firstly needs to
   select a parent node by choosing among the nodes that replied with a
   Router Advertisement (RA) after an initial Router Solicitation (RS).
   A "first come first served" selection policy is sufficient.  Then it
   asks for a PASA address.  In its reply the parent will propose an
   address according to the node's role, which is indicated in the D-bit
   of the GAAO message (see Section 10).  The proposed address is
   algorithmically calculated using the PASA Address Assignment Function
   (AAF).

Is this algorithm stable if there are multiple replies to the RS 
message? IOW, will the same address be assigned regardless of the router 
chosen. This goes back to my question if you want to allow redundant 
routers.


5) ISSUE: Root Node Address

Figure 6 starts out with:
root   +--+
 1 | append more bits to form |
 O +   | brother's address|

Subsequent discussion says the root address is "1". So why is the "0" 
present?


However the AAF algorithm always assigns addresses ending in "0" to 
routers. Wouldn't it be more consistent to give the root the address 
"0"? (Or does the address packing/unpacking described in section 7 
require the root address to begin with a "1" bit?)


6) ISSUE: Tree Address Assignment Function

In section 6.1 (Tree Address Assignment Function) the function is 
defined as "AAF(role, r, h)" but all the following examples show it as 
A(...). Please be consistent.


Also I don't understand *when* the AAF function is run for a particular 
node. It is when a particular node seeks its parent and then asks for an 
address, but does it every time it restarts? That doesn't seem 
deterministic. What if nodes start or restart at indeterminant times? I 
suspect you are making some assumptions that aren't stated. Please clarify.


7) ISSUE: Packet forwarding

In section 7.1 all the steps reduce to either "send to parent" or send 
to a particular child. How? I presume this requires a MAC address, but 
there has been no mention of these. It seems to require all nodes to 
keep a MAC address of their parent and routers to keep a MAC for each 
child with an assigned PASA address. This state hasn't been discussed.


8) ISSUE: PASA address padding

In section 8.2 (PASA-6LoRH Format) you say "PASA addresses are aligned 
on the least significant bits." But your example AAF assigns variable 
length addresses that are left aligned. I think these can only be 
reconciled by requiring the root node address to begin with a "1" bit 
and then left aligning to the first "1" bit when unpadding. One way or 
another you need to have a way to determine the bit len

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-lamps-rfc5019bis-05

[Paul Kyzivat]

Looks good!

On 4/3/24 11:09 AM, Corey Bonnell wrote:

Hi Paul,
Thanks again for your careful review. -07 resolves the malformed section
reference:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-lamps-rfc5019bis-06=draft-ietf-lamps-rfc5019bis-07=--html

Thanks,
Corey

-Original Message-
From: Paul Kyzivat 
Sent: Wednesday, April 3, 2024 10:19 AM
To: Corey Bonnell ;
draft-ietf-lamps-rfc5019bis@ietf.org
Cc: General Area Review Team ; last-c...@ietf.org; LAMPS

Subject: Re: Gen-ART Last Call review of draft-ietf-lamps-rfc5019bis-05

Corey,

On 4/3/24 8:45 AM, Corey Bonnell wrote:

Hello Paul,
Thank you for your detailed review and insightful feedback. We have
just uploaded -06 to the Datatracker:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5019bis/.

We believe -06 addresses all the concerns that you raised. Please let
us know if there are still unresolved items.


Yes, you have nicely addressed all my concerns. But one error crept in:

In sec 3.2.1 there is "{#sha1-sec}". I presume this is intended to be a
reference that has been mangled.

Thanks,
Paul


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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-lamps-rfc5019bis-05

[Paul Kyzivat]

Corey,

On 4/3/24 8:45 AM, Corey Bonnell wrote:

Hello Paul,
Thank you for your detailed review and insightful feedback. We have just
uploaded -06 to the Datatracker:
https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5019bis/.

We believe -06 addresses all the concerns that you raised. Please let us know
if there are still unresolved items.


Yes, you have nicely addressed all my concerns. But one error crept in:

In sec 3.2.1 there is "{#sha1-sec}". I presume this is intended to be a 
reference that has been mangled.


Thanks,
Paul

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

[Gen-art] Gen-ART Last Call review of draft-ietf-lamps-rfc5019bis-05

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lamps-rfc5019bis-05
Reviewer: Paul Kyzivat
Review Date: 2024-03-23
IETF LC End Date: 2024-03-29
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


ISSUES:

MINOR: 4

1) MINOR: Abstract:

The abstract from RFC 5019 has not been carried over to this bis. It has 
been replaced by an explanation for why RFC 5019 is being updated.  Once 
this is published this explanation text will cease to be relevant to a 
new reader. I suggest bringing back the abstract from RFC 5019. 
(Possibly with updates.) The explanation for why the bis was made can be 
moved to an appendix.


That appendix should also include the list of substantive changes now at 
the end of section 1.


2) MINOR: Duplications from RFC 6960

Sections 3.1.1 and 3.2.1 now includes ASN.1 definitions copied from RFC 
6960. I suggest that you at least make clear that these are copies and 
are not changed from RFC 6960. Or reconsider whether including them 
substantially improves the document.


3) MINOR: Security considerations

You should consider adding security considerations discussing the 
implications of the backward compatibility with RFC 5019. (E.g., 
continuing to support SHA-1.)


4) MINOR: Examples

Is there a reason why Appendix A containing examples has been removed?

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-lamps-e2e-mail-guidance-14

[Paul Kyzivat]

Daniel,

On 2/22/24 4:28 PM, Daniel Kahn Gillmor wrote:

On Thu 2024-02-22 15:41:35 -0500, Paul Kyzivat wrote:

But I do encourage you to say *something* about web server based email
clients, since they are such a big part of the ecosystem.  (What
percentage of all emails have gmail on at least one end?) Perhaps
discuss the limitations on secure email with such clients.


I wouldn't want to delay the release of the draft on this, and i'd be
concerned about it blowing up into a large critique of the web
permissions model, which is really outside the scope of what we can
possibly review.

But i hear you that at least some reference to this as a concern might
be warranted.  I've noted this over at
https://gitlab.com/dkg/e2e-mail-guidance/-/issues/12 so there is a place
to keep track of the issue.

If you (or anyone reading this) wants to propose some short, well-scoped
text (either on this thread or in the issue), i'd be happy to review.


In the end this is your call. And I don't feel I have sufficient 
understanding of the subject to craft such text. But, if I am asked to 
do a telechat review of this document I will raise the issue so that the 
IESG think about it. Then it will be their call.


Thanks,
Paul

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-lamps-e2e-mail-guidance-14

[Paul Kyzivat]

Daniel,

Thanks for the explanation. This all sounds good to me.

But I do encourage you to say *something* about web server based email 
clients, since they are such a big part of the ecosystem.  (What 
percentage of all emails have gmail on at least one end?) Perhaps 
discuss the limitations on secure email with such clients.


Thanks,
Paul

On 2/22/24 3:00 PM, Daniel Kahn Gillmor wrote:

Hi Paul--

Thanks for this review!  I've just staged some minor cleanup edits in
git (https://gitlab.com/dkg/e2e-mail-guidance/) that should address your
concerns.  After my co-editors have had a chance to review and discuss,
we'll probably roll them up with the suggestions from other reviewers
into a new draft.

More comments interleaved below:

On Sat 2024-02-17 18:31:18 -0500, Paul Kyzivat wrote:

1) NIT: Section 9.7.2:

In the following:

"If such a proxy handles certificate discovery in inbound messages (see
Appendix A.2.1), it will also need to communicate the results of that
discovery process to its corresponding proxy for message composition
(see Section 9.7.1)."

I think there is a problem here with "... proxy ... communicate ... to
... proxy". Shouldn't it communicate to the MUA?


In the transparent proxy scenario (which this section is warning about),
the proxy doesn't/can't communicate to the MUA about cryptographic
information, because the MUA is decidedly ignorant.  So the text here is
as intended -- it's about the inbound proxy talking to the outbound
proxy.  But i agree it could be clearer, the first proxy is now "inbound
proxy" and the second proxy is now "outbound proxy".


2) NIT: Section 2.2

s/Implmenters/Implementers/


thanks, fixed.


3) NIT: Section 8.1.1

s/rFC822Name/RFC822Name/


I think this should actually be rfc822Name (this is how it appears in
e.g., RFC 8705).  I'll fix both instances of the term.


4) NIT: Section 9.5

s/(e.g. and IMAP mailbox)/(e.g. an IMAP mailbox)/


thanks, fixed.


5) NIT: IdNits:

IdNits reports many things, most of them bogus. A couple of them look to
me like they deserve consideration:

-- Obsolete informational reference (is this intentional?): RFC 3501
   (Obsoleted by RFC 9051)


good catch, updated.


-- Duplicate reference: draft-ietf-openpgp-crypto-refresh,
   mentioned in 'I-D.ietf-openpgp-crypto-refresh', was also
   mentioned in 'I-D.ietf-openpgp-crypto-refresh-13'.


Thanks, fixed by pointing to draft -13 uniformly.



Other Comments/Questions:

I found this document very informative. I wasn't aware how many issues
there are with this feature. The work required to make an MUA comply
with this document seems daunting. Is it expected that this will happen
for popular MUAs?


I agree that it is daunting.  My takeaway from working as an editor on
this document is that no one has really tried to make an e-mail client
that is natively secure and easy to use from an end-to-end cryptographic
perspective before.  In fact, in some of the testing i've done, i'm
reminded of the state of web browsers in about 1998, where some folks
had done some thinking about security, but what security mechanisms
existed were pretty haphazard and definitely not robust.

We've done a lot of work on web browsers since then, including work to
explicitly document and standardize what kinds of cryptographic state
are kept, how certain (cryptographic and non-cryptographic) features
interact, and how to mitigate risks from those interactions. Sadly, no
one ever seems to have done that work for MUAs that i've been able to
find.  This document can be read either as a foundation for that kind of
work, or as a wistful epistle from a future that might have been.  I'd
prefer the former, of course, but we'll see.

I don't know of any MUA that actually implements all of these
recommendations yet, though each recommendation is drawn from actual
behaviors of clients in the wild today.

I can't speak to the intent of popular MUA developers, thouh, sadly.


Also, do you consider web server based implementations of email clients
(such as gmail) to be proxies? If so it might be good to say so
explicitly. If not, then should they be discussed separately?


Due to the operational model of the web, I think there are some pretty
fundamental challenges to a remotely-hosted webserver-based MUA that
wants to offer end-to-end cryptographic security.

In particular, if you assume that the webserver hosting the MUA itself
is part of the threat model, then there are many many additional
concerns that we did not include in this document.


When composing a reply a user may find that desired parts of a
replied-to message have not been quoted by the MUA. (Due to the rules in
5.4.) Such user is likely to curse and then simply copy/paste the
desired text. Is the MUA expected to detect this behavior and discourage it?


My experience is that most users (outside of peculiar types like IETF
participants) have no idea that there is any quoted

[Gen-art] Gen-ART Last Call review of draft-ietf-lamps-e2e-mail-guidance-14

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lamps-e2e-mail-guidance-14
Reviewer: Paul Kyzivat
Review Date: 2024-02-17
IETF LC End Date: 2024-02-19
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


NITS: 5

(I also have included some questions at the end that I don't think 
qualify as issues.)


1) NIT: Section 9.7.2:

In the following:

"If such a proxy handles certificate discovery in inbound messages (see 
Appendix A.2.1), it will also need to communicate the results of that 
discovery process to its corresponding proxy for message composition 
(see Section 9.7.1)."


I think there is a problem here with "... proxy ... communicate ... to 
... proxy". Shouldn't it communicate to the MUA?


2) NIT: Section 2.2

s/Implmenters/Implementers/

3) NIT: Section 8.1.1

s/rFC822Name/RFC822Name/

4) NIT: Section 9.5

s/(e.g. and IMAP mailbox)/(e.g. an IMAP mailbox)/

5) NIT: IdNits:

IdNits reports many things, most of them bogus. A couple of them look to 
me like they deserve consideration:


  -- Obsolete informational reference (is this intentional?): RFC 3501
 (Obsoleted by RFC 9051)

  -- Duplicate reference: draft-ietf-openpgp-crypto-refresh,
 mentioned in 'I-D.ietf-openpgp-crypto-refresh', was also
 mentioned in 'I-D.ietf-openpgp-crypto-refresh-13'.


Other Comments/Questions:

I found this document very informative. I wasn't aware how many issues 
there are with this feature. The work required to make an MUA comply 
with this document seems daunting. Is it expected that this will happen 
for popular MUAs?


Also, do you consider web server based implementations of email clients 
(such as gmail) to be proxies? If so it might be good to say so 
explicitly. If not, then should they be discussed separately?


When composing a reply a user may find that desired parts of a 
replied-to message have not been quoted by the MUA. (Due to the rules in 
5.4.) Such user is likely to curse and then simply copy/paste the 
desired text. Is the MUA expected to detect this behavior and discourage it?


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

[Gen-art] Gen-ART Last Call review of draft-ietf-netconf-trust-anchors-22

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-netconf-trust-anchors-22
Reviewer: Paul Kyzivat
Review Date: 2024-01-24
IETF LC End Date: 2024-01-24
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Note: This review was cursory because this reviewer is ignorant of Yang, 
and so cannot say anything meaningful about the substance of the document.


NITS: 2

1) NIT: section 1:

s/references truststore instances./references to truststore instances./

2) NIT: section 2.1.3.5

s/containing in inner list/containing an inner list/

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

[Gen-art] Gen-ART Last Call review of draft-ietf-detnet-pof-06

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-detnet-pof-06
Reviewer: Paul Kyzivat
Review Date: 2023-11-16
IETF LC End Date: 2023-11-22
IESG Telechat date: ?

Summary:

This draft is ready for publication as an Informational RFC.

Issues: None

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

[Gen-art] Gen-ART Early review of draft-ietf-bess-evpn-mh-pa-09

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at <https://wiki.ietf.org/group/gen/GenArtFAQ>.


Please resolve these comments along with any other comments you may receive.

Document: draft-ietf-bess-evpn-mh-pa-09
Reviewer: Paul Kyzivat
Review Date: 2023-11-10
IETF LC End Date: ?
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issues: 2
Nits: 0

Note: This reviewer is not burdened with any knowledge of the subject 
matter. It is possible that the points I raise below may be entirely 
clear to a subject matter expert. Just take this as input from a fresh 
and unbiased set of eyes.


Otherwise the draft seems in good shape.

1) ISSUE: Ambiguity, Section 3.2(c):

I find the normative statement here to be ambiguous:

"PEs in the redundancy group MAY exchange only the Ethernet-Segment (ES) 
route (Route Type‑4) when ESI is configured on a Layer‑3 interface."


To what does "MAY" apply? What is the alternative? Does this mean that 
exchanging the ES route is optional? Or is this excluding exchanging 
other forms of route? Or something else?


2) ISSUE: Confusing algorithm in 4.3(2):

I find the expression:

"2. BDF(Es) = Sk| Weight(Es, Si) >= Weight(Es, Sk), and Weight(Es, Sk) 
>= Weight(Es, Sj)."


confusing, even with the subsequent qualifier:

"BDF(Es) is defined as that PE with address Sk for which the computed 
Weight is the next highest after the Weight of the DF. j is the running 
index from 0 to N-1; i and k are selected values."


Can you find a clearer way to state this?




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

Re: [Gen-art] Genart Last Call review of draft-freed-smtp-limits-06

[Paul Kyzivat]

John,

I appreciate your points. I understand that there are tradeoffs. Perhaps 
we do need community input on this.


Normally I copy the wg on genart reviews. Since there was no wg here I 
didn't do that, and forget to copy the Last Call list. How do I fix that 
and include your reply? Should further community discussion occur on the 
last call list, or is something more bounded better?


More inline below.

On 9/17/23 2:34 PM, John C Klensin wrote:

[snip]


The EMAILCORE WG got hit by that problem while working on
draft-ietf-emailcore-rfc5321bis which, among other things,
specifies most of what appears in that Mail Parameters registry.
It is particularly important for email because there has been a
history of implementations and providers making up their own
stuff and not bothering to register.  Most of the relevant
registries have traditionally specified standards track or
IESG-approved Experimental, which is clearly too high a barrier
to entry for anyone who does not want to take the time or who
just does not want to mess with, or recognize the authority of,
the IETF or IANA.  It isn't clear that Specification Required is
a much lower barrier, especially for that second group or if the
Designated Expert initiates a community review.  If one wants
no, or absolutely minimal, barriers, then only FCFS will do.  On
the other hand, there are implementers and designers who still
think that the IETF is useful and that a serious community
review could improve the details of what they want to do.  So
the plan, and the one preferred for name-value pairs for SMTP
LIMITS, if that the registrant picks between FCFS (with minimal
requirements for documentation or anything else) and full
standards track review, including the documentation requirements
for the latter. The registry would then indicate which one was
chosen and potentially contain different information for the two.

See Section 8 of draft-ietf-emailcore-rfc5321bis-19 or
draft-klensin-iana-consid-hybrid for different takes about how
the above might be specified, but with the understanding that
the right way to approach this would be in a revision to RFC
8126/ BCP 26.


My philosophy on registries is that

1) Documents referencing a registry need to be absolutely clear where 
the registry can be found. (I want to be able to use what is in the 
document to search and find the right registry the first time!)


And the registries themselves need to:

2) Provide sufficient info so a developer implementing a spec can 
discover all specs relevant to him by following references, including 
references to registries. (So we don't require the developer to be psychic.)


3) Give enough information to screen out most entries that aren't 
relevant to a developer's task without reading the associated document. 
(This is most important when there are many entries in the registry.)


I'm troubled by FCFS registries that don't provide enough information to 
be understood by an arbitrary developer without prior knowledge. This 
makes the item proprietary. I guess I'm ok with it if the intent is to 
support proprietary features.



   john

p.s. did you intend to copy the Last Call list?


Yes :-(

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

[Gen-art] Genart Last Call review of draft-freed-smtp-limits-06

[Paul Kyzivat]

Document: draft-freed-smtp-limits-06
Reviewer: Paul Kyzivat
Review Date: 2023-09-15
IETF LC End Date: 2023-10-04
IESG Telechat date: ?

Summary: This draft is on the right track but has open issues, described 
in the review.


Minor Issue: How the new IANA registry is specified

Section 7.2 seems to conflate two things:

- the information that must be provided in a specification
  document that registers new limits

- the information that is to included in the registry itself

ISTM that the registry itself should contain the limit name and a 
reference to the specification document. It might also contain the value 
syntax, or at least an indication if a value is allowed.


The descriptions of semantics, restrictions, and security considerations 
don't lend themselves to inclusion in the registry, but should be 
clearly spelled out in the specification.


Also, the request for the new registry should probably include its exact 
name ("SMTP Server Limits"?), and that it should be included within the 
"MAIL Parameters" protocol registry.


Otherwise IMO this document is in fine shape to move forward.

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

[Gen-art] Gen-ART Last Call review of draft-ietf-nvo3-bfd-geneve-11

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-nvo3-bfd-geneve-11
Reviewer: Paul Kyzivat
Review Date: 2023-07-11
IETF LC End Date: 2023-07-08
IESG Telechat date: ?

Summary:

This draft is ready for publication as a Standards Track RFC.

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

[Gen-art] Gen-ART Last Call review of draft-ietf-lsr-ip-flexalgo-11 [REVISED]

[Paul Kyzivat]

[Resending with the the wg email address corrected]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lsr-ip-flexalgo-11
Reviewer: Paul Kyzivat
Review Date: 2023-05-12
IETF LC End Date: 2023-05-16
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


NITS: 2

1) NIT: typo

In section 5: s/datapalne/data-plane/

2) NIT: reported by IDNits

In section 6.1:

 == Missing Reference: 'RFC5120' is mentioned on line 301, but not defined

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

[Gen-art] Gen-ART Last Call review of draft-ietf-lsr-ip-flexalgo-11

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lsr-ip-flexalgo-11
Reviewer: Paul Kyzivat
Review Date: 2023-05-16
IETF LC End Date: 2023-05-16
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


NITS: 2

1) NIT: typo

In section 5: s/datapalne/data-plane/

2) NIT: reported by IDNits

In section 6.1:

 == Missing Reference: 'RFC5120' is mentioned on line 301, but not defined

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

Re: [Gen-art] Gen-ART Early review of draft-ietf-rtgwg-net2cloud-problem-statement-21

[Paul Kyzivat]

Linda,

On 3/27/23 3:34 AM, Linda Dunbar wrote:

Paul,

Revision based on your comments and suggestions has been uploaded: 
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/


I rechecked, and you got almost all of my nits. There is still a 
formatting error in bullet (a) of section 3.5. And several things 
reported by IdNits remain. (The formatting error is also detected by 
IdNits as a long line.)


This will give you the IdNits report:
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-rtgwg-net2cloud-problem-statement-22.txt=True

If you fix those I will be able to resolve all my concerns.

You should always run IdNits on a draft before submitting it. While it 
doesn't catch everything and it can be over-zealous its report is very 
helpful.


Thanks,
Paul


Hope you can change your review status with this new revision.

Thank you,
Linda

-Original Message-
From: Paul Kyzivat 
Sent: Thursday, March 23, 2023 10:20 PM
To: Linda Dunbar ; 
draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org
Cc: General Area Review Team ; rt...@ietf.org
Subject: Re: [Gen-art] Gen-ART Early review of 
draft-ietf-rtgwg-net2cloud-problem-statement-21

Linda,

I finally convinced the review tracking system to recognize my revision to the 
review.

Sorry for the trouble,
Paul

On 3/22/23 5:07 PM, Paul Kyzivat wrote:

Linda,

On 3/22/23 4:48 PM, Linda Dunbar wrote:

Paul,
Thank you very much. Can you please change the review status for the
draft?


I haven't seen a revised version yet. But I withdrew my only issue I
just sent a revised review that removes it and leaves only the nits.

I'm currently struggling with the review tracking system to get the
status change recorded there, but will do so.

  Thanks,
  Paul


Thank you very much,
Linda


-Original Message-
From: Paul Kyzivat 
Sent: Wednesday, March 22, 2023 9:25 AM
To: Linda Dunbar ;
draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org
Cc: General Area Review Team ; rt...@ietf.org
Subject: Re: Gen-ART Early review of
draft-ietf-rtgwg-net2cloud-problem-statement-21

Hi Linda,

On 3/21/23 8:10 PM, Linda Dunbar wrote:

Paul,
Thank you very much for the review.
Please see below for the resolution to your comments.
The revision will be uploaded next Monday when the IETF submission
opens.
Linda


I've included some followup comments inline below.

[snip]


ISSUE (MINOR)
The intended purpose of and audience for this document isn't clear.
I infer this is primarily intended to kick off and guide further
normative standards work, and hence the audience is other IETF
participants. It would be helpful to spell this out. The abstract
notes things that are out of scope. Clarifying the audience and
purpose would also help in determining scope.
[Linda] How about adding the following statement?
/The intent is primarily for guiding further standards work in the
Routing Area./


After rereading the relevant sections I think I was wrong to raise an
issue - you seem to have sufficiently explained the intent without
making any changes.

[snip]


* Section 3.2
Something is wrong with the grammar in:
"When those failure events happen, the Cloud DC GW which is visible
to clients are running fine."
It can be fixed by s/clients are/clients is/, if that is what you mean.
[Linda] Is the following statement more clear?
/When a site failure happens, the Cloud DC GW visible to clients is
running fine; therefore, the site failure is not detectable by the
Clients using BFD. /


Yes, that reads well.

[snip]


[Linda] Changed the statement to the following:
/Many applications have multiple instances instantiated in different
Cloud DCs. A commonly deployed solution has DNS server(s) responding
to an FQDN (Fully Qualified Domain Name) inquiry with an IP address
of the closest or lowest cost DC that can reach the instance. /


Sounds good.

[snip]

 Thanks,
 Paul


___
Gen-art mailing list
Gen-art@ietf.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2Fgen-art=05%7C01%7Clinda.dunbar%40
futurewei.com%7C3b105aaa8ecf434bc21008db2ba156c3%7C0fee8ff2a3b240189c7
53a1d5591fedc%7C1%7C0%7C638151744175053665%7CUnknown%7CTWFpbGZsb3d8eyJ
WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
%7C%7C%7C=%2Fl0I%2Bq4iwu2rRuwUtMcZbg3SRkwSuzrPM3IjkBiA3wk%3D
erved=0




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

Re: [Gen-art] Gen-ART Early review of draft-ietf-rtgwg-net2cloud-problem-statement-21

[Paul Kyzivat]

Linda,

I finally convinced the review tracking system to recognize my revision 
to the review.


Sorry for the trouble,
Paul

On 3/22/23 5:07 PM, Paul Kyzivat wrote:

Linda,

On 3/22/23 4:48 PM, Linda Dunbar wrote:

Paul,
Thank you very much. Can you please change the review status for the 
draft?


I haven't seen a revised version yet. But I withdrew my only issue I 
just sent a revised review that removes it and leaves only the nits.


I'm currently struggling with the review tracking system to get the 
status change recorded there, but will do so.


 Thanks,
 Paul


Thank you very much,
Linda


-Original Message-
From: Paul Kyzivat 
Sent: Wednesday, March 22, 2023 9:25 AM
To: Linda Dunbar ; 
draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org

Cc: General Area Review Team ; rt...@ietf.org
Subject: Re: Gen-ART Early review of 
draft-ietf-rtgwg-net2cloud-problem-statement-21


Hi Linda,

On 3/21/23 8:10 PM, Linda Dunbar wrote:

Paul,
Thank you very much for the review.
Please see below for the resolution to your comments.
The revision will be uploaded next Monday when the IETF submission 
opens.

Linda


I've included some followup comments inline below.

[snip]


ISSUE (MINOR)
The intended purpose of and audience for this document isn't clear. I
infer this is primarily intended to kick off and guide further
normative standards work, and hence the audience is other IETF
participants. It would be helpful to spell this out. The abstract
notes things that are out of scope. Clarifying the audience and
purpose would also help in determining scope.
[Linda] How about adding the following statement?
/The intent is primarily for guiding further standards work in the
Routing Area./


After rereading the relevant sections I think I was wrong to raise an 
issue - you seem to have sufficiently explained the intent without 
making any changes.


[snip]


* Section 3.2
Something is wrong with the grammar in:
"When those failure events happen, the Cloud DC GW which is visible to
clients are running fine."
It can be fixed by s/clients are/clients is/, if that is what you mean.
[Linda] Is the following statement more clear?
/When a site failure happens, the Cloud DC GW visible to clients is
running fine; therefore, the site failure is not detectable by the
Clients using BFD. /


Yes, that reads well.

[snip]


[Linda] Changed the statement to the following:
/Many applications have multiple instances instantiated in different
Cloud DCs. A commonly deployed solution has DNS server(s) responding
to an FQDN (Fully Qualified Domain Name) inquiry with an IP address of
the closest or lowest cost DC that can reach the instance. /


Sounds good.

[snip]

Thanks,
Paul


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


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

Re: [Gen-art] Gen-ART Early review of draft-ietf-rtgwg-net2cloud-problem-statement-21

[Paul Kyzivat]

Linda,

On 3/22/23 4:48 PM, Linda Dunbar wrote:

Paul,
Thank you very much. Can you please change the review status for the draft?


I haven't seen a revised version yet. But I withdrew my only issue I 
just sent a revised review that removes it and leaves only the nits.


I'm currently struggling with the review tracking system to get the 
status change recorded there, but will do so.


Thanks,
Paul


Thank you very much,
Linda


-Original Message-
From: Paul Kyzivat 
Sent: Wednesday, March 22, 2023 9:25 AM
To: Linda Dunbar ; 
draft-ietf-rtgwg-net2cloud-problem-statement@ietf.org
Cc: General Area Review Team ; rt...@ietf.org
Subject: Re: Gen-ART Early review of 
draft-ietf-rtgwg-net2cloud-problem-statement-21

Hi Linda,

On 3/21/23 8:10 PM, Linda Dunbar wrote:

Paul,
Thank you very much for the review.
Please see below for the resolution to your comments.
The revision will be uploaded next Monday when the IETF submission opens.
Linda


I've included some followup comments inline below.

[snip]


ISSUE (MINOR)
The intended purpose of and audience for this document isn't clear. I
infer this is primarily intended to kick off and guide further
normative standards work, and hence the audience is other IETF
participants. It would be helpful to spell this out. The abstract
notes things that are out of scope. Clarifying the audience and
purpose would also help in determining scope.
[Linda] How about adding the following statement?
/The intent is primarily for guiding further standards work in the
Routing Area./


After rereading the relevant sections I think I was wrong to raise an issue - 
you seem to have sufficiently explained the intent without making any changes.

[snip]


* Section 3.2
Something is wrong with the grammar in:
"When those failure events happen, the Cloud DC GW which is visible to
clients are running fine."
It can be fixed by s/clients are/clients is/, if that is what you mean.
[Linda] Is the following statement more clear?
/When a site failure happens, the Cloud DC GW visible to clients is
running fine; therefore, the site failure is not detectable by the
Clients using BFD. /


Yes, that reads well.

[snip]


[Linda] Changed the statement to the following:
/Many applications have multiple instances instantiated in different
Cloud DCs. A commonly deployed solution has DNS server(s) responding
to an FQDN (Fully Qualified Domain Name) inquiry with an IP address of
the closest or lowest cost DC that can reach the instance. /


Sounds good.

[snip]

Thanks,
Paul


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

[Gen-art] Gen-ART Early review of draft-ietf-rtgwg-net2cloud-problem-statement-21 REVISED

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Please resolve these comments along with any other comments you may receive.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-rtgwg-net2cloud-problem-statement-21
Reviewer: Paul Kyzivat
Review Date: 2023-03-22
IETF LC End Date: ?
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Note: This review is limited by this reviewer's unfamiliarity with MPLS 
or BGP. I strongly suggest you get a review by someone who can address 
those topics.


Issues: 0
Nits: several

NITS:

The following is a bunch of editorial nits for you to consider:

* Section 2: s/Salesforces/Salesforce/

* Section 3.2

Something is wrong with the grammar in:

"When those failure events happen, the Cloud DC GW which is visible to 
clients are running fine."


It can be fixed by s/clients are/clients is/, if that is what you mean.

* Section 3.3:

s/state of the art solutions is/state of the art solutions are/

s/load balancer by responding a FQDN/a load balancer by responding with 
a FQDN/


s/Local DNS resolver become/The Local DNS resolver becomes/

* Section 3.4

The expanded definition of UPF appears with the 2nd usage. It would be 
easier on the reader to move it to the first use.


* Section 3.5

The phrase "There are many aspects of security issues" is awkward. 
Perhaps one of the following would be better:


- There are many aspects of security
- There are many security issues

Also a formatting issue in item (a).

* Section 3.8

The wording of the following is awkward:

"One of the concerns of using Cloud services is not aware of where the 
resource is located, especially Cloud operators can move application 
instances from one place to another."


I suggest:

- s/is not aware/is not being aware/
- s/especially/especially that/

* Section 4.1

s/Figure below/Figure 1 below/

In the same paragraph:

- s/workloads are accessible/workloads that are accessible/

* Section 4.3

s/used to dynamically connecting MPLS/used to dynamically connect MPLS/
s/As MPLS VPN provide/As MPLS VPNs provide/

* IdNits reports a number of other issues. I won't repeat them here.
You can run it to see them.






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

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

Re: [Gen-art] Gen-ART Early review of draft-ietf-rtgwg-net2cloud-problem-statement-21

[Paul Kyzivat]

Hi Linda,

On 3/21/23 8:10 PM, Linda Dunbar wrote:

Paul,
Thank you very much for the review.
Please see below for the resolution to your comments.
The revision will be uploaded next Monday when the IETF submission opens.
Linda


I've included some followup comments inline below.

[snip]


ISSUE (MINOR)
The intended purpose of and audience for this document isn't clear. I 
infer this is primarily intended to kick off and guide further normative 
standards work, and hence the audience is other IETF participants. It 
would be helpful to spell this out. The abstract notes things that are 
out of scope. Clarifying the audience and purpose would also help in 
determining scope.

[Linda] How about adding the following statement?
/The intent is primarily for guiding further standards work in the 
Routing Area./


After rereading the relevant sections I think I was wrong to raise an 
issue - you seem to have sufficiently explained the intent without 
making any changes.


[snip]


* Section 3.2
Something is wrong with the grammar in:
"When those failure events happen, the Cloud DC GW which is visible to 
clients are running fine."

It can be fixed by s/clients are/clients is/, if that is what you mean.
[Linda] Is the following statement more clear?
/When a site failure happens, the Cloud DC GW visible to clients is 
running fine; therefore, the site failure is not detectable by the 
Clients using BFD. /


Yes, that reads well.

[snip]


[Linda] Changed the statement to the following:
/Many applications have multiple instances instantiated in different 
Cloud DCs. A commonly deployed solution has DNS server(s) responding to 
an FQDN (Fully Qualified Domain Name) inquiry with an IP address of the 
closest or lowest cost DC that can reach the instance. /


Sounds good.

[snip]

Thanks,
Paul

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

[Gen-art] Gen-ART Early review of draft-ietf-rtgwg-net2cloud-problem-statement-21

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Please resolve these comments along with any other comments you may receive.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-rtgwg-net2cloud-problem-statement-21
Reviewer: Paul Kyzivat
Review Date: 2023-03-19
IETF LC End Date: ?
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Note: This review is limited by this reviewer's unfamiliarity with MPLS 
or BGP. I strongly suggest you get a review by someone who can address 
those topics.


Issues: 1
Nits: several

ISSUE (MINOR)

The intended purpose of and audience for this document isn't clear. I 
infer this is primarily intended to kick off and guide further normative 
standards work, and hence the audience is other IETF participants. It 
would be helpful to spell this out. The abstract notes things that are 
out of scope. Clarifying the audience and purpose would also help in 
determining scope.


NITS:

The following is a bunch of editorial nits for you to consider:

* Section 2: s/Salesforces/Salesforce/

* Section 3.2

Something is wrong with the grammar in:

"When those failure events happen, the Cloud DC GW which is visible to 
clients are running fine."


It can be fixed by s/clients are/clients is/, if that is what you mean.

* Section 3.3:

s/state of the art solutions is/state of the art solutions are/

s/load balancer by responding a FQDN/a load balancer by responding with 
a FQDN/


s/Local DNS resolver become/The Local DNS resolver becomes/

* Section 3.4

The expanded definition of UPF appears with the 2nd usage. It would be 
easier on the reader to move it to the first use.


* Section 3.5

The phrase "There are many aspects of security issues" is awkward. 
Perhaps one of the following would be better:


- There are many aspects of security
- There are many security issues

Also a formatting issue in item (a).

* Section 3.8

The wording of the following is awkward:

"One of the concerns of using Cloud services is not aware of where the 
resource is located, especially Cloud operators can move application 
instances from one place to another."


I suggest:

- s/is not aware/is not being aware/
- s/especially/especially that/

* Section 4.1

s/Figure below/Figure 1 below/

In the same paragraph:

- s/workloads are accessible/workloads that are accessible/

* Section 4.3

s/used to dynamically connecting MPLS/used to dynamically connect MPLS/
s/As MPLS VPN provide/As MPLS VPNs provide/

* IdNits reports a number of other issues. I won't repeat them here.
You can run it to see them.






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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-extend-dtls-authorize-05

[Paul Kyzivat]

Hi John,

On 1/22/23 3:40 AM, John Mattsson wrote:

Hi Paul,

Thanks for you review.


I very much agree with you that this should have been part of the RFC 
9202. In fact, I pointed out the need for TLS compatibility very early 
in the standardization process. The situation right now is that this was 
unfortunately not done, and that TLS/TCP is very much needed for the 
3GPP use of RFC 9202. This should have been standardized yesterday, so 
any increased delay would not be good. 3GPP is waiting for this draft. A 
future update to RFC 9202 might be worth doing.


It will be for the wg, ad, and iesg to decide if compromising the 
quality of the document to meet this schedule desire is an acceptable 
compromise.


But it fails to dothe work of actually making those revisions. It leaves 
that work to the reader. It is hard to believe that all readers will 
infer the identical set of changes.


I don’t see what is missing and what would be hard to infer, and I am 
not an author of RFC 9202.


There is general language that needs to be applied to many parts of 
9202. I'm sure the authors this this is clear and unambiguous, but I 
don't think so.


It would be more constructive if you could 
provide advice on how to improve draft-ietf-ace-extend-dtls-authorize.


It could emumerate every required change to 9202. Effectively a diff, 
though it needn't be formally written in the form of a diff.


But doing that is comparable in difficulty to actually creating an 
rfc9202bis.


If this isn't done, and the current doc becomes a standards track rfc, 
then every implementer will need to do the same work.



I suggest that this document's status be changed to an informational
I think it would be strange if DTLS transport is standards track and TLS 
is informal. Also Informational is not compatible with the current IANA 
actions. I would suggest not doing this.


My point is to view it as requirements work for an rfc9202bis. Such a 
document, if published, would be informational. But these days it seems 
that there is a trend to leave such documents as drafts rather than 
progressing them to informational rfcs.


Thanks,
Paul


Cheers,

John

*From: *Paul Kyzivat 
*Date: *Friday, 20 January 2023 at 18:32
*To: *draft-ietf-ace-extend-dtls-authorize@ietf.org 

*Cc: *General Area Review Team , last-c...@ietf.org 
, a...@ietf.org 
*Subject: *Gen-ART Last Call review of 
draft-ietf-ace-extend-dtls-authorize-05


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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq 
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>.


Document: draft-ietf-ace-extend-dtls-authorize-05
Reviewer: Paul Kyzivat
Review Date: 2023-01-20
IETF LC End Date: 2023-01-24
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the
review.

Issues: 1

1) ISSUE: Form and completeness of the document

This document reads as a good concept document proposing how RFC 9202
could be revised to allow use of both TLS and DTLS. But it fails to do
the work of actually making those revisions. It leaves that work to the
reader. It is hard to believe that all readers will infer the identical
set of changes.

I suggest that this document's status be changed to an informational,
and then work begin on an rfc9202bis document that incorporates the
proposed changes.



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

[Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-service-assurance-architecture-11 [RESEND]

[Paul Kyzivat]

[Resending to include the wg and last-call.]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-service-assurance-architecture-11
Reviewer: Paul Kyzivat
Review Date: 2022-11-15
IETF LC End Date: 2022-11-20
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issues: 1
Nits: 8

1) ISSUE: Section 3.6: ambiguity

As best I understand the text "Under Maintenance" is being used in two 
different ways that can cause ambiguity:


- "When a service or subservice is flagged as under maintenance, it must 
report a generic "Under Maintenance" symptom, for propagation towards 
subservices that depend on this specific subservice: any other symptom 
from this service, or by one of its impacting dependencies must not be 
reported."


-  " In more complex cases, for instance with a primary and backup path 
... In such cases, the status of the service instance might include the 
"Under Maintenance" as well as other symptoms (e.g. from the backup path)"


In the latter case, if nothing is wrong with the backup path then there 
might only be the "Under Maintenance" from the primary path, and it 
would be indistinguishable from a case where there was no backup path.


IIUC it is important that these cases be distinguishable.


2) NIT: Section 3: missing word

"Based on the service configuration provided by the service 
orchestrator, the SAIN orchestrator decomposes the assurance graph. It 
then sends to the SAIN agents the assurance graph along some other 
configuration options."


s/along some other/along with some other/


3) NIT: Section 3.3.3: Improper DNS name in example

"Assume that we want to assure a kubernetes cluster https://kubernetes.io.;

Examples like this should only use DNS domains intended for examples, 
such as kubernetes.example.org.



4) NIT: Section 3.1.1: missing word

"The status of a should depend on the status of c, d, e, f, g, and h"

s/status of a should/status of a  should/


5) NIT: Section 3.6: confusing wording

"Symptoms related to the device-specific subservices, such as the 
interfaces, might be ignored as well as their state changes is probably 
the consequence of the maintenance."


Hard to parse. Does the following work?

"Symptoms related to the device-specific subservices, such as the 
interfaces, might also be ignored because their state changes are 
probably the consequence of the maintenance."



6) NIT: Section 3.6: punctuation

Odd punctuation in:

"... subservices that depend on this specific subservice: any other 
symptom ..."


I think this would be better as two sentences:

"... subservices that depend on this specific subservice. Any other 
symptom ..."



7) NIT: Section 3.7: bad syntax

Syntax problems with:

"One of them is the domain of service management on network elements, 
with also requires its own assurance."


Does the following express the intent?

"One of them is the domain of service management on network elements, 
that also require their own assurance."



8) NIT: Section 3.7: awkward language

The following language is quite awkward:

" Exactly like ...
, exactly like ...
, exactly like ...
. Exactly like ... .

I suggest breaking this out as a list.


9) NIT: Section 3.9: unusual language

The following is IMO unusual phrasing:

"The assurance graph will change along the time"

I think the following would be a better phrasing:

"The assurance graph will change over time"



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

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

[Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-service-assurance-architecture-11

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-service-assurance-architecture-11
Reviewer: Paul Kyzivat
Review Date: 2022-11-15
IETF LC End Date: 2022-11-20
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issues: 1
Nits: 8

1) ISSUE: Section 3.6: ambiguity

As best I understand the text "Under Maintenance" is being used in two 
different ways that can cause ambiguity:


- "When a service or subservice is flagged as under maintenance, it must 
report a generic "Under Maintenance" symptom, for propagation towards 
subservices that depend on this specific subservice: any other symptom 
from this service, or by one of its impacting dependencies must not be 
reported."


-  " In more complex cases, for instance with a primary and backup path 
... In such cases, the status of the service instance might include the 
"Under Maintenance" as well as other symptoms (e.g. from the backup path)"


In the latter case, if nothing is wrong with the backup path then there 
might only be the "Under Maintenance" from the primary path, and it 
would be indistinguishable from a case where there was no backup path.


IIUC it is important that these cases be distinguishable.


2) NIT: Section 3: missing word

"Based on the service configuration provided by the service 
orchestrator, the SAIN orchestrator decomposes the assurance graph. It 
then sends to the SAIN agents the assurance graph along some other 
configuration options."


s/along some other/along with some other/


3) NIT: Section 3.3.3: Improper DNS name in example

"Assume that we want to assure a kubernetes cluster https://kubernetes.io.;

Examples like this should only use DNS domains intended for examples, 
such as kubernetes.example.org.



4) NIT: Section 3.1.1: missing word

"The status of a should depend on the status of c, d, e, f, g, and h"

s/status of a should/status of a  should/


5) NIT: Section 3.6: confusing wording

"Symptoms related to the device-specific subservices, such as the 
interfaces, might be ignored as well as their state changes is probably 
the consequence of the maintenance."


Hard to parse. Does the following work?

"Symptoms related to the device-specific subservices, such as the 
interfaces, might also be ignored because their state changes are 
probably the consequence of the maintenance."



6) NIT: Section 3.6: punctuation

Odd punctuation in:

"... subservices that depend on this specific subservice: any other 
symptom ..."


I think this would be better as two sentences:

"... subservices that depend on this specific subservice. Any other 
symptom ..."



7) NIT: Section 3.7: bad syntax

Syntax problems with:

"One of them is the domain of service management on network elements, 
with also requires its own assurance."


Does the following express the intent?

"One of them is the domain of service management on network elements, 
that also require their own assurance."



8) NIT: Section 3.7: awkward language

The following language is quite awkward:

" Exactly like ...
, exactly like ...
, exactly like ...
. Exactly like ... .

I suggest breaking this out as a list.


9) NIT: Section 3.9: unusual language

The following is IMO unusual phrasing:

"The assurance graph will change along the time"

I think the following would be a better phrasing:

"The assurance graph will change over time"



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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-lamps-rfc3709bis-06

[Paul Kyzivat]

Russ,

On 10/25/22 2:20 PM, Russ Housley wrote:

Paul:


Document: draft-ietf-lamps-rfc3709bis-06
Reviewer: Paul Kyzivat
Review Date: 2022-10-25
IETF LC End Date: 2022-10-28
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the review.

Issues:

Major: 0
Minor: 1
Nits:  2

1) MINOR: In Section 4.1 (Extension Format):

The following:

"CAs SHOULD use the one-way hash function that is associated with the certificate 
signature to compute the hash value, and CAs MAY include other hash values."

introduces the possibility that a client might not support *any* of the 
provided hash algorithms. This seems bad.

RFC3709 didn't have this problem because it required that an SHA-1 hash be 
included and supported.

This can be fixed by changing "CAs SHOULD" to "CAs MUST".


We are seeing a few signature algorithms that are not following the hash-then-sign 
pattern. I'm not sure how to allow the signature on the certificate to use one of them 
(like EdDSA) when one has to know a lot about the algorithm details to determine which 
hash is used internally.  As you say, the "CAs MUST" would require the 
certificate issuer to do that research.  Do others have an opinion?


Well then, how about picking some algorithm (to replace SHA-1) that 
clients must support and that must be used in cases when cert signature 
algorithm can't be used?


Or worst case, discuss what is to be done by a client who doesn't 
support any of the offered hash algorithms.



2) NIT: From IdNits:

** Downref: Normative reference to an Informational RFC: RFC 1952

I think it would be ok to change the reference to Informative.


RFC 1952 is already in the downref registry, so it is not a concern.  I wish 
id-nits checked the registry...


Ah, OK.

Thanks,
Paul


3) NIT: Typos

In Section 3 (Logotype Data):

s/then each image objects/then each image object/

In Section 7 (Image Formats):

s/The following table lists many commons/The following table lists many common/

s/requirements these image formats/requirements for these image formats/

s/the client will receive response/the client will receive a response/

(The last one above appears twice.)

In Section 10 (Privacy Considerations):

s/cache logotype data is cached/cache logotype data/


All of these nits have been corrected in my edit buffer.  Thanks for the 
careful read.

Russ



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

[Gen-art] Gen-ART Last Call review of draft-ietf-lamps-rfc3709bis-06

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lamps-rfc3709bis-06
Reviewer: Paul Kyzivat
Review Date: 2022-10-25
IETF LC End Date: 2022-10-28
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issues:

Major: 0
Minor: 1
Nits:  2

1) MINOR: In Section 4.1 (Extension Format):

The following:

"CAs SHOULD use the one-way hash function that is associated with the 
certificate signature to compute the hash value, and CAs MAY include 
other hash values."


introduces the possibility that a client might not support *any* of the 
provided hash algorithms. This seems bad.


RFC3709 didn't have this problem because it required that an SHA-1 hash 
be included and supported.


This can be fixed by changing "CAs SHOULD" to "CAs MUST".

2) NIT: From IdNits:

** Downref: Normative reference to an Informational RFC: RFC 1952

I think it would be ok to change the reference to Informative.

3) NIT: Typos

In Section 3 (Logotype Data):

s/then each image objects/then each image object/

In Section 7 (Image Formats):

s/The following table lists many commons/The following table lists many 
common/


s/requirements these image formats/requirements for these image formats/

s/the client will receive response/the client will receive a response/

(The last one above appears twice.)

In Section 10 (Privacy Considerations):

s/cache logotype data is cached/cache logotype data/

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-lsr-ospf-l2bundles-06

[Paul Kyzivat]

Ketan,

I've trimmed the conversation down to just the relevant points.

On 9/21/22 10:07 AM, Ketan Talaulikar wrote:

KT> This ID-nits warning is perhaps simply because the normative 
reference is not from an IETF publication and so perhaps the tool is not 
able to determine if that publication is "standards" or informational. 
As far as the guidance from draft-kucherawy, I'll wait for our AD and 
IESG to share their views - we'll do as indicated by the IESG.


OK

KT> If I understand your point, and I am paraphrasing, the idea is that 
we add this document as reference on the OSPFv2/v3 code point registry 
and in this document's IANA section we add guidelines for IANA to look 
for whether the allocation request has specified the applicability to 
the L2 Bundle Member Sub-TLV. So that acts as a checkpoint before future 
allocations out of this registry. Is that correct?


Yes

So this is half-step 
between the current state of the document and the suggested new document 
that changes the registry organization.


I guess. If this hypothetical new document straightens things out 
better, then this would simply cover anything that happens until that 
new document is adopted, or in case that never happens.


Alternately, you could hold this document until that other one is ready.


One last thought: have you considered whether potential future updates
to the definitions to currently defined sub-TLVs could ever change
their
applicability? 



KT> That would be very remote/unlikely IMO.

I suspect any time a change is made to the registry that
adds/replaces a reference to a document defining a sub-TLV, the newly
referenced document will need to "indicate applicability".

KT> Sure and this should be taken care of by the IANA checks when the 
new document reference is updated in registry.


Yes.

Thanks,
Paul

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-lsr-ospf-l2bundles-06

[Paul Kyzivat]

Ketan,

On 9/20/22 10:30 AM, Ketan Talaulikar wrote:


1) NIT: 1 Introduction

IDNITS reports:

     -- Possible downref: Non-RFC (?) normative reference: ref.
     'IEEE802.1AX'

As best I can tell there is no need for this reference to be normative.
(Its only an example in the introduction.) I suggest making this a
non-normative reference.


KT> We kept it as normative since this document is all about "bundle 
members" and that refers to the 802.1AX. However, I am ok to change that 
to informative if the IESG suggests so.


I just saw a draft concerned with this issue:

  Last Call:  (Procedures for Standards
  Track Documents to Refer Normatively to Documents at a Lower Level) to
  Best Current Practice

It isn't approved yet so it isn't definitive, but its close enough that 
it might be wise to follow it.


Its easier to just avoid the issue by calling the reference 
non-normative. But its your call, together with your AD.



2) MINOR: Section 2: Normative requirements on future documents

While I don't fully understand all the document dependencies, the
following normative requirement:

     ... Specifications that introduce new sub-TLVs of the Extended Link
     TLV MUST indicate their applicability for the L2 Bundle Member
     Attributes Sub-TLV.  An implementation MUST ignore any sub-TLVs
     received that are not applicable in the context of the L2 Bundle
     Member Attribute Sub-TLV.

looks to me like it may be imposing requirements on future work that
may
not itself be aware of or normatively linked to this document. 


KT> This is correct.

The
registry in question is defined only by RFC7684. Figure 2 further
supports this point by effectively revising the format for the
registry,
adding an additional column.

KT> The intention was not to change the registry format. Please see 
further below.


I suggest it would be appropriate to formally update the registry to
reference this document to impose requirements on future registrations,
and add a column indicating applicability in the context of the L2
Bundle Member Attribute Sub-TLV.

The same logic applies to Figure 3 and the IANA OSPFv3 Extended-LSA
Sub-TLVs registry. I suggest the same sort of fix for it.

KT> Your point is valid and this has been discussed with the AD and the 
WG. Please check the following threads for those details and how we got 
to the current state of the document:


https://mailarchive.ietf.org/arch/msg/lsr/1MzfiHUq7LlY9VQFhtLR7j9eo2g/ 



https://mailarchive.ietf.org/arch/msg/lsr/UJgcBwSLcbVYPjrp0SicsDcHpj0/ 



I can't decipher the logic of the discussion. (Feels like I need more 
context than what is in the thread, but I didn't spend a lot of time 
trying.)


I acknowledge that it isn't strictly necessary to change the table 
format in the registry.


But it is essential to do *something* that forces anyone trying to add a 
new entry to either of those tables to "indicate their applicability for 
the L2 Bundle Member Attributes Sub-TLV". That needs to be a new 
requirement for adding an entry to either table.


How to achieve that? Currently someone wanting to add to those tables 
will look for the applicable rules in the Reference at the top of the 
table, to [RFC7684]. That doesn't impose your new rule. So at the least, 
you can add an additional reference to the top of each table, to your 
document.


And then, to make it clear, I recommend adding another item to your IANA 
Considerations that clearly states it applies to anyone adding or 
changing anything in these tables, and restate or clearly reference the 
requirements I highlighted to in Section 2.


While adding an applicability column isn't technically necessary, it 
would make it harder for future updates to forget this step, since they 
would be forced to figure out what to put in that column.


One last thought: have you considered whether potential future updates 
to the definitions to currently defined sub-TLVs could ever change their 
applicability? I suspect any time a change is made to the registry that 
adds/replaces a reference to a document defining a sub-TLV, the newly 
referenced document will need to "indicate applicability".


Thanks,
Paul

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

[Gen-art] Gen-ART Last Call review of draft-ietf-lsr-ospf-l2bundles-06

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lsr-ospf-l2bundles-06
Reviewer: Paul Kyzivat
Review Date: 2022-09-16
IETF LC End Date: 2022-09-29
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issues:

Major: 0
Minor: 1
Nits:  1

1) NIT: 1 Introduction

IDNITS reports:

   -- Possible downref: Non-RFC (?) normative reference: ref.
   'IEEE802.1AX'

As best I can tell there is no need for this reference to be normative. 
(Its only an example in the introduction.) I suggest making this a 
non-normative reference.


2) MINOR: Section 2: Normative requirements on future documents

While I don't fully understand all the document dependencies, the 
following normative requirement:


   ... Specifications that introduce new sub-TLVs of the Extended Link
   TLV MUST indicate their applicability for the L2 Bundle Member
   Attributes Sub-TLV.  An implementation MUST ignore any sub-TLVs
   received that are not applicable in the context of the L2 Bundle
   Member Attribute Sub-TLV.

looks to me like it may be imposing requirements on future work that may 
not itself be aware of or normatively linked to this document. The 
registry in question is defined only by RFC7684. Figure 2 further 
supports this point by effectively revising the format for the registry, 
adding an additional column.


I suggest it would be appropriate to formally update the registry to 
reference this document to impose requirements on future registrations, 
and add a column indicating applicability in the context of the L2 
Bundle Member Attribute Sub-TLV.


The same logic applies to Figure 3 and the IANA OSPFv3 Extended-LSA 
Sub-TLVs registry. I suggest the same sort of fix for it.


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

[Gen-art] Gen-ART Last Call review of draft-ietf-sidrops-rov-no-rr-03

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-sidrops-rov-no-rr
Reviewer: Paul Kyzivat
Review Date: 2022-07-23
IETF LC End Date: 2022-08-02
IESG Telechat date: ?

Summary:

This draft is ready for publication as a Standards Track RFC.

Issues:

Major: 0
Minor: 0
Nits:  0

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ippm-ioam-flags-08

[Paul Kyzivat]

Since this issue has already been considered by the wg I'm fine if you 
leave things as they are.


Thanks,
Paul

On 6/14/22 2:26 AM, Tal Mizrahi wrote:

Dear Paul,

Many thanks for the comments.

Please see my response below, marked [TM].

Cheers,
Tal.

On Sun, Jun 12, 2022 at 9:01 PM Paul Kyzivat  wrote:


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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ippm-ioam-flags-08
Reviewer: Paul Kyzivat
Review Date: 2022-06-??
IETF LC End Date: 2022-06-14
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should
be fixed before publication.

Issues:

Major: 0
Minor: 0
Nits:  2

1) NIT: Doc name inconsistent with scope

The name & title of this draft isn't very indicative of the content of
the document. This document doesn't just define the *flag* for loopback;
it also defines the entire loopback *mechanism*, which is a much bigger
deal.

It appears to me that the primary function of the document is to define
the loopback mechanism, with the definition of the flag being necessary
but secondary.

This could be fixed by simply changing the name and title of the
document. (Or at least the title since the name will disappear in the
resulting rfc.)

Or the specification of the loopback *mechanism* could be moved to a
different document and this document reduced to simply defining the flags.



[TM] There is a delicate history here. Originally, the loopback and
active functionality were part of RFC 9197 (before it was published as
an RFC). At some point the working group commented that flag
definition should be separated from the data field definition (RFC
9197). Here is the discussion about this in IETF 104, and specifically
notice the text "regarding the editorials,  the draft specify out of
scope context, shouldn’t specify protocol behavior.  Will be discussed
in side meetings ... repeated for the active flag":
https://datatracker.ietf.org/meeting/104/materials/minutes-104-ippm-00

It was then further discussed in the following side meeting, and the
decision was to have a separate draft that defines the loopback and
active flag:
https://mailarchive.ietf.org/arch/msg/ippm/XwOLqE-SLYoHL_x613BNgX2RORI/

I would suggest to stay with the current document title, since any
change can potentially restart this delicate discussion again.



2) NIT: Outdated reference

IdNits reports:
   == Outdated reference: draft-ietf-ippm-ioam-data has been published as
  RFC 9197


[TM] Agreed. Will be fixed.


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

[Gen-art] Gen-ART Last Call review of draft-ietf-ippm-ioam-flags-08

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ippm-ioam-flags-08
Reviewer: Paul Kyzivat
Review Date: 2022-06-??
IETF LC End Date: 2022-06-14
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Issues:

Major: 0
Minor: 0
Nits:  2

1) NIT: Doc name inconsistent with scope

The name & title of this draft isn't very indicative of the content of 
the document. This document doesn't just define the *flag* for loopback; 
it also defines the entire loopback *mechanism*, which is a much bigger 
deal.


It appears to me that the primary function of the document is to define 
the loopback mechanism, with the definition of the flag being necessary 
but secondary.


This could be fixed by simply changing the name and title of the 
document. (Or at least the title since the name will disappear in the 
resulting rfc.)


Or the specification of the loopback *mechanism* could be moved to a 
different document and this document reduced to simply defining the flags.


2) NIT: Outdated reference

IdNits reports:
 == Outdated reference: draft-ietf-ippm-ioam-data has been published as
RFC 9197

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

Re: [Gen-art] [art] [Last-Call] Artart last call review of draft-ietf-teep-architecture-16

[Paul Kyzivat]

I've been seeing this discussion of Russ' artart review.
But I have seen no discussion of my genart review of it. Did you perhaps 
not get it?


Thanks,
Paul

On 4/7/22 4:52 PM, Mingliang Pei wrote:

Hi Russ,

Great, thank you. Please see inline. I will update RFC with the two 
points agreed.


Best,

Ming


On Thu, Apr 7, 2022 at 12:31 PM Russ Housley > wrote:


Please see below.


On Apr 6, 2022, at 8:54 PM, Mingliang Pei
mailto:mingliang.pei=40broadcom@dmarc.ietf.org>> wrote:

Thanks Russ for your comments. Thanks Hannes for the PR. I made a
minor comment on the PR. The changes look good overall.

Please see my comments inline about "trust anchor" and "app store".

Best,

Ming

On Mon, Mar 28, 2022 at 11:06 PM Hannes Tschofenig
mailto:hannes.tschofe...@arm.com>> wrote:

Hi Russ,

Thanks for the review.

I have created a few PR based on your comments:
https://github.com/ietf-teep/architecture/pull/234


I have added a few remarks below (mainly agreeing with your
observations).

Ciao
Hannes


-Original Message-
From: Russ Housley via Datatracker mailto:nore...@ietf.org>>
Sent: Tuesday, March 29, 2022 12:08 AM
To: a...@ietf.org 
Cc: draft-ietf-teep-architecture@ietf.org
;
last-c...@ietf.org ; t...@ietf.org

Subject: Artart last call review of
draft-ietf-teep-architecture-16

Reviewer: Russ Housley
Review result: Almost Ready

I am the assigned ARTART reviewer for this Internet-Draft.

Document: draft-ietf-teep-architecture-16
Reviewer: Russ Housley
Review Date: 2022-03-28
IETF LC End Date: 2022-04-07
IESG Telechat date: unknown

Summary: Almost Ready

Major Concerns: None.


Minor Concerns:

Section 3.3 says:

   Weak security in Internet of Things (IoT) devices has been
posing
   threats to critical infrastructure that relies upon such
devices.

I'm a bit confused by this opening sentence.  IoT devices
usually depend upon an infrastructure.  This seems to be
talking about an infrastructure that depends upon a collection
of IoT devices.  I suggest a minor edits to help the reader
understand that this sentence is not talking about network
infrastructure.

[Hannes] I have changed the sentence to improve the wording.

Section 9.3 says that a compromised REE "might drop or delay
messages".
This discussion should be expanded to include the replay of
messages.

[Hannes] Agree.

Section 9.4 says:

   A root CA for TAM certificates might get compromised or its
   certificate might expire, or a Trust Anchor other than a
root CA
   certificate may also expire or be compromised.

I do not understand the difference between a Root CA and a
Trust Anchor.
These are usually used a synonyms.  Please explain the
difference that in intended here.

[Hannes] Good point. I removed part of the sentence.


[Ming] Trust Anchor definition says "The Trust Anchor may be a
certificate or it may be a raw public key.".When it is a
certificate, it doesn't have to be the root certificate. It could
be an issuing CA while it isn't a common practice. Do we limit it
to a self-signed root CA? I am fine with this, and update accordingly.


I think the point about not a "Root Certificate" in all situations
is very helpful.  Please add that to the document.


Ming: will add a clarification line in the definition of "Trust Anchor" 
that a "A Trust Anchor can be a non-root certificate when it is a 
certificate.", and keep the original statement above.



Nits:

Section 1 says:

   ... The problems in the bullets above, on the
   other hand, require a new protocol, i.e., the TEEP
protocol, for TEEs
   that can install and enumerate TAs in a TEE-secured
location and
   where another domain-specific protocol standard (e.g., [GSMA],
   [OTRP]) that meets the needs is not already in use.

Recommend breaking this long sentence up into at least two
sentences.
There are two points.  First, the need for a protocol to
address the items listed earlier.  Second, where an existing
domain-specific protocol does not already exist, a new more
general protocol is needed.

[Hannes] Splitting the sentence improves readability.

Section 4.4 says:

   ... Implementations must 

[Gen-art] Gen-ART Last Call review of draft-ietf-teep-architecture-16

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-teep-architecture-16
Reviewer: Paul Kyzivat
Review Date: 2022-04-??
IETF LC End Date: 2022-04-07
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issues:

Major: 0
Minor: 2
Nits:  3

1) MINOR: Section 4.5, Fig 3

I find this figure confusing. It starts out looking like a sequence 
diagram, where time flows from top to bottom. But then overlayed on it 
is a nested text outline that seems to interact with the sequence 
diagram. Based on the outline numbering I expect the time sequence to be 
2a,2b,3,4. but based on positioning within the sequence diagram it seems 
that the order should be 2a,3,2b,4. I don't understand how this is 
intended to be read.


2) MINOR: Section 6.2.1:

Is any persistent state assumed in this API or is it stateless? If state 
is assumed, I would like to see the state model described.


3) NIT: Section 1: NIT

   TEEs use hardware enforcement combined with software protection to
   secure TAs and its data.

s/its/their/

4) NIT: Section 2: Device User:...

The last sentence is a fragment. Needs to be reworded.

5) NIT: IdNits

IdNits reports a couple of outdated references that need updating.




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

[Gen-art] Gen-ART Last Call review of draft-ietf-6man-mtu-option-12

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-6man-mtu-option-12
Reviewer: Paul Kyzivat
Review Date: 2022-02-04
IETF LC End Date: 2022-02-10
IESG Telechat date: ??

Summary:

This draft is ready for publication as an Experimental RFC.

Comments and Questions:

I didn't attempt to evaluate the security considerations as it is 
totally outside my scope. I trust this will be dealt with by a security 
review.


I have the following questions about the draft. (I don't think they even 
rise to the level of nits.)


1) Regarding PMTU range in section 5:

Was any consideration given to supporting PMTUs greater than 2^16?

2) Regarding multiplexing of Rtn-PMTU and R-Flag in section 5:

Min-PMTU is permitted to be odd, but Rtn-PMTU is forced to be even to 
allow room for the R-Flag. Hence, if the Min-PMTU ends up odd, then it 
will be rounded down in Rtn-PMTU.


Why not restrict Min-PMTU to be even as well? This would provide 
consistency and make clear that MTUs need to be even? This could be done 
by reducing Min-PMTU to 15 bits, adding a 1-bit reserved field, and a 
few explanatory words to the text.


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

[Gen-art] Gen-ART Early Review of draft-ietf-opsawg-mud-iot-dns-considerations-02

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at <​ 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-mud-iot-dns-considerations-02
Reviewer: Paul Kyzivat
Review Date: 2021-12-18
IETF LC End Date: ?
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


General Thoughts:

I struggled in choosing a Summary statement. I'm caught between:

* This draft is on the right track but has open issues, described in the 
review.


* This draft has serious issues, described in the review, and needs to 
be rethought.


I don't feel qualified to make that call, so I've gone with the more 
positive choice.


One reason for by ambivalence is that I'm uncertain if the things 
recommended in this document are *good enough* to be described as BCPs. 
I would hope that following BCPs would give high probability of 
successful deployment. I'm not convinced of that.


The real question may be whether the MUD approach can work for all the 
types of deployment that IoT manufacturers might want to use? And if so 
whether RFC8520 together with some BCPs is sufficient to accomplish that?


Issues:

Major: 3
Minor: 2
Nits:  3

1) MAJOR: Section 3: Probabilistic results

Several if the strategies in this section appear to be probabilistic in 
nature. E.g.,


   ... the list may have
   changed between the time that the MUD controller did the lookup and
   the time that the IoT device does the lookup ...
   In order to compensate for this, the MUD controller SHOULD regularly
   do DNS lookups.

Even with regular lookups the IoT devices could experience intermittent 
failures. IMO the document needs to explore this issue. Is it good 
enough if it sometimes fails when the list changes? Should the device do 
something to mitigate the issue?


2) MAJOR: Section 3: Installation Specific Mechanisms

I'm bothered by the statement: "In this case, additional installation 
specific mechanisms are probably needed to get the right view of DNS." 
Isn't this just hand waving? (I.e. you can't currently imagine a 
solution?) "Installation specific" is particularly troubling, since its 
hard to imagine what an operator doing the installation would be capable 
of doing.


I think you need to dig deeply into this, or else somehow scope the 
problem to exclude it.


3) MAJOR: Section 6: Recommendations

While following these recommendations may be helpful in achieving 
workable deployments involving MUD it seems unlikely that all 
manufacturers of IoT devices would be able to comply with them all. 
(E.g., Do not use geofenced names.) What are manufacturers who can't 
comply to do?


4) MINOR: Section 3: Strategies to map names

The statement: "This is not a successful strategy, and do not use it." 
seems to be out of place here. Shouldn't this be in section 6?


5) MINOR: Section 4: Anti-Patterns

It isn't clear what you want done with these. I presume you want to tell 
device manufacturers to stop doing these things. If so, then I suggest 
you add BCPs recommending what manufacturers should do instead.


6) NIT: XXX

The document uses "XXX --" in several places. I'm assuming the intent is 
to expand these in a future version.


7) NIT: Section 1: Section cross references

This section refers to "The first section ... The second section ... The 
third section ... The fourth section ...". However the section numbers 
of the appropriate sections are 3,4,5,6. You need to switch to referring 
to sections by numbers that are specified by xrefs.


8) NIT: Section 1: "DNS Presolution"

Is the use of "DNS presolution" intentional, or did you mean "DNS 
resolution"? While "presolution" is a word, I don't find any meaning for 
"DNS presolution".






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

[Gen-art] Gen-ART Telechat review of draft-ietf-bess-evpn-bum-procedure-updates-11

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at <​ 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bess-evpn-bum-procedure-updates-11
Reviewer: Paul Kyzivat
Review Date: 2021-10-13
IETF LC End Date: 2021-09-07
IESG Telechat date: 2021-10-21

Summary:

This draft has serious issues, described in the review, and needs to be 
rethought.


General:

This review is substantially the same as my Last Call review. The 
authors disagreed with my primary concern, but neither did they dissuade 
me from my opinion. I understand that this largely a matter of 
philosophy and style. I'm repeating my concern here for consideration by 
the IESG. What follows is verbatim from my LC review.


My review of this document is limited because I have no knowledge of the 
subject domain. Nevertheless I think I was able to grasp the gist of 
what this document intends to achieve and identify a concern. However it 
is possible that I have misunderstood and so my comments may be off base.


While I have no reason to doubt the mechanisms specified, I think the 
manner in which they are specified is likely to lead to confusion and 
misunderstanding by developers.


IIUC, RFC7117 improved the handling of BUM traffic for VPLS, but did not 
address BUM traffic for EVPN. Then RFC7432 specified how to handle BUM 
traffic for EVPN while referencing RFC7117 for some of its procedures, 
even though RFC7117 had no provision for support of EVPN.


It appears to me that someone who had an implementation of RFC7117 for 
VPLS might have had to modify it to support RFC7432, yet RFC7432 did not 
indicate that it updated RFC7117. The developer would have had to infer 
what changes were required. But at least the changes seem to be small 
and unlikely to be misunderstood.


The current document specifies in its heading and abstract that it 
updates RFC7432, while not mentioning RFC7117. Yet section 2 says:


   ... For brevity, only changes/additions to relevant
   [RFC7117] and [RFC7524] procedures are specified, instead of
   repeating the entire procedures.

From these it is ambiguous whether RFC7117 is or is not being updated. 
It then goes on to state:


   Note that these are to be applied
   to EVPN only, and not updates to [RFC7117] or [RFC7524].

This further clouds things. How could it be known how future updates to 
those documents might interact with the changes in this document?


In the remainder of the document I find no explicit text that appears to 
normatively updates RFC7432. I find this mystifying.


However there are numerous places that normatively change RFC7117. 
Several of these are of the form:


   The following bullet in Section N.N.N.N of [RFC7117]:
   ...
   is changed to the following when applied to EVPN:
   ...

even though RFC7117 didn't contemplate supporting EVPN at all. This 
seems to assume that an entirely different implementation of RFC7117 
will be made for EVPN and these modifications made to that, while not 
impacting implementations of RFC7117 being used for other types of VPNs. 
Is this a reasonable assumption?


Overall it seems that it will be very difficult for a developer to read 
this document and determine exactly what must be implemented, or after 
the fact to determine whether an implementation conforms to this document.


IMO a different style of specification is called for. Probably an 
RFC7117bis and perhaps a RFC7432bis.


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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-bess-evpn-bum-procedure-updates-09

[Paul Kyzivat]

Hi,

This is just a genart review, so of course you are free to disregard it. 
Just consider it to offer some thinking points brought into the 
discussion of the draft.


Best Wishes,
Paul

On 9/10/21 8:44 AM, Jeffrey (Zhaohui) Zhang wrote:

Hi Paul,

Please see zzh2> below.

-Original Message-
From: Paul Kyzivat 
Sent: Wednesday, September 8, 2021 11:15 AM
To: Jeffrey (Zhaohui) Zhang ; 
draft-ietf-bess-evpn-bum-procedure-updates@ietf.org
Cc: General Area Review Team 
Subject: Re: Gen-ART Last Call review of 
draft-ietf-bess-evpn-bum-procedure-updates-09

[External Email. Be cautious of content]


Hi Jeffrey (Zhaohui),

You comments are helpful for me to better understand how this document
relates to the other two. But it doesn't alter my conclusions. More inline.


IIUC, RFC7117 improved the handling of BUM traffic for VPLS, but did not
address BUM traffic for EVPN. Then RFC7432 specified how to handle BUM
traffic for EVPN while referencing RFC7117 for some of its procedures,
even though RFC7117 had no provision for support of EVPN.

It appears to me that someone who had an implementation of RFC7117 for
VPLS might have had to modify it to support RFC7432, yet RFC7432 did not
indicate that it updated RFC7117. The developer would have had to infer
what changes were required. But at least the changes seem to be small
and unlikely to be misunderstood.

Zzh> RFC7432's reference to RFC7117 is informational (so that people familiar with 7117 
can easily relate to the similar procedures), and it (RFC7432) covers "inclusive P2MP 
tunnel" only (when it comes to BUM support), i.e., all BUM traffic (from a PE) goes 
into a single P2MP tunnel that reaches all other PEs, whether a PE needs to receive traffic 
or not. That inclusive tunnel is also un-segmented.
Zzh> RFC7117 itself does also cover selective and segmented tunnel (for VPLS), 
and this document, covers selective and/or segmented tunnel for EVPN.

The current document specifies in its heading and abstract that it
updates RFC7432, while not mentioning RFC7117. Yet section 2 says:

  ... For brevity, only changes/additions to relevant
  [RFC7117] and [RFC7524] procedures are specified, instead of
  repeating the entire procedures.

   From these it is ambiguous whether RFC7117 is or is not being updated.

zzh> This document does indeed not update RFC7117/7524, which is for VPLS/MVPN 
not for EVPN.


IIUC you are saying that 7117 and 7524 intend to serve similar roles,
each for a different VPN technology, each standing alone for the VPN
technology it addresses.

Then this document is intended to serve a similar role for EVPN.

Do I have that right?

Zzh2> Correct.


Zzh> However, since most of the selective/segmented tunnel procedures for EVPN are 
very similar to those in RFC7117/7524,  > we decided not to repeat them in this 
document, but to refer to

7117/7524 with modifications pointed out.

So this document doesn't stand alone. It is highly dependent on rfc7117,
being in effect a derivative work.

Zzh2> It does reuse the text from RFC7117 with modifications when it comes 
selective/segmented tunnels.


It then goes on to state:

  Note that these are to be applied
  to EVPN only, and not updates to [RFC7117] or [RFC7524].

This further clouds things. How could it be known how future updates to
those documents might interact with the changes in this document?

Zzh> As explained above, the intention is to refer to existing procedures in 
RFC7117/7524 with modifications pointed out for EVPN selective/segmented tunnels. 
Those modifications are for EVPN only not for VPLS/MVPN.


So, if revisions are ever made to rfc7117, to fix bugs or whatever, and
those revisions are relevant to EVPN as well then it will be necessary
to make comparable revisions to this document?

Zzh2> Only if to fix bugs in relevant 7117 text and that bug applies here as 
well. Other optional extensions to the relevant RFC7117 text would not require 
changes in this document.
Zzh2> Note that this "referring to rfc7117 text with modification pointed out" 
is just to avoid repeating the text that is already specified for a similar technology.
Zzh2> The alternative is to copy the same text in this document - and if there 
is a bug to be fixed in relevant original 7117 text, it's likely this document 
needs a revision, too.
Zzh2> This can be viewed as a (partial) snapshot of 7117 included in this 
document. If there is a 7117bis, this snapshot does not change.

And if rfc7117 is obsoleted (replaced by a later bis) then this document
will continue to be based on the then obsolete document.

Zzh2> Both VPLS and EVPN are Ethernet VPN technologies, though EVPN is the more 
modern/advanced, and it's less likely that there will be new development on the 
VPLS technology.
Zzh2> As explained above, this document having a (partial) snapshot of RFC7117 
(even if becomes obsolete) is fine 

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-bess-evpn-bum-procedure-updates-09

[Paul Kyzivat]

Hi Jeffrey (Zhaohui),

You comments are helpful for me to better understand how this document 
relates to the other two. But it doesn't alter my conclusions. More inline.



IIUC, RFC7117 improved the handling of BUM traffic for VPLS, but did not
address BUM traffic for EVPN. Then RFC7432 specified how to handle BUM
traffic for EVPN while referencing RFC7117 for some of its procedures,
even though RFC7117 had no provision for support of EVPN.

It appears to me that someone who had an implementation of RFC7117 for
VPLS might have had to modify it to support RFC7432, yet RFC7432 did not
indicate that it updated RFC7117. The developer would have had to infer
what changes were required. But at least the changes seem to be small
and unlikely to be misunderstood.

Zzh> RFC7432's reference to RFC7117 is informational (so that people familiar with 7117 
can easily relate to the similar procedures), and it (RFC7432) covers "inclusive P2MP 
tunnel" only (when it comes to BUM support), i.e., all BUM traffic (from a PE) goes 
into a single P2MP tunnel that reaches all other PEs, whether a PE needs to receive traffic 
or not. That inclusive tunnel is also un-segmented.
Zzh> RFC7117 itself does also cover selective and segmented tunnel (for VPLS), 
and this document, covers selective and/or segmented tunnel for EVPN.

The current document specifies in its heading and abstract that it
updates RFC7432, while not mentioning RFC7117. Yet section 2 says:

 ... For brevity, only changes/additions to relevant
 [RFC7117] and [RFC7524] procedures are specified, instead of
 repeating the entire procedures.

  From these it is ambiguous whether RFC7117 is or is not being updated.

zzh> This document does indeed not update RFC7117/7524, which is for VPLS/MVPN 
not for EVPN.


IIUC you are saying that 7117 and 7524 intend to serve similar roles, 
each for a different VPN technology, each standing alone for the VPN 
technology it addresses.


Then this document is intended to serve a similar role for EVPN.

Do I have that right?

Zzh> However, since most of the selective/segmented tunnel procedures for EVPN are very similar to those in RFC7117/7524,  > we decided not to repeat them in this document, but to refer to 

7117/7524 with modifications pointed out.

So this document doesn't stand alone. It is highly dependent on rfc7117, 
being in effect a derivative work.



It then goes on to state:

 Note that these are to be applied
 to EVPN only, and not updates to [RFC7117] or [RFC7524].

This further clouds things. How could it be known how future updates to
those documents might interact with the changes in this document?

Zzh> As explained above, the intention is to refer to existing procedures in 
RFC7117/7524 with modifications pointed out for EVPN selective/segmented tunnels. 
Those modifications are for EVPN only not for VPLS/MVPN.


So, if revisions are ever made to rfc7117, to fix bugs or whatever, and 
those revisions are relevant to EVPN as well then it will be necessary 
to make comparable revisions to this document?


And if rfc7117 is obsoleted (replaced by a later bis) then this document 
will continue to be based on the then obsolete document.



In the remainder of the document I find no explicit text that appears to
normatively updates RFC7432. I find this mystifying.

Zzh> All procedures in this document (including those referring to 7117/7524) 
are additional optional procedures that 7432 does not cover.


The relationship is very confusing.


However there are numerous places that normatively change RFC7117.
Several of these are of the form:

 The following bullet in Section N.N.N.N of [RFC7117]:
 ...
 is changed to the following when applied to EVPN:
 ...

even though RFC7117 didn't contemplate supporting EVPN at all. This
seems to assume that an entirely different implementation of RFC7117
will be made for EVPN and these modifications made to that, while not
impacting implementations of RFC7117 being used for other types of VPNs.
Is this a reasonable assumption?

Zzh> Yes.
Zzh> RFC7117 is for VPLS, which predates EVPN. EVPN comes later and is specified in 7432, 
though 7432 has informational reference to 7117 when it comes to "inclusive 
non-segmented P2MP" tunnel, and this document refers to 7117's selective/segmented 
tunnel procedures with modifications pointed out.

Overall it seems that it will be very difficult for a developer to read
this document and determine exactly what must be implemented, or after
the fact to determine whether an implementation conforms to this document.


I stand by this statement above.


IMO a different style of specification is called for. Probably an
RFC7117bis and perhaps a RFC7432bis.


OK. Now I see that a rfc7117bis isn't appropriate. Yet I think it calls 
for some sort of explicit derivative work, that is effectively a copy of 
rfc7117 with your changes applied. Perhaps it should also replace 
rfc7432 regarding EVPS.


Or, perhaps 

[Gen-art] Gen-ART Last Call review of draft-ietf-bess-evpn-bum-procedure-updates-09

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bess-evpn-bum-procedure-updates-09
Reviewer: Paul Kyzivat
Review Date: 2021-09-04
IETF LC End Date: 2021-09-07
IESG Telechat date: ?

Summary:

This draft has serious issues, described in the review, and needs to be 
rethought.


General:

My review of this document is limited because I have no knowledge of the 
subject domain. Nevertheless I think I was able to grasp the gist of 
what this document intends to achieve and identify a concern. However it 
is possible that I have misunderstood and so my comments may be off base.


While I have no reason to doubt the mechanisms specified, I think the 
manner in which they are specified is likely to lead to confusion and 
misunderstanding by developers.


IIUC, RFC7117 improved the handling of BUM traffic for VPLS, but did not 
address BUM traffic for EVPN. Then RFC7432 specified how to handle BUM 
traffic for EVPN while referencing RFC7117 for some of its procedures, 
even though RFC7117 had no provision for support of EVPN.


It appears to me that someone who had an implementation of RFC7117 for 
VPLS might have had to modify it to support RFC7432, yet RFC7432 did not 
indicate that it updated RFC7117. The developer would have had to infer 
what changes were required. But at least the changes seem to be small 
and unlikely to be misunderstood.


The current document specifies in its heading and abstract that it 
updates RFC7432, while not mentioning RFC7117. Yet section 2 says:


   ... For brevity, only changes/additions to relevant
   [RFC7117] and [RFC7524] procedures are specified, instead of
   repeating the entire procedures.

From these it is ambiguous whether RFC7117 is or is not being updated. 
It then goes on to state:


   Note that these are to be applied
   to EVPN only, and not updates to [RFC7117] or [RFC7524].

This further clouds things. How could it be known how future updates to 
those documents might interact with the changes in this document?


In the remainder of the document I find no explicit text that appears to 
normatively updates RFC7432. I find this mystifying.


However there are numerous places that normatively change RFC7117. 
Several of these are of the form:


   The following bullet in Section N.N.N.N of [RFC7117]:
   ...
   is changed to the following when applied to EVPN:
   ...

even though RFC7117 didn't contemplate supporting EVPN at all. This 
seems to assume that an entirely different implementation of RFC7117 
will be made for EVPN and these modifications made to that, while not 
impacting implementations of RFC7117 being used for other types of VPNs. 
Is this a reasonable assumption?


Overall it seems that it will be very difficult for a developer to read 
this document and determine exactly what must be implemented, or after 
the fact to determine whether an implementation conforms to this document.


IMO a different style of specification is called for. Probably an 
RFC7117bis and perhaps a RFC7432bis.



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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-httpbis-cache-header-08

[Paul Kyzivat]

On 7/7/21 12:31 AM, Mark Nottingham wrote:




On 3 Jul 2021, at 2:00 am, Paul Kyzivat  wrote:



I suggest you provide IANA with a template for the registry, and provide 
authors of extension parameters with a template for what should be included in 
a specification document.

There's a registration template in Section 4, referenced from the IANA 
considerations.


Yes, I saw that. But IANA isn't instructed to make a registry containing those 
things. (They are described as being input to the expert. I'm greatly in favor 
of specifying what input the expert should consider.)

Also, IANA is asked to populate the registry from section 2. But section 2 
isn't consistent with that template.

I suggest you be clear about how the IANA registry should be formatted, and 
then provide a filled in template containing what you want to go into the 
registry from section 2.


Since this discussion, IANA has commented on the draft, and didn't have any 
issues with identifying how to populate the registry. I did, however, forget to 
register the HTTP header itself :)


OK. But wait and see what they end up creating for the initial entries.

Can you give a plausible example of an extension that could be 
sufficiently defined without an accompanying document? Where the only 
information available to the user is what is contained in the IANA registry?


Thanks,
Paul

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-httpbis-cache-header-08

[Paul Kyzivat]

Hi Mark,

On 7/2/21 2:05 AM, Mark Nottingham wrote:

Hi Paul,

Thanks for the review; I've added the WG mailing list to the CC.


On 2 Jul 2021, at 2:55 am, Paul Kyzivat  wrote:

1) Minor: Is a hit or fwd parameter required?

Is it required that an entry contain one of "hit" or "fwd"? Section 2.1 makes 
it clear that you can't use both, but is less clear that one of them must be included. But 
logically it seems that an entry without either wouldn't be very useful.

I suggest that this be stated explicitly.


It's not required; conceivably, there's value in knowing that a cache was 
merely present. As the spec states, all parameters are OPTIONAL.


OK


2) Minor: ttl for other caches

I'm not clear about the following in section 3:

   Going through two separate layers of caching, where the cache closest
   to the origin responded to an earlier request with a stored response,
   and a second cache stored that response and later reused it to
   satisfy the current request:

   Cache-Status: OriginCache; hit; ttl=1100,
 "CDN Company Here"; hit; ttl=545

When "CDN Company Here" replies with a hit is it responsible for updating the 
ttl for the OriginCache? (Based on the time that has elapsed since it cached the value.) 
If not, does that ttl have any relevance?


No - 'ttl' is how fresh a response is in a cache when it's served; recording it 
helps to determine how old the response was at each step. As the spec says:

"When adding a value to the Cache-Status header field, caches SHOULD preserve the 
existing field value, to allow debugging of the entire chain of caches handling the 
request."


OK. This does mean that only the ttl from the "hit" entry is meaningful.


3) Minor: registration of parameters

IMO the process of registration is underspecified.

For one thing, IANA is not instructed as to what the registry itself should 
look like. Given that a specification document is optional, the registry 
presumably must contain everything specified by the template in section 4 for 
new parameter registrations. But the instructions for pre-populating the 
registry from section 2 would mean copying a *lot* free formatted text into the 
registry.

ISTM that it would be more straightforward to always require a specification 
and have the IANA registry refer to it.

Alternatively, you could have different templates for registering with/without 
a specification and different registry formats for each.

I suggest you provide IANA with a template for the registry, and provide 
authors of extension parameters with a template for what should be included in 
a specification document.


There's a registration template in Section 4, referenced from the IANA 
considerations.


Yes, I saw that. But IANA isn't instructed to make a registry containing 
those things. (They are described as being input to the expert. I'm 
greatly in favor of specifying what input the expert should consider.)


Also, IANA is asked to populate the registry from section 2. But section 
2 isn't consistent with that template.


I suggest you be clear about how the IANA registry should be formatted, 
and then provide a filled in template containing what you want to go 
into the registry from section 2.



4) Minor: Applicability of this header field is confusing

Section 2 says:

   The Cache-Status header field is only applicable to responses that
   are generated by an origin server.  An intermediary SHOULD NOT append
   a Cache-Status member to responses that it generates, even if that
   intermediary contains a cache, except when the generated response is
   based upon a stored response (e.g., a 304 Not Modified or 206 Partial
   Content).

The use of "are" implies to me that the cache received the response from the origin 
server just now. Using "were" (or even more explicit language) would tell me that this 
was a response received by the cache either now or in the past.

Also, IIUC the cache can't ever really distinguish if it received a response 
from the origin server or another cache. So how can it know if this response 
*ever* was created by the origin server? All it can know is that it received it 
from a server closer to the origin.

Can you clarify the language?


OK. I've changed 'are' to 'have been'.


Thanks.

Paul


Thanks again for the review,


--
Mark Nottingham   https://www.mnot.net/



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

[Gen-art] Gen-ART Last Call review of draft-ietf-httpbis-cache-header-08

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-httpbis-cache-header-08
Reviewer: Paul Kyzivat
Review Date: 2021-07-07
IETF LC End Date: 2021-07-01
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


General:

What I read in Security Considerations section scares me, but I'm not 
competent to express an opinion. I am going to leave this to the 
security review.


Issues:

Major: 0
Minor: 4
Nits:  0

1) Minor: Is a hit or fwd parameter required?

Is it required that an entry contain one of "hit" or "fwd"? Section 2.1 
makes it clear that you can't use both, but is less clear that one of 
them must be included. But logically it seems that an entry without 
either wouldn't be very useful.


I suggest that this be stated explicitly.

2) Minor: ttl for other caches

I'm not clear about the following in section 3:

   Going through two separate layers of caching, where the cache closest
   to the origin responded to an earlier request with a stored response,
   and a second cache stored that response and later reused it to
   satisfy the current request:

   Cache-Status: OriginCache; hit; ttl=1100,
 "CDN Company Here"; hit; ttl=545

When "CDN Company Here" replies with a hit is it responsible for 
updating the ttl for the OriginCache? (Based on the time that has 
elapsed since it cached the value.) If not, does that ttl have any 
relevance?


3) Minor: registration of parameters

IMO the process of registration is underspecified.

For one thing, IANA is not instructed as to what the registry itself 
should look like. Given that a specification document is optional, the 
registry presumably must contain everything specified by the template in 
section 4 for new parameter registrations. But the instructions for 
pre-populating the registry from section 2 would mean copying a *lot* 
free formatted text into the registry.


ISTM that it would be more straightforward to always require a 
specification and have the IANA registry refer to it.


Alternatively, you could have different templates for registering 
with/without a specification and different registry formats for each.


I suggest you provide IANA with a template for the registry, and provide 
authors of extension parameters with a template for what should be 
included in a specification document.


4) Minor: Applicability of this header field is confusing

Section 2 says:

   The Cache-Status header field is only applicable to responses that
   are generated by an origin server.  An intermediary SHOULD NOT append
   a Cache-Status member to responses that it generates, even if that
   intermediary contains a cache, except when the generated response is
   based upon a stored response (e.g., a 304 Not Modified or 206 Partial
   Content).

The use of "are" implies to me that the cache received the response from 
the origin server just now. Using "were" (or even more explicit 
language) would tell me that this was a response received by the cache 
either now or in the past.


Also, IIUC the cache can't ever really distinguish if it received a 
response from the origin server or another cache. So how can it know if 
this response *ever* was created by the origin server? All it can know 
is that it received it from a server closer to the origin.


Can you clarify the language?

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-finding-geofeeds-06

[Paul Kyzivat]

Hi Randy,

Comments inline.

On 4/29/21 4:30 PM, Randy Bush wrote:

hi paul:

thanks for the review.


1) Minor: Definition of "remarks: Geofeed"

Section 3 says:

... The format of the inetnum: geofeed
attribute MUST be as in this example, "remarks: Geofeed" followed by
a URL ...

 From the examples and common sense there should be a space preceding
the URL. But the text doesn't mention this.

I suggest changing to:

... The format of the inetnum: geofeed
attribute MUST be as in this example, "remarks: Geofeed " followed by
a URL ...


aha!  good one.  thanks.


Also, is the word "Geofeed" case sensitive?


"MUST be as in this example."  do we need ABNF the ex compiler hacker
asks?  i can add enough syntactic sugar to give you a diabetic coma :)


I don't think you need abnf. But some text specifying it is/isn't case 
sensitive would help. It may not be necessary if there is a strong 
established policy for handling case in RPSL. But even if there is it 
might not be applicable to processing the text of remarks.



i contend that it was good enough that your eagle eye caught a bug.


2) Minor: Modification of RPSL

Section 3 says:

While we leave global agreement of RPSL modification to the relevant
parties, we specify that a proper geofeed: attribute in the inetnum:
class be simply "geofeed: " followed by a URL which will vary, but
MUST refer only to a [RFC8805] geofeed file.
...
Until all producers of inetnum:s, i.e. the RIRs, state that they have
migrated to supporting a geofeed: attribute, consumers looking at
inetnum:s to find geofeed URLs MUST be able to consume both the
remarks: and geofeed: forms.

This is a bit presumptive. You say you are leaving the RPSL
modification to others, yet you are herein standardizing the exact
form that modification must take. What if the relevant parties want to
choose a different form?


we have met the enemy and he is us -- pogo by walt kelly

the work is being done in the ripe database wg of which most authors are
part.  the wg is driving off this draft and really appreciates having
the syntax thrown over the wall.  the ripe community is more cooperative
than the ietf.


If these two efforts are already coordinated then all is well.


3) Minor/Nit: IANA Considerations

I don't understand why this section is present. I don't find any
reference of it within the document.


0 1197: SEQUENCE {
4  917:  SEQUENCE {
83:   [0] {
   101:INTEGER 2
  : }
   13   20:   INTEGER 27AD394083D7F2B5B99B8670C775B2B96EE166E3
   35   13:   SEQUENCE {
   379:OBJECT IDENTIFIER
  : sha256WithRSAEncryption (1 2 840 113549 1 1 11)   <=
   480:NULL
  : }
...

you mean you don't read decoded certs for breakfast? 


No I don't. Now it is clear.


they are said to
make one strong.  the few i have tried had other effects :)



4) NIT: Use of "awesome"

I'm not sure how to feel about using *awesome* in the Introduction. It
seems unusually informal for a standards document. But in a way I also
find it refreshing.


so do we.  as i said to the kind opsdir reviewer, we'll see how far up
the chain a sense of perspective still exists.


It will be interesting to see.


IdNits reports a number of things worth looking into. Notably the
downrefs


the downrefs are only informational.  they are the best doccos on
INETNUM today.  sigh.


But the references are included in the Normative References section. If 
you put them in an Informative References section then I think IdNits 
will be happy.



and the lack of an IPv6 example.


iij deployed ipv6 on our global network in '97, so i don't really feel a
strong need to pander to the insecurities of today's ipv6 fans.  action
speaks louder than words.  .


Its only a matter of how much you want to fight mother nature (IdNits). 
If you "fix" the things it complains about then nobody will bring up the 
issue again.


Thanks,
Paul


as i said to kyle, secdir reviewer, unless someone pushes, i'll hold -07
until a few more reviews come in.

again, review MUCH appreciated.

randy



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

[Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-finding-geofeeds-06

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-finding-geofeeds-06
Reviewer: Paul Kyzivat
Review Date: 2021-04-29
IETF LC End Date: 2021-05-04
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


General:

I'm not competent to review the crypto and security aspects of this 
document. Hopefully there will also be a security review to cover those.


Issues:

Major: 0
Minor: 3
Nits:  2

1) Minor: Definition of "remarks: Geofeed"

Section 3 says:

   ... The format of the inetnum: geofeed
   attribute MUST be as in this example, "remarks: Geofeed" followed by
   a URL ...

From the examples and common sense there should be a space preceding 
the URL. But the text doesn't mention this. I suggest changing to:


   ... The format of the inetnum: geofeed
   attribute MUST be as in this example, "remarks: Geofeed " followed by
   a URL ...

Also, is the word "Geofeed" case sensitive?

2) Minor: Modification of RPSL

Section 3 says:

   While we leave global agreement of RPSL modification to the relevant
   parties, we specify that a proper geofeed: attribute in the inetnum:
   class be simply "geofeed: " followed by a URL which will vary, but
   MUST refer only to a [RFC8805] geofeed file.
   ...
   Until all producers of inetnum:s, i.e. the RIRs, state that they have
   migrated to supporting a geofeed: attribute, consumers looking at
   inetnum:s to find geofeed URLs MUST be able to consume both the
   remarks: and geofeed: forms.

This is a bit presumptive. You say you are leaving the RPSL modification 
to others, yet you are herein standardizing the exact form that 
modification must take. What if the relevant parties want to choose a 
different form?


ISTM that this document should only mandate support for the Remarks form 
and leave support of the modified RPSL form to later, after RPSL has 
been updated.


3) Minor/Nit: IANA Considerations

I don't understand why this section is present. I don't find any 
reference of it within the document.


4) NIT: Use of "awesome"

I'm not sure how to feel about using *awesome* in the Introduction. It 
seems unusually informal for a standards document. But in a way I also 
find it refreshing.


I just suggest you rethink about whether you want that. I'm good either way.

5) Nit: IdNits

IdNits reports a number of things worth looking into. Notably the 
downrefs and the lack of an IPv6 example.


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

[Gen-art] Gen-ART Telechat review of draft-ietf-ace-dtls-authorize-16

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at <​ 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-ace-dtls-authorize-16
Reviewer: Paul Kyzivat
Review Date: 2020-03-19
IETF LC End Date: 2020-07-20
IESG Telechat date: 2021-03-23

Summary:

This draft is ready for publication as a Standards Track RFC.

General:

I had extensive discussions with the authors following my last call 
review. All of my concerns have now been addressed.


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

[Gen-art] Gen-ART Last Call review of draft-ietf-detnet-ip-over-tsn-05

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-detnet-ip-over-tsn-05
Reviewer: Paul Kyzivat
Review Date: 2021-02-05
IETF LC End Date: 2021-02-05
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


General:

I'm unqualified to meaningfully comment on the technical quality of this 
document. I've reviewed it for form.


Issues:

Major: 0
Minor: 0
Nits:  2

1) NIT: Unlinked references

In section 1 paragraph 2, and section 3 paragraph 1, there are 
references to [RFC8939] that are not linked.


2) NIT: From IdNits

IdNits reports:

  == Outdated reference: A later version (-14) exists of
 draft-ietf-detnet-security-12

There are a couple of other warnings, but they are spurious.

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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-anima-grasp-api-08

[Paul Kyzivat]

Brian,

Thanks. I'm happy now.

Paul

On 12/3/20 4:22 PM, Brian E Carpenter wrote:

Below...

On 04-Dec-20 04:17, Paul Kyzivat wrote:

Brian,

One more thing occurred to me:

On 12/2/20 12:29 PM, Paul Kyzivat wrote:


Also, the goal of negotiation isn't clear to me. I gather it must be for
the two sides to agree on a particular value for the objective. But for
that to work there must be some rules about how values can change in
each step so that the result stabililizes, rather than causing a battle
that ends with loop count exhaustion. This could be achieved by always
negotiating *down*, or always *up*. But that requires that the objective
value type have an ordering function. Given the general nature of the
objective I don't think that can be assumed.


No, it explicitly is not defined either in the protocol nor the API.
The syntax and semantics of the objective value are defined
per-objective,
and the objective might or might not be ordered. So there is
intentionally
no answer to your question.

In most cases I'd expect that there would be an ordering but we didn't
want
to constrain the use cases in that way. Also note that a failed
negotiation
(e.g. the loop count expires, or where one end simply rejects the other's
offer) is not a protocol failure.



ISTM that more work is needed to define the negotiation process in a way
that ensures it ends with both sides agreeing on a single value for the
objective.


As noted, that is per-objective. The most complicated case I've coded
is IP prefix assignment, and it works fine, except that if there is
no prefix available of the maximum desired length, the requester ends
up unsatisfied - as intended. There should be no condition in which
the negotiation loops indefinitely; it either succeeds or fails.


Without that the result in non-deterministic. The two sides may have
conflicting goals, and then the result will only be determined by the
loop count and timeout.

Alternately, implementors will establish side agreements that aren't
governed by standards.

That seems like an undesirable state of affairs.


One possibility would be to define the negotiation policy on a
per-objective basis. This would be required as part of the definition of
the objective that is registered with IANA. It would define how the
value may change from step to step of negotiation to ensure convergence.


The IANA policy is Specification Required. We already have this in the
GRASP spec itself:

There must be a well-defined procedure for concluding that a
negotiation cannot succeed, and if so deciding what happens next
(e.g., deadlock resolution, tie-breaking, or revert to best-effort
service).  This MUST be specified for individual negotiation
objectives.

The natural place to expand on that is in draft-ietf-anima-asa-guidelines
as it develops.

Regards
 Brian



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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-anima-grasp-api-08

[Paul Kyzivat]

Brian,

One more thing occurred to me:

On 12/2/20 12:29 PM, Paul Kyzivat wrote:


Also, the goal of negotiation isn't clear to me. I gather it must be for
the two sides to agree on a particular value for the objective. But for
that to work there must be some rules about how values can change in
each step so that the result stabililizes, rather than causing a battle
that ends with loop count exhaustion. This could be achieved by always
negotiating *down*, or always *up*. But that requires that the objective
value type have an ordering function. Given the general nature of the
objective I don't think that can be assumed.


No, it explicitly is not defined either in the protocol nor the API.
The syntax and semantics of the objective value are defined 
per-objective,
and the objective might or might not be ordered. So there is 
intentionally

no answer to your question.

In most cases I'd expect that there would be an ordering but we didn't 
want
to constrain the use cases in that way. Also note that a failed 
negotiation

(e.g. the loop count expires, or where one end simply rejects the other's
offer) is not a protocol failure.



ISTM that more work is needed to define the negotiation process in a way
that ensures it ends with both sides agreeing on a single value for the
objective.


As noted, that is per-objective. The most complicated case I've coded
is IP prefix assignment, and it works fine, except that if there is
no prefix available of the maximum desired length, the requester ends
up unsatisfied - as intended. There should be no condition in which
the negotiation loops indefinitely; it either succeeds or fails.


Without that the result in non-deterministic. The two sides may have 
conflicting goals, and then the result will only be determined by the 
loop count and timeout.


Alternately, implementors will establish side agreements that aren't 
governed by standards.


That seems like an undesirable state of affairs.


One possibility would be to define the negotiation policy on a 
per-objective basis. This would be required as part of the definition of 
the objective that is registered with IANA. It would define how the 
value may change from step to step of negotiation to ensure convergence.


Thanks,
Paul

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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-anima-grasp-api-08

[Paul Kyzivat]

Brian,

On 12/1/20 8:13 PM, Brian E Carpenter wrote:

Hi Paul,

Comments in line. There's one definite good catch in your
review, and obviously more clarifications are needed.


I'll comment this one last time. Then I will be satisfied that I have 
communicated my thoughts, and I'm happy with whatever you decide to do.



On 01-Dec-20 15:06, Paul Kyzivat wrote:

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by the
IESG for the IETF Chair. Please wait for direction from your document
shepherd or AD before posting a new version of the draft. For more
information, please see the FAQ at <​
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-anima-grasp-api-08
Reviewer: Paul Kyzivat
Review Date: 2020-11-30
IETF LC End Date: 2020-10-28
IESG Telechat date: 2020-12-01

Summary:

This draft is on the right track but has open issues, described in the
review.

General:

This document has addressed some of the concerns I had during the last
call review. However some of my concerns remain and some new ones have
arisen in this version.

Issues:

Major: 3
Minor: 6
Nits:  1

1) MAJOR: Negotiation

The text in section 2.3.5 now makes clear that the sequence of steps in
the negotiation is non-deterministic - both sides can call
negotiate_step and negotiate_wait. I believe this can result in the two
sides not agreeing on what values have been negotiated. (For instance,
what if one side calls negotiate_step concurrently with the other side
calling end_negotiate? Which value has been agreed upon?)


The negotiate_step calls alternate between the two peers, until one of them
calls end_negotiate (or a timeout kills the session). I hoped that
was clear in the protocol diagram. We can make it explicit, for people
who haven't fully digested the protocol spec. Since that's ~50 pages, it
certainly takes some digestion.

(negotiate_wait would be interjected by the peer who has the next go, simply
indicating that the next step is delayed. That could happen, for example,
if the ASA needed to negotiate something with a third party before
continuing.)


The figure shows alternation, but IIUC that is only an example. I 
understood the text as permitting either side to perform negotiate_step 
or negotiate_wait at will. A requirement for alternation would solve the 
problem.


Reading it again, I see how it can be interpreted as you say is 
intended. But it isn't clear. To clarify, is the intent that a 
negotiate_step, negotiate_wait, or end_negotiate is required in response 
to receipt of request_negotiate or negotiate_step? And a negotiate_step 
or end_negotiate is also required following the sending of 
negotiate_wait. And those are the only permitted sequences?


A state machine would be helpful to show this in an unambiguous way.


The loop_count
adds to the confusion. Are the two sides intended to have independent
loop count values? It seems these too can become unsynchronized.


The loop count also bounces backwards and forwards in alternate steps.
Again, we can underline that in the text.


That would be helpful.


Also, the goal of negotiation isn't clear to me. I gather it must be for
the two sides to agree on a particular value for the objective. But for
that to work there must be some rules about how values can change in
each step so that the result stabililizes, rather than causing a battle
that ends with loop count exhaustion. This could be achieved by always
negotiating *down*, or always *up*. But that requires that the objective
value type have an ordering function. Given the general nature of the
objective I don't think that can be assumed.


No, it explicitly is not defined either in the protocol nor the API.
The syntax and semantics of the objective value are defined per-objective,
and the objective might or might not be ordered. So there is intentionally
no answer to your question.

In most cases I'd expect that there would be an ordering but we didn't want
to constrain the use cases in that way. Also note that a failed negotiation
(e.g. the loop count expires, or where one end simply rejects the other's
offer) is not a protocol failure.



ISTM that more work is needed to define the negotiation process in a way
that ensures it ends with both sides agreeing on a single value for the
objective.


As noted, that is per-objective. The most complicated case I've coded
is IP prefix assignment, and it works fine, except that if there is
no prefix available of the maximum desired length, the requester ends
up unsatisfied - as intended. There should be no condition in which
the negotiation loops indefinitely; it either succeeds or fails.


Without that the result in non-deterministic. The two sides may have 
conflicting goals, and then the result will only be determined by the 
loop count and timeout.


Alternately, implementors will establish side agreements that aren't 
governed by standards.


That seem

[Gen-art] Gen-ART Telechat review of draft-ietf-anima-grasp-api-08

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at <​ 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-anima-grasp-api-08
Reviewer: Paul Kyzivat
Review Date: 2020-11-30
IETF LC End Date: 2020-10-28
IESG Telechat date: 2020-12-01

Summary:

This draft is on the right track but has open issues, described in the 
review.


General:

This document has addressed some of the concerns I had during the last 
call review. However some of my concerns remain and some new ones have 
arisen in this version.


Issues:

Major: 3
Minor: 6
Nits:  1

1) MAJOR: Negotiation

The text in section 2.3.5 now makes clear that the sequence of steps in 
the negotiation is non-deterministic - both sides can call 
negotiate_step and negotiate_wait. I believe this can result in the two 
sides not agreeing on what values have been negotiated. (For instance, 
what if one side calls negotiate_step concurrently with the other side 
calling end_negotiate? Which value has been agreed upon?) The loop_count 
adds to the confusion. Are the two sides intended to have independent 
loop count values? It seems these too can become unsynchronized.


Also, the goal of negotiation isn't clear to me. I gather it must be for 
the two sides to agree on a particular value for the objective. But for 
that to work there must be some rules about how values can change in 
each step so that the result stabililizes, rather than causing a battle 
that ends with loop count exhaustion. This could be achieved by always 
negotiating *down*, or always *up*. But that requires that the objective 
value type have an ordering function. Given the general nature of the 
objective I don't think that can be assumed.


ISTM that more work is needed to define the negotiation process in a way 
that ensures it ends with both sides agreeing on a single value for the 
objective.


2) MINOR: Dry Run Negotiation

Dry Run negotiation is very under-specified. Why would it be used? I 
guess that an ASA might use dry run negotiation to inform future actual 
negotiation. Can anything be inferred from a dry run negotiation about 
how an actual negotiation will go? When participating in a dry run 
negotiation, how should an ASA decide what response to make? Should it 
take into account current resource availability? Or should it respond 
based on best-case or worst-case resource availability? Or what?


This requires further clarification.

3) MAJOR: Confusing semantics of 'request_negotiate'

In section 2.3.5 I don't understand the following:

 1.  The 'session_nonce' parameter is null.  In this case the
 negotiation has succeeded in one step and the peer has
 accepted the request.  The returned 'proffered_objective'
 contains the value accepted by the peer, which is therefore
 equal to the value in the requested 'objective'.  For this
 reason, no session nonce is needed, since the session has
 ended.

IIUC this requires a network exchange with the peer. I don't see how 
this can complete *immediately*. ISTM that this could only complete 
immediately if it were satisfied from a local cache. That doesn't seem 
appropriate for this function.


Similarly, in bullet 2 I don't see how the proffered_objective would be 
available in the initial call, before a response has been received from 
the peer..


Does "immediately" here simply mean that the negotiation is completed in 
one exchange between the two ends? If so, isn't a session nonce still 
required in an event loop implementation in order to handle the one 
response?


Bullet 2 also says:

 ... The
 returned 'proffered_objective' contains the first value
 proffered by the negotiation peer.  The contents of this
 instance of the objective must be used to prepare the next
 negotiation step (see negotiate_step() below) because it
 contains the updated loop count, sent by the negotiation
 peer.  The GRASP code automatically decrements the loop
 count by 1 at each step, and returns an error if it becomes
 zero.

I guess that the 'proffered_objective' in the return parameters is the 
counter-offer to the objective passed in the call. And that you expect 
the objective value used in any subsequent negotiate_step to be derived 
by modifying this value. So far this new wording has improved my 
understanding.


But the loop_count in the objective is especially confusing. It seems 
that it is handled quite differently from the rest of the objective. You 
specify (in 2.3.2.3) that it has a default value of GRASP_DEP_LOOPCT. 
But who is expect

[Gen-art] Gen-ART Last Call review of draft-ietf-anima-grasp-api-07

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-anima-grasp-api-07
Reviewer: Paul Kyzivat
Review Date: 2020-10-28
IETF LC End Date: 2020-10-28
IESG Telechat date: ?

This draft is on the right track but has open issues, described in the 
review.


General:

I began this review without any knowledge of Anima. I did read several 
of the related documents for context, but my overall understanding 
remains somewhat sketchy. So take my comments with with that in mind. 
(At least you get a fresh, untainted perspective.)


Issues:

Major: 5
Minor: 6
Nits:  2

1) MAJOR: Unclear model for API function usage

As I read through sections 2.3.2 through 2.3.6 these I got progressively 
more confused. I finally concluded that a big picture of how API 
functions interact is lacking.


For one thing, there isn't a clear delineation between those calls used 
by requesters and those used by responders. And then valid sequencing of 
calls is hard to tease out.


It would be helpful to have one state model for requesters and another 
for responders. It may also be helpful to break this out for threaded 
and event loop variants.


My subsequent issues regarding these sections are reflective of this 
confusion.


2) MAJOR: What state does GRASP retain for Objectives?

It is clear that the GRASP must retain the names of registered 
objectives. There are implications that it must keep more. Seemingly it 
must retain received flooded objectives, on a per-source basis. It is 
unclear if it is only for registered objectives, or also for 
unregistered objectives. This could potentially become a large resource 
drain if there are lots of nodes flooding values.


Negotiated objectives seem to be treated differently. It isn't clear to 
me if GRASP needs to retain copies of their values.


3) MAJOR: Consistency of Objective definitions

In section 2.3.1.2 and elsewhere, presumably all parties that use a 
particular objective must agree on the values of synch, neg, dry, and 
the format of the value.


Apparently you are relying on each caller getting this right. What 
happens when this isn't the case? How can blame be ascribed so that the 
problem can be fixed?


4) MAJOR: Confusing semantics of 'request_negotiate'

In section 2.3.4 I don't understand the following:

 1.  The 'session_nonce' parameter is null.  In this case the
 negotiation has succeeded immediately (the peer has
 accepted the request).  The returned 'proffered_objective'
 contains the value accepted by the peer.

IIUC this requires a network exchange with the peer. I don't see how 
this can complete *immediately*. ISTM that this could only complete 
immediately if it were satisfied from a local cache. That doesn't seem 
appropriate for this function.


Similarly, in bullet 2 I don't see how the proffered_objective would be 
available in the initial call.


Or is this text only applicable to a threaded implementation with 
synchronous calls?


Bullet 2 also says:

 ... The
 returned 'proffered_objective' contains the first value
 proffered by the negotiation peer.  The contents of this
 instance of the objective must be used in the subsequent
 negotiation call because it contains the updated loop
 count, sent by the negotiation peer.

Do you mean this must be used in the call to negotiate_step? But that 
would mean asking for what has already been granted. For the the 
negotiation to be useful I would expect that the next round would ask 
for a value somewhere between what was originally requested and what was 
initially offered.


I think you need to say more about the whole concept of negotiation and 
how it is expected to work. Also, additional discussion of the purpose 
and semantics of dry run negotiation.


One more thing: you don't explain the semantics of 'timeout'. Is it only 
used locally, to terminate the synchronous form of the call? Or is it 
transmitted and used by the responder to control how long it might spend 
trying to fulfill the request before giving up?


5) MAJOR: Confusing semantics of 'negotiate_step'

In section 2.3.4, I'm confused by:

Called in the same thread as the
preceding 'request_negotiate' or 'listen_negotiate'

I understand use of this following request_negotiate, but not with 
listen_negotiate. A negotiation should consist of an ordered sequence of 
"rounds" of bidding. Allowing both requester and responder to initiate a 
next step can lead to a disruption of the ordering. I would expect this 
to only be used by the caller of request_negotiate. What am I missing?


6) MINOR(MA

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

[Paul Kyzivat]

On 10/28/20 4:09 AM, Olaf Bergmann wrote:

Hi Paul, Ben and Göran,

Thanks for sorting this out. I have reverted #28 as Ben had suggested.

Paul, if you are happy with the other change [1] (a SHOULD for access
token uniqueness per client in alignment with the framework document), I
can submit version -14


Sure. Go for it.

Thanks,
Paul


[1] 
https://github.com/ace-wg/ace-dtls-profile/commit/86008b3327f32e8ac2da0aa1b0110db64e3a467f

Grüße
Olaf

Paul Kyzivat  writes:


On 10/26/20 4:21 PM, Benjamin Kaduk wrote:

Hi Göran, Paul, Olaf,

Sorry for the slow reply.

I agree with Göran's original assessment that the language referring to
7049bis does provide enough information to have a deterministic encoding
for the HKDF inputs.

As such, I don't think pull #28 is needed, and would prefer that it was
reverted (the specific wording doesn't do a great job indicating
that the
whole list of requirements is "normative", to the extent that any
example
can be normative).


Ben, having raised the point, and knowing that you understood it, I am
satisfied with whatever changes you do or don't decide to make to
address it.


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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

[Paul Kyzivat]

On 10/26/20 4:21 PM, Benjamin Kaduk wrote:

Hi Göran, Paul, Olaf,

Sorry for the slow reply.

I agree with Göran's original assessment that the language referring to
7049bis does provide enough information to have a deterministic encoding
for the HKDF inputs.

As such, I don't think pull #28 is needed, and would prefer that it was
reverted (the specific wording doesn't do a great job indicating that the
whole list of requirements is "normative", to the extent that any example
can be normative).


Ben, having raised the point, and knowing that you understood it, I am 
satisfied with whatever changes you do or don't decide to make to 
address it.


Thanks,
Paul


Thanks,

Ben

On Thu, Oct 15, 2020 at 05:24:37PM +, Göran Selander wrote:

Hi Paul,

Returning to the final remaining comment in your review. I made a pull request 
to clarify the change I proposed at the end of the mail below (to which I 
didn't find a response but I may have missed it):

https://github.com/ace-wg/ace-dtls-profile/pull/28

Does this address your concern?

Thanks,
Göran


On 2020-09-25, 17:07, "Göran Selander"  wrote:

 Hi Paul,

 On 2020-09-17, 17:26, "Paul Kyzivat"  wrote:

 Hi Olaf,

 On 9/17/20 4:09 AM, Olaf Bergmann wrote:
 > Hi Paul,
 >
 > Responding to you remaining comments please see inline.
 >
 > Paul Kyzivat  writes:
 >
 >>>>> * Also in section 3.3:
 >>>>>
 >>>>>  All CBOR data types are encoded in CBOR using preferred 
serialization
 >>>>>  and deterministic encoding as specified in Section 4 of
 >>>>>  [I-D.ietf-cbor-7049bis].  This implies in particular that the 
"type"
 >>>>>  and "L" components use the minimum length encoding.  The 
content of
 >>>>>  the "access_token" field is treated as opaque data for the 
purpose of
 >>>>>  key derivation.
 >>>>>
 >>>>> IIUC the type of serialization and encoding is a requirement. 
Will
 >>>>> need some rewording to make it so.
 >>>>
 >>>> I take it that you and Ben have agreed that the example 
description does
 >>>> not necessarily need normative language as the description of 
this key
 >>>> derivation procedure is meant as an example how the authorization 
server
 >>>> and the resource server can securely agree on a shared secret to 
be used
 >>>> between the client and the resource server.
 >>
 >> This still confuses me. IIUC preferred serialization and 
deterministic
 >> encoding are *optional* in CBOR. The text hear seems to require it,
 >> but doesn't use normative language to do so.
 >>
 >> If these are required for things to work then you make a normative
 >> statement about it. E.g., "The "type" and "L" components MUST use 
the
 >> minimum length encoding."
 >>
 >> Or do you intend that some other (non-minimum-length) MAY be used? 
(In
 >> which case both sides would need a side agreement on what encoding 
is
 >> used.)
 >
 > The text here just gives an example how key derivation may be used by
 > the authorization server and the resource server to agree on a shared
 > secret (that is used to encrypt the traffic between the resource 
server
 > and the to-be-authorized client).
 >
 > To that regard, the text is not really normative. The only normative
 > language we need here would be to avoid security issues. Commenting 
on
 > the data representation here is to be understood as a suggestion to 
use,
 > e.g., preferred CBOR serialization according to 7049bis.
 >
 > [...]

 Sorry to be so dense, but I'm still not getting it.

 I take your point that this is only an example of a way to agree on a
 shared secret. But at the end of the day they indeed must somehow agree
 on a shared secret. *If* they use this technique then it will only work
 if they also agree on a consistent way to do the serialization and
 encoding that is otherwise not standardized. So they need a side
 agreement, which is not a good situation for a standardized protocol.

 At the very least it seems like you should highlight that some sort of
 out of band communication is required between the authorization and
 resource servers to 

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

[Paul Kyzivat]

Hi Olaf,

On 9/17/20 4:09 AM, Olaf Bergmann wrote:

Hi Paul,

Responding to you remaining comments please see inline.

Paul Kyzivat  writes:


* Also in section 3.3:

 All CBOR data types are encoded in CBOR using preferred serialization
 and deterministic encoding as specified in Section 4 of
 [I-D.ietf-cbor-7049bis].  This implies in particular that the "type"
 and "L" components use the minimum length encoding.  The content of
 the "access_token" field is treated as opaque data for the purpose of
 key derivation.

IIUC the type of serialization and encoding is a requirement. Will
need some rewording to make it so.


I take it that you and Ben have agreed that the example description does
not necessarily need normative language as the description of this key
derivation procedure is meant as an example how the authorization server
and the resource server can securely agree on a shared secret to be used
between the client and the resource server.


This still confuses me. IIUC preferred serialization and deterministic
encoding are *optional* in CBOR. The text hear seems to require it,
but doesn't use normative language to do so.

If these are required for things to work then you make a normative
statement about it. E.g., "The "type" and "L" components MUST use the
minimum length encoding."

Or do you intend that some other (non-minimum-length) MAY be used? (In
which case both sides would need a side agreement on what encoding is
used.)


The text here just gives an example how key derivation may be used by
the authorization server and the resource server to agree on a shared
secret (that is used to encrypt the traffic between the resource server
and the to-be-authorized client).

To that regard, the text is not really normative. The only normative
language we need here would be to avoid security issues. Commenting on
the data representation here is to be understood as a suggestion to use,
e.g., preferred CBOR serialization according to 7049bis.

[...]


Sorry to be so dense, but I'm still not getting it.

I take your point that this is only an example of a way to agree on a 
shared secret. But at the end of the day they indeed must somehow agree 
on a shared secret. *If* they use this technique then it will only work 
if they also agree on a consistent way to do the serialization and 
encoding that is otherwise not standardized. So they need a side 
agreement, which is not a good situation for a standardized protocol.


At the very least it seems like you should highlight that some sort of 
out of band communication is required between the authorization and 
resource servers to establish the shared secret or the algorithm to be 
used for deriving the shared secret.



OLD:

New access tokens issued by the authorization server are supposed to
replace previously issued access tokens for the respective client.

NEW:

New access tokens issued by the authorization server replace
previously issued access tokens for the respective client.


The above is still non-normative. Perhaps:

   New access tokens issued by the authorization server MUST replace
   previously issued access tokens for the respective client.


Following Section 5.8.1 of the framework document, this should be a
SHOULD (the text there reads as: "This specification RECOMMENDS that an
RS stores only one token per proof-of-possession key, meaning that an
additional token linked to the same key will overwrite any existing
token at the RS."

The text then would read as follows (changes are the new SHOULD and
"needs a common understanding" instead of "must have":

OLD:

According to
Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one
access token for each client.  New access tokens issued by the
authorization server replace previously issued access tokens for the
respective client.  The resource server therefore must have a common
understanding with the authorization server how access tokens are
ordered.  The authorization server may, e.g., specify a "cti" claim
for the access token (see Section 5.8.3 of
[I-D.ietf-ace-oauth-authz]) to employ a strict order.

NEW:

According to
Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one
access token for each client.  New access tokens issued by the
authorization server SHOULD replace previously issued access tokens for the
respective client.  The resource server therefore needs a common
understanding with the authorization server how access tokens are
ordered.  The authorization server may, e.g., specify a "cti" claim
for the access token (see Section 5.8.3 of
[I-D.ietf-ace-oauth-authz]) to employ a strict order.


That seems ok.

Thanks,
Paul

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

[Paul Kyzivat]

On 9/8/20 7:14 AM, Olaf Bergmann wrote:

Hi Paul,

I hope you are doing well. On request from Jim Schaad who acts as the
document shepherd, we have submitted draft-ietf-ace-dtls-authorize-13
including the changes proposed below. Please feel free to contact us if
you do not agree with these proposals.


Thanks for addressing my comments. For the most part the changes address 
my concerns. My lack of any deep understanding of the subject material 
limits the extent that I can comprehend if my concerns have been 
sufficiently addressed. Further comments inline.



Grüße
Olaf

Olaf Bergmann  writes:


Thank you very much for your review and the very useful suggestions
therein. Please find our comments inline. All issues that have not been
resolved in the prior discussion threads with Ben and Jim have been
addressed in the editor's copy of the draft.

Paul Kyzivat  writes:


I am the assigned Gen-ART reviewer for this draft. The General Area
1) MAJOR: Management of token storage in RS

There seems to be an expectation that when the client uploads an
access token that the RS will retain it until the client attempts to
establish a DTLS association. This seems to require some sort of
management of token lifetime in the RS. The only discussion I can find
of this issue is the following in section 7:

... A similar issue exists with the
unprotected authorization information endpoint where the resource
server needs to keep valid access tokens until their expiry.
Adversaries can fill up the constrained resource server's internal
storage for a very long time with interjected or otherwise retrieved
valid access tokens.

This seems to imply a normative requirement to keep tokens until their
expiry. But I find no supporting normative requirements about
this. And, this section only presents it as a DoS attack, rather than
a potential problem with valid usage.


There is no normative requirement to keep tokens until their expiry. A
resource server could dispose of a stored token at any time, forcing a
client to retrieve another access token for subsequent requests directed
to the respective resource server. The only requirement imposed on the
resource server is that it must not send data to the client if there is
no valid access token that authorizes this action (this is described in
Section 3.4).

Usually, a resource server implementation would keep the received access
tokens as long as it deems useful for the intended interaction with the
client, with the expiration time being an upper bound for the storage
time (see Section 3.4).


I think I understand. Discarding tokens while they are still in use 
would result in sub-optimal behavior (including potential thrashing). 
But this can be viewed as an optimization or quality of implementation 
issue.



ISTM that there is an implied requirement that the RS have the
capacity to store one access token for every PoP key of every
authorized client. If so, that ought to be stated. If not, then some
other way of bounding storage ought to be discussed.


The ACE framework already states in Section 5.8.1 that the "RS
MUST be prepared to store at least one access token for future use"
and "RECOMMENDS that an RS stores only one token per
proof-of-possession key". This is now re-iterated in this profile
as suggested:

NEW:

   A resource server MUST have the capacity to store one access token
   for every proof-of-possession key of every authorized client.


Sounds good.


Although a reasonable implementation
of this profile would try to provide storage for every PoP key of
every authorized client, this could easily get out of bounds with the
separate upload mechanism to the authz-info resource as pointed out in
the cited paragraph from the security considerations. This now has
been elaborated as follows:

OLD:

   A similar issue exists with the unprotected authorization
   information endpoint where the resource server needs to keep valid
   access tokens until their expiry. Adversaries can fill up the
   constrained resource server's internal storage for a very long time
   with interjected or otherwise retrieved valid access tokens.

NEW:

   A similar issue exists with the unprotected authorization
   information endpoint when the resource server needs to keep valid
   access tokens for a long time. Adversaries could fill up the
   constrained resource server's internal storage for a very long time
   with interjected or otherwise retrieved valid access tokens.  To
   mitigate against this, the resource server should set a time
   boundary until an access token that has not been used until then
   will be deleted.


Sounds good.


2) MAJOR: Missing normative language

I found several places where the text seems to suggest required
behavior but fails to do so using normative language:

* In section 3.3:

... Instead of
providing the keying material in the access token, the authorization
server includes the key identifier in

[Gen-art] Gen-ART Last Call review of draft-ietf-avtcore-cc-feedback-message-08

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-avtcore-cc-feedback-message-08
Reviewer: Paul Kyzivat
Review Date: 2020-09-16
IETF LC End Date: 2020-09-16
IESG Telechat date: ?

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


I noticed one nit (typo) in section 7:

   s/ecn-capaable-rtp/ecn-capable-rtp/

Beyond that I have one question/suggestion that I'm happy to have you 
consider or ignore as you see fit:


In the case of missing packets it seems that you have the opportunity to 
save some space by encoding a run of contiguous missing packets as a 
single packet metric block with L=0, using the remaining bits in the 
metric block to encode the number of missing packets. Whether that is an 
optimization worth the trouble to do is a question I can't answer.


Otherwise, IMO this draft is ready to go.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

[Paul Kyzivat]

Hi Ben,

Please find my comments inline.

On 7/27/20 3:10 PM, Benjamin Kaduk wrote:

Hi Paul,

Just a couple notes in addition to what Jim already mentioned.

On Sun, Jul 19, 2020 at 04:23:46PM -0400, Paul Kyzivat wrote:

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ace-dtls-authorize-12
Reviewer: Paul Kyzivat
Review Date: 2020-07-19
IETF LC End Date: 2020-07-20
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the
review.

General:

TBD

Issues:

Major: 2
Minor: 1
Nits:  1

1) MAJOR: Management of token storage in RS

There seems to be an expectation that when the client uploads an access
token that the RS will retain it until the client attempts to establish
a DTLS association. This seems to require some sort of management of
token lifetime in the RS. The only discussion I can find of this issue
is the following in section 7:

 ... A similar issue exists with the
 unprotected authorization information endpoint where the resource
 server needs to keep valid access tokens until their expiry.
 Adversaries can fill up the constrained resource server's internal
 storage for a very long time with interjected or otherwise retrieved
 valid access tokens.

This seems to imply a normative requirement to keep tokens until their
expiry. But I find no supporting normative requirements about this. And,
this section only presents it as a DoS attack, rather than a potential
problem with valid usage.

ISTM that there is an implied requirement that the RS have the capacity
to store one access token for every PoP key of every authorized client.
If so, that ought to be stated. If not, then some other way of bounding
storage ought to be discussed.

2) MAJOR: Missing normative language

I found several places where the text seems to suggest required behavior
but fails to do so using normative language:

* In section 3.3:

 ... Instead of
 providing the keying material in the access token, the authorization
 server includes the key identifier in the "kid" parameter, see
 Figure 7.  This key identifier enables the resource server to
 calculate the symmetric key used for the communication with the
 client using the key derivation key and a KDF to be defined by the
 application, for example HKDF-SHA-256.  The key identifier picked by
 the authorization server needs to be unique for each access token
 where a unique symmetric key is required.
 ...
 Use of a unique (per resource server) "kid" and the use of a key
 derivation IKM that is unique per authorization server/resource
 server pair as specified above will ensure that the derived key is
 not shared across multiple clients.

The uniqueness seems to be a requirement. Perhaps "needs to be unique"
should be "MUST be unique". (And something similar for the IKM.)

* Also in section 3.3:

 All CBOR data types are encoded in CBOR using preferred serialization
 and deterministic encoding as specified in Section 4 of
 [I-D.ietf-cbor-7049bis].  This implies in particular that the "type"
 and "L" components use the minimum length encoding.  The content of
 the "access_token" field is treated as opaque data for the purpose of
 key derivation.

IIUC the type of serialization and encoding is a requirement. Will need
some rewording to make it so.


Both this and the previous item are scoped by the following text:

The method for how the resource server determines the symmetric key
from an access token containing only a key identifier is application-
specific; the remainder of this section provides one example.

So it's not entirely clear that normative language is appropriate in the
discussion of the example behavior.


OK. That makes sense.


* In section 3.3.1:

 ... To
 be consistent with the recommendations in [RFC7252] a client is
 expected to offer at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8
 [RFC6655] to the resource server.

I think "is expected" should be "MUST".

* Also in section 3.3.1:

 ... This
 specification assumes that the access token is a PoP token as
 described in [I-D.ietf-ace-oauth-authz] unless specifically stated
 otherwise.

I think "assumes ... unless" should be "MUST ... unless".


My understanding is that this is just talking about the text in the
document itself.  But as far as I remember we always require PoP tokens, so
this could just be removed.


It gets simpler if you always require PoP tokens. Does it state that 
normatively somewhere?

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

[Paul Kyzivat]

Jim,

Sorry - I forgot to respond sooner.

Please see comments inline.

Thanks,
Paul

On 7/19/20 6:29 PM, Jim Schaad wrote:




-Original Message-
From: Paul Kyzivat 
Sent: Sunday, July 19, 2020 1:24 PM
To: draft-ietf-ace-dtls-authorize@ietf.org
Cc: General Area Review Team 
Subject: Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ace-dtls-authorize-12
Reviewer: Paul Kyzivat
Review Date: 2020-07-19
IETF LC End Date: 2020-07-20
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the

review.


General:

TBD

Issues:

Major: 2
Minor: 1
Nits:  1

1) MAJOR: Management of token storage in RS

There seems to be an expectation that when the client uploads an access

token

that the RS will retain it until the client attempts to establish a DTLS
association. This seems to require some sort of management of token

lifetime

in the RS. The only discussion I can find of this issue is the following

in section 7:


 ... A similar issue exists with the
 unprotected authorization information endpoint where the resource
 server needs to keep valid access tokens until their expiry.
 Adversaries can fill up the constrained resource server's internal
 storage for a very long time with interjected or otherwise retrieved
 valid access tokens.

This seems to imply a normative requirement to keep tokens until their

expiry.

But I find no supporting normative requirements about this. And, this

section

only presents it as a DoS attack, rather than a potential problem with

valid

usage.

ISTM that there is an implied requirement that the RS have the capacity to
store one access token for every PoP key of every authorized client.
If so, that ought to be stated. If not, then some other way of bounding

storage

ought to be discussed.


In section 5.8.1 of draft-ietf-ace-oauth-authz is the sentence "The RS MUST
be prepared to store at least one access token for future use."   When this
was put in, this is exactly what we were discussing.  There is no
requirement that an RS needs to store two access tokens for future use.  I
think this means that there is a strongly bounded requirement on storage.


When I read that, it seems that the stated requirement is to store one 
token *in total*, yet the context implies that it ought to be one token 
*per* client.


The procedures defined aren't going to work unless there is one per client.


Authors - It might be worthwhile to re-iterate this requirement in both of
the profile documents.



2) MAJOR: Missing normative language

I found several places where the text seems to suggest required behavior

but

fails to do so using normative language:

* In section 3.3:

 ... Instead of
 providing the keying material in the access token, the authorization
 server includes the key identifier in the "kid" parameter, see
 Figure 7.  This key identifier enables the resource server to
 calculate the symmetric key used for the communication with the
 client using the key derivation key and a KDF to be defined by the
 application, for example HKDF-SHA-256.  The key identifier picked by
 the authorization server needs to be unique for each access token
 where a unique symmetric key is required.
 ...
 Use of a unique (per resource server) "kid" and the use of a key
 derivation IKM that is unique per authorization server/resource
 server pair as specified above will ensure that the derived key is
 not shared across multiple clients.

The uniqueness seems to be a requirement. Perhaps "needs to be unique"
should be "MUST be unique". (And something similar for the IKM.)

* Also in section 3.3:

 All CBOR data types are encoded in CBOR using preferred serialization
 and deterministic encoding as specified in Section 4 of
 [I-D.ietf-cbor-7049bis].  This implies in particular that the "type"
 and "L" components use the minimum length encoding.  The content of
 the "access_token" field is treated as opaque data for the purpose of
 key derivation.

IIUC the type of serialization and encoding is a requirement. Will need

some

rewording to make it so.

* In section 3.3.1:

 ... To
 be consistent with the recommendations in [RFC7252] a client is
 expected to offer at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8
 [RFC6655] to the resource server.

I think "is expected" should be "MUST".


The rule would be MUST implement not MUST offer.  A client co

Re: [Gen-art] Genart last call review of draft-ietf-mmusic-msrp-usage-data-channel-21

[Paul Kyzivat]

Brian,

On 7/12/20 6:40 PM, Brian Carpenter via Datatracker wrote:


Nits:
-


4.1.  MSRP URI



 transport  /= "dc"


I see that RFC7977 takes a slightly different approach to updating the ABNF:


 transport  =  "tcp" / "ws" / 1*ALPHANUM


The advantage of listing out

   transport  =  "tcp" / "ws" / "dc" / 1*ALPHANUM

would be that the reader sees the full list.


While it might be nice to see the full list, it can't be counted on to 
remain the full list. If each update did this, then every draft that 
updates the list should formally Update every other document that 
updates the list.


The *point* of /= in abnf is that it decouples the particular addition 
from all others.


This sort of thing should really have an IANA registry. But often the 
expectation is that changes aren't made often enough to justify that. 
Lacking that, IMO /= is the preferred way to go.


Just kibitzing,
Paul


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

[Gen-art] Gen-ART Telechat review of draft-hodges-webauthn-registries-07

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-hodges-webauthn-registries-07
Reviewer: Paul Kyzivat
Review Date: 2020-05-15
IETF LC End Date: 2020-04-29
IESG Telechat date: 2020-05-19

Summary:

This draft is ready for publication as an Informational RFC.

General:

Thanks for addressing my Last Call comments.

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

[Gen-art] Gen-ART Last Call review of draft-hodges-webauthn-registries-05

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-hodges-webauthn-registries-05
Reviewer: Paul Kyzivat
Review Date: 2020-04-13
IETF LC End Date: 2020-04-29
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issue: Additional registry fields defined by experts

Section 2 specifies that experts are allowed to define additional fields 
to be collected in the registry. It isn't clear to me how this is 
intended to work, or could work. Some concerns that come to mind are:


* Is this on a per-registration basis? Once a new field has been 
requested, must that field be retroactively added to all preexisting 
registrations and all future entries in the registry?


* How will someone who is consulting the registry discover the meaning 
of the new fields?


* Does IANA have procedures to handle this sort of modification to the 
registries?


ISTM that the "Notes" field can already be used for extra 
format-specific data. Adding additional fields that apply to all entries 
would be better served by a formal revision to the registry.


If you really want to preserve this ability for experts to add fields 
then you need to specify in great detail how this is to work, and verify 
with IANA that it is feasible.


Otherwise the document seems ready to go.


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

[Gen-art] Gen-ART Telechat review of draft-spinosa-urn-lex-13

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-spinosa-urn-lex-13
Reviewer: Paul Kyzivat
Review Date: 2020-02-18
IETF LC End Date: 2017-09-14
IESG Telechat date: 2020-02-18

Summary:

This draft is on the right track but has open issues, described in the 
review.


General:

I did a Last Call review on version -11 three years ago. Given the 
amount of time that has passed, and the extent of changes, I'm surprised 
that there wasn't another Last Call prior to scheduling the Telechat!


I had difficulty classifying the severity of the issues. Individually 
most of them may be minor, but in aggregate they imply that IMO the 
document still requires a lot of work.


Issues:

Major: 1
Minor: 15
Nits:  2

1) MAJOR: Structure & ordering of the document

In spite of my earlier experience with this document I found it very 
difficult to read in a single front to back pass. In retrospect, I think 
it would have made much more sense if I had read Section 7 first.


A major problem was that I got the impression it was a goal that an 
arbitrary legal document reader should be able to construct a valid LEX 
URN to that document from information readily available to him, 
typically in the body of the document itself. Yet I found many places 
where terms must be chosen in ways that are not deterministic.


In retrospect, especially after reading Section 7, I tentatively reached 
the conclusion that my first impression was wrong. Instead, it appears 
that an expert (probably within the Jurisdiction Registrar) must choose 
the LEX URN representation(s) for the legal document. This can then be 
incorporated into the document and/or some metadata about the document 
that is potentially available to those who later have need to reference 
the document.


I'm not sure I'm right about this. How this is intended to work should 
be spelled out early in the document. I suggest moving Section 7 early 
in the document, and elaborating it to cover this.


Section 3 (Registration Template) is very hard to follow when reading 
the document front to back. Understanding it requires information that 
hasn't yet been provided. In particular, section 3.1 gives an overview 
of the syntax of 'jurisdiction', but not for 'local-name'. It then goes 
on to present examples of full lex URNs.


I suggest that it would be helpful to move sections 2 and 3 to a 
position later in the document - somewhere after section 5. Near or in 
Section 11 (IANA considerations) would be a good place.


2) MINOR(?): Encoding national characters and diacritic signs

Section 4.4 has guidelines for encoding national characters and 
diacritic signs for compatibility with DNS. I'm not qualified to 
evaluate whether these guidelines are in agreement with best practice 
for DNS. If it hasn't already, this document should be reviewed and 
approved by relevant experts.


3) MINOR: Section 5 (Specific Syntax and Features of the LEX Identifier):

It isn't clear to me what specific components of the syntax are being 
addressed in this section. I *think* these apply to 'jurisdiction-unit'. 
Can you please make this clear?


I'm concerned that most of the specifications here are only RECOMMENDED. 
Who makes the decision whether to follow these rules, and how can it be 
assured that they are followed consistently? It is a problem if a 
consistent approach to these isn't followed. For instance, when a reader 
of a document is trying to create a LEX URN manually from a reference in 
the text, how will he know whether to follow the recommendation or not?


(However, if the expectation is that an expert constructs the URN then 
this is less of a concern.)


4) MINOR: Annexes and Sub-Annexes:

When I read Section 6.4 the first time I was confused about the 
significance of multiple annexes in a name - whether this refers to peer 
annexes of the main document, or to a sub-annex of an annex. I later 
learned (in section 7) that it means sub-annexes. This is an example of 
why the doc needs reordering. Or else spell this out in this section.


5) MINOR: "original" as document version

Both sections 6.6 and C1.2 discuss using "original" as the document 
version to identify the original version of the document. But this is 
allowed to be written in different languages. However it doesn't specify 
how the language for this is chosen. How can someone constructing the 
URN from a textual reference decide which spelling to use? More 
specification is needed.


6) MINOR: Manifestation:

The following in section 6.7:

   Note that the value "all" can be expressed by language-dependent
   equivalents. To indicate 

[Gen-art] Gen-ART Telechat review of draft-ietf-dots-architecture-16

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-dots-architecture-16
Reviewer: Paul Kyzivat
Review Date: 2020-01-31
IETF LC End Date: 2019-01-31
IESG Telechat date: 2020-02-04

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Thank you for fixing the issues I reported in the last call review. Only 
one nit remains. IdNits reports:


== The document seems to lack the recommended RFC 2119 boilerplate, even 
if it appears to use RFC 2119 keywords -- however, there's a paragraph 
with a matching beginning. Boilerplate error? (The document does seem to 
have the reference to RFC 2119 which the ID-Checklist requires).


There is one other reported nit (obsolete reference). It is bogus 
because it is intended.


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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dots-architecture-15

[Paul Kyzivat]

Reddy,

Your proposed changes sound good.

Thanks,
Paul

On 1/27/20 7:33 AM, tirumal reddy wrote:
On Mon, 27 Jan 2020 at 15:36, tirumal reddy <mailto:kond...@gmail.com>> wrote:


Hi Paul,

Thanks for the review. Please see inline

On Thu, 23 Jan 2020 at 21:09, Paul Kyzivat mailto:pkyzi...@alum.mit.edu>> wrote:

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dots-architecture-15
    Reviewer: Paul Kyzivat
Review Date: 2020-01-23
IETF LC End Date: 2020-01-27
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described
in the
review.

General:

This is a very well written document! Even though I lack any
knowledge
of the subject domain I was generally able to understand it.

I had trouble classifying some of my issues below. I wanted to
make them
be questions. But in a review such as this it makes more sense
to state
them as issues of clarity in the text, since the reader should
ideally
not be left with questions.

Issues:

Major: 0
Minor: 5
Nits:  0

1) MINOR: Resource Ownership:

The 2nd paragraph of section 2.2.2 stresses that it is important
for a
DOTS Server to verify that the DOTS Client owns the resources
over which
it is requesting mitigation.

There seems to be quite a lot hiding behind that requirement. In
particular, how is the server supposed to be in a position to do
that
verification? This seems to require that the server have access to
ownership information. While that may be easy in some cases
(e.g., when
the server is operated by the ISP that assigned the resources to
the
client), in other cases it could be hard. I'd like to see more
discussion of this.


The exact mechanism to validate the resources owned by the DOTS
client domain is deployment-specific. I can add the following
example mechanisms to address your comment:

The exact mechanism for the DOTS servers to validate that the resources 
are within the
scope of the DOTS client domain is deployment-specific.  For example,
if the DOTS client domain leverages the DDoS mitigation service of
its Internet Transit Provider (ITP), it knows the prefixes assigned
to the DOTS client domain.  If the DDoS Mitigation is offered by a
third party DDoS mitigation service provider, and if the resources
are not owned by the requesting domain, it can impose penalties for
violating the service level agreement.  Alternatively, the DDoS
mitigation service provider and the DOTS client domain can opt to use
the identifier validation challenges discussed in [RFC8555] and
[I-D.ietf-acme-ip] to identify whether the DOTS client domain
actually controls the resources. Note that the challenges for
validating control of resources must be performed when no attack
traffic is present.


I have modified the above text as follows for better clarity:

The exact mechanism for the DOTS servers to validate that the resources are 
within the
scope of the DOTS client domain is deployment-specific.  For example,
if the DOTS client domain leverages the DDoS mitigation service of
its Internet Transit Provider (ITP), the ITP knows the prefixes
assigned to the DOTS client domain.  However, if the DDoS Mitigation
is offered by a third party DDoS mitigation service provider, it does
not know the resources owned by the DOTS client domain.  The DDoS
mitigation service provider and the DOTS client domain can opt to use
the identifier validation challenges discussed in [RFC8555] and
[I-D.ietf-acme-ip] to identify whether the DOTS client domain
actually controls the resources.  The challenges for validating
control of resources must be performed when no attack traffic is
present and works only for "dns" and "ip" identifier types.  Further,
if the DOTS client lies about the resources owned by the DOTS client
domain, the DDoS mitigation service provider can impose penalties for
violating the service level agreement.

-Tiru


2) MINOR: Scope and lifetime of sessions:

Section 3.1 states that a session can be a signal channel
session or a
data channel session or both. I'm confused about the
relationship

[Gen-art] Gen-ART Last Call review of draft-ietf-dots-architecture-15

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dots-architecture-15
Reviewer: Paul Kyzivat
Review Date: 2020-01-23
IETF LC End Date: 2020-01-27
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


General:

This is a very well written document! Even though I lack any knowledge 
of the subject domain I was generally able to understand it.


I had trouble classifying some of my issues below. I wanted to make them 
be questions. But in a review such as this it makes more sense to state 
them as issues of clarity in the text, since the reader should ideally 
not be left with questions.


Issues:

Major: 0
Minor: 5
Nits:  0

1) MINOR: Resource Ownership:

The 2nd paragraph of section 2.2.2 stresses that it is important for a 
DOTS Server to verify that the DOTS Client owns the resources over which 
it is requesting mitigation.


There seems to be quite a lot hiding behind that requirement. In 
particular, how is the server supposed to be in a position to do that 
verification? This seems to require that the server have access to 
ownership information. While that may be easy in some cases (e.g., when 
the server is operated by the ISP that assigned the resources to the 
client), in other cases it could be hard. I'd like to see more 
discussion of this.


2) MINOR: Scope and lifetime of sessions:

Section 3.1 states that a session can be a signal channel session or a 
data channel session or both. I'm confused about the relationships here.


If a session can consist of both, how are they related? Is there some 
state that ties them together?


Can a channel survive the loss and reestablishment of a TCP connection? 
Or does the creation of a new connection create a new channel?


What is the act that creates a new channel, and what destroys one?

I'd like to see some more text explaining this.

3) MINOR: Feedback for recursive mitigation:

Section 3.2.3 says:

   ... To maximize
   mitigation visibility to the DOTS client, however, the recursing
   domain SHOULD provide recursed mitigation feedback in signals
   reporting on mitigation status to the DOTS client.  For example, the
   recursing domain's mitigator should incorporate into mitigation
   status messages available metrics such as dropped packet or byte
   counts from the recursed mitigation.

This seems to imply that feedback from So to Cn is routed to Mn for 
merging with Mn's feedback. That seems to violate the architecture. Can 
the feedback from So be routed by Gn back to Cc?


Can this be clarified?

4) MINOR: Security of recursive mitigation:

The last paragraph of section 3.2.3 says:

   Deployment of recursive signaling may result in traffic redirection,
   examination and mitigation extending beyond the initial bilateral
   relationship between DOTS client and DOTS server.  As such, client
   control over the network path of mitigated traffic may be reduced.
   DOTS client operators should be aware of any privacy concerns, and
   work with DOTS server operators employing recursive signaling to
   ensure shared sensitive material is suitably protected.

This sounds like hand waving. Am I right in thinking this is talking 
about incorporating the details of recursion in the service level agreement?


5) MINOR: Normative references:

I was surprised by the scarcity of normative references. I went looking 
for MUSTs referencing RFCs and found three: RFC8612 (DOTS Requirements), 
and RFCs 5389 and 7350 (STUN related). Please consider making these 
normative references.


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

[Gen-art] Gen-ART Last Call review of draft-boydseda-ipfix-psamp-bulk-data-yang-model-02

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-boydseda-ipfix-psamp-bulk-data-yang-model-02
Reviewer: Paul Kyzivat
Review Date: 2019-12-16
IETF LC End Date: 2019-12-23
IESG Telechat date: (if known)

Summary:

This draft is on the right track but has open issues, described in the 
review.


Disclaimer:

I didn't review the actual YANG content in any meaningful way as I'm not 
fluent in it and assume the Yang Doctor will do that.


Issues:

Major: 0
Minor: 5
Nits:  1

1) MINOR:

This document will obsolete RFC6728 but it isn't evident to me whether 
it is backward compatible with the predecessor. Is there a plan for 
migration, or coexistence? It seems like this needs some discussion.


2) MINOR:

Section 1.1 says it contains a historical timeline. But the events in 
this timeline are not in chronological order. It would be easier to 
understand if you actually enumerated the events in chronological order.


3) MINOR:

Section 3 says that the document describes reference models based on 
RFC6728. But this document obsoletes RFC6728. This seems to set up a 
situation where there is a dependency on an obsoleted document. I 
presume this is not the intent.


I'm guessing that the models in this document have been derived from 
those in RFC6728, presumably in a way that is backward compatible in 
some sense. Can the relationship be described more precisely?


4) MINOR:

In sections 4.4.4 and 4.5.4 the file is identified by a URI. Are there 
limitations on the sort of URI this may be?


It seems to me this should be constrained in some way.

5) MINOR:

Some of the IP addresses and DNS names used in examples are not suitable 
for use in documentation:


In Appendix A:

- The IP address 192.100.2.1 used is not one of those reserved for 
documentation.


- The DNS names "proxy1.sys.com", "collect1.sys.com", "coll-1.ex.net", 
"coll-2.ex.net" are not among those reserved for documentation.


6) NIT:

In section 5 there are two uses of the word "proportions" where I think 
you mean "portions":


   ... As Exporters and Collectors implement different functions, the
   corresponding proportions of the model are conditional on the
   following features:

and:

   ... Therefore,
   the corresponding proportions of the model are conditional on the
   following feature:

(THE END)

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

[Gen-art] Last Call review of draft-ietf-dmm-distributed-mobility-anchoring-13

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dmm-distributed-mobility-anchoring-13
Reviewer: Paul Kyzivat
Review Date: 2019-10-12
IETF LC End Date: 2019-10-14
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


General:

I found that I lack the subject matter expertise to meaningfully review 
this document. I read it carefully, along with one of the references. 
But it appeared that I would need to internalize quite a number of other 
references before it would be possible to really follow this.


I did review it for form - the document is well written. (Most documents 
that I review have at least a few problems with form.)


IdNits returns a couple of outdated references that should be cleaned up:

  == Outdated reference: A later version (-18) exists of
 draft-ietf-dmm-ondemand-mobility-17

  == Outdated reference: A later version (-02) exists of
 draft-ietf-rtgwg-atn-bgp-01

I have no other comments.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-pce-stateful-hpce-11

[Paul Kyzivat]

Dhruv,

Thanks for addressing my concerns.

Regarding (C-E / E-C) and (EC-EP / EP-EC): I recognized that there was 
more to it, and that using "E" for P-PCE in this document would be 
problematic. I guess this is just a conflict between documents that has 
to be tolerated.


And it hadn't dawned on me that the linking issues were artifacts of the 
automatic generation mechanism.


Thanks,
Paul

On 8/21/19 7:26 AM, Dhruv Dhody wrote:

Hi Paul,

Thanks for your review, please see inline...

On Tue, Aug 20, 2019 at 9:58 PM Paul Kyzivat  wrote:


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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-pce-stateful-hpce-11
Reviewer: Paul Kyzivat
Review Date: 2019-08-20
IETF LC End Date: 2019-08-28
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should
be fixed before publication.

Issues:

Major: 0
Minor: 0
Nits:  7

1) NIT: No glossary

Since I am not familiar with the subject domain, when I started reading
this document I felt I was lost among the acronyms. While you are good
at defining these at first use, I couldn't keep them all in mind as I
read. I had to create my own glossary to support me while reading. I
would really appreciate having a glossary in the document.



Added.


2) NIT: Inconsistent terminology

In section 3 two pairs of terms are introduced: (C-E / E-C) and (EC-EP /
EP-EC). IIUC in the first pair "E" stands for "PCE" while in the second
pair "E" seems to stand for "Extended", while "P" stands for PCE. I
found this very confusing. I think it would be better to allow "E" to
mean the same thing in both pairs. Perhaps you could use "X" to stand
for "eXtended". Then there would be clear parallels:

C -> XC
E -> XE

Please consider doing something relieve the confusion.



The use of notation C-E and E-C is as per RFC 8231
https://tools.ietf.org/html/rfc8231#section-4 where PCC to PCE is
(C-E) and PCE to PCC is (E-C). In this document we wanted to represent
messages between C-PCE (child PCE) to P-PCE (parent PCE) and we used
EC-EP for it and the reverse EP-EC for P-PCE to C-PCE communication.

This was discussed during shepherd review as well (as we were using CE
and PE before but that was causing confusion because of the well known
meaning of those terms in routing).

I would like to keep the existing notations that has WG support.


3) NIT: Badly formed sentence

I can't parse this sentence in section 3.1:

 Procedures as described in [RFC6805] are applied and where the
 ingress C-PCE (Child PCE), triggers a path computation request for
 the LER in the domain where the LSP originates, sends a request to
 the P-PCE.

Can you rephrase it?



Updated.


4) NIT: Unclear text

In section 3.1 are steps A/B/C/D to be added at the *end*, after step
11? It would help to be explicit.

In step (C) of section 3.2, can you please be explicit about which node
is to execute these elements? I think it is PCE5, but I'm not certain.



Updated.


5) NIT: Unlinked references

Some RFC references (e.g. [RFC8051] and [RFC8231] in section 1.1, and
[RFC8232] in section 3.1) are not linked in the HTML version. I suggest
a global search for all such unlinked references in the source.



The HTML version of the draft is automatically generated from the text
version. The `rfcmarkup` is used to render the HTML of the I-D/sRFCs.
Specifically, rfcmarkup produces the final HTML using heuristics from
the source TXT and this is beyond the control of the authors.


6) NIT: Bad reference link

In the following from section 3.1:

 Steps 1 to 11 are exactly as described in section 4.6.2 (Hierarchical
 PCE End-to-End Path Computation Procedure) of [RFC6805], the

the "section 4.6.2" is linked to the non-existent section 4.6.2 of
*this* document rather than RFC6805.

A similar link to the same spot in section 3.2 is ok.



I arranged the words so that rfcmarkup works.


7) NIT: Outdated references:

IdNits reports outdated references. I trust these will be updated in due
course.



Updated.

Working Copy: 
https://github.com/dhruvdhody/ietf/blob/master/draft-ietf-pce-stateful-hpce-12.txt
Diff: 
https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-stateful-hpce-11=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-hpce-12.txt

Thanks!
Dhruv



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

[Gen-art] Gen-ART Last Call review of draft-ietf-pce-stateful-hpce-11

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-pce-stateful-hpce-11
Reviewer: Paul Kyzivat
Review Date: 2019-08-20
IETF LC End Date: 2019-08-28
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Issues:

Major: 0
Minor: 0
Nits:  7

1) NIT: No glossary

Since I am not familiar with the subject domain, when I started reading 
this document I felt I was lost among the acronyms. While you are good 
at defining these at first use, I couldn't keep them all in mind as I 
read. I had to create my own glossary to support me while reading. I 
would really appreciate having a glossary in the document.


2) NIT: Inconsistent terminology

In section 3 two pairs of terms are introduced: (C-E / E-C) and (EC-EP / 
EP-EC). IIUC in the first pair "E" stands for "PCE" while in the second 
pair "E" seems to stand for "Extended", while "P" stands for PCE. I 
found this very confusing. I think it would be better to allow "E" to 
mean the same thing in both pairs. Perhaps you could use "X" to stand 
for "eXtended". Then there would be clear parallels:


C -> XC
E -> XE

Please consider doing something relieve the confusion.

3) NIT: Badly formed sentence

I can't parse this sentence in section 3.1:

   Procedures as described in [RFC6805] are applied and where the
   ingress C-PCE (Child PCE), triggers a path computation request for
   the LER in the domain where the LSP originates, sends a request to
   the P-PCE.

Can you rephrase it?

4) NIT: Unclear text

In section 3.1 are steps A/B/C/D to be added at the *end*, after step 
11? It would help to be explicit.


In step (C) of section 3.2, can you please be explicit about which node 
is to execute these elements? I think it is PCE5, but I'm not certain.


5) NIT: Unlinked references

Some RFC references (e.g. [RFC8051] and [RFC8231] in section 1.1, and 
[RFC8232] in section 3.1) are not linked in the HTML version. I suggest 
a global search for all such unlinked references in the source.


6) NIT: Bad reference link

In the following from section 3.1:

   Steps 1 to 11 are exactly as described in section 4.6.2 (Hierarchical
   PCE End-to-End Path Computation Procedure) of [RFC6805], the

the "section 4.6.2" is linked to the non-existent section 4.6.2 of 
*this* document rather than RFC6805.


A similar link to the same spot in section 3.2 is ok.

7) NIT: Outdated references:

IdNits reports outdated references. I trust these will be updated in due 
course.


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

[Gen-art] Gen-ART Last Call review of draft-ietf-idr-bgp-extended-messages-33 UPDATED

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-idr-bgp-extended-messages-33
Reviewer: Paul Kyzivat
Review Date: 2019-07-09
IETF LC End Date: 2019-07-18
IESG Telechat date: ?

Summary:

[This is a revision to the first version I sent out, that had a number 
of mistakes.]


This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Issues:

Major: 0
Minor: 0
Nits:  2

1) NIT:

Section 4 says:

   If a BGP message with a Length greater than 4,096 octets is received
   by a BGP listener who has not advertised the Extended Message
   Capability, the listener MUST treat this as a malformed message, and
   MUST generate a NOTIFICATION with the Error Subcode set to Bad
   Message Length (see [RFC4271] Sec 6.1).

The "MUST" seems inappropriate because this is not new normative 
behavior. Rather it is the existing behavior, as it states. This is 
already covered by the 2nd paragraph of Section 5, so why does it need 
to be covered here as well?


2) NIT:

Reading the last two security considerations in section 8 leaves me 
concerned. I was expecting to see some further discussion of how these 
issues can be mitigated, or why it is OK that they are not.


Otherwise this short document seems to be in good shape.


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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-idr-bgp-extended-messages-33

[Paul Kyzivat]

Randy,

On 7/4/19 2:28 PM, Randy Bush wrote:

paul,

thanks for the review.  appreciated.


The Abstract and Introduction are written in the abstract, implying
(to me) that the requirements here are intended to be broadly
applicable for the stated purposes, over an extended period of
time. On the other hand, I get the impression that requirements in
this document are actually more focused, intended for use in a
one-time selection of an Internet video codec to be a successor to
HEVC and VP9.

If this document is intended only for one-time use then it isn't
evident to me why it ever needs to become an RFC.


it is intended to change bgp forever.


Oops!!! I'm sorry. This was a cut/paste error from another review. 
Please ignore the entire Summary section. I will resend this review.



1) NIT:

Section 4 says:

If a BGP message with a Length greater than 4,096 octets is received
by a BGP listener who has not advertised the Extended Message
Capability, the listener MUST treat this as a malformed message, and
MUST generate a NOTIFICATION with the Error Subcode set to Bad
Message Length (see [RFC4271] Sec 6.1).

The "MUST" seems inappropriate because this is not new normative
behavior. Rather it is the existing behavior, at it states. This is
already covered by the 2nd paragraph of Section 5, so why does it need
to be covered here as well?


the authors have received instruction both ways on this one.  so is it
ok if we let the routing ad, alvaro, call it.  i have no dog in this
fight.


Fair enough.


2) NIT:

Reading the last two security considerations in section 8 leaves me
concerned. I was expecting to see some further discussion of how these
issues can be mitigated, or why it is OK that they are not.


i am not sure if there are mitigations.

i believe that the hope is that actual message lengths are well below 4k
today, and this will deploy before they really grow.  e.g. we do not
expect bgpsec in more then five years, more likely ten.


I didn't have a good idea what to expect in the way of mitigations, but 
the consequences seemed relatively dire.


Perhaps you could put in some of this explanation and stress the need 
for support to be deployed widely before it is needed.


Thanks,
Paul

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

[Gen-art] Gen-ART Last Call review of draft-ietf-idr-bgp-extended-messages-33

[Paul Kyzivat]

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

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-idr-bgp-extended-messages-33
Reviewer: Paul Kyzivat
Review Date: 2019-07-09
IETF LC End Date: 2019-07-18
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Disclaimer:

I have very little understanding of the subject matter of this document, 
so this review is limited to the form and structure of the document.


General:

The Abstract and Introduction are written in the abstract, implying (to 
me) that the requirements here are intended to be broadly applicable for 
the stated purposes, over an extended period of time. On the other hand, 
I get the impression that requirements in this document are actually 
more focused, intended for use in a one-time selection of an Internet 
video codec to be a successor to HEVC and VP9.


If this document is intended only for one-time use then it isn't evident 
to me why it ever needs to become an RFC.


Issues:

Major: 0
Minor: 0
Nits:  2

1) NIT:

Section 4 says:

   If a BGP message with a Length greater than 4,096 octets is received
   by a BGP listener who has not advertised the Extended Message
   Capability, the listener MUST treat this as a malformed message, and
   MUST generate a NOTIFICATION with the Error Subcode set to Bad
   Message Length (see [RFC4271] Sec 6.1).

The "MUST" seems inappropriate because this is not new normative 
behavior. Rather it is the existing behavior, at it states. This is 
already covered by the 2nd paragraph of Section 5, so why does it need 
to be covered here as well?


2) NIT:

Reading the last two security considerations in section 8 leaves me 
concerned. I was expecting to see some further discussion of how these 
issues can be mitigated, or why it is OK that they are not.


Otherwise this short document seems to be in good shape.


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

[Gen-art] Gen-ART Last Call review of draft-ietf-netvc-requirements-09

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-netvc-requirements-09
Reviewer: Paul Kyzivat
Review Date: 2019-05-29
IETF LC End Date: 2019-06-04
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Disclaimer:

I have very little understanding of the subject matter of this document, 
so this review is limited to the form and structure of the document.


General:

The Abstract and Introduction are written in the abstract, implying (to 
me) that the requirements here are intended to be broadly applicable for 
the stated purposes, over an extended period of time. On the other hand, 
I get the impression that requirements in this document are actually 
more focused, intended for use in a one-time selection of an Internet 
video codec to be a successor to HEVC and VP9.


If this document is intended only for one-time use then it isn't evident 
to me why it ever needs to become an RFC.


Issues:

Major: 0
Minor: 2
Nits:  4

1) Minor:

In section 1, there is no indication here of where these requirements 
came from, and why they should be considered to be the proper 
requirements for the purpose. I think that is important to state.


2) Minor:

In the following passage in section 3.2.2:

  The real-time encoder tools subset should provide
  meaningful improvement in compression efficiency at reasonable
  complexity of hardware and software encoder implementations as
  compared to current real-time implementations of state-of-the-art
  video compression technologies such as HEVC/H.265 and VP9.

the use of "current" is problematic in a document that will become an 
RFC, because the implied time frame may not be apparent to a reader of 
the RFC.


3) NIT:

Section 4.2 references the NETVC WG. Referencing an IETF work group is 
rarely appropriate in an RFC. This adds to my inference that this 
document is intended as one-time input to an evaluation to be carried 
out by this WG. That again brings into question whether this document 
should be intended to progress to RFC.


4) NIT:

I don't see the point of section 6. These aren't *conclusions*. This is 
more like a summary, and seems redundant with section 1.


5) NIT:

In section 8, references [6] and [14] are solely URLs. According to 
RFC7322 this is not allowed:


   Note that URIs may not be the sole information provided for a
   reference entry.

And while [8] has some description, it is too cryptic to understand what 
it is about without first following the link. Nor is its significance 
explained at the point of reference. (If I understand correctly, the 
point is to identify requirements for upload to Utube to be a significant.)


These references need to be beefed up to describe what is being referenced.

6) NIT:

I find it strange that Appendices A & B are not referenced in the body 
of the document, except for the table of contents.


In my experience most documents that have lists of terminology put them 
in a section early in the body of the document, so they will be seen 
before the terminology is used in the document.


THE END

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-iasa2-rfc4071bis-08

[Paul Kyzivat]

On 4/10/19 1:23 PM, Joseph Lorenzo Hall wrote:

Thanks much for your review... responses inline:

On Wed, Mar 13, 2019 at 5:01 PM Paul Kyzivat <mailto:pkyzi...@alum.mit.edu>> wrote:


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by the
IESG for the IETF Chair. Please treat these comments just like any
other
last call comments. For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-iasa2-rfc4071bis-08
    Reviewer: Paul Kyzivat
Review Date: 2019-03-13
IETF LC End Date: 2019-03-18
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should
be fixed before publication.

Issues:

Major: 0
Minor: 1
Nits:  3


I only see three nits below... did the minor one get lost?


My mistake. No Minor issues.

Thanks,
Paul

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

[Gen-art] Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
Reviewer: Paul Kyzivat
Review Date: 2019-01-23
IETF LC End Date: 2019-01-31
IESG Telechat date: 2019-04-09

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issues:

Major: 0
Minor: 1
Nits:  0

1) MINOR (maybe MAJOR):

Section 3.2 includes the following:

When a node does not support the Availability TLV, it SHOULD
generate PathErr message with the error code "Extended Class-Type
Error" and the error value "Class-Type mismatch" (see [RFC2205]).

This seems to be placing a normative requirement on implementations of 
RSVP that *don't* support this document. That is clearly impossible.


I am guessing that this is the standard normative behavior for 
implementations of RSVP that encounter a TLV type they don't understand. 
(I tried to find this in RFC2205 but failed.) If so, then this section 
should be reworded to indicate that this is the behavior that will occur 
rather than a new normative requirement.


OTOH, if this is not the standard handling for unknown TLV types then 
you need to rethink this.


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

[Gen-art] Gen-ART Last Call review of draft-ietf-iasa2-rfc4071bis-08

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-iasa2-rfc4071bis-08
Reviewer: Paul Kyzivat
Review Date: 2019-03-13
IETF LC End Date: 2019-03-18
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Issues:

Major: 0
Minor: 1
Nits:  3

1) NIT:

In the following in section 4.8:

   Any major change to the IASA 2.0 arrangements shall require a similar
   level of community consensus and deliberation and ...

It isn't clear to me what "similar" refers to.

2) NIT:

The following passage from section 6.10:

   Board decisions may be made either by vote communicated in a meeting
   of the Board (including telephonic and video), or via an asynchronous
   written (including electronic) process.  Absentee voting and voting
   by proxy shall not be permitted.

confuses me. Absentee voting isn't permitted, but asynchronous written 
voting is permitted. What is the distinction?


3) NIT:

Regarding the following from section 6.11:

   As a result, an Interim Board was formed on
   a temporary basis until the first full board was constituted.
   ...
   o  One ISOC trustee, selected by the ISOC Board of Trustees

This is written in the past tense, so I guess it has already happened. 
But the "individuals" are only identified in the abstract. I would think 
this should identify specific individuals. Perhaps that isn't necessary 
for the ex officio members since they can be resolved to a particular 
individual at any time. But that isn't so for the ISOC trustee.



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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13

[Paul Kyzivat]

Amy,

On 1/24/19 11:00 AM, Yemin (Amy) wrote:

Hi Paul,

Thanks for the comments.
Regarding nits: we followed the usual way, just show the value field. But I 
don't mind to make a complete figure.


In most places that define TLVs I see the type and length included in 
the figure. If the documents related to yours don't do that, and you 
want to follow that style, then please at least indicate in the text 
that you are only showing the value part, and explicitly call out the 
type and length.



Minor issue: you're quiet right. It should be a MUST here.


You didn't mention my question:


   When a node does not support the Availability TLV, it SHOULD
   generate PathErr message with the error code "Extended Class-Type
   Error" and the error value "Class-Type mismatch" (see [RFC2205]).

I have a question about this: Is this the default behavior that is prescribed 
for any unknown TLV type
found in an Ethernet SENDER_TSPEC object, or is this behavior specific to the 
"availability" TLV?


You can't mandate new behavior for things that don't implement this 
specification. If this is already the mandated behavior for an unknown 
TLV type then you technically don't need to say anything. If you want 
to, then best to reference the place that mandated this behavior. (I 
didn't find it in RFC2205.) And you could quote what that behavior is, 
or paraphrase it in a non-normative way.


Thanks,
Paul


We will address these comments in next version. Thanks again.

BR,
Amy
____
发件人: Paul Kyzivat [pkyzi...@alum.mit.edu]
发送时间: 2019年1月24日 2:28
收件人: draft-ietf-ccamp-rsvp-te-bandwidth-availability@ietf.org
抄送: General Area Review Team
主题: Gen-ART Last Call review of 
draft-ietf-ccamp-rsvp-te-bandwidth-availability-13

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by the
IESG for the IETF Chair. Please treat these comments just like any other
last call comments. For more information, please see the FAQ at
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ccamp-rsvp-te-bandwidth-availability-13
Reviewer: Paul Kyzivat
Review Date: 2019-01-23
IETF LC End Date: 2019-01-31
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the
review.

Issues:

Major: 0
Minor: 1
Nits:  1

1) NIT:

Section 3.1 includes the following:

 ... The Ethernet SENDER_TSPEC object
 MAY include more than one Availability TLV. The Availability TLV has
 the following format:

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Index  | Reserved  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Availability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I find it confusing that this is described as a TLV yet it shows neither
a type nor a length. Apparently it is only showing the value portion of
the TLV. The type portion is only mentioned in the IANA considerations
section, and isn't explicitly linked to this element. I would expect
this to be shown something like:

 0   1   2   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4 | Length=96 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Index  | Reserved  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Availability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(But the type value needs to be keyed to the IANA assigned value, since
there is no guarantee that IANA will assign 4 for this.)

2) MINOR:

Section 3.2 includes the following:

 When a node does not support the Availability TLV, it SHOULD
 generate PathErr message with the error code "Extended Class-Type
 Error" and the error value "Class-Type mismatch" (see [RFC2205]).

I have a question about this: Is this the default behavior that is
prescribed for any unknown TLV type found in an Ethernet SENDER_TSPEC
object, or is this behavior specific to the "availability" TLV? It is a
problem if this is not the default behavior.

And is there a reason for SHOULD (rather than MUST) here? If so, please
describe the situations where this need not be done.



___
Gen-art maili

[Gen-art] Gen-ART Last Call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-ccamp-rsvp-te-bandwidth-availability-13
Reviewer: Paul Kyzivat
Review Date: 2019-01-23
IETF LC End Date: 2019-01-31
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issues:

Major: 0
Minor: 1
Nits:  1

1) NIT:

Section 3.1 includes the following:

   ... The Ethernet SENDER_TSPEC object
   MAY include more than one Availability TLV. The Availability TLV has
   the following format:

   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Index  | Reserved  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Availability |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I find it confusing that this is described as a TLV yet it shows neither 
a type nor a length. Apparently it is only showing the value portion of 
the TLV. The type portion is only mentioned in the IANA considerations 
section, and isn't explicitly linked to this element. I would expect 
this to be shown something like:


   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Type=4 | Length=96 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Index  | Reserved  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Availability |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(But the type value needs to be keyed to the IANA assigned value, since 
there is no guarantee that IANA will assign 4 for this.)


2) MINOR:

Section 3.2 includes the following:

   When a node does not support the Availability TLV, it SHOULD
   generate PathErr message with the error code "Extended Class-Type
   Error" and the error value "Class-Type mismatch" (see [RFC2205]).

I have a question about this: Is this the default behavior that is 
prescribed for any unknown TLV type found in an Ethernet SENDER_TSPEC 
object, or is this behavior specific to the "availability" TLV? It is a 
problem if this is not the default behavior.


And is there a reason for SHOULD (rather than MUST) here? If so, please 
describe the situations where this need not be done.


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

[Gen-art] Gen-ART Last Call review of draft-ietf-lsr-isis-rfc7810bis-03

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-lsr-isis-rfc7810bis-03
Reviewer: Paul Kyzivat
Review Date: 2018-12-09
IETF LC End Date: 2018-12-12
IESG Telechat date: ?

Summary:

This draft is ready for publication as a Standards Track RFC.

Issues: None

It was very easy to review this document because a diff with RFC7810 
showed me everything of note, and this was consistent with Appendix A.


Changing an RFC in a way that is not backwards compatible is 
problematic, but the authors have clearly considered the issues and find 
this the best of bad alternatives.


The reference to draft-ietf-idr-te-pm-bgp-14 is now out of date. I'm not 
raising it as a nit because chasing references to drafts is futile and 
this will be fixed by the editor.


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

[Gen-art] Gen-ART Telechat review of draft-ietf-ospf-segment-routing-msd-20

[Paul Kyzivat]

[Resending with corrected subject line]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-ospf-segment-routing-msd-20
Reviewer: Paul Kyzivat
Review Date: 2018-09-14
IETF LC End Date: 2018-08-29
IESG Telechat date: 2018-09-25

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Issues:

Major: 0
Minor: 0
Nits:  1

1) NIT:

IdNits reports:

  == Outdated reference: A later version (-15) exists of
 draft-ietf-isis-segment-routing-msd-13

We discussed this earlier during last call review and you indicated that 
it must be a tooling issue because your document source doesn't 
reference a particular version of this document. If so you can leave 
this to be fixed by the editor during publication.


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

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

[Gen-art] Gen-ART Telechat review of draft-ietf-ospf-segment-routing-msd-17

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-ospf-segment-routing-msd-20
Reviewer: Paul Kyzivat
Review Date: 2018-09-14
IETF LC End Date: 2018-08-29
IESG Telechat date: 2018-09-25

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Issues:

Major: 0
Minor: 0
Nits:  1

1) NIT:

IdNits reports:

 == Outdated reference: A later version (-15) exists of
draft-ietf-isis-segment-routing-msd-13

We discussed this earlier during last call review and you indicated that 
it must be a tooling issue because your document source doesn't 
reference a particular version of this document. If so you can leave 
this to be fixed by the editor during publication.


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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-segment-routing-msd-17

[Paul Kyzivat]

On 8/28/18 1:30 PM, Jeff Tantsura wrote:

Hi Paul,

Many thanks!
I have uploaded .18 version that should address your comments.
Please let me know.


Looks good.

I forgot to run IdNits before, so I ran it now on -18. It is reporting 
one warning:


  == Outdated reference: A later version (-14) exists of
 draft-ietf-isis-segment-routing-msd-13

Thanks,
Paul

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-segment-routing-msd-17

[Paul Kyzivat]

On 8/27/18 6:18 PM, Jeff Tantsura wrote:

Hi Paul,

Yes, I completely agree with you, outside of routing context the document is quite 
difficult to parse, but so are most routing protocol extensions documents, they built on 
top of "well known" (to routing community) data.


Yes. I've also reviewed a couple of others, and it is difficult to get 
to the point that I can make any sense of the docs, even without trying 
to understand the subtleties that are being addressed. But that isn't 
necessarily a problem as long as the docs make sense to the intended 
audience.



MSD (Type) is a particular capability as supported and configured by a node or 
a link on a node.
While the most obvious use case is SR indeed (SR stacks MPLS labels that define 
characteristics of a path thought the network), number of labels a system can 
impose is finite and that is the number  advertised by BMI-MSD  (as defined in 
isis draft) . There are other types, some of them already defined (max readable 
depth for entropy), some of them are going to be defined on the future.
So there could be another application (not SR) that could use the data(MSDs) 
distributed thru OSPF/ISIS.


Please note - there's. text in isis draft, that is a response to the comment 
similar to your

"Note that in a non-SR MPLS network, label depth is what is defined by the MSD 
advertisements."

Would this comment work for you?
Many thanks!


I've raised the issue. I'll be satisfied with whatever you think is the 
right fix, if any.


Thanks,
Paul


Cheers,
Jeff

On 8/27/18, 12:50, "Paul Kyzivat"  wrote:

 Jeff,
 
 On 8/27/18 2:18 PM, Jeff Tantsura wrote:
 
 >  2) MINOR:

 >
 >  Section 1 also says:
 >
 >  Although MSD
 >  advertisements are associated with Segment Routing, the
 >  advertisements MAY be present even if Segment Routing itself is 
not
 >  enabled.
 >
 >  I found nothing else in the document that elaborated on this. 
Further
 >  explanation is needed, in a section other than the introduction.
 > [jeff] the meaning of the statement is that MSD MAY be advertised even 
if Segment Routing is not enabled, ie MSD(s) advertisement could be used by any 
other application that would find the data provided of value. I would appreciate, 
if you could be more specific about what's missing.
 
 Perhaps this is obvious to the likely readers, but not to me...
 
 (As someone with absolutely no knowledge of OSPF I found the specifics

 of the document to be nearly impenetrable. But I'm not part of the
 target audience.)
 
 I thought this information was specific to segment routing (whatever

 that is), so what is the point of having this information if segment
 routing isn't enabled? How would it be used? For me some discussion of
 that would be helpful.
 
 In any case, AFAIK an "introduction" serves to introduce the material

 that is covered in more depth later in the document. In this case it
 isn't introducing anything that comes later. If it is to only appear in
 one place, then I would expect it to be later in the document.
 
 	Thanks,

Paul
 






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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-segment-routing-msd-17

[Paul Kyzivat]

Jeff,

On 8/27/18 2:18 PM, Jeff Tantsura wrote:


 2) MINOR:
 
 Section 1 also says:
 
 Although MSD

 advertisements are associated with Segment Routing, the
 advertisements MAY be present even if Segment Routing itself is not
 enabled.
 
 I found nothing else in the document that elaborated on this. Further

 explanation is needed, in a section other than the introduction.
[jeff] the meaning of the statement is that MSD MAY be advertised even if 
Segment Routing is not enabled, ie MSD(s) advertisement could be used by any 
other application that would find the data provided of value. I would 
appreciate, if you could be more specific about what's missing.


Perhaps this is obvious to the likely readers, but not to me...

(As someone with absolutely no knowledge of OSPF I found the specifics 
of the document to be nearly impenetrable. But I'm not part of the 
target audience.)


I thought this information was specific to segment routing (whatever 
that is), so what is the point of having this information if segment 
routing isn't enabled? How would it be used? For me some discussion of 
that would be helpful.


In any case, AFAIK an "introduction" serves to introduce the material 
that is covered in more depth later in the document. In this case it 
isn't introducing anything that comes later. If it is to only appear in 
one place, then I would expect it to be later in the document.


Thanks,
Paul

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

[Gen-art] Gen-ART Last Call review of draft-ietf-ospf-segment-routing-msd-17

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-ospf-segment-routing-msd-17
Reviewer: Paul Kyzivat
Review Date: 2018-08-27
IETF LC End Date: 2018-08-29
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issues:

Major: 0
Minor: 3
Nits:  1

1) MINOR:

The abstract says:

   This
   document defines only one type of MSD, but defines an encoding that
   can support other MSD types.

and later section 1 says:

   It also defines
   the Base MPLS Imposition MSD type.

I can find nothing in the document that does this definition. It seems 
that this definition is actually done by 
draft-ietf-isis-segment-routing-msd, which is referenced. The text needs 
to agree with the structuring of the documents.


2) MINOR:

Section 1 also says:

   Although MSD
   advertisements are associated with Segment Routing, the
   advertisements MAY be present even if Segment Routing itself is not
   enabled.

I found nothing else in the document that elaborated on this. Further 
explanation is needed, in a section other than the introduction.


3) MINOR:

The first paragraph of section 4 says:

   When Link MSD is present for a given MSD type, the value of the Link
   MSD MUST take preference over the Node MSD.  When a Link MSD type is
   not signalled but the Node MSD type is, then the value of that *Link*
   MSD type MUST be considered as the corresponding *Node* MSD type
   value.

This appears to have scrambled the use of Link and Node a bit. I think 
it is intended to say:


   When Link MSD is present for a given MSD type, the value of the Link
   MSD MUST take preference over the Node MSD.  When a Link MSD type is
   not signalled but the Node MSD type is, then the value of that Node
   MSD type MUST be considered as the corresponding Link MSD type value.

4) NIT:

Section 2 uses: 'The Type:' when documenting the "Type" field of the 
TLV,  while sections 3 uses: 'Type:'. These ought to be consistent.


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

[Gen-art] Gen-ART Last Call review of draft-ietf-codec-ambisonics-07

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-codec-ambisonics-07
Reviewer: Paul Kyzivat
Review Date: 2018-07-03
IETF LC End Date: 2018-07-10
IESG Telechat date: ?

Summary:

This draft is ready for publication as a Standards Track RFC.

I found the document to be in fine shape. This is based on the form of 
the document. I'm not qualified to judge the merit of the technical 
choices made.


This is unusual for Gen-ART reviews I do. I almost always find *some* issue.

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-rfc4960-errata-06

[Paul Kyzivat]

On 6/4/18 5:39 AM, Gorry Fairhurst wrote:

The document write-up describes the process that has been used with SCTP 
updates, and this document follows this plan - this is information to 
help the WG prepare a bis document, that we plan to populate with these 
edits to the spec and adopt as a WG item in Montreal.


In that case, do you actually intend for this document to progress to an 
informational RFC, or just leave it as a draft and let it expire once 
the bis has captured all it contains?


(My understanding is that there is now a preference not to waste 
resources publishing transient documents like this.)



Q3: While the draft name contains “-errata-“, it is unclear whether the
draft only covers issues for which erratas has been filed, or whether
other issues (e.g., issues that have been discussed on the list) are 
also

included.
There are other issues discussed on the list, and the text proposed here 
is what the WG has discussed and finally agreed upon to appear in the 
.bis document. It would be OK to add something about that.


So is this really just a capture of agreements the wg has made about 
planned changes to 4960, where many of them have been motivated by errata?


Thanks,
Paul

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

[Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-rfc4960-errata-06

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-tsvwg-rfc4960-errata-06
Reviewer: Paul Kyzivat
Review Date: 2018-06-03
IETF LC End Date: 2018-06-04
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issues:

Major: 1
Minor: 2
Nits:  1

1) MAJOR:

The format of this document disturbs me. According to the abstract:

   ... This
   document provides deltas to RFC4960 and is organized in a time
   ordered way.  The issues are listed in the order they were brought
   up.  Because some text is changed several times the last delta in the
   text is the one which should be applied.

This format makes the document hard to deal with. A developer who wants 
to implement sctp with some or all of the errata fixes will want to work 
from a variant of 4960 that incorporates all of those fixes - a bis. But 
it isn't clear how this document helps with that. I don't think you can 
start with 4960 and simply apply all the deltas sequentially, because 
overlapping changes won't work right.


A developer won't be interested in the order in which errata were 
reported. An actual bis document would be more useful to a developer 
than this format. Is that not being done because doing so would be more 
difficult? Or because it isn't yet certain that these are the correct fixes?


I think you should give some serious consideration of the most suitable 
form for this document, in the context of how it is intended to be used.


2) MINOR (maybe MAJOR):

Discovering where one change is impacted by another change is hard.

I dug into the details of the document to understand how many places 
there are actually overlaps between the changes in multiple sections. 
(It took a lot of work to do this.) I found five of these:


- 3.1 / 3.23
- 3.3 / 3.43
- 3.5 / 3.10
- 3.6 / 3.23
- 3.24 / 3.32

(I don't guarantee that this list is exhaustive.)

Of these, I think only one (3.1/3.23) explicitly indicates the conflict, 
and it only indicates it within 3.23.


Most of the changes don't have any conflicts. And some of the conflicts 
could be removed by being more precise in indicating the change being 
made. In cases where this isn't possible, the presence of the conflict 
should be indicated in each section that has a conflict, with cross 
references. IOW, shift the burden of detecting conflicts from the reader 
to the document.


3) MINOR:

Errata Tracking: Apparently each subsection of section 3 covers one 
erratum. But the errata numbers are not mentioned. Each section ought to 
reference the errata number it responds to.


4) NIT:

In section 3.35 (DSCP Changes) the change to section 10.1 isn't properly 
indicated. It shows 'Old text' twice rather than 'Old text' and 'New text'.


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

[Gen-art] Gen-ART Last Call review of draft-ietf-tsvwg-rfc4960-errata-06

[Paul Kyzivat]

[[INCOMPLETE, NOT READY TO SEND. PLEASE IGNORE]]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-tsvwg-rfc4960-errata-06
Reviewer: Paul Kyzivat
Review Date: 2018-06-03
IETF LC End Date: 2018-06-04
IESG Telechat date: ?

Summary:

This draft is on the right track but has open issues, described in the 
review.


Issues:

Major: 1
Minor: 2
Nits:  1

1) MAJOR:

The format of this document disturbs me. According to the abstract:

   ... This
   document provides deltas to RFC4960 and is organized in a time
   ordered way.  The issues are listed in the order they were brought
   up.  Because some text is changed several times the last delta in the
   text is the one which should be applied.

This format makes the document hard to deal with. A developer who wants 
to implement sctp with some or all of the errata fixes will want to work 
from a variant of 4960 that incorporates all of those fixes - a bis. But 
it isn't clear how this document helps with that. I don't think you can 
start with 4960 and simply apply all the deltas sequentially, because 
overlapping changes won't work right.


A developer won't be interested in the order in which errata were 
reported. An actual bis document would be more useful to a developer 
than this format. Is that not being done because doing so would be more 
difficult? Or because it isn't yet certain that these are the correct fixes?


I think you should give some serious consideration of the most suitable 
form for this document, in the context of how it is intended to be used.


2) MINOR (maybe MAJOR):

Discovering where one change is impacted by another change is hard.

I dug into the details of the document to understand how many places 
there are actually overlaps between the changes in multiple sections. 
(It took a lot of work to do this.) I found five of these:


- 3.1 / 3.23
- 3.3 / 3.43
- 3.5 / 3.10
- 3.6 / 3.23
- 3.24 / 3.32

(I don't guarantee that this list is exhaustive.)

Of these, I think only one (3.1/3.23) explicitly indicates the conflict, 
and it only indicates it within 3.23.


Most of the changes don't have any conflicts. And some of the conflicts 
could be removed by being more precise in indicating the change being 
made. In cases where this isn't possible, the presence of the conflict 
should be indicated in each section that has a conflict, with cross 
references. IOW, shift the burden of detecting conflicts from the reader 
to the document.


3) MINOR:

Errata Tracking: Apparently each subsection of section 3 covers one 
erratum. But the errata numbers are not mentioned. Each section ought to 
reference the errata number it responds to.


4) NIT:

In section 3.35 (DSCP Changes) the change to section 10.1 isn't properly 
indicated. It shows 'Old text' twice rather than 'Old text' and 'New text'.


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

[Gen-art] Gen-ART Telechat review of draft-ietf-tokbind-negotiation-12

[Paul Kyzivat]

For IESG Evaluation reviews: I am the assigned Gen-ART reviewer for this 
draft. The General Area Review Team (Gen-ART) reviews all IETF documents 
being processed by the IESG for the IETF Chair. Please wait for 
direction from your document shepherd or AD before posting a new version 
of the draft. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-tokbind-negotiation-12
Reviewer: Paul Kyzivat
Review Date: 2018-05-04
IETF LC End Date: 2017-11-27
IESG Telechat date: 2018-05-08

Summary:

This draft is ready for publication as a Standards Track RFC.

Issues:

Major: 0
Minor: 0
Nits:  0

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

Re: [Gen-art] Gen-ART Telechat review of draft-ietf-i2rs-yang-dc-fabric-network-topology-07

[Paul Kyzivat]

On 4/1/18 11:09 PM, Zhuangyan (Yan) wrote:

Hi Paul,

Thank you very much for your review and comments.
Some responses below.

Best Regards,

Yan

-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: Sunday, April 01, 2018 1:20 AM
To: draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.org
Cc: General Area Review Team <gen-art@ietf.org>
Subject: Gen-ART Telechat review of 
draft-ietf-i2rs-yang-dc-fabric-network-topology-07

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. 
Please wait for direction from your document shepherd or AD before posting a new 
version of the draft. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-i2rs-yang-dc-fabric-network-topology-07
Reviewer: Paul Kyzivat
Review Date: 2018-03-31
IETF LC End Date: 2018-04-03
IESG Telechat date: 2018-04-05

Summary:

This draft is basically ready for publication, but has nits that should be 
fixed before publication.

Disclaimer:

I conducted this review without any knowledge of YANG modeling. So the sort of 
review I can do is superficial.

Issues:

Major: 0
Minor: 0
Nits:  4

(1) NIT:

In my opinion many of the normative references aren't actually normative, and 
can/should be changed to informative references. In particular the following 
all seem likely candidates: RFC5246 (TLS),
RFC6241 and RFC6242 (NETCONF), RFC8040 (RESTCONF), RFC8342 (NMDA), RFC8346. 
There may be others.
[Yan] For RFC5246 (TLS), RFC6241, RFC6242 (NETCONF), RFC8040 (RESTCONF) and 
RFC8342 (NMDA), they are building blocks for YANG module usage and definition, 
hence referenced as normative.


I get your point, but as best I can tell there is no normative 
dependency on any of them. They are all *possible* substrates for using 
this work, but none of them are required.


But it is your call.


(3) NIT:

IdNits reports 3 errors and 7 warnings, regarding long lines, references that 
are missing, unused, obsolete, and a downref. Please fix the errors and review 
the warnings.
[Yan] I checked v-07 with idnits 2.15.01, there is no errors/warnings or nits 
found...can you direct me to the tool you use?


I'm sorry. I actually reviewed -08, even though my message said I 
reviewed -07. I looked at the HTMLized version:


https://tools.ietf.org/html/draft-ietf-i2rs-yang-dc-fabric-network-topology-08

and then cliced [Nits] at the top:

https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-i2rs-yang-dc-fabric-network-topology-08.txt

Thanks,
Paul

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

[Gen-art] Gen-ART Telechat review of draft-ietf-i2rs-yang-dc-fabric-network-topology-07

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-i2rs-yang-dc-fabric-network-topology-07
Reviewer: Paul Kyzivat
Review Date: 2018-03-31
IETF LC End Date: 2018-04-03
IESG Telechat date: 2018-04-05

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Disclaimer:

I conducted this review without any knowledge of YANG modeling. So the 
sort of review I can do is superficial.


Issues:

Major: 0
Minor: 0
Nits:  4

(1) NIT:

In my opinion many of the normative references aren't actually 
normative, and can/should be changed to informative references. In 
particular the following all seem likely candidates: RFC5246 (TLS), 
RFC6241 and RFC6242 (NETCONF), RFC8040 (RESTCONF), RFC8342 (NMDA), 
RFC8346. There may be others.


(2) NIT:

In the IANA Considerations section the formatting is hard to read. 
Distinct elements for the registry (e.g., "URI:" and "Registrant 
Contact:") are run together. For readability they should be on separate 
lines.


(3) NIT:

IdNits reports 3 errors and 7 warnings, regarding long lines, references 
that are missing, unused, obsolete, and a downref. Please fix the errors 
and review the warnings.


(4) NIT:

In the title of section 2:

s/Definitions an Acronyms/Definitions and Acronyms/

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

[Gen-art] Gen-ART Last Call review of draft-ietf-lime-yang-connection-oriented-oam-model-05

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-lime-yang-connection-oriented-oam-model-05
Reviewer: Paul Kyzivat
Review Date: 2018-02-19
IETF LC End Date: 2018-02-19
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.


Disclaimer:

I conducted this review without any knowledge of YANG modeling. So the 
sort of review I can do is superficial.


Issues:

Major: 0
Minor: 0
Nits:  5

Other:

This is probably just my lack of understanding of this technology, but 
in section 4.3 do MEPs only have identity in the context of a MA? That 
is what this model seems to show. I would expect that MEPs have 
existence independent of MAs, and hence would be modeled independently 
within a domain.


(1) NIT: General

Throughout the document I noticed a number of missing articles. I am not 
going to call these out because it would make this review very long and 
tedious. The IESG editor will presumably fix these.


(2) NIT: Abstract:

OAM should be expanded in the abstract. I realize it is expanded in the 
title, but the abstract is likely to be seen in contexts where the title 
isn't present.


(3) NIT: Section 6.2:

This section says:

   For Base Mode of operation we
   propose to use MEP-ID zero (0) as the default MEP-ID.

This language might make sense in an early draft, but isn't very 
suitable for a document on the verge of being an RFC. (Who is this being 
proposed to? Who will decide?)


(4) NIT: Section 7.1: Generic YANG Model extension for TRILL OAM

The following is not a complete sentence:

   In the RPC extension, the continuity-
   check and path-discovery RPC are extended with TRILL specific.

This needs to say "with TRILL specific *something*".

(5) NIT: Reported by IdNits tool:

The idnits tool reports a number issues and warnings. Some are spurious, 
but the following seem to require attention so that these warnings are 
no longer generated:


  Checking nits according to https://www.ietf.org/id-info/checklist :



  ** The abstract seems to contain references
 ([I-D.ietf-netmod-revised-datastores]), which it shouldn't.  Please
 replace those with straight textual mentions of the documents in 
question.



  Miscellaneous warnings:



  == The document seems to lack the recommended RFC 2119 boilerplate, 
even if

 it appears to use RFC 2119 keywords.

 (The document does seem to have the reference to RFC 2119 which the
 ID-Checklist requires).
  -- The document date (February 6, 2018) is 13 days in the past.  Is this
 intentional?


  Checking references for intended status: Proposed Standard



  == Outdated reference: A later version (-10) exists of
 draft-ietf-netmod-revised-datastores-07

  == Outdated reference: A later version (-06) exists of
 draft-ietf-netmod-yang-tree-diagrams-02

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

[Gen-art] Gen-ART Telechat review of draft-ietf-opsawg-capwap-alt-tunnel-11

[Paul Kyzivat]

I am the assigned Gen-ART reviewer for this draft. The General Area 
Review Team (Gen-ART) reviews all IETF documents being processed by the 
IESG for the IETF Chair. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.


Document: draft-ietf-opsawg-capwap-alt-tunnel-11
Reviewer: Paul Kyzivat
Review Date: 2018-01-20
IETF LC End Date: 2017-12-13
IESG Telechat date: 2018-01-23

Summary:

This draft is ready for publication as an Experimental RFC.

(Thanks for resolving all of my issues on the prior version.)

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-10

[Paul Kyzivat]

On 12/14/17 2:12 AM, Duzongpeng wrote:

Hi, Paul

Thank you for your reply.
We have updated the draft again, the version 11-2.
If any problem, please connect us.


This resolves my concerns.

Thank you,
Paul


Best Regards
Zongpeng Du

About the comments:

Now I am more confused. This is new, rather than documenting existing 
deployed practice. It is not standards track, so this is not an intent to 
define something that can be deployed But it is being published as an archive.

Was this once intended to be standards track, but without sufficient interest or support 
to complete it as a standard. Is this then reflecting that "we did a lot of work on 
this and want to publish it in case there is future interest in doing something like 
this"?

If so, that is fine. If it is something else, then it would be helpful to have 
further explanation.

Yes, this was once to be standards track. But market trend changed 
while the work was going on, and then it was not finished.
Your understanding about "we did a lot of work on this and want to publish it in case 
there is future interest in doing something like this" is right. 

I'm still confused about what message is used to convey this. Is it an existing 
message in another spec, in which the AR List Element may be inserted? If so, 
does that message already allow elements defined elsewhere, such as this one, 
to be included? How would it be deciphered?

We made some corrections about it. It is a mistake to include it 
directly in the IEEE 802.11 WLAN Config. Response
Firstly, we change the Figure. Now, the IEEE 802.11 WLAN Configuration Response 
message contains an alternate tunnel encapsulation message element, in which 
the AR list element can be included.
Secondly, we rewrite the explanation under the graph. Now, it is said that "To 
enable this, the IEEE 802.11 WLAN Configuration Response may carry the alternate tunnel 
encapsulation message element containing the AR list elementcorresponding to the 
selected AR as shown in Figure 5."
Thirdly, in Section 3.2.  Alternate Tunnel Encapsulations Type, we add some 
explanations:
" Besides, the message element can also be sent by the WTP to communicate the 
selected AR(s)."
Fourthly, in Section 5.1.  Access Router Information Elements, we add some 
explanations:
" If the Alternate Tunnel Encapsulations Type message element is sent  
   by the WTP to communicate the selected AR(s), this Access Router 
   Information Element SHOULD be contained."




Another problem:
  A message is mistaken used in the draft because of negligence, and we correct 
it.
In current version, it is said that WTP Alternate Tunnel Fail Indication 
(defined in this specification)
MAY be carried in the CAPWAP Station Configuration Request message
which is defined in [RFC5415].
However, it should be *WTP Event Request * message instead.
The CAPWAP Station Configuration Request message is sent by the AC to the WTP,
And the WTP Event Request message is used by a WTP to send information to its 
AC.

-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: Thursday, December 14, 2017 6:55 AM
To: Duzongpeng; draft-ietf-opsawg-capwap-alt-tunnel@ietf.org
Cc: General Area Review Team
Subject: Re: Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-10

On 12/13/17 3:56 AM, Duzongpeng wrote:

Hi, Paul

Please see inline.
Thank you very much for your careful review.
We have updated the draft accordingly.
If any problem, please connect us.

Best Regards
Zongpeng Du

-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: Tuesday, December 12, 2017 3:48 AM
To: draft-ietf-opsawg-capwap-alt-tunnel@ietf.org
Cc: General Area Review Team
Subject: Gen-ART Last Call review of
draft-ietf-opsawg-capwap-alt-tunnel-10

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. 
Please treat these comments just like any other last call comments. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-capwap-alt-tunnel-10
Reviewer: Paul Kyzivat
Review Date: 2017-12-11
IETF LC End Date: 2017-12-13
IESG Telechat date: TBD

Summary:

This draft is on the right track but has open issues, described in the review.

(Thanks for fixing most of the issues I raised in the previous round.)

Issues:

Major: 0
Minor: 7
Nits:  1

(1) MINOR:

In Section 1.3, if this document is intended to serve as a *historical* reference, then why isn't 
then intended status "Historic" rather than "Experimental"?
There have been discussions about it among the authors, chairs, and the ADs. 
Finally, the "Experimental" type is decid

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-10

[Paul Kyzivat]

On 12/13/17 9:27 PM, Warren Kumari wrote:

On Wed, Dec 13, 2017 at 5:55 PM, Paul Kyzivat <pkyzi...@alum.mit.edu> wrote:

On 12/13/17 3:56 AM, Duzongpeng wrote:



In Section 1.3, if this document is intended to serve as a *historical*
reference, then why isn't then intended status "Historic" rather than
"Experimental"?
There have been discussions about it among the authors, chairs,
and the ADs. Finally, the "Experimental" type is decided.
According to https://tools.ietf.org/html/rfc2026#section-4.2, the
historical type means:
 A specification that has been superseded by a more recent
 specification or is for any other reason considered to be obsolete is
 assigned to the "Historic" level.
Our document is a new one, so it is not very proper for us to declare a
historical type.

 Also in RFC2026, it is said that
 The "Experimental" designation typically denotes a specification that
 is part of some research or development effort.  Such a specification
 is published for the general information of the Internet technical
 community and as an archival record of the work, subject only to
 editorial considerations and to verification that there has been
 adequate coordination with the standards process (see below).

 So we consider that the "Experimental" type is more suitable here.

 And to avoid ambiguity, we have changed the "This experimental
document is intended to serve as a historical reference for any future work
as to the operational and deployment requirements." To
 "This experimental document is intended to serve as **an archival
record** for any future work as to the operational and deployment
requirements."




Now I am more confused. This is new, rather than documenting existing
deployed practice. It is not standards track, so this is not an intent to
define something that can be deployed But it is being published as an
archive.

Was this once intended to be standards track, but without sufficient
interest or support to complete it as a standard. Is this then reflecting
that "we did a lot of work on this and want to publish it in case there is
future interest in doing something like this"?



Yup :-)


If so, that is fine. If it is something else, then it would be helpful to
have further explanation.


Yup, up until version 8 this was a Standards Track document. It got
significant review (and went though an IETF LC / IESG ballot) as that
but ran into some issues and was returned to the WG. It seems like the
interest in deploying it decreased -- but, it is still a valid use,
and interest may return in the future. Experimental might not be the
right status, but I don't really think Historic is either. It could be
Informational, but that doesn't quite feel right either.


OK. Then this makes sense. Maybe we need a new category for this sort of 
thing. (I think I have another use for it.)


Thanks,
Paul

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

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-10

[Paul Kyzivat]

On 12/13/17 3:56 AM, Duzongpeng wrote:

Hi, Paul

Please see inline.
Thank you very much for your careful review.
We have updated the draft accordingly.
If any problem, please connect us.

Best Regards
Zongpeng Du

-Original Message-
From: Paul Kyzivat [mailto:pkyzi...@alum.mit.edu]
Sent: Tuesday, December 12, 2017 3:48 AM
To: draft-ietf-opsawg-capwap-alt-tunnel@ietf.org
Cc: General Area Review Team
Subject: Gen-ART Last Call review of draft-ietf-opsawg-capwap-alt-tunnel-10

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
(Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. 
Please treat these comments just like any other last call comments. For more 
information, please see the FAQ at 
<​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-opsawg-capwap-alt-tunnel-10
Reviewer: Paul Kyzivat
Review Date: 2017-12-11
IETF LC End Date: 2017-12-13
IESG Telechat date: TBD

Summary:

This draft is on the right track but has open issues, described in the review.

(Thanks for fixing most of the issues I raised in the previous round.)

Issues:

Major: 0
Minor: 7
Nits:  1

(1) MINOR:

In Section 1.3, if this document is intended to serve as a *historical* reference, then why isn't 
then intended status "Historic" rather than "Experimental"?
There have been discussions about it among the authors, chairs, and the ADs. 
Finally, the "Experimental" type is decided.
According to https://tools.ietf.org/html/rfc2026#section-4.2, the historical 
type means:
A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the "Historic" level.
Our document is a new one, so it is not very proper for us to declare a 
historical type.

Also in RFC2026, it is said that
The "Experimental" designation typically denotes a specification that
is part of some research or development effort.  Such a specification
is published for the general information of the Internet technical
community and as an archival record of the work, subject only to
editorial considerations and to verification that there has been
adequate coordination with the standards process (see below).

So we consider that the "Experimental" type is more suitable here.

And to avoid ambiguity, we have changed the "This experimental document is 
intended to serve as a historical reference for any future work as to the operational and 
deployment requirements." To
"This experimental document is intended to serve as **an archival record** 
for any future work as to the operational and deployment requirements."



Now I am more confused. This is new, rather than documenting existing 
deployed practice. It is not standards track, so this is not an intent 
to define something that can be deployed But it is being published as an 
archive.


Was this once intended to be standards track, but without sufficient 
interest or support to complete it as a standard. Is this then 
reflecting that "we did a lot of work on this and want to publish it in 
case there is future interest in doing something like this"?


If so, that is fine. If it is something else, then it would be helpful 
to have further explanation.



  (2) MINOR:

Section 3 contains:

 Since AC can configure a WTP with more than one AR available for the
 WTP to establish the data tunnel(s) for user traffic, it may be
 useful for the WTP to communicate the selected AR.  To enable this,
 the IEEE 802.11 WLAN Configuration Response may contain the AR list
 element containing the selected AR.

But "IEEE 802.11 WLAN Configuration Response" is not defined in this version of 
the document. Seems like this may be a dangling reference from a prior version.
Thanks for proposing the problem. We add some explanations for the 
problem.
Firstly, change the sentence to " the IEEE 802.11 WLAN Configuration Response 
may contain the AR list
 element containing the selected AR *as shown in Figure 5*."
Secondly, change the Config. To Configuration in the Figure 5, and add the [ AR List 
Element ]  in the IEEE 802.11 WLAN Configuration Response message.


I'm still confused about what message is used to convey this. Is it an 
existing message in another spec, in which the AR List Element may be 
inserted? If so, does that message already allow elements defined 
elsewhere, such as this one, to be included? How would it be deciphered?



(3) MINOR:

In Section 3.1, Figure 6 shows Tunnel-Type1 occupying the first 16 bits of a 32 
bit value, and Tunnel-Type (2..N) all occupying the 2nd 16 bits of that value. 
That doesn't work for N>2. I *presume* that the intent is that this be an array 
of 16 bit values in network order sta