jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-capport-api

Commentary: Add key for extending sessions . Implements . 
 I want to be clear that there is no extend - session API here . It 's just an indication that the user could do that somehow , in a browser . 
 correct , there 's no specific API to do so . It just indicates if there 's a possibility of the user doing so . Future mechanisms for doing so automatically are left for the future =) 
 Boolean value to add . Suggested names have been and . 
 LGTM
"can-extend-session" (optional, boolean): indicates that the URL
specified as "user-portal-url" allows the user to extend a session
once the client is no longer in a state of captivity.  This
provides a hint that a client system can suggest accessing the
portal URL to the user when the session is near its limit in terms
of time or bytes.
Draft: draft-ietf-capport-api

Commentary: Completes 
 As discussed in the IETF hackathon / informal meeting , the consensus is to change expire - date ( an absolute iso datetime ) to seconds - remaining integer ( named after bytes - remaining ) 
 This was already done ! 
 thanks , missed that 
 The draft currently specifies a deadline as an absolute time . Experience with implementation showed that time remaining ( in seconds ) was easier to implement and less subject to the vagaries of clock differences .
"expire-date" (optional, string formatted as RFC3339 datetime):
indicates the date and time after which the client will be in a
captive state.  The API server SHOULD include this value if the
client is not captive (i.e. captive=false) and SHOULD omit this
value for captive clients.
"seconds-remaining" (optional, integer): indicates the number of
seconds remaining, after which the client will be placed into a
captive state.  The API server SHOULD include this value if the
client is not captive (i.e. captive=false) and SHOULD omit this
value for captive clients.
Draft: draft-ietf-capport-api

Commentary: Adding a security considerations section to describe the security benefits that are , along with the concern about trusting any hostnames even after authentication . I 'd like to get some form of this in soon , and then rev the document before the IETF 105 cutoff . 
 thanks for starting this . looks like a good text to start with . Should we also propose something to the privacy section ? 
 We have a bit in the privacy section already , so I was going to leave it for now . If you have suggested text , let me know and I ’ll add it !
TBD: Provide complete security requirements and analysis.
One of the goals of this protocol is to improve the security of the
communication between client hosts and Captive Portal systems.
Client traffic is protected from passive listeners on the local
network by requiring TLS-encrypted connections between the client and
the Captive Portal API server, as described in api-details.  All
communication between the clients and the API server MUST be
encrypted.
In addition to encrypting communications between clients and Captive
Portal systems, this protocol requires a basic level of
authentication from the API server, as described in server-auth.
Specifically, the API server MUST present a valid certificate on
which the client can perform revocation checks.  This allows the
client to ensure that the API server has authority for a hostname
that can be presented to a user.
It is important to note that while the server authentication checks
can validate a specific hostname, it is certainly possible for the
API server to present a valid certificate for a hostname that uses
non-standard characters or is otherwise designed to trick the user
into believing that its hostname is some other, more trustworthy,
name.  This is a danger of any scenario in which a hostname is not
typed in by a user.
Draft: draft-ietf-capport-api

Commentary: Addresses , with the decisions made at the last IETF meeting 
 Added text based on Martin 's suggestions 
 As   pointed out , we should describe the model we assume for API server authentication . Then we need to describe the requirements on this . An important point here is that CRL or OCSP checking are likely to fail for a captive UE . A recommendation for servers to use OCSP stapling is likely necessary ( whitelisting CRL or OCSP servers is probably workable , but OCSP stapling is a far superior solution ) . 
 This needs to mention AIA chasing as well . Some client implementations do that ( others think that it 's a crazy idea , but that 's not a debate we need to enter into here).looks good .
The purpose of accessing the Captive Portal API over an HTTPS
connection is twofold: first, the encrypted connection protects the
integrity and confidentiality of the API exhange from other parties
on the local network; and second, it provides the client of the API
an opportunity to authenticate the server that is hosting the API.
This authentication is aimed at allowing a user to be reasonably
confident that the entity providing the Captive Portal API has a
valid certificate for the hostname in the URI (such as
"example.com").  The hostname of the API SHOULD be displayed to the
user in order to indicate the entity which is providing the API
service.
Clients performing revocation checking will need some means of
accessing revocation information for certificates presented by the
API server.  Online Certificate Status Protocol RFC6960 (OCSP)
stapling, using the TLS Certificate Status Request extension RFC6066
SHOULD be used.  OCSP stapling allows a client to perform revocation
checks without initiating new connections.  To allow for other forms
of revocation checking, a captive network could permit connections to
OCSP responders or Certificate Revocation Lists (CRLs) that are
referenced by certificates provided by the API server.
Certificates with missing intermediate certificates that rely on
clients validating the certificate chain using the URI specified in
the Authority Information Access (AIA) extension RFC5280 SHOULD NOT
be used by the Captive Portal API server.  If the certificates do
require the use of AIA, the captive network will need to allow client
access to the host specified in the URI.
If the client is unable to validate the certificate presented by the
API server, it MUST NOT proceed with any of the behavior for API
interaction described in this document.  The client will proceed to
interact with the captive network as if the API capabilities were not
present.  It may still be possible for the user to access the network
by being redirected to a web portal.
Draft: draft-ietf-capport-api

Commentary: Satisfied 
 application / json is fine in the general sense , but if you want to ever do things like versioning , then a media type is important . Crib from if you want a recent example . 
 Discussed in London , consensus to use a new media type . 
 I am ok with the text .
The Captive Portal API data structures are specified in JavaScript
Object Notation (JSON) RFC7159.
The Captive Portal API data structures are specified in JavaScript
Object Notation (JSON) RFC7159.  Requests and responses for the
Captive Portal API use the "application/captive+json" media type.
Clients SHOULD include this media type as an Accept header in their
GET requests, and servers MUST mark this media type as their Content-
Type header in responses.
This document registers the media type for Captive Portal API JSON
text, "application/captive+json".
Encoding considerations are identical to those specified for the
"application/json" media type.
This document specifies format of conforming messages and the
interpretation thereof.
This media type is intended to be used by servers presenting the
Captive Portal API, and clients connecting to such captive
networks.
See Authors' Addresses section.
Draft: draft-ietf-capport-api

Commentary: Satisfies 
 looks good . 
 Should we hold the addition of this until we have something that depends on it being in the API ? 
 We certainly can , although if we want to use a key as discussed in the WG meeting for the purposes of ICMP validation , having a way to add a key here is nice for removing a bootstrapping step . Hopefully we can get an updated ICMP document out with the API document , and they can reference one another in this way . 
 Discussed in London , remove this . 
 accepted
Note that the use of the hmac-key is not defined in this document,
but is intended for use in the enforcement step of the Captive Portal
Architecture.