Subject: [Captive-portals] Alvaro Retana's No Objection on draft-ietf-capport-architecture-08: (with COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Tue, 09 Jun 2020 13:16:49 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-capport-architecture-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have some minor comments:

(1) Please expand CAPPORT.

(2) §1: s/This document standardizes an architecture/This document describes an
architecture   This is not a standard track document.

(3) §1: "MAY allow a device to be alerted"   Other parts of the document (even
in the same section) talk about "devices can be notified" or "informs an
end-user", while "alert" is not mentioned anywhere else.  Given that "alert"
has the normative attachment, it would be nice to use consistent language.

(4) §2.1: "E.g....MAY avoid updating..."   s/MAY/may   This is an example, not
a normative statement.

(5) §3.1: "An Identifier MAY be a field...Or, an Identifier MAY be an ephemeral
property..."   s/MAY/may  These seem to be statements and not normative
statements.

---

From: Kyle Larose <[email-masked]>
Date: Sat, 13 Jun 2020 08:52:28 -0400

Hi Alvaro.

Thanks for the review. Responses inline.

> draft-ietf-capport-architecture-08: No Objection
We'll do this.

> architecture   This is not a standard track document.

This has been pointed out by other reviewers as well. We'll correct it.

> has the normative attachment, it would be nice to use consistent language.

Seems reasonable. We'll change the language to be consistent.

> (4) §2.1: "E.g....MAY avoid updating..."   s/MAY/may   This is an example, not

I agree. I'll change it as part of rephrasing this statement to
address Benjamin's
review comments.

> property..."   s/MAY/may  These seem to be statements and not normative

We were trying to say that the identifier was allowed to be one of
those two things, but
I don't see the need for the normative language: what makes a possible
identifier is discussed
later. I'll replace the two 'MAY' occurrences with 'could'.

Thanks!

Kyle