jiebi/TextFlow huggingface dataset:
Original text:
8. This document requires no actions from IANA. <del> 9. The proposal relies on identifying and resolving any mDNS-based ICE candidates as part of adding/processing a remote candidate.  ICESDP section 4.1 could be updated to explicitly allow mDNS names in the connection-address field. The proposal relies on adding the ability to register mDNS names at ICE gathering time.  This could be described in ICESDP and/or WebRTCSpec. The proposal allows updating IPHandling so that mode 2 is not the mode used by default when user consent is not required.  Instead, the default mode could be defined as mode 3 with mDNS-based ICE candidates. </del>

Reviewer comments:
This work is already in motion in the desired documents.
LGTM
IOW, should this document define the new modes, or just how mDNS should be used to hide local IP addresses? If the latter, we would then also need to write a ip-handling v2 that defined the new modes, and pointed at this doc for details on how the technique should work.
From last meeting discussions, the plan was to define the new modes in this document and add a note in the ip-handling document that new modes might be defined with an informative reference to this document. I think defining the new modes in this document will also ease the authoring work and the review from the RTCWeb WG. In the long run, I think an ip-handling v2 might be a better place for the definition of the modes. For instance the guidelines around a default mode does belong in the ip-handling document, not the mdns-ice-candidate document.
OK. This particular document may be in the wrong WG then, but we can leave those details for later.
Leaving this open to cull the Specification Requirements section once it has been fully incorporated into ip-mdns-ext.

Revised text:
8. This document requires no actions from IANA.
Original text:
2.1. <del> The following information serves as the registration form for the "application/yaml" media type. </del>  application

Reviewer comments:
This might be a bit nitpicky, but I think the draft should explicitly say that contains YAML.
If you are ok with the integration, feel free to squash and merge NAME

Revised text:
2.1.  <ins> The media type for YAML text is "application/yaml"; the following information serves as the registration form for this media type. </ins> application
Original text:
see <del> The syntax and semantics of fragment identifiers specified for +yaml SHOULD be as specified for application-yaml The syntax and semantics for fragment identifiers for a specific "xxx/yyy+yaml" SHOULD be processed as follows: For cases defined in +yaml, where the fragment identifier resolves per the +yaml rules, then process as specified in +yaml. For cases defined in +yaml, where the fragment identifier does not resolve per the +yaml rules, then process as specified in "xxx/yyy+yaml". For cases not defined in +yaml, then process as specified in "xxx/yyy+yaml". </del>  See

Reviewer comments:
no default frag-id for +yaml media types have to explicitly declare syntax and semantics
Compile fragment identifier section [ ] for [x] for ? Can we pospone this?
It seems strange to me that a media type would define a new "language" intrinsic.
I believe the registration should include the fragment identifier. +json does not identify one, which creates problems. It probably should have a registration update to address it. Not registering fragment handling means that a reference to a YAML-borne schema cannot be referenced. The part beyond the # would be formally nonsensical (as it is today). We can take some inspiration from the work on the same issue for JSON Schema. JSON Pointer tells us how to craft fragments. The same format applies to the semantic equivalent in YAML documents. I'll put in a pull request.
NAME we have splitted the two documents. I think that yaml fragment identifiers should probably be delegated to "structured" media types since there are multiple possibilities (eg. json-path, json pointers, ...) WRT openapi+yaml for example, we can state that the fragment uses json pointers.
NAME Can you confirm that the YAML community agrees with the current statement wrt fragment identifiers?
I'm pretty sure that fragment identifiers should not be defined for at least for now. As demonstrated e.g. by the work going on even in this repo, YAML is used to represent multiple different forms of structured data, some of which may at times be represented by other formats, such as JSON. So while YAML 1.1 and 1.2 do explicitly support on nodes that would rather naturally work as fragment identifiers, there's somewhat significant risk that this would complicate usage with sub-formats that natively use different methods, such as JSON Pointers. On the other hand, defining fragment identifiers for to follow the YAML spec for referring to anchors would make sense.
FWIW, I completely agree.
The choice to leave the fragment identifier of the structured syntax suffix to the media type is sensible: I will PR that.

Revised text:
see  <ins> Differently from "application/yaml", there is no fragment identification syntax defined for +yaml.  A specific "xxx/ yyy+yaml" media type needs to define the syntax and semantics for fragment identifiers because the ones in application-yaml do not apply unless explicitly expressed. </ins> See
Original text:
1.2.  This section describes how to use alias nodes (see Section 3.2.2.2 and 7.1 of YAML) as fragment identifiers to designate nodes. If multiple nodes would match a fragment identifier, the first such match is selected. <del> A fragment identifier is not guaranteed to reference an existing node.  Therefore, applications SHOULD define how an unresolved alias node ought to be handled. </del> Users concerned with interoperability of fragment identifiers: SHOULD limit alias nodes to a set of characters that do not based data serialization language designed around the common native data types of dynamic programming languages. <del> An empty fragment identifier references the root node.  A fragment identifier starting with "*" is to be interpreted as a YAML alias node application-yaml-fragment.  A fragment identifier starting with "/" is to be interpreted as a JSON Pointer JSON-POINTER and is evaluated on the YAML representation graph, walking through alias nodes; this syntax can only reference YAML nodes that are on a path that is made up of nodes interoperable with the JSON data model (see int-yaml-and-json). </del>  Additional information:

Reviewer comments:
includes clarification on JSON Pointer and alias nodes compatibility includes FAQ fragment identifier moved from media type to section empty fragment + are both under JSON Pointer
cc: NAME NAME PTAL
According to NAME this PR should better clarify JSON Pointer use, so I am going to merge it. The decision on forcing +yaml fragment is deferred to that I will rebase.

Revised text:
1.2. <ins> A fragment identifier starting with "*" is to be interpreted as a YAML alias node fragment-alias-node. A fragment identifier that is empty or that starts with "/" is to be interpreted as a JSON Pointer JSON-POINTER and is evaluated on the YAML representation graph, walking through alias nodes; this syntax can only reference YAML nodes that are on a path that is made up of nodes interoperable with the JSON data model (see int-yaml-and-json). A fragment identifier is not guaranteed to reference an existing node.  Therefore, applications SHOULD define how an unresolved alias node ought to be handled. 1.2.1. </ins> This section describes how to use alias nodes (see Section 3.2.2.2 and 7.1 of YAML) as fragment identifiers to designate nodes. If multiple nodes would match a fragment identifier, the first such match is selected.  Users concerned with interoperability of fragment identifiers: SHOULD limit alias nodes to a set of characters that do not based data serialization language designed around the common native data types of dynamic programming languages.  <ins> See </ins> Additional information:
Original text:
to be interpreted as in URI. The terms "presentation", "stream", "YAML document", "representation <del> graph", "node", "alias node", "anchor" and "anchor name" in this document are to be interpreted as in YAML. </del>  1.2. considerations apply. When using YAML as a more efficient format to serialize information <del> intended to be consumed as JSON, information can be discarded: this includes comments (see Section 3.2.3.3 of YAML) and alias nodes (see Section 7.1 of YAML), that do not have a JSON counterpart. </del>  Implementers need to ensure that relevant information will not be lost during the processing.  For example, they might consider

Reviewer comments:
in YAML and JSON, explicits that you need to use only information that is stored in the representation graph, not other. See
mention presentation and serialization details they cannot be used to interoperably convey information comments, ordering and anchor names fall in the above categories.

Revised text:
to be interpreted as in URI. The terms "presentation", "stream", "YAML document", "representation  <ins> graph", "tag", "node", "alias node", "anchor" and "anchor name" in this document are to be interpreted as in YAML. </ins> 1.2. considerations apply. When using YAML as a more efficient format to serialize information  <ins> intended to be consumed as JSON, information not reflected in the representation graph and classified as presentation or serialization detail (see Section 3.2 of YAML) can be discarded.  This includes comments (see Section 3.2.3.3 of YAML), directives, and alias nodes (see Section 7.1 of YAML) that do not have a JSON counterpart. </ins> Implementers need to ensure that relevant information will not be lost during the processing.  For example, they might consider
Original text:
Magic number(s) N/A <del> File extension(s): yaml, yml </del>  Macintosh file type code(s): N/A 3.3.  When using flow collection styles (see Section 7.4 of YAML) a YAML document could look like JSON JSON, thus similar interoperability considerations apply. types like custom and local tags such as "!!python/object" and "!mytag" (see Section 2.4 of YAML); <del> 3.4. </del>  To allow fragment identifiers to traverse alias nodes, the YAML representation graph needs to be generated before the fragment

Reviewer comments:
looks good to me (with one minor editorial note i left as a comment).
Would it be valuable to express a preference for over for file extensions? I'm assuming 3 character extensions are legacy from DOS file systems that had a 3 character limit. I reviewed the YAML 1.2 spec and there is no mention of using as a file extensions, so this might be a good opportunity to steer the community away from having two extensions.
Pls let's annihilate the DOS zombie!
NAME let's summon NAME and the YAML folks on that. IMHO: agree on expressing a preference disagree on removing references to .yml, since it's used in the wild. My2¢, R.
Discussed with YAML folks. Ok for indicating a preference without normative implications.

Revised text:
Magic number(s) N/A  <ins> File extension(s): "yaml" (preferred), "yml".  See int-yaml- filename-extension. </ins> Macintosh file type code(s): N/A 3.3. <ins> The "yaml" filename extension is the preferred one; it is the most popular and widely used on the web.  The "yml" filename extension is still used.  The simultaneous usage of two filename extensions in the same context might cause interoperability issues (e.g. when both a "config.yaml" and a "config.yml" are present). 3.4. </ins> When using flow collection styles (see Section 7.4 of YAML) a YAML document could look like JSON JSON, thus similar interoperability considerations apply. types like custom and local tags such as "!!python/object" and "!mytag" (see Section 2.4 of YAML);  <ins> 3.5. </ins> To allow fragment identifiers to traverse alias nodes, the YAML representation graph needs to be generated before the fragment
Original text:
agreement properties of MLS will confirm that all members of the group agree on the content of these extensions. <del> Application messages carried by MLS are opaque; they can contain arbitrary data.  The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted.  Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. </del> 5.8.  The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can authentication mechanisms, ciphersuites, and infrastructure functionalities. <del> 5.9. </del>  It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this

Reviewer comments:
As discussed in today's interim. This is essentially repushing which should not have been reverted.
URL
Interim 2022-06-09: Informational refence from RFC to a draft is allowed Agreement to just un-revert / re-land
Fixed in

Revised text:
agreement properties of MLS will confirm that all members of the group agree on the content of these extensions.  5.8. <ins> Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism necessary to negotiate the format of that content over the lifetime of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- D.mahy-mls-content-neg, unless the specific application defines another mechanism which more appropriately addresses the same requirements for that application of MLS. The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted. Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. 5.9. </ins> The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can authentication mechanisms, ciphersuites, and infrastructure functionalities.  <ins> 5.10. </ins> It is important that multiple versions of MLS be able to coexist in the future.  Thus, MLS offers a version negotiation mechanism; this
Original text:
assume this. Users will often use multiple devices, e.g., a phone as well as a <del> laptop.  Different devices are represented as different clients with independent cryptographic state. </del>  3.

Reviewer comments:
Thanks Brendan! I'll merge this modulo the deletion of the paragraph regarding "being a member" since that was specifically discussed during an interim call.

Revised text:
assume this. Users will often use multiple devices, e.g., a phone as well as a  <ins> laptop.  The formal definition of a Group in MLS is the set of clients that have knowledge of the shared group secret established in the group key establishment phase of the protocol and have contributed to it.  Until a Member has been added to the group and contributed to the group secret in a manner verifiable by other members of the group, other members cannot assume that the Member is a member of the group.  Different devices are represented as different clients with independent cryptographic state. </ins> 3.
Original text:
Issue credentials to clients that attest to bindings between identities and signature key pairs <del> Enable a group member to verify that a credential presented by another member is valid with respect to a reference identifier </del>  Enable a group member to verify that a credential represents the <del> same application-level device as another credential </del>  A member with a valid credential authenticates its MLS messages by signing them with the private key corresponding to the public key epoch and begins the next one. In practice, there's a realistic risk of two members generating <del> Commit messages at the same time, based on the same state, and both </del>  attempting to send them to the group at the same time.  The extent to which this is a problem, and the appropriate solution, depends on the design of the Delivery Service.  Per the CAP theorem, there are two Strategies for sequencing messages in CP and AP systems are described in the next two subsections. <del> However, note that a Delivery Service could also reorder messages or provide an inconsistent view to different users not just accidentally, but maliciously.  The protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </del>  Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply

Reviewer comments:
This PR pulls in the CAP theorem-related discussion from URL which is a more helpful way to frame DS design.

Revised text:
Issue credentials to clients that attest to bindings between identities and signature key pairs  <ins> Enable a client to verify that a credential presented by another client is valid with respect to a reference identifier </ins> Enable a group member to verify that a credential represents the  <ins> same application-level device as another credential when possible </ins> A member with a valid credential authenticates its MLS messages by signing them with the private key corresponding to the public key epoch and begins the next one. In practice, there's a realistic risk of two members generating  <ins> Commit messages at the same time, based on the same counter, and both </ins> attempting to send them to the group at the same time.  The extent to which this is a problem, and the appropriate solution, depends on the design of the Delivery Service.  Per the CAP theorem, there are two Strategies for sequencing messages in CP and AP systems are described in the next two subsections.  <ins> However, note that a malicious Delivery Service could also reorder messages or provide an inconsistent view to different users.  The protocol is designed such that this only results in a group no longer being functional and the group members possibly detecting this and requesting reinitialization. </ins> Other forms of Delivery Service misbehavior are still possible that are not easy to detect.  For instance, a Delivery Service can simply
Original text:
Abstract <del> The Messaging Layer Security (MLS) protocol I-D.ietf-mls-protocol </del>  specification has the role of defining a Group Key Agreement protocol, including all the cryptographic operations and serialization/deserialization functions necessary for scalable and past epoch is received, clients use a deterministic tie-breaking policy to decide if they should continue using the Commit they originally accepted or revert and use the later one.  Note that <del> any copies of previous or forked group states MUST be deleted </del>  within a reasonable amount of time to ensure the protocol provides forward-secrecy.

Reviewer comments:
According to I-D Nits: Checking nits according to URL : The abstract seems to contain references ([I-D.ietf-mls-protocol]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 557: 'URL forked group states MUST be deleted...'
TY!
Thanks NAME

Revised text:
Abstract  <ins> The Messaging Layer Security (MLS) protocol (I-D.ietf-mls-protocol) </ins> specification has the role of defining a Group Key Agreement protocol, including all the cryptographic operations and serialization/deserialization functions necessary for scalable and past epoch is received, clients use a deterministic tie-breaking policy to decide if they should continue using the Commit they originally accepted or revert and use the later one.  Note that  <ins> any copies of previous or forked group states must be deleted </ins> within a reasonable amount of time to ensure the protocol provides forward-secrecy.
Original text:
Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism <del> necessary to negotiate the format of that content over the lifetime </del>  of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- <del> D.mahy-mls-content-neg, unless the specific application defines </del>  another mechanism which more appropriately addresses the same requirements for that application of MLS.

Reviewer comments:
Made minor changes to the section of content and framing. Updated reference draft-mahy-mls-content-neg -> draft-mahy-mls-content-adv The recommended mechanism is advertising content/media types, not a full negotiation mechanism.

Revised text:
Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism  <ins> necessary to determine the format of that content over the lifetime </ins> of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I-  <ins> D.mahy-mls-content-adv, unless the specific application defines </ins> another mechanism which more appropriately addresses the same requirements for that application of MLS.
Original text:
Clients should not be able to send messages to groups which appear to be from other Clients  4. As the MLS protocol provides an important service to users, its cryptographic keys for attachments is usually higher than for messages, hence slightly weakening the PCS guarantees for attachments. 

Reviewer comments:
As per Jan MLS meetup, malicious insiders should be considered as a potential threat, though perhaps in a restricted set of scenarios. It is probably bad if a malicious group member can trivially DoS people, for example, as in naïve ART.

Revised text:
Clients should not be able to send messages to groups which appear to be from other Clients <ins> Clients should not be able to perform trivial denials of service </ins> 4. As the MLS protocol provides an important service to users, its cryptographic keys for attachments is usually higher than for messages, hence slightly weakening the PCS guarantees for attachments. <ins> 4.2.2.4. In general we do not consider denial of service to be the responsibility of the protocol.  However, it should not be possible for anyone to perform a trivial denial of service from which it is hard to recover. --- back </ins>