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

Commentary:  suggested : " I was just thinking that if we have a whole sentence about how " you 're going to have to do the old thing anyway , though " , someone might read that and say " well , if I have to keep doing the old thing , why should I bother with this new thing " . So , appending a " ; nonetheless , the mechanism provided by this document provides a more reliable and performant way to do so , and is therefore the preferred mechanism for captive - portal detection " or similar is what I had in mind . " 
 Will do , and just submit ( ' ai n't nobody got time for nit PRs :-P ) 
 Maybe de - hyphenate captive - portal
Paragraph (version A):
The Captive Portal DHCP / RA Option informs the client that it may be
behind a captive portal and provides the URI to access an API as
defined by [draft-ietf-capport-api].  This is primarily intended to
improve the user experience by showing the user the captive portal
information faster and more reliably.  Note that, for the foreseeable
future, captive portals will still need to implement interception
techniques to serve legacy clients, and clients will need to perform
probing to detect captive portals.
Paragraph (version B):
The Captive Portal DHCP / RA Option informs the client that it may be
behind a captive portal and provides the URI to access an API as
defined by [draft-ietf-capport-api].  This is primarily intended to
improve the user experience by showing the user the captive portal
information faster and more reliably.  Note that, for the foreseeable
future, captive portals will still need to implement interception
techniques to serve legacy clients, and clients will need to perform
probing to detect captive portals"; nonetheless, the mechanism
provided by this document provides a more reliable and performant way
to do so, and is therefore the preferred mechanism for captive-portal
detection.
Draft: draft-ietf-capport-rfc7710bis

Commentary: Looking at this now it 's really not clear what I was thinking before . Fortunately , IANA folks are on top things .   " " " First , Section 4.1 states that " This document registers a new entry under the IETF URN Sub - namespace defined in [ RFC3553 ] " however , the registry at defined by RFC 3553 is actually the IETF URN Sub - namespace for Registered Protocol Parameter Identifiers registry . In addition , neither registry 's columns match the columns named in the registration . IANA Question --The authors provide the following registration information in Section 4.1 of the draft : Registry name : Captive Portal Unrestricted Identifier URN : urn : ietf : params : capport : unrestricted Specification : RFC TBD ( this document ) Repository : RFC TBD ( this document ) Index value : Only one value is defined ( see URN above ) . No hierarchy is defined and therefore no sub - namespace registrations are possible . The IETF URN Sub - namespaces registry records the following information : Sub - namespace Reference IANA Registry Reference And the IETF URN Sub - namespace for Registered Protocol Parameter Identifiers provide the following information : Registered Parameter Identifier Reference IANA Registry Reference Is the registration information in Section 4.1 of the draft for a different registry ; or , is the information provided different from the requirements for the IETF URN Sub - namespace for Registered Protocol Parameter Identifiers registry ? " " " 
 Per  : " " " The way we 'd normally do this sort of registration is to register " capport " in the " IETF URN Sub - namespace for Registered Protocol Parameter Identifiers " registry , and create a new registry ( probably with Expert Review or Specification Required , but it also could be FCFS ) for " Captive Portal URN Labels " or some name like that , and that registry would have " unrestricted " in it , resulting in the full URN we want . The " Captive Portal URN Labels " registry would be the IANA Registry Reference for the first registration . " " " I propose we go for the Fully Monty registration . 
 Given recent discussion that capport : unrestricted may be fine on its own I will close this ( again ) for now .
Paragraph (version A):
Only one value is defined (see URN above).  No hierarchy is
defined and therefore no sub-namespace registrations are possible.
Paragraph (version B):
Only one value is defined (see URN above).  No hierarchy is defined
and therefore no sub-namespace registrations are possible.
Draft: draft-ekwk-capport-rfc7710bis

Commentary: " " " — Section 5 — Purely a judgment thing here , so do what you hink is best : it seems to me that the Security Considerations in 7710 rather buried the lede . The bottom line is that by removing the MitM interception , this mechanism improves security by making the portal and its actions visible , rather than hidden , and that vulnerabilities that exist here also existed before and are now lessened . I would say something like that up front , in a new first paragraph , and then continue with the existing text as is . But , again , as you judge best ; this is just a comment . " " "
Paragraph (version B):
By removing or reducing the need for captive portals to perform MITM
hijacking, this mechanism improves security by making the portal and
its actions visible, rather than hidden, and reduces the likelihood
that users will disable useful security safeguards like DNSSEC
validation, VPNs, etc.  In addition, because the system knows that it
is behind a captive portal, it can know not to send cookies,
credentials, etc.  By handing out a URI which is protected with TLS,
the captive portal operator can attempt to reassure the user that the
captive portal is not malicious.
Paragraph (version A):
By simplifying the interaction with the captive portal systems, and
doing away with the need for interception, we think that users will
be less likely to disable useful security safeguards like DNSSEC
validation, VPNs, etc.  In addition, because the system knows that it
is behind a captive portal, it can know not to send cookies,
Draft: draft-ekwk-capport-rfc7710bis

Commentary: Additionally , clarify recommended URI limit of 255 in each of DHCPv6 and IPv6  option description text . 
 Approved ( text crafted on phone ) . The duplication of the warning length is intentional .... 
 " " " — Sections 2.1 and 2.2 — Why are n’t the diagrams for the two in the same format ? And neither explicitly says what the length of the “ len ” field is . In the v4 version , one has to guess that it ’s the same size as the “ code ” field , 1 byte . In the v6 version , one can look at the diagram . I suggest making the diagrams the same format ( calibrated with bit / byte markings ) and explicitly specifying in the text the size of the “ len ” field . " " " I rather suspect this goes back to whichever source documents from which the option format text was copied . Nevertheless , harmonizing them seems reasonable . 
 Additionally : we should restate the 255 byte limit from DHCPv4 in each option 's description .
Paragraph (version B):
The maximum length of the URI that can be carried in IPv4 DHCP is 255
bytes, so URIs longer than 255 bytes should not be provisioned via
IPv6 DHCP options.
Paragraph (version B):
The maximum length of the URI that can be carried in IPv4 DHCP is 255
bytes, so URIs longer than 255 bytes should not be provisioned via
IPv6 RA options.
Draft: draft-ekwk-capport-rfc7710bis

Commentary: Approved -- discussed on phone ... 
 " " " The URI SHOULD NOT contain an IP address literal . Why not , and how does it maintain interoperability to have this as SHOULD NOT , rather than MUST NOT ? " " " 
 My recollection ( possibly faulty ) , is that we could have made this a MUST NOT in large part because we want the URI to be identical across IPv4 and IPv6 -based options , but that going from SHOULD NOT to MUST NOT could be over - prescriptive . Is my recollection correct , and would such a move be over - prescriptive ? 
 That is right . It is also somewhat more challenging to get a valid certificate for an IP address than a domain name .
Paragraph (version A):
The URI SHOULD NOT contain an IP address literal.
Paragraph (version B):
The URI SHOULD NOT contain an IP address literal.  Exceptions to this
might include networks with only one operational IP address family
where DNS is either not available or not fully functional until the
captive portal has been satisfied.
Draft: draft-ekwk-capport-rfc7710bis

Commentary: " " " It looks like the two consecutive paragraphs that both begin with “ A captive portal ” have some duplication with regard to the absence of “ Accept ” headers ; please check that and adjust if you agree that some information can be merged or removed . " " " Indeed , these paragraphs seem to be saying almost the exact same thing . I think the 2nd paragraph can be removed , once it 's clear whether / how to move its SHOULD to the 1st paragraph . 
 A bunch of unrelated changes :)
Paragraph (version A):
A captive portal server MAY redirect requests that do not have an
Accept header field (RFC7231 Section 5.3) containing a field item
whose content-type is "application/capport+json" to the URL conveyed
in the "user-portal-url" API key.  When performing such content
negotiation (RFC7231 Section 3.4), implementors of captive portals
need to keep in mind that such responses might be cached, and
therefore SHOULD include an appropriate Vary header field (RFC7231
Section 7.1.4) or mark them explicitly uncacheable (for example,
using Cache-Control: no-store RFC7234 Section 5.2.2.3).
Paragraph (version A):
A captive portal MAY do content negotiation (RFC7231 section 3.4) and
attempt to redirect clients querying without an explicit indication
of support for the captive portal API content type (i.e. without
application/capport+json listed explicitly anywhere within an Accept
header vis.  RFC7231 section 5.3).  In so doing, the captive portal
SHOULD redirect the client to the value associated with the "user-
portal-url" API key.
Paragraph (version B):
A captive portal MAY do content negotiation (RFC7231 section 3.4) and
attempt to redirect clients querying without an explicit indication
of support for the captive portal API content type (i.e. without
application/capport+json listed explicitly anywhere within an Accept
header vis.  RFC7231 section 5.3).  In so doing, the captive portal
SHOULD redirect the client to the value associated with the "user-
portal-url" API key.  When performing such content negotiation
(RFC7231 Section 3.4), implementors of captive portals need to keep
in mind that such responses might be cached, and therefore SHOULD
include an appropriate Vary header field (RFC7231 Section 7.1.4) or
mark them explicitly uncacheable (for example, using Cache-Control:
no-store RFC7234 Section 5.2.2.3).
Draft: draft-ekwk-capport-rfc7710bis

Commentary: Additionally : Update DHCPv6 reference from RFC 3315 to RFC 8415 . Include reference to DHCPv6 option format text . Include reference to DHCPv4 option format text in RFC 2132 . The DHCPv4 and v6 diagrams are not harmonized in this change . Each option format has sever documents using the style currently depicted . Issue : 
 " " " — Sections 2.1 and 2.2 — Why are n’t the diagrams for the two in the same format ? And neither explicitly says what the length of the “ len ” field is . In the v4 version , one has to guess that it ’s the same size as the “ code ” field , 1 byte . In the v6 version , one can look at the diagram . I suggest making the diagrams the same format ( calibrated with bit / byte markings ) and explicitly specifying in the text the size of the “ len ” field . " " " I rather suspect this goes back to whichever source documents from which the option format text was copied . Nevertheless , harmonizing them seems reasonable . 
 Additionally : we should restate the 255 byte limit from DHCPv4 in each option 's description .
Paragraph (version A):
In order to support multiple "classes" of clients (e.g.  IPv4 only,
IPv6 only with DHCPv6 (RFC3315), and IPv6 only with RA) the captive
network can provision the client with the URI via multiple methods
(IPv4 DHCP, IPv6 DHCP, and IPv6 RA).  The captive portal operator
SHOULD ensure that the URIs provisioned by each method are equivalent
to reduce the chance of operational problems.  The maximum length of
the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer
than 255 bytes should not be provisioned via IPv6 DHCP or IPv6 RA
either.
Paragraph (version B):
In order to support multiple "classes" of clients (e.g.  IPv4 only,
IPv6 only with DHCPv6 (RFC8415), and IPv6 only with RA) the captive
network can provision the client with the URI via multiple methods
(IPv4 DHCP, IPv6 DHCP, and IPv6 RA).  The captive portal operator
SHOULD ensure that the URIs provisioned by each method are equivalent
to reduce the chance of operational problems.  The maximum length of
the URI that can be carried in IPv4 DHCP is 255 bytes, so URIs longer
than 255 bytes should not be provisioned via IPv6 DHCP nor IPv6 RA
options.
Paragraph (version A):
Len: The length, in octets of the URI.
Paragraph (version B):
Len: The length (one octet), in octets of the URI.
Paragraph (version B):
See RFC2132, Section 2 for more on the format of IPv4 DHCP options.
Paragraph (version A):
option-len: The length, in octets of the URI.
Paragraph (version A):
See RFC7227, Section 5.7 for more examples of DHCP Options with URIs.
Paragraph (version B):
option-len: The unsigned 16-bit length, in octets, of the URI.
Paragraph (version B):
See RFC7227, Section 5.7 for more examples of DHCP Options with URIs.
See RFC8415, Section 21.1 for more on the format of IPv6 DHCP
options.
Draft: draft-ekwk-capport-rfc7710bis

Commentary: " " " — Section 3 — Specifically , URIs learned via any of the options in Section 2 should take precedence over any URI learned via some other mechanism Given the MUST that comes before this , I think the word “ should ” ought to be removed , to avoid any confusion . " " " Actually , this text is left over from the brief period of time when there was an HTTP redirect Link - Relation header . That option was removed , and I think the 2nd paragraph can be deleted . The 1st and 3rd paragraphs can probably be reworked into two much tighter paragraphs .
Paragraph (version A):
A device may learn about Captive Portal API URIs through more than
one of (or indeed all of) the above options.  It is a network
configuration error if the learned URIs are not all identical.
Paragraph (version A):
However, if the URIs learned are not in fact all identical the
captive device MUST prioritize URIs learned from network provisioning
or configuration mechanisms before all other URIs.  Specifically,
URIs learned via any of the options in option should take precedence
over any URI learned via some other mechanism, such as a redirect.
Paragraph (version A):
If the URIs learned via more than one option described in option are
not all identical, this condition should be logged for the device
owner or administrator.  Implementations can select their own
precedence order.
Paragraph (version B):
A device may learn about Captive Portal API URIs through more than
one of (or indeed all of) the above options.  Implementations can
select their own precedence order (e.g., prefer one of the IPv6
options before the DHCPv4 option, or vice versa, et cetera).
Paragraph (version B):
If the URIs learned via more than one option described in option are
not all identical, this condition should be logged for the device
owner or administrator; it is a network configuration error if the
learned URIs are not all identical.
Draft: draft-ekwk-capport-rfc7710bis

Commentary: — Section 1.1 — Please use the new BCP 14 boilerplate from RFC 8174 .
Paragraph (version A):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 RFC2119 RFC8174 when, and only when, they appear in all capitals,
as shown here.
Draft: draft-ekwk-capport-rfc7710bis

Commentary: Note that I do need you both to confirm that you have fulfilled IPR obligations . 
 Thank you !
Paragraph (version A):
RFC7710 used DHCP code point 160.  Due to a conflict, this document
specifies TBD.
Paragraph (version B):
This document replaces RFC 7710.  RFC 7710 used DHCP code point 160.
Due to a conflict, this document specifies TBD.
Paragraph (version B):
This document replaces RFC 7710 RFC7710.
Paragraph (version A):
Networks with no captive portals MAY explicitly indicate this
condition by using this option with the IANA-assigned URI for this
purpose (see ietf_params_capport-unrestricted).  Clients observing
the URI value "urn:ietf:params:capport-unrestricted" MAY forego time-
consuming forms of captive portal detection.
Paragraph (version B):
Networks with no captive portals MAY explicitly indicate this
condition by using this option with the IANA-assigned URI for this
purpose (see iana-urn).  Clients observing the URI value
"urn:ietf:params:capport-unrestricted" MAY forego time-consuming
forms of captive portal detection.
Paragraph (version A):
Index value: Only one value is defined (see URN above).  No hierarchy
is defined and therefore no sub-namespace registrations are possible.
Paragraph (version B):
Only one value is defined (see URN above).  No hierarchy is
defined and therefore no sub-namespace registrations are possible.
Draft: draft-ekwk-capport-rfc7710bis

Commentary: Forgot to make PR . This is the " good " one , should be abandoned ... 
 Nope -- I think it is still TBD - we 've asked / strongly suggested 114 in the IANA section , but I think it would feel presumptive to state that it is ... W 
 I believe this should be changed to 114 , or IANA - TBD . 
 Yikes , good catch . I changed it to TBD , and also a sentence to the Abstract noting that it has changed from 160 to TBD ( it seemed important enough ) . Thank you ! W 
 have changed or will change ? I ca n't see this in the current version(s ) of the draft here . 
 I swear I 'd done this , and event sent a PR , but I can not find it .... so , just made a new one ... 
 I had created the branch , and made the edits , but apparently forgot to make the PR .... and then , because I could n't find it , I made a new branch , change and PR ( ) , and then realized the original was better , so I removed PR and created ... Oy vey ,    , had forgotten to close ... 
 Should the TBDs be 114 ? Either that , or the list of changes should be TBD as well ?
Paragraph (version B):
RFC7710 used DHCP code point 160.  Due to a conflict, this document
specifies TBD.
Paragraph (version A):
In many environments, users need to connect to a captive-portal
server and agree to an Acceptable Use Policy (AUP) and / or provide
billing information before they can access the Internet.  It is
anticipated that the IETF will work on a more fully featured protocol
at some point, to ease interaction with Captive Portals.  Regardless
of how that protocol operates, it is expected that this document will
provide needed functionality because the client will need to know
when it is behind a captive portal and how to contact it.
Paragraph (version B):
In many environments, users need to connect to a captive-portal
device and agree to an Acceptable Use Policy (AUP) and / or provide
billing information before they can access the Internet.  Regardless
of how that mechanism operates, this document provides functionality
to allow the client to know when it is behind a captive portal and
how to contact it.
Draft: draft-ekwk-capport-rfc7710bis

Commentary: … ptive - portals / vIDCvkyKXdvMGjwvOHuTsSgFzt8/ 
 LGTM , for this change to address 1/2 of the referenced comments .
Paragraph (version A):
If the URIs learned via more than one option described in option are
not all identical, this condition should be logged for the device
owner or administrator.  URI precedence in this situation is not
specified by this document.
Paragraph (version B):
If the URIs learned via more than one option described in option are
not all identical, this condition should be logged for the device
owner or administrator.  Implementations can select their own
precedence order.
Draft: draft-ekwk-capport-rfc7710bis

Commentary: Earlier version of this document requested a parameter to be used for Link Relation purposes . This LinkRel use was removed as was the explicit parameter request , but the surround grammar was overlooked . Also : rev draft version to -02 and document month to February in anticipation of post a new version .
Paragraph (version A):
This document requests two new IETF URN protocol parameter (RFC3553)
entries.  This document also requests a reallocation of DHCPv4 option
codes (see exp106 for background).
Paragraph (version B):
This document requests one new IETF URN protocol parameter (RFC3553)
entry.  This document also requests a reallocation of DHCPv4 option
codes (see exp106 for background).
Draft: draft-ekwk-capport-rfc7710bis

Commentary: At IETF 106 , we discussed removing the link relation . This PR does that . 
 I suppose we should be reading and implementing draft - ietf - git - github - wg - configuration ... As  's T - shirt says : " In my defense I was left unsupervised . " 
 100 % agreed about the build output ... 
 People who put build output in their repository deserve a special place .
Paragraph (version A):
Some captive portal network deployments may be unable to change, or
unwilling to risk changing, the network infrastructure necessary to
use any of the above options.  In such deployments, when clear text
HTTP intercept and redirection are used, a Link relation header
(RFC8288, Section 3.3) MAY be inserted to convey to a HTTP client
(user agent) the associated Captive Portal API URI.
Paragraph (version A):
HTTP user agents MUST ignore this link relation in any context other
than when explicitly probing to detect the presence of a captive
portal.  Failure to do so could allow an attacker to inject a Captive
Portal API URI other than the correct URI for a given network or for
networks where there is no captive portal present at all.
Paragraph (version A):
However, if the URIs learned are not in fact all identical the
captive device MUST prioritize URIs learned from network provisioning
or configuration mechanisms before all other URIs.  Specifically,
URIs learned via any of the options in option should take precedence
over any URI learned via a mechanism like the one described in
linkrel.
Paragraph (version B):
However, if the URIs learned are not in fact all identical the
captive device MUST prioritize URIs learned from network provisioning
or configuration mechanisms before all other URIs.  Specifically,
URIs learned via any of the options in option should take precedence
over any URI learned via some other mechanism, such as a redirect.
Paragraph (version A):
Index value: Only one value is defined (see URN above).  No hierarchy
is defined and therefore no sub-namespace registrations are possible.
Draft: draft-ekwk-capport-rfc7710bis

Commentary: Fixes issue 
 Aaaaannd fixed the merge conflicts again . please take a look ! 
 In our interop testing , all of the implementations of portals require that the DHCP option is in the request list in order for it to be sent . We should be explicit that this is what SHOULD be done in the document ( clients SHOULD request ) .
Paragraph (version B):
Clients that support the Captive Portal DHCP option SHOULD include
the option in the Parameter Request List in DHCPREQUEST messages.
DHCP servers MAY send the Captive Portal option without any explicit
request.