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

Commentary: A reviewer requested that we provide more detail on how the user equipment should so certificate validation . This does so . 
 Do this . Figure out the proper ' name type ' . 
  suggests Let 's use this , and attribute it to him in the acknowledgements .
If User Equipment supports the Captive Portal API, it MUST validate
the API server's TLS certificate (see RFC2818).  An Enforcement
Device SHOULD allow access to any services that User Equipment could
need to contact to perform certificate validation, such as OCSP
responders, CRLs, and NTP servers; see Section 4.1 of I-D.ietf-
capport-api for more information.  If certificate validation fails,
User Equipment MUST NOT proceed with any of the behavior described
above.
If User Equipment supports the Captive Portal API, it MUST validate
the API server's TLS certificate (see RFC2818) according to the
procedures in RFC6125.  The API server's URI is obtained via a
network provisioning protocol, which will typically provide a
hostname to be used in TLS server certificate validation, against a
DNS-ID in the server certificate.  If the API server is identified by
IP address, the iPAddress subjectAltName is used to validate the
server certificate.  An Enforcement Device SHOULD allow access to any
services that User Equipment could need to contact to perform
certificate validation, such as OCSP responders, CRLs, and NTP
servers; see Section 4.1 of I-D.ietf-capport-api for more
information.  If certificate validation fails, User Equipment MUST
NOT proceed with any of the behavior described above.
The authors thank Benjamin Kaduk for providing the content related to
TLS certificate validation of the API server.
Draft: draft-ietf-capport-architecture

Commentary: Open up the abstract 's wording a bit so we make it clear that other provisioning protocols could be used in the future for discovering the API URI . 
  writes :
This document describes a captive portal architecture.  DHCP or
Router Advertisements (RAs), an optional signaling protocol, and an
HTTP API are used to provide the solution.  The role of Provisioning
Domains (PvDs) is described.
This document describes a captive portal architecture.  Network
provisioning protocols such as DHCP or Router Advertisements (RAs),
an optional signaling protocol, and an HTTP API are used to provide
the solution.  The role of Provisioning Domains (PvDs) is described.
Draft: draft-ietf-capport-architecture

Commentary: We 've had lots of people asking about the mac address as an identifier . Mention it , and point out that we wo n't give a deep discussion about it . 
 This one will likely be controversial . I would n't mind input from a few others . 
 Thanks for the reviews / suggestions . 
 The MAC address is such an obvious identifier , particularly since it 's so widely used . We 've have multiple questions about it during reviews . We should probably add some simple text pointing that out . E.g. " The MAC address of a device is often used as an identity in existing implementations . A discussion of it has been omitted for brevity , but the MAC address could be used subject to the criteria in section 3.2 "
The MAC address of a device is often used as an identifier in
existing implementations.  This document does not discuss the use of
MAC addresses within a captive portal system, but they can be used as
an identifier type, subject to the criteria in id_recommended_props.
Draft: draft-ietf-capport-architecture

Commentary: If we 're using an IP as an identifier , dual stack can add complexity . Mention this . 
 Raised during review that dual - stack is a use - case worth calling out explicitly . Some suggested text : " Further attention should be paid to a device using dual - stack [ rfc4213 ] : it could have both an IPv4 and an IPv6 address at the same time . There could be no properties in common between the two addresses , meaning that some form of mapping solution could be required to form a single identity from the two address . "
In some situations, the User Equipment may have multiple IP
addresses, while still satisfying all of the recommended properties.
This raises some challenges to the components of the network.  For
example, if the User Equipment tries to access the network with
multiple IP addresses, should the Enforcement Device and API Server
treat each IP address as a unique User Equipment, or should it tie
the multiple addresses together into one view of the subscriber?  An
implementation MAY do either.  Attention should be paid to IPv6 and
the fact that it is expected for a device to have multiple IPv6
addresses on a single link.  In such cases, identification could be
performed by subnet, such as the /64 to which the IP belongs.
In some situations, the User Equipment may have multiple IP addresses
(either IPv4, IPv6 or a dual-stack RFC4213 combination), while still
satisfying all of the recommended properties.  This raises some
challenges to the components of the network.  For example, if the
User Equipment tries to access the network with multiple IP
addresses, should the Enforcement Device and API Server treat each IP
address as a unique User Equipment, or should it tie the multiple
addresses together into one view of the subscriber?  An
implementation MAY do either.  Attention should be paid to IPv6 and
the fact that it is expected for a device to have multiple IPv6
addresses on a single link.  In such cases, identification could be
performed by subnet, such as the /64 to which the IP belongs.
Draft: draft-ietf-capport-architecture

Commentary: It makes sense that in a network each component would have multiple replicas for redundancy and scale . Mention that . 
 Pointed out during review : we mention that components may be logically combined , but we do n't talk about redundancy or scale .
The Provisioning Service, API Server, and User Portal are described
as discrete functions.  An implementation might provide the multiple
functions within a single entity.
The Provisioning Service, API Server, and User Portal are described
as discrete functions.  An implementation might provide the multiple
functions within a single entity.  Furthermore, these functions,
combined or not, as well as the Enforcement Device, could be
replicated for redundancy or scale.
Draft: draft-ietf-capport-architecture

Commentary: There was some confusion about how network access is constrained for when the user equipment has n't satisfied the captive portal conditions . Mention that it 's up to the provider 's policies . 
 Raised during review . Is it allowed by definition ( i.e. within the walled garden ) Is it more nuanced ? Is it just up to the use - case ? 
  suggests in reply to my suggestions : I propose we do this . 
 replied with : Let 's do that .
The Enforcement Device component restricts the network access of User
Equipment according to site-specific policy.  Typically User
Equipment is permitted access to a small number of services and is
denied general network access until it satisfies the Captive Portal
Conditions.
The Enforcement Device component restricts the network access of User
Equipment according to site-specific policy.  Typically User
Equipment is permitted access to a small number of services
(according to the policies of the network provider) and is denied
general network access until it satisfies the Captive Portal
Conditions.
Draft: draft-ietf-capport-architecture

Commentary: We never defined what RA was . Do so by expanding it to Router Advertisment in the abstract . 
 Note : it 's still not clear to me whether we need to cite the RA / DHCP / etc RFCs , or whether they 're considered ' well - known ' enough to be left alone . Or , is that a questdion for the rfc editors ? 
 I 'm comfortable with taking DHCP and   as assumed knowledge . Both are on the . 
 We never define what an '  ' is , but we use that term in section 4.1 . We should consider expanding it to the full term ( Router Advertisement ) . We may also want to add an informative reference to it when we first mention it . Note that we have the same problem with DHCP here -- I 'm not sure offhand what the best practice is regarding terms that have fairly wide use , but may not be understood by everyone ( and even what that set of terms is ) . 
 RA is listed in the abbreviations document : but of course " expand on first use " seems like sound editorial practice .
This document describes a captive portal architecture.  DHCP or
Router Advertisements, an optional signaling protocol, and an HTTP
API are used to provide the solution.  The role of Provisioning
Domains (PvDs) is described.
This document describes a captive portal architecture.  DHCP or
Router Advertisements (RAs), an optional signaling protocol, and an
HTTP API are used to provide the solution.  The role of Provisioning
Domains (PvDs) is described.
Draft: draft-ietf-capport-architecture

Commentary: We only use UE in one section . Everywhere else we use User Equipment .   in that section so we are consistent with our use of it . 
 It was pointed out that we sometimes use UE rather than user equipment ( e.g. section 3.5 . ) . Let 's be consistent , perhaps shortening all references to UE other than where it is defined .
A Captive Portal API needs to present information to clients that is
unique to that client.  To do this, some systems use information from
the context of a request, such as the source address, to identify the
UE.
Using information from context rather than information from the URI
allows the same URI to be used for different clients.  However, it
also means that the resource is unable to provide relevant
information if the UE makes a request using a different network path.
This might happen when UE has multiple network interfaces.  It might
also happen if the address of the API provided by DNS depends on
where the query originates (as in split DNS RFC8499).
Accessing the API MAY depend on contextual information.  However, the
URIs provided in the API SHOULD be unique to the UE and not dependent
on contextual information to function correctly.
Though a URI might still correctly resolve when the UE makes the
request from a different network, it is possible that some functions
could be limited to when the UE makes requests using the captive
network.  For example, payment options could be absent or a warning
could be displayed to indicate the payment is not for the current
connection.
A Captive Portal API needs to present information to clients that is
unique to that client.  To do this, some systems use information from
the context of a request, such as the source address, to identify the
User Equipment.
Using information from context rather than information from the URI
allows the same URI to be used for different clients.  However, it
also means that the resource is unable to provide relevant
information if the User Equipment makes a request using a different
network path.  This might happen when User Equipment has multiple
network interfaces.  It might also happen if the address of the API
provided by DNS depends on where the query originates (as in split
DNS RFC8499).
Accessing the API MAY depend on contextual information.  However, the
URIs provided in the API SHOULD be unique to the User Equipment and
not dependent on contextual information to function correctly.
Though a URI might still correctly resolve when the User Equipment
makes the request from a different network, it is possible that some
functions could be limited to when the User Equipment makes requests
using the captive network.  For example, payment options could be
absent or a warning could be displayed to indicate the payment is not
for the current connection.
Draft: draft-ietf-capport-architecture

Commentary: Multiple reviewers objected to the way in which we captured interactions with headless / UI - less devices . Clarify the document 's intent . Do this by removing language that indicated that we would eventually get around to adding the requirements , and specify explicitly that we are not handling devices without UIs . 
  points out in his review : He suggests as a solution : I propose we do this . The first mention is in section one . We can say something along the lines of " A future document could provide a solution for devices without user interfaces . This document focuses on devices with user interfaces . " 
 On page 4 :   writes , 
 We might want to avoid relying on the captivity concept so heavily , but this is a good change nonetheless .
A side-benefit of the architecture described in this document is that
devices without user interfaces are able to identify parameters of
captivity.  However, this document does not yet describe a mechanism
for such devices to escape captivity.
A side-benefit of the architecture described in this document is that
devices without user interfaces are able to identify parameters of
captivity.  However, this document does not describe a mechanism for
such devices to negotiate for unrestricted network access.  A future
document could provide a solution to devices without user interfaces.
This document focuses on devices with user interfaces.
At this time we consider only devices with web browsers, with web
applications being the means of satisfying Captive Portal Conditions.
An example interactive User Equipment is a smart phone.
This document only considers devices with web browsers, with web
applications being the means of satisfying Captive Portal Conditions.
An example of such User Equipment is a smart phone.
Draft: draft-ietf-capport-architecture

Commentary: This replaces all mentions of capport ( other than document slugs ) with " captive portal " . Note : this change includes the title of the document . 
   writes , We should do this . 
 Or erase all mentions of ' capport '
This document describes a CAPPORT architecture.  DHCP or Router
Advertisements, an optional signaling protocol, and an HTTP API are
used to provide the solution.  The role of Provisioning Domains
(PvDs) is described.
This document describes a captive portal architecture.  DHCP or
Router Advertisements, an optional signaling protocol, and an HTTP
API are used to provide the solution.  The role of Provisioning
Domains (PvDs) is described.
A standard for providing a portal URI using DHCP or Router
Advertisements is described in RFC7710bis.  The CAPPORT architecture
expects this URI to indicate the API described in section_api.
A standard for providing a portal URI using DHCP or Router
Advertisements is described in RFC7710bis.  The captive portal
architecture expects this URI to indicate the API described in
section_api.
Draft: draft-ietf-capport-architecture

Commentary: This was raise during multiple reviews : the api does n't make the user portal URI mandatory . Further , there is a use - case where we want to notify of a ' venue url ' without being captive . Change up the wording . 
   ,  writes : 
 This was also brought up by   during the the api document 's last call . Let 's fix it . Two options were raised during that review ( by Tommy and  , respectively ):  that the API be able to provide the URI Qualify the requirement to indicate when the URI is required ( e.g. when captive portal enforcement may be active ) . Some proposals : I 'm not sure it 's worth discussing the use - case that leads to it being useful for it to be optional ( e.g. the venue w/ notification or extra info ) . 
 We went with the first proposal , " the API MUST be able to provide a URI " 
 The new wording leaves it open for the API to make it optional . OK .
At minimum, the API MUST provide: (1) the state of captivity and (2)
a URI for the User Portal.
At minimum, the API MUST provide the state of captivity.  Further the
API MUST be able to provide a URI for the User Portal.
Draft: draft-ietf-capport-architecture

Commentary: To replace " web - portal " and " Captive Portal Server " Address issue 
 Note : this actually fixed 
 Sorry , do n't know where I got 45 from 
 Some reviewers have found " Captive Portal Server " to be confusing when read alongside " Captive Portal API Server " . Let 's change it to something a bit more distinct .   has suggested " user portal " , which seems reasonable . While we 're in there , make sure we 're consistent with this use . It was also pointed out that we used " web portal " in quite a few places ( e.g. sec 2.6 , section 4 ) . 
 A reasonable
Captive Portal Server: The web server providing a user interface for
assisting the user in satisfying the conditions to escape captivity.
User Portal: The web server providing a user interface for assisting
the user in satisfying the conditions to escape captivity.
At minimum, the API MUST provide: (1) the state of captivity and (2)
a URI for the Captive Portal Server.
At minimum, the API MUST provide: (1) the state of captivity and (2)
a URI for the User Portal.
The Provisioning Service, API Server, and Web Portal Server are
described as discrete functions.  An implementation might provide the
multiple functions within a single entity.
The Provisioning Service, API Server, and User Portal are described
as discrete functions.  An implementation might provide the multiple
functions within a single entity.
Draft: draft-ietf-capport-architecture

Commentary: We were using " Captive Portal Enforcement " , " Captive Portal Enforcement Device " and " Enforcement Device " , with varying capitilisation , inconsistently throughout the document . Address that by defining the component as " Captive Portal Enforcement Device " , and using that term in section headings , and " Enforcement Device " everywhere else . Fixes issue 
 Looks good to me 
 Used in different ways : Captive Portal Enforcement , enforcement device , etc . 
 I think keeping it shorter is likely better . ? Caps to make it clear it 's a first class component in the architecture ?
Captive Portal Enforcement: The network equipment which enforces the
traffic restriction.
Captive Portal Enforcement Device: The network equipment which
enforces the traffic restriction.  Also known as Enforcement Device.
The User Equipment is the device that a user desires to be attached
to a network with full access to all hosts on the network (e.g., to
have Internet access).  The User Equipment communication is typically
restricted by the Captive Portal Enforcement, described in
section_capport_enforcement, until site-specific requirements have
been met.
The User Equipment is the device that a user desires to be attached
to a network with full access to all hosts on the network (e.g., to
have Internet access).  The User Equipment communication is typically
restricted by the Enforcement Device, described in
section_capport_enforcement, until site-specific requirements have
been met.
The Captive Portal Enforcement component restricts the network access
of User Equipment according to site-specific policy.  Typically User
Equipment is permitted access to a small number of services and is
denied general network access until it satisfies the Captive Portal
Conditions.
The Enforcement Device component restricts the network access of User
Equipment according to site-specific policy.  Typically User
Equipment is permitted access to a small number of services and is
denied general network access until it satisfies the Captive Portal
Conditions.
Draft: draft-ietf-capport-architecture

Commentary: Everyone was confused by the phrasing that the API needed to provide evidence it supported the architecture . Since it 's a proper component of the architecture , it does n't really need to ; that is assumed . Rather , it needs to inform the client of versions / types / etc so that the client can determine whether it supports the API . Rephrase accordingly . Fixes issue 
 Thanks again for the suggested text , 
 A reviewer says , Suggestion : state that a version of the protocol should be included in the API response . 
 Is n't the content - type of the API response sufficient indication ? That implies that we might need a new content - type if we want to make incompatible changes in a subsequent revision , but I think that is a good plan . 
 At the architecture level , can we state the point more clearly ? Maybe better to state what the User Equipment should do if the API response does n't make sense ? 
 So , the fact that we 've discovered the API likely means that we 're interacting with the architecture -- i.e. we got there from PvD or the dhcp option . So , I 'm not sure what it would mean to not support the architecture in that case . It would be a provisioning mistake , I guess ? We should suggest what the UE could do in that case , though , for robustness . So , maybe mention that the API should have a content - type in the response to indicate that it is indeed a captive portal API , and then what to do if the UE does n't recognize that ? 
 So I think that the reviewer here was simply confused about the choice of words and phrasing . How about : A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports . For an HTTP - based interaction , such as in { { API } } this might be achieved by using a content type that is unique to the protocol .
At minimum, the API MUST provide: (1) the state of captivity and (2)
a URI for the Captive Portal Server.  The API SHOULD provide evidence
to the caller that it supports the present architecture.
At minimum, the API MUST provide: (1) the state of captivity and (2)
a URI for the Captive Portal Server.
A caller to the API needs to be presented with evidence that the
content it is receiving is for a version of the API that it supports.
For an HTTP-based interaction, such as in I-D.ietf-capport-api this
might be achieved by using a content type that is unique to the
protocol.
Draft: draft-ietf-capport-architecture

Commentary: I 'll merge this later today when I go over it and submit the new draft then . 
 Done . 
 Thanks ! IESG here we come . 
 The CAPPORT API document explains some requirements on deployments to allow certificate validation of servers , specifically in Section 4.1.1 . Server Authentication . Last call comments noted that the architecture should have notes that such provisions are needed . 
 This appears to be the last PR active on the respository . Can we have an updated version of the draft please?Thanks !
If User Equipment supports the Captive Portal API, it MUST validate
API server TLS certificate (see RFC2818).  An Enforcement device
SHOULD allow access to any services that User Equipment could need to
contact to perform certificate validation, such as OCSP responders,
CRLs, and NTP servers; see Section 4.1 of I-D.ietf-capport-api for
more information.  If certificate validation fails, User Equipment
MUST NOT proceed with any of the behavior described above.