Hi Alvaro. Thanks for the review. Responses inline.
On Tue, 9 Jun 2020 at 16:16, Alvaro Retana via Datatracker <nore...@ietf.org> wrote: > > Alvaro Retana has entered the following ballot position for > draft-ietf-capport-architecture-08: No Objection > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have some minor comments: > > (1) Please expand CAPPORT. > We'll do this. > (2) §1: s/This document standardizes an architecture/This document describes > an > architecture This is not a standard track document. This has been pointed out by other reviewers as well. We'll correct it. > > (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. 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 > a normative statement. I agree. I'll change it as part of rephrasing this statement to address Benjamin's review comments. > > (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. > 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 _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
