Sent by servers when a client certificate is desired but none was provided by the client.  New Alert values are assigned by IANA as described in iana- considerations.

RFC 7301 defines the ALPN extension and defined a new alert "noapplicationprotocol". TLS 1.3 uses ALPN but currently misses the alert in Section 6.
URL You also need to add it to the Error Alerts section with a description.

Sent by servers when a client certificate is desired but none was provided by the client. <ins> Sent by servers when a client advertises protocols that the server does not support. </ins> New Alert values are assigned by IANA as described in iana- considerations.


In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the <del> TLS_AES_128_GCM_SHA256 cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256 cipher suites. (see cipher-suites) </del>  A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for

Note that I'm not entirely convinced we need the GCM reference because RFC 5116, which is referenced in B.4 for the suites, includes a reference to it.
ID nits complains of the following unused references: == Unused Reference: 'AES' is defined on line 4147, but no explicit reference was found in the text == Unused Reference: 'GCM' is defined on line 4305, but no explicit reference was found in the text == Unused Reference: 'PKCS6' is defined on line 4339, but no explicit reference was found in the text == Unused Reference: 'PKCS7' is defined on line 4342, but no explicit reference was found in the text == Unused Reference: 'RFC4279' is defined on line 4371, but no explicit reference was found in the text == Unused Reference: 'RFC4507' is defined on line 4392, but no explicit reference was found in the text == Unused Reference: 'RFC5054' is defined on line 4401, but no explicit reference was found in the text == Unused Reference: 'RFC5746' is defined on line 4425, but no explicit reference was found in the text == Unused Reference: 'RFC5878' is defined on line 4436, but no explicit reference was found in the text == Unused Reference: 'RFC7366' is defined on line 4479, but no explicit reference was found in the text
Looking at the editor's copy only AES and GCM remain. I think we can safely remove both because those references are picked up but the cipher suite definitions.
Strike that since we're defining some suites we need to include GCM and move it normative. We can drop the AES reference because it's picked up by the GCM reference.

In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the  <ins> TLS_AES_128_GCM_SHA256 GCM cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 GCM and TLS_CHACHA20_POLY1305_SHA256 RFC7539 cipher suites.  (see cipher-suites) </ins> A TLS-compliant application MUST support digital signatures with rsa_pkcs1_sha256 (for certificates), rsa_pss_sha256 (for


in signature-algorithms.  The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. <del> Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in RFC5246.  IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm Registry to list values 4-223 as "Reserved". </del>

Is it strictly necessary to include the following in the TLS1.3 draft: Finally, this document obsoletes the TLS HashAlgorithm Registry and the TLS SignatureAlgorithm Registry, both originally created in [RFC5246]. IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as “Reserved” and the TLS SignatureAlgorithm Registry to list values 4-223 as “Reserved”. If this text wasn't in the TLS1.3 draft everything would be fine right? If that's the case, then this text from s10 should be moved to .
Sorry, I'm not following the issue. I'm happy to move it out, though.
It kind of seems like the move of registries should be done atomically, which is ~guaranteed by doing it in the same document, but could still be done atomically if the two documents are advanced at the same time. (I, like ekr, am not really clear on what the issue is, though.)
I guess I see reserving the remaining values as essentially slamming the door on future assignments. Was that the intent? spt
I should have also added that URL already includes a paragraph indicating that Compression Method Identifiers, HashAlgorithm, and SignatureAlgorithm are obsoleted by TLS1.3; adds a note to the registries indicating as much. spt
My understanding was that yes, "don't look here, go look over there" was the idea. Any new allocation would need to go in the SignatureScheme registry, regardless of whether it also ended up in the HashAlgorithm or SignatureAlgorithm registry as well for someone's convenience. Since you have to go to the new registry anyway, it doesn't seem like there would be value in also adding it to the old/deprecated registry.
Okay that makes sense and it explains why the values in the Compression Method Identifiers isn’t also “reserved”. I guess I’m off the mind that this para could safely be move to the IANA draft.
Specially move the text to s13 of .


(*) indicates changes to the wire protocol which may require implementations to update.  draft-20 Add "post_handshake_auth" extension to negotiate post-handshake At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.  This message <del> creates a pre-shared key (PSK) binding between the ticket value and the resumption master secret. </del>  The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello by the client.  The server MUST generate a fresh value for each ticket it sends.  The value of the ticket to be used as the PSK identity.  The ticket itself is an opaque label.  It MAY either be a database lookup key or a self-encrypted and self-authenticated value. NOT depend on being able to send large quantities of padding in early data records.  Note that in principle it is possible to continue issuing new tickets which indefinitely extend the lifetime of the keying material originally derived from an initial non-PSK handshake (which was most Hash.length zero bytes.  Concretely, for the present version of TLS 1.3, secrets are added in the following order: <del> PSK (a pre-shared key established externally or a </del>  resumption_master_secret value from a previous connection) (EC)DHE shared secret (ecdhe-shared-secret-calculation)

ticket is associated with a different PSK. This provides somewhat increased security in cases where you have multiple PSKs for the same connection and one PSK is compromised. The motivation here is that in cases where the server maintains a session database rather than self-encrypted tickets, the server might delete tickets as they are used,. This change provides FS for connections which have been used, even if there are other outstanding tickets in the session cache associated with the same original connection.
Big +1 to this change as we are tentatively planning to use a session-cache-like approach for resumption and this will make it possible for us to use multiple tickets, or post-auth tickets, to the same client. As-is this is not quite possible.
Is the new ticketnonce field supposed to be somehow wired to that new hkdf-expand-label call? Right now, it seems like all the PSKs produced on the same connection will be the same. The context of that call is specified to be empty, but based on surrounding text, I guess the context should be ticketnonce?
Good catch, yeah...
It might be preferable to use Hash(NewSessionTicket) in HKDF-Expand-Label rather than ticketnonce, directly, thus binding the PSK to the whole ticket. (HKDF-Expand-Label does say it wants a hash value, anyway) Also, how big of a nonce do we really need? Up to 255 bytes feels like over-generalization. If we just made it a type "Random" (same as hellos), then its 32 bytes, plus the 4 from ticketage_add (if a message hash is used), should be enough entropy to ensure uniqueness if all generated properly. It'd also be simpler to specify "32 bytes generated by a secure random number generator" yet again rather than just say it needs a unique value and leave the generation up to the implementation to figure out.
Alternative design: add an extra derive step to the generation of the PSK that takes the PSK ID as input. A server that splits their cache can perform this step as soon as they issue the PSK. So can the client if they want to. Then there is no extra nonce on the wire (the PSK ID is the nonce). That is, for resumption, change: to:
NAME NAME interesting suggestion, but kind of limiting in that it makes it impossible to implement any kind of self-encryption scheme at all (though it works fine with identities which are just lookup keys) Consider the case where instead of a session cache, the server wants to self-encrypt using a puncturable encryption scheme (see URL and URL for background) to encrypt each ticket. With the construction I propose you would do: PSKi = HKDF-Expand(RMS, nonce) ticketi = Encrypt(Kpub, PSKi) However, in the construction you propose, this won't work because it creates a circular dependency between PSKi and ticket_i. So, I think if we want to do this, it would be more flexible to have an extra nonce. NAME my motivation for making this variable length isn't to allow the nonce to be extra large but rather to allow it to be small. It seems unlikely that one would want to produce more than 2^32 tickets and so either 4 byte counter or 8 randomly-generated bytes should be plenty, especially given that the impact of collision is just a reduction of PFS to the current state.
My thought was that in a self-encrypting scheme you would save the resumption master on the principle that the ticket decryption key is your point of exposure. It only makes sense to separate keys if you don't have something like a ticket decryption key lying around.
Right, but as I said, that doesn't apply if you have a more sophisticated self-encryption scheme, as in the examples I indicated above
Can't you implement that scheme by putting the nonce in the ticket?
I don't think so, no, because the problem is the dependency of the key on its own encryption
Oh, I see now. Those schemes could work, but unless the client is involved in the process at least to the extent that a key is separated at the client, the self-encrypted ticket would have to contain the RMS, not the i-th derived PSK. At that point any ticket is a threat to any other (the basic model we have today). I'm not thrilled by those puncturable encryption papers. Storage is cheap, especially for keys. It's globally consistent synchronization that hurts. If it were me, I'd worry less about the storage problem and more about the synchronization one. I guess that the assertion is that globally consistent state for a single user's set of MTAs is manageable.
Right, that's why we would need the nonce.
I think some sort of text stating some of the possible methods to handle the nonce is warranted, rather than leaving its generation completely unspecified. Maybe have a paragraph just describing a recommended way to set up a simple session database? Should this be discussed further on-list?
We'll certainly need to discuss on the list before merging this. I'll send something relatively soon. That said, I don't believe that the changes you propose would improve the specification. It's not our job to tell people how to generate unique values and we don't do it elsewhere in the spec where we require uniqueness.
Huh? Of course we do, e.g.: URL (per record nonce) URL (says e.g. randomly generate) Also, I'm not suggesting a hard requirement; just some sort of starting point recommendation(s).
Neither of these are solely uniqueness requirements. The first of these is a requirement for interoperability. The second is an example where it's not uniqueness that matters (in fact, it used to just say unique) and now it is specifically intended to be unpredictable, which is why we mandate it. You'll note that this is a recent change made after I realized that it was a partial security condition. Prior to this it just required uniqueness.
would it be stronger to use the entire NewSessionTicket message as the context for the PSK HDKF instead of just the nonce? This would bind any extensions as well to the resumption PSK
The HKDF output is supposed to be included in the encrypted ticket, see (e.g.) URL
NAME makes sense, nvm then
NAME alternatively we could have the client send the Hash of the NewSessionTicket message back to the server during resumption, but might be overkill.
NAME NAME OK to merge?
NAME okay to merge
Generally I like this, just one question inline.

(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-21 Add a per-ticket nonce so that each ticket is associated with a different PSK (*). </ins> draft-20 Add "post_handshake_auth" extension to negotiate post-handshake At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.  This message  <ins> creates a pre-shared key (PSK) binding between the ticket value and a secret derived from the resumption master secret. </ins> The client MAY use this PSK for future handshakes by including the ticket value in the "pre_shared_key" extension in its ClientHello by the client.  The server MUST generate a fresh value for each ticket it sends. <ins> A unique per-ticket value. </ins> The value of the ticket to be used as the PSK identity.  The ticket itself is an opaque label.  It MAY either be a database lookup key or a self-encrypted and self-authenticated value. NOT depend on being able to send large quantities of padding in early data records. <ins> The PSK associated with the ticket is computed as: Because the ticket_nonce value is distinct for each NewSessionTicket message, a different PSK will be derived for each ticket. </ins> Note that in principle it is possible to continue issuing new tickets which indefinitely extend the lifetime of the keying material originally derived from an initial non-PSK handshake (which was most Hash.length zero bytes.  Concretely, for the present version of TLS 1.3, secrets are added in the following order:  <ins> PSK (a pre-shared key established externally or derived from the </ins> resumption_master_secret value from a previous connection) (EC)DHE shared secret (ecdhe-shared-secret-calculation)


Also, candidate trickling needs to be correlated to a specific ICE negotiation session, so that if there is an ICE restart, any delayed updates for a previous session can be recognized as such and ignored <del> by the receiving party. </del>  One important aspect of Vanilla ICE is that connectivity checks for a specific foundation and component are attempted simultaneously by

NAME and NAME had an editors' discussion (see URL) about how to specify the handling of ICE restarts in the context of Trickle ICE. One possible approach would be to send a new ufrag and pwd without triggering a full offer/answer exchange, because Trickle (and ICE itself) can be used with application protocols that are not tied to O/A. There is an SDP dependency on the a= line, but we've disengaged Trickle ICE from SDP, too. Also, if the sender doesn't include a media description then a new offer might not be necessary anyway. I'm hoping that NAME can propose text...
At IETF 95, there was support for explicitly indicating which ufrag/pwd the candidate applies to. But the specifics are signaling-specific. So perhaps we should just update the text to say "SHOULD be explicit" in some way. URL
I am fine also adding to the spec a sample way of labeling them (the way Trickle for SIP does) Emil , Peter Thatcher EMAIL wrote:
By the way, this came up in the JSEP work recently, that with ICE restarts being roll-back-able, the explicit ufrag is really needed for edge cases there. We think the right solution is using a ufrag on the JS object, not on the SDP (since we also need to include it on the end of candidates message, and since it would look weird being duplicated in so many lines in the current remote description).
It looks like we already have a paragraph that indicates an implementation should have an explicit ufrag (or other correlation). Great! So, I made a PR to add some examples: URL
resolved

Also, candidate trickling needs to be correlated to a specific ICE negotiation session, so that if there is an ICE restart, any delayed updates for a previous session can be recognized as such and ignored  <ins> by the receiving party.  For example, applications that choose to signal candidates via SDP may include a ufrag value in the SDP that represents candidates (such as "a=candidate ... ufrag abc").  Or as another exmaple, WebRTC implementations may include a ufrag in the JavaScript objects that represent candidates. </ins> One important aspect of Vanilla ICE is that connectivity checks for a specific foundation and component are attempted simultaneously by


Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL domain and ROLL.  RPL Leaf: An IPv6 host that is attached to a RPL router and obtains connectivity through a RPL Destination Oriented Directed Acyclic Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a storing network on traffic that is leaving the LLN, but this document should not preclude such a future innovation.  It should just be noted that an incoming RH3 must be fully consumed, or very carefully <del> inspected. </del>  The RPI, if permitted to enter the LLN, could be used by an attacker to change the priority of a packet by selecting a different

…S and COMMENT) On December 18, 2020 at 10:42:24 AM, Pascal Thubert (pthubert) (pthubert=EMAIL) wrote: Hello Michael and all: Yes, I expected policies that would validate the right of a Leaf to participate to a DODAG ,or to remap the information from the leaf (could be the RPI, the opaque field in the EARO, or the 6-tuple) into an RPI. Yes, as I said in my response I thought it was quite common. I'm surprised to find little art to quote. Cool, we're good! Pascal Roll mailing list EMAIL URL Roll mailing list EMAIL URL

Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL domain and ROLL. <ins> Consumed: A Routing Header is consumed when the Segments Left field is zero, which indicates that the destination in the IPv6 header is the final destination of the packet and that the hops in the Routing Header have been traversed. </ins> RPL Leaf: An IPv6 host that is attached to a RPL router and obtains connectivity through a RPL Destination Oriented Directed Acyclic Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a storing network on traffic that is leaving the LLN, but this document should not preclude such a future innovation.  It should just be noted that an incoming RH3 must be fully consumed, or very carefully  <ins> inspected to match a policy that applies to this network and is correctly processed by the leaves. </ins> The RPI, if permitted to enter the LLN, could be used by an attacker to change the priority of a packet by selecting a different


Most of the use cases described herein require the use of IPv6-in- IPv6 packet encapsulation.  When encapsulating and decapsulating <del> packets, RFC 6040 [RFC6040] MUST be applied to map the setting of the explicit congestion notification (ECN) field between inner and outer headers.  Additionally, I-D.ietf-intarea-tunnels is recommended reading to explain the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling. </del>  Non-constrained uses of RPL are not in scope of this document, and applicability statements for those uses may provide different advice, encapsulation.  For simplification, this document uses the standalone term leaf to mean a RPL leaf. <del> RPL Packet Information (RPI): The abstract information that RFC6550 places in IP packets.  The term is commonly used, including in this document, to refer to the RPL Option RFC6553 that transports that abstract information in an IPv6 Hop-by-Hop Header. </del>  RPL-aware-node (RAN): A device which implements RPL.  Please note that the device can be found inside the LLN or outside LLN. Flag Day: It is a mechanism for resolving an interoperability situation (e.g. lack of interoperation between new RPI Option Type (0x23) and old RPI Option Type (0x63) nodes) by making an abrupt, <del> planned changeover from one to the other. </del>  Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- aware-nodes send information to the root about their parents.  Thus, Object) messages are all RPL Control messages but with different Code values.  A RPL Stack is shown in fig_RPLStack. <del> RPL supports two modes of Downward traffic: in storing mode (SM), it is fully stateful; in non-storing mode (Non-SM), it is fully source routed.  A RPL Instance is either fully storing or fully non-storing, i.e. a RPL Instance with a combination of a fully storing and non- storing nodes is not supported with the current specifications at the time of writing this document.  Notice that external routes are advertised (Upwards traffic) with non-storing-mode messaging even in a storing-mode network. </del>  4. When the packet arrives from Internet to 6LBR the RPI is added in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address set to the RAL) and sent to 6LR, which modifies the rank in the RPI. <del> When the packet arrives at the RAL, the IPv6-in-IPv6 header is decapsulated, the RPI is removed and the packet processed. </del>  The Storing-int2rpl shows the table that summarizes what headers are needed for this use case.

…linfo-42: (with COMMENT) Hello Ines: I believe we need Michael for the flag day terminology. I do not believe that it denotes specifically a transition but rather the fact that you need to reboot the network to effectuate that transition. After all the method of using a bit also ends up in a transition, but the network can stay up during that time. More below: From: Ines Robles Sent: jeudi 7 janvier 2021 18:50 To: Pascal Thubert (pthubert) ; Pascal Thubert Cc: Michael Richardson Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-42: (with COMMENT) Hi Michael, Pascal In the github-version the Ben's issues are addressed as follows: .... Section 2 Flag Day: In this document, refers to a transition that involves having a network with different values of RPI Option Type. Is the flag day the act of transitioning the network from one value to the other, or only the sub-case when it is a disruptive transition, or ...? transitioning the network from one value to the other. Section 3 routed. A RPL Instance is either fully storing or fully non-storing, i.e. a RPL Instance with a combination of storing and non-storing nodes is not supported with the current specifications at the time of writing this document. (I assume there is no conflict between this statement and the behavior described in Section 4.1.1 whereby external routes are advertised with non-storing-mode messaging even in a storing-mode network.) Added text to avoid confusion: RPL supports two modes of Downward traffic: in storing mode (SM), it is fully stateful; in non-storing mode (Non-SM), it is fully source routed. A RPL Instance is either fully storing or fully non-storing, i.e. a RPL Instance with a combination of a fully storing and non-storing nodes is not supported with the current specifications at the time of writing this document. Notice that external routes are advertised (Upwards traffic) with non-storing-mode messaging even in a storing-mode network. Adding “internal” RPL supports two modes of Downward traffic: -> RPL supports two modes of Downward internal traffic: Section 4.1.1 In order to enable IP-in-IP all the way to a 6LN, it is beneficial that the 6LN supports decapsulating IP-in-IP, but that is not assumed by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a packet SHOULD terminate the tunnel at a parent 6LR unless it is aware that the RUL supports IP-in-IP decapsulation. Is there anything useful to say about how the Root would know that the RUL supports IP-in-IP decapsulation? ("No" is a valid answer :) Not in the scope of this document. Section 4.3 This modification is required in order to be able to decompress the RPL Option with the new Option Type of 0x23. nit(?): is it the RPL Option or the entire header that is decompressed? decompress the option Section 6 For traffic leaving a RUL, if the RUL adds an opaque RPI then the description of the RAL applies. The 6LR as a RPL border router SHOULD rewrite the RPI to indicate the selected Instance and set the flags. I'm not sure that I fully understand this point (specifically, "the description of the RAL applies"). Similar text also appears in the Security Considerations. the description of the RAL applies, means that the 6LR has to modify the RPI that it receives from the leaf. For clarification we updated to: For traffic leaving a RUL, if the RUL adds an opaque RPI then the 6LR as a RPL border router SHOULD rewrite the RPI to indicate the selected Instance and set the flags. Thanks, Ines. Benjamin Kaduk via Datatracker wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-roll-useofrplinfo-42: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Unfortunately, I only had time to review the diff from the -29 (that addressed my previous batch of comments) and the -42, and was not able to attempt to look closely at the new tables and their depiction of the added/modified/removed/untouched headers. As such, I do not have many comments. Since we are marking MOP value 7 as reserved, do we expect this document to be listed as a reference for that entry in the registry? Section 1 Most of the use cases described therein require the use of IPv6-in- nit: s/therein/herein/ Section 2 Flag Day: In this document, refers to a transition that involves having a network with different values of RPI Option Type. Is the flag day the act of transitioning the network from one value to the other, or only the sub-case when it is a disruptive transition, or ...? Section 3 routed. A RPL Instance is either fully storing or fully non-storing, i.e. a RPL Instance with a combination of storing and non-storing nodes is not supported with the current specifications at the time of writing this document. (I assume there is no conflict between this statement and the behavior described in Section 4.1.1 whereby external routes are advertised with non-storing-mode messaging even in a storing-mode network.) Section 4.1.1 In order to enable IP-in-IP all the way to a 6LN, it is beneficial that the 6LN supports decapsulating IP-in-IP, but that is not assumed by [RFC8504]. If the 6LN is a RUL, the Root that encapsulates a packet SHOULD terminate the tunnel at a parent 6LR unless it is aware that the RUL supports IP-in-IP decapsulation. Is there anything useful to say about how the Root would know that the RUL supports IP-in-IP decapsulation? ("No" is a valid answer :) Section 4.3 This modification is required in order to be able to decompress the RPL Option with the new Option Type of 0x23. nit(?): is it the RPL Option or the entire header that is decompressed? Section 6 For traffic leaving a RUL, if the RUL adds an opaque RPI then the description of the RAL applies. The 6LR as a RPL border router SHOULD rewrite the RPI to indicate the selected Instance and set the flags. I'm not sure that I fully understand this point (specifically, "the description of the RAL applies"). Similar text also appears in the Security Considerations. Section 8.2.4 There seem to be some changes in the table compared to the -29; were these verified to be correct? Section 12 Also, this applies in the case where the leaf is aware of the RPL instance and passes a correct RPI, the 6LR needs a configuration that allows that leaf to inject in that instance. nit: the second comma should probably be a colon or em dash.
Many thanks Ines! With I m good to green light this and the other 2 drafts (RUL and turnon). Are we ready to publish 43? Michael ? Take care , Pascal
Pascal Thubert wrote: I'm good.

Most of the use cases described herein require the use of IPv6-in- IPv6 packet encapsulation.  When encapsulating and decapsulating  <ins> packets, RFC6040 MUST be applied to map the setting of the explicit congestion notification (ECN) field between inner and outer headers. Additionally, I-D.ietf-intarea-tunnels is recommended reading to explain the relationship of IP tunnels to existing protocol layers and the challenges in supporting IP tunneling. </ins> Non-constrained uses of RPL are not in scope of this document, and applicability statements for those uses may provide different advice, encapsulation.  For simplification, this document uses the standalone term leaf to mean a RPL leaf.  <ins> RPL Packet Information (RPI): The information defined abstractly in RFC6550 to be placed in IP packets.  The term is commonly used, including in this document, to refer to the RPL Option RFC6553 that transports that abstract information in an IPv6 Hop-by-Hop Header. RFC8138 provides an alternate (more compressed) formating for the same abstract information. </ins> RPL-aware-node (RAN): A device which implements RPL.  Please note that the device can be found inside the LLN or outside LLN. Flag Day: It is a mechanism for resolving an interoperability situation (e.g. lack of interoperation between new RPI Option Type (0x23) and old RPI Option Type (0x63) nodes) by making an abrupt,  <ins> disruptive changeover from one to the other. </ins> Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- aware-nodes send information to the root about their parents.  Thus, Object) messages are all RPL Control messages but with different Code values.  A RPL Stack is shown in fig_RPLStack.  <ins> RPL supports two modes of Downward internal traffic: in storing mode (SM), it is fully stateful; in non-storing mode (Non-SM), it is fully source routed.  A RPL Instance is either fully storing or fully non- storing, i.e. a RPL Instance with a combination of a fully storing and non-storing nodes is not supported with the current specifications at the time of writing this document.  External routes are advertised with non-storing-mode messaging even in a storing mode network, see nnstext </ins> 4. When the packet arrives from Internet to 6LBR the RPI is added in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address set to the RAL) and sent to 6LR, which modifies the rank in the RPI.  <ins> When the packet arrives at the RAL, the packet is decapsulated, which removes the RPI before the packet is processed. </ins> The Storing-int2rpl shows the table that summarizes what headers are needed for this use case.


Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane <del> draft-ietf-roll-useofrplinfo-43 </del>  Abstract An LLN with hostile nodes within it would not be protected against impersonation with the LLN by entry/exit filtering. <del> The RH3 header usage described here can be abused in equivalent ways (to disguise the origin of traffic and attack other nodes) with an IPv6-in-IPv6 header to add the needed RH3 header.  As such, the attacker's RH3 header will not be seen by the network until it reaches the end host, which will decapsulate it.  An end-host should be suspicious about an RH3 header which has additional hops which have not yet been processed, and SHOULD ignore such a second RH3 header. In addition, the LLN will likely use RFC8138 to compress the IPv6-in- IPv6 and RH3 headers.  As such, the compressor at the RPL-root will see the second RH3 header and MAY choose to discard the packet if the RH3 header has not been completely consumed.  A consumed (inert) RH3 header could be present in a packet that flows from one LLN, crosses the Internet, and enters another LLN.  As per the discussion in this document, such headers do not need to be removed.  However, there is no case described in this document where an RH3 is inserted in a non- storing network on traffic that is leaving the LLN, but this document should not preclude such a future innovation.  It should just be noted that an incoming RH3 must be fully consumed, or very carefully inspected to match a policy that applies to this network and is correctly processed by the leaves. </del>  The RPI, if permitted to enter the LLN, could be used by an attacker to change the priority of a packet by selecting a different

…linfo-42 What about : The RH3 header usage described here can be abused in equivalent ways. An external attacker may form a packet with an RH3 that is not fully consumed and encapsulate it to hide the RH3 from intermediate nodes and disguise the origin of traffic. As such, the attacker's RH3 header will not be seen by the network until it reaches the destination, which will decapsulate it. As indicated in section 4.2 of , RPL routers are responsible for ensuring that an SRH is only used between RPL routers. As such, if there is an RH3 that is not fully consumed in the encapsulated packet, the node that decapsulates it MUST ensure that the outer packet was originated in the RPL domain and drop the packet otherwise. Also, as indicated by section 2 of , RPL Border Routers "do not allow datagrams carrying an SRH header to enter or exit a RPL routing domain". This sentence must be understood as concerning non-fully-consumed packets. A consumed (inert) RH3 header could be present in a packet that flows from one LLN, crosses the Internet, and enters another LLN. As per the discussion in this document, such headers do not need to be removed. However, there is no case described in this document where an RH3 is inserted in a non-storing network on traffic that is leaving the LLN, but this document should not preclude such a future innovation. In short, a packet that crosses the border of the RPL domain MAY carry and RH3, and if so, that RH3 MUST be fully consumed. From: Pascal Thubert (pthubert) Sent: jeudi 14 janvier 2021 14:12 To: Ines Robles Cc: Michael Richardson ; Pascal Thubert Subject: RE: Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-42: (with COMMENT) We must do that, for sure. I’m reviewing the text that’s really hard to understand… From: Ines Robles Sent: jeudi 14 janvier 2021 13:53 To: Pascal Thubert (pthubert) Cc: Michael Richardson ; Pascal Thubert Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-42: (with COMMENT) Thank you very much Pascal and Michael, I am available tomorrow after 3pm UTC. Ok, from the discussion: " Erik recommend referring to RFC 6554 S4.2 for how to handle RH3's if the node is also a RPL-aware router and say it MUST drop the packet if segments left is non-zero and it's not a RPL-aware router." maybe we should do just that, would it be ok? thanks, ines. Pascal Thubert (pthubert) wrote: I had a chat with Alvaro; he's waiting for the DISCUSS from Erik. Sadlt 43 does not address that DISCUSS. The offending text is " The RH3 header usage described here can be abused in equivalent ways (to disguise the origin of traffic and attack other nodes) with an IPv6-in-IPv6 header to add the needed RH3 header. As such, the attacker's RH3 header will not be seen by the network until it reaches the end host, which will decapsulate it. An end-host should be suspicious about an RH3 header which has additional hops which have not yet been processed, and SHOULD ignore such a second RH3 header. In addition, the LLN will likely use [RFC8138] to compress the IPv6- in-IPv6 and RH3 headers. As such, the compressor at the RPL-root will see the second RH3 header and MAY choose to discard the packet if the RH3 header has not been completely consumed. A consumed (inert) RH3 header could be present in a packet that flows from one LLN, crosses the Internet, and enters another LLN. As per the discussion in this document, such headers do not need to be removed. However, there is no case described in this document where an RH3 is inserted in a non-storing network on traffic that is leaving the LLN, but this document should not preclude such a future innovation. It should just be noted that an incoming RH3 must be fully consumed, or very carefully inspected to match a policy that applies to this network and is correctly processed by the leaves. " This text is hard to read and makes little sense for the most part since the incoming packet from the Internet will be encapsulated so there will not be 2 RH2 even if the incoming packet has one. I'm on it, will propose a pull, but happy to discuss what we really want to say. My answer is to indicate that there is encaps and that the inner packet MUST be consumed as Erik says when processed by a Host. Since the root does not know whether the leaf is a host or an external router, there's little we can do beyond applying a policy. Thoughts? Call? Pascal

Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane  <ins> draft-ietf-roll-useofrplinfo-44 </ins> Abstract An LLN with hostile nodes within it would not be protected against impersonation with the LLN by entry/exit filtering.  <ins> The RH3 header usage described here can be abused in equivalent ways. An external attacker may form a packet with an RH3 that is not fully consumed and encapsulate it to hide the RH3 from intermediate nodes and disguise the origin of traffic.  As such, the attacker's RH3 header will not be seen by the network until it reaches the destination, which will decapsulate it.  As indicated in section 4.2 of RFC6554, RPL routers are responsible for ensuring that an SRH is only used between RPL routers.  As such, if there is an RH3 that is not fully consumed in the encapsulated packet, the node that decapsulates it MUST ensure that the outer packet was originated in the RPL domain and drop the packet otherwise. Also, as indicated by section 2 of RFC6554, RPL Border Routers "do not allow datagrams carrying an SRH header to enter or exit a RPL routing domain".  This sentence must be understood as concerning non- fully-consumed packets.  A consumed (inert) RH3 header could be present in a packet that flows from one LLN, crosses the Internet, and enters another LLN.  As per the discussion in this document, such headers do not need to be removed.  However, there is no case described in this document where an RH3 is inserted in a non-storing network on traffic that is leaving the LLN, but this document should not preclude such a future innovation. In short, a packet that crosses the border of the RPL domain MAY carry and RH3, and if so, that RH3 MUST be fully consumed. </ins> The RPI, if permitted to enter the LLN, could be used by an attacker to change the priority of a packet by selecting a different


Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL Domain and ROLL. <del> RPL-aware-node: A device which implements RPL.  Please note that the device can be found inside the LLN or outside LLN. </del>  <del> RPL-Aware-Leaf(RAL): A RPL-aware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG. </del>  RPL-unaware-node: A device which does not implement RPL, thus the device is not-RPL-aware.  Please note that the device can be found inside the LLN. <del> RPL-Unaware-Leaf(RUL): A RPL-unaware-node which is a leaf of a (Destination Oriented Directed Acyclic Graph) DODAG. </del>  6LoWPAN Node (6LN): RFC6775 defines it as: "A 6LoWPAN node is any host or router participating in a LoWPAN.  This term is used when The final node should be able to remove one or more IPv6-in-IPv6 headers which are all addressed to it.  The final node does not process the RPI, the node ignores the RPI.  Further details about <del> this are mentioned in I-D.thubert-roll-unaware-leaves, which specifies RPL routing for a 6LN acting as a plain host and not being aware of RPL. </del>  The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to zero in order to aid in compression RFC6437.

RPL was missing a good definition of a LEAF. this clarifies.
updated the deprecated ref to rul draft

Terminology defined in RFC7102 applies to this document: LLN, RPL, RPL Domain and ROLL.  <ins> RPL Leaf: An IPv6 host that is attached to a RPL router and obtains connectivity through a RPL Destination Oriented Directed Acyclic Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a consumed Routing Header and as an IPv6 host, it is expected to ignore a Hop-by-Hop header.  It results that a RPL Leaf can correctly receive a packet with RPL artifacts.  On the other hand, a RPL Leaf is not expected to generate RPL artifacts or to support IP-in-IP encapsulation.  For simplification, this document uses the standalone term leaf to mean a RPL leaf. </ins>  <ins> RPL-aware-node (RAN): A device which implements RPL.  Please note that the device can be found inside the LLN or outside LLN. RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf. </ins> RPL-unaware-node: A device which does not implement RPL, thus the device is not-RPL-aware.  Please note that the device can be found inside the LLN.  <ins> RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf. </ins> 6LoWPAN Node (6LN): RFC6775 defines it as: "A 6LoWPAN node is any host or router participating in a LoWPAN.  This term is used when The final node should be able to remove one or more IPv6-in-IPv6 headers which are all addressed to it.  The final node does not process the RPI, the node ignores the RPI.  Further details about  <ins> this are mentioned in I-D.ietf-roll-unaware-leaves, which specifies RPL routing for a 6LN acting as a plain host and not being aware of RPL. </ins> The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to zero in order to aid in compression RFC6437.


serving.  An isolated LoWPAN also contains a 6LBR in the network, which provides the prefix(es) for the isolated network." <del> Flag Day: A transition that involves having a network with different values of RPI Option Type.  Thus the network does not work correctly (Lack of interoperation). </del>  Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- aware-nodes send information to the root about their parents.  Thus, A RUL is a special case of external target when the target is actually a host and it is known to support a consumed Routing Header and to ignore a HbH header as prescribed by RFC8200.  The target may <del> have been learned through as a host route or may have been registered to the 6LR using RFC8505. </del>  In order to enable IP-in-IP all the way to a 6LN, it is beneficial that the 6LN supports decapsulating IP-in-IP, but that is not assumed The leaves marked as RUL (G and J) are devices which do not speak RPL at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/ <del> DAC and efficient-ND only to participate in the network RFC6775.  In </del>  the document these leaves (G and J) are also referred to as an IPv6 node. outer IP header.  The new header is placed after this new outer IP header. <del> A corollary is that an RH3 or RPL Option can only be removed by an intermediate router if it is placed in an encapsulating IPv6 Header, which is addressed TO the intermediate router.  When it does so, the </del>  whole encapsulating header must be removed.  (A replacement may be added).  This sometimes can result in outer IP headers being addressed to the next hop router using link-local address. the RPI down to three bytes or less removes much of the pressure to optimize this any further I-D.ietf-anima-autonomic-control-plane. <del> The earlier examples are more extensive to make sure that the process is clear, while later examples are more concise. </del>  <del> The uses cases are delineated based on the following requirements: </del>  The RPI has to be in every packet that traverses the LLN. addressed to: (1) the final destination (the RAL node that is the target (tgt)), (2) the "root", or (3) the 6LR parent of a RUL. <del> In cases where no IPv6-in-IPv6 header is needed, the column states as "No".  If the IPv6-in-IPv6 header is needed, the column shows "must". </del>  In all cases, the RPI is needed, since it identifies inconsistencies (loops) in the routing topology.  In general, the RH3 is not needed because it is not used in storing mode.  However, there is one scenario (from the root to the RUL in SM) where the RH3 can be used <del> to indicate the RUL (Storing-root2notrplnoIPIP). </del>  The leaf can be a router 6LR or a host, both indicated as 6LN.  The root refers to the 6LBR (see fig_CommonTopology). number of routers (6LR) that the packet goes through from the 6LBR (Node A) to the RUL (Node G). <del> The 6LBR will insert an RPI, encapsulated in a IPv6-in-IPv6 header. The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL (6LR_n).  The 6LR parent of the RUL removes the header and sends the packet to the RUL. </del>  The Storing-root2notrpl summarizes what headers are needed for this use case. routers (6LR) that the packet goes through from the RUL to the 6LBR. When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), <del> the 6LR_1 will insert an RPI, encapsulated in a IPv6-in-IPv6 header. The IPv6-in-IPv6 header is addressed to the root (Node A).  The root removes the header and processes the packet. </del>  The Storing-notrpl2root shows the table that summarizes what headers are needed for this use case where the IPv6-in-IPv6 header is in-IPv6 header to the root.  Thus, the root removes the RPI and send the packet to the Internet. <del> No IPv6-in-IPv6 header is required. </del> Note: In this use case, it is used a node as a leaf, but this use case can be also applicable to any RPL-aware-node type (e.g. 6LR)

This covers the text from the beginning up to Section 7.2.1. These were reviewed with Pascal on March 26th. I will continue my review from Section 7.2.2 forward. More trivial editorial suggestions to follow, as well.
Many thanks for these fixs.

serving.  An isolated LoWPAN also contains a 6LBR in the network, which provides the prefix(es) for the isolated network."  <ins> Flag Day: In this document, refers to a transition that involves having a network with different values of RPI Option Type. </ins> Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- aware-nodes send information to the root about their parents.  Thus, A RUL is a special case of external target when the target is actually a host and it is known to support a consumed Routing Header and to ignore a HbH header as prescribed by RFC8200.  The target may  <ins> have been learned through an external routing protocol or may have been registered to the 6LR using RFC8505. </ins> In order to enable IP-in-IP all the way to a 6LN, it is beneficial that the 6LN supports decapsulating IP-in-IP, but that is not assumed The leaves marked as RUL (G and J) are devices which do not speak RPL at all (not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/  <ins> DAC and 6LoWPAN ND only to participate in the network RFC8505.  In </ins> the document these leaves (G and J) are also referred to as an IPv6 node. outer IP header.  The new header is placed after this new outer IP header.  <ins> A corollary is that an intermediate router can remove an RH3 or RPL Option only if it is placed in an encapsulating IPv6 Header that is addressed TO this intermediate router.  When doing the above, the </ins> whole encapsulating header must be removed.  (A replacement may be added).  This sometimes can result in outer IP headers being addressed to the next hop router using link-local address. the RPI down to three bytes or less removes much of the pressure to optimize this any further I-D.ietf-anima-autonomic-control-plane.  <ins> Throughout the following subsections, the examples are described in more details in the first subsections, and more concisely in the later ones. </ins>  <ins> The uses cases are delineated based on the following IPV6 and RPL mandates: </ins> The RPI has to be in every packet that traverses the LLN. addressed to: (1) the final destination (the RAL node that is the target (tgt)), (2) the "root", or (3) the 6LR parent of a RUL.  <ins> In cases where no IPv6-in-IPv6 header is needed, the column states "No", and the destination is N/A (Not Applicable).  If the IPv6-in- IPv6 header is needed, the column shows "must". </ins> In all cases, the RPI is needed, since it identifies inconsistencies (loops) in the routing topology.  In general, the RH3 is not needed because it is not used in storing mode.  However, there is one scenario (from the root to the RUL in SM) where the RH3 can be used  <ins> to point at the RUL (Storing-root2notrplnoIPIP). </ins> The leaf can be a router 6LR or a host, both indicated as 6LN.  The root refers to the 6LBR (see fig_CommonTopology). number of routers (6LR) that the packet goes through from the 6LBR (Node A) to the RUL (Node G).  <ins> The 6LBR will encapsulate the packet in an IPv6-in-IPv6 header, and prepend an RPI.  The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL (6LR_n).  The 6LR parent of the RUL removes the header and sends the packet to the RUL. </ins> The Storing-root2notrpl summarizes what headers are needed for this use case. routers (6LR) that the packet goes through from the RUL to the 6LBR. When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E),  <ins> the 6LR_1 will insert encapsulate the packet in an IPv6-in-IPv6 header and prepend an RPI.  The IPv6-in-IPv6 header is addressed to the root (Node A).  The root removes the header and processes the packet. </ins> The Storing-notrpl2root shows the table that summarizes what headers are needed for this use case where the IPv6-in-IPv6 header is in-IPv6 header to the root.  Thus, the root removes the RPI and send the packet to the Internet.  Note: In this use case, it is used a node as a leaf, but this use case can be also applicable to any RPL-aware-node type (e.g. 6LR)


merge outstanding pull requests. Editors SHOULD create a new Internet-Draft submission two weeks prior <del> to every session (see Section 7.1 of RFC2418).  Though discussion could use the current version of a document from version control, participants in a session can't be expected to monitor changes to documents in real-time; a published Internet-Draft ensures that there is a common, stable state that is known to all participants. </del>  Revisions used to generate documents that are submitted as Internet- Drafts SHOULD be tagged in repositories to provide a record of volume of activity to follow.  Participants who wish to limit this time commitment might follow GitHub activity selectively, either by following only specific issues or by occasionally reviewing the state <del> of the document.  Chairs are reminded that assessing consensus based on GitHub content alone cannot be assumed to reach all interested participants. </del>  A Working Group chair MUST consult the Working Group mailing list for any issue that is potentially contentious.  Relying on input provided through GitHub alone might result in gaining input from a narrower set of participants.  This includes important milestones like Working Group Last-Call, where review from the widest possible audience <del> ensures a higher quality document.  Managing input from multiple sources in assessing consensus is similar to what is needed when balancing mailing list discussion versus in-person meeting discussion. </del>  <del> It is expected that technical decisions will be made based on discussion and interaction on GitHub.  This is especially the case during early stages of development of a document.  Any decisions are ultimately confirmed through review, and ultimately, through Working Group Last Call (see Section 7.4 of RFC2418). </del>  The use of issues and labels has proven to be effective in managing contentious issues.  Explicitly labeling closed issues to explicitly

This has two commits: Unpack "session" a little more to make it clear that this isn't just IETF meetings. Explain that participation on GitHub isn't the only possible input, and the effect that this has on assessing WG consensus.

merge outstanding pull requests. Editors SHOULD create a new Internet-Draft submission two weeks prior  <ins> to every session, which includes IETF meetings, other in-person meetings, and telephone or video conferences (see Section 7.1 of RFC2418).  Though discussion could use the current version of a document from version control, participants in a session can't be expected to monitor changes to documents in real-time; a published Internet-Draft ensures that there is a common, stable state that is known to all participants. </ins> Revisions used to generate documents that are submitted as Internet- Drafts SHOULD be tagged in repositories to provide a record of volume of activity to follow.  Participants who wish to limit this time commitment might follow GitHub activity selectively, either by following only specific issues or by occasionally reviewing the state  <ins> of the document.  Other participants might not use GitHub at all. Chairs are reminded that assessing consensus based on GitHub content alone cannot be assumed to reach all interested participants. Chairs MUST consider input from all discussion venues when assessing consensus including GitHub, mailing lists, and in-person meetings. Each venue has different selection biases that might need to be considered. </ins> A Working Group chair MUST consult the Working Group mailing list for any issue that is potentially contentious.  Relying on input provided through GitHub alone might result in gaining input from a narrower set of participants.  This includes important milestones like Working Group Last-Call, where review from the widest possible audience  <ins> ensures a higher quality document. </ins>  <ins> If permitted, GitHub will be used for technical discussion and decisions, especially during early stages of development of a document.  Any decisions are ultimately confirmed through review, and ultimately, through Working Group Last Call (see Section 7.4 of RFC2418). </ins> The use of issues and labels has proven to be effective in managing contentious issues.  Explicitly labeling closed issues to explicitly


changes from a fork (or any branch) into their copy. Editors SHOULD make pull requests for all substantial changes rather <del> than committing directly to the "master" branch of the repository. Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </del>  This document assumes that there is a unified effort on a document, all concentrated on a git "master" branch.  More

Section 4.2 says "Editors SHOULD make pull requests for all substantial changes rather than committing directly to the "master" branch of the repository." Adding a short explanation will help make this more likely to happen.

changes from a fork (or any branch) into their copy. Editors SHOULD make pull requests for all substantial changes rather  <ins> than committing directly to the "master" branch of the repository.  A pull request creates an artifact that records the reasons for changes and provides other contributors with an opportunity to review the change.  Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </ins> This document assumes that there is a unified effort on a document, all concentrated on a git "master" branch.  More


This document is meant as a supplement to existing Working Group practices.  It provides guidance to Working Group chairs and participants on how they can best use GitHub within the framework <del> established by RFC 2418 RFC2418.  The small number of rules in this document are there to ensure common usage patterns between Working Groups and to avoid issues that have been encountered in the past. </del>  A companion document, GH-CONFIG, describes administrative processes that support the practices described in this document. For both sets of users, this document aims to provide some amount of advice on practices that have proven to be effective.  1.5. The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are

For , but not all of it.
Some working groups use GitHub to manage changes to charters or other working group materials, like agendas and presentations for sessions. I'd suggest that no great amount of detail is needed because these aren't the primary focus of the document, but it probably should include at least a passing mention of these uses and acknowledge that they are permitted.
Discussed in Singapore; MT to add text.
Closed in .
How this fits into existing processes is something that needs more thorough investigation if we're publishing an RFC on this.
Discussed in Singapore; no objections, merged, and closing.

This document is meant as a supplement to existing Working Group practices.  It provides guidance to Working Group chairs and participants on how they can best use GitHub within the framework  <ins> established by RFC 2418 RFC2418.  This document aims to establish norms that reduce the variation in usage patterns between different Working Groups and to avoid issues that have been encountered in the past. </ins> A companion document, GH-CONFIG, describes administrative processes that support the practices described in this document. For both sets of users, this document aims to provide some amount of advice on practices that have proven to be effective. <ins> This document only aims to address use of GitHub in developing documents.  Working Groups could choose to use the tool to aid in managing their charter or session materials such as agendas, minutes, and presentations.  Though the advice here might apply more broadly, using GitHub to manage other material is out of scope for this document. </ins> 1.5. The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are


GitHub prominently links to the CONTRIBUTING file on certain pages. This file SHOULD be used in preference to the README for information <del> that new contributors need.  A link to the CONTRIBUTING file from the README is advised. </del>  In addition to Working Group policies, notices on repositories MUST <del> include citations for BCPs 78 and 79 (COPYRIGHT, IPR) and other IETF contribution policies.  A copy or reference to the IETF Note Well [6] is ideal. </del>  3. A document editor can still use GitHub independently for documents that they edit, even if the Working Group does not expressly choose <del> to use GitHub.  Any such public repository MUST follow the guidelines in BCPs 78 and 79 (COPYRIGHT, IPR) and bear notices to that effect. This recognizes that editors have traditionally chosen their own methods for managing the documents they edit but preserves the need for contributors to understand their obligations with respect to IETF processes. </del>  3.2.

This consolidates text about notices in the "communicating policies" section, which seems most appropriate.
Thanks!

GitHub prominently links to the CONTRIBUTING file on certain pages. This file SHOULD be used in preference to the README for information  <ins> that new contributors need.  The README SHOULD contain a link to the CONTRIBUTING file. </ins> In addition to Working Group policies, notices on repositories MUST  <ins> include citations for the IETF Note Well [6]. </ins> 3. A document editor can still use GitHub independently for documents that they edit, even if the Working Group does not expressly choose  <ins> to use GitHub.  Any such public repository MUST follow the IETF Note Well and bear notices; see notices.  This recognizes that editors have traditionally chosen their own methods for managing the documents they edit but preserves the need for contributors to understand their obligations with respect to IETF processes. </ins> 3.2.


A companion document, GH-CONFIG, describes administrative processes that support the practices described in this document.  1.1. Version control systems are a critical component of software Organizations are a way of forming groups of contributors on GitHub. Each Working Group SHOULD create a new organization for the Working Group.  A Working Group organization SHOULD be named consistently so <del> that it can be found.  For instance, the name could be ietf-<wgname> or ietf-<wgname>-wg. </del>  A single organization SHOULD NOT be used for all IETF activity, or all activity within an area.  Large organizations create too much changes from a fork (or any branch) into their copy. Editors SHOULD make pull requests for all substantial changes rather <del> than committing directly to the "master" branch of the repository.  A pull request creates an artifact that records the reasons for changes and provides other contributors with an opportunity to review the change.  Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </del>  This document assumes that there is a unified effort on a document, all concentrated on a git "master" branch.  More Widespread use of git reduces the exposure to a system failure because the primary repository is replicated in multiple locations. This includes hosted web pages; the content of web pages is <del> maintained as a branch in the main repository.  Maintaining a mirror of a repository that is hosted on GitHub is relatively simple and might be considered as a way to provide a backup for the primary repository. </del>  However, other information maintained on GitHub is more vulnerable to loss.  This includes issues and discussion on those issues,

See URL cc NAME I have reviewed draft-ietf-git-using-github-03 in preparation for IETF last call. The document is almost ready for LC. I have just a couple of substantive questions and suggestions to be answered before initiating the LC. I’ve also included some nits that should be resolved together with any last call comments. === Substantive comments === == General == Should there be some words in this document about how research groups might draw inspiration from this document, but that specific guidance for research groups is out of scope? == Section 2.1 == draft-ietf-git-github-wg-configuration settled on the naming convention ietf-wg- so this document needs to be updated to align with that. == Section 4.2 == Do you want to say a few words about who determines what constitutes a "substantial" change (or add a forward reference to Section 5 and provide some uniform statement about it there)? For example, might some WGs determine that anything non-editorial is substantial (also discussed in 5.3.2)? Whose call would that be? == Section 4.3 == Should we see if the secretariat can setup server infrastructure to support github-notify-ml for WGs that want it, and have a process whereby WGs can request support for it? This would imply changes to draft-ietf-git-github-wg-configuration rather than to this document, but I figured I would ask while I'm reviewing this. == Section 10 == I'd like to suggest: OLD Maintaining a mirror of a repository that is hosted on GitHub is relatively simple and might be considered as a way to provide a backup for the primary repository. NEW Maintaining a mirror of a repository that is hosted on GitHub is relatively simple and is specified in [GH-CONFIG] to provide IETF-hosted backups for WG repositories. == Nits == Section 1: Perhaps you should add a citation to URL on first use of Github. Section 1.1: Same comment as above, adding a citation for Git might be useful for completeness/posterity. Section 1.4: s/does require/requires/ Section 3: s/accomplish the Charter/accomplish the charter objectives/ Section 3.1: s/Working Group Chairs that decide/Working Group Chairs who decide/ Section 3.4: You might want to clarify what you mean by text-based (some people might interpret it as documents being submitted in binary or something ... better to be clear) Section 4.1.2: "Restrictions on closing issues are generally not advisable until a document has reached a certain degree of maturity." This is a little vague. Perhaps you mean "Restrictions on who can close an issue"? Section 4.2: s/how they manage changes./how they manage changes amongst themselves./ Section 6: s/MAY request the creation of an Internet-Draft at any time/MAY request a revision of an Internet-Draft being managed on Github at any time/ Section 7: s/GitHub, mailing lists, and in-person meetings/GitHub, mailing lists, interim meetings, and IETF meetings/ Section 7: s/explicitly identify/identify/ Section 8: s/For a document that use/For a document that uses/ Section 9: s/that raises what a new issue/that raises a new issue/ Thanks, Alissa

A companion document, GH-CONFIG, describes administrative processes that support the practices described in this document. <ins> Although similar, guidance for IRTF Research Groups is out of scope for this document.  However, such groups may draw inspiration for GitHub use from the contents herein. </ins> 1.1. Version control systems are a critical component of software Organizations are a way of forming groups of contributors on GitHub. Each Working Group SHOULD create a new organization for the Working Group.  A Working Group organization SHOULD be named consistently so  <ins> that it can be found.  For instance, the name could be ietf- wg-<wgname>, as recommended in GH-CONFIG. </ins> A single organization SHOULD NOT be used for all IETF activity, or all activity within an area.  Large organizations create too much changes from a fork (or any branch) into their copy. Editors SHOULD make pull requests for all substantial changes rather  <ins> than committing directly to the "master" branch of the repository. See mature-documents for discussion on what constitutes a substantial change.  A pull request creates an artifact that records the reasons for changes and provides other contributors with an opportunity to review the change.  Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </ins> This document assumes that there is a unified effort on a document, all concentrated on a git "master" branch.  More Widespread use of git reduces the exposure to a system failure because the primary repository is replicated in multiple locations. This includes hosted web pages; the content of web pages is  <ins> maintained as a branch in the main repository.  As specified in GH- CONFIG, maintaining a mirror of a repository hosted on GitHub provides IETF-hosted backups for WG repositories. </ins> However, other information maintained on GitHub is more vulnerable to loss.  This includes issues and discussion on those issues,


GitHub is a service operated at https://github.com/ [5].  GitHub provides centralized storage for git repositories.  GitHub is freely <del> accessible on the open Internet, albeit currently only via IPv4. </del>  <del> GitHub provides a simplified and integrated interface to not only git, but also provides basic user management, an issue tracker, associated wikis, project hosting, and other features. </del>  There are a large number of projects at GitHub and a very large community of contributors.  One way in which some IETF Working Groups have benefited is through increased numbers of reviews and associated <del> issues, along with other improvements that come from broader participation by facilitating those in the community to participate. </del>  1.3. 1.5. <del> The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are used in this document.  It's not shouting; when they are capitalized, they have the special meaning defined in BCP 14 RFC2119 RFC8174. </del>  2. interest in using GitHub and making a consensus call to determine if the proposed policy and use is acceptable. <del> Chairs MUST involve Area Directors in any decision to use GitHub for anything more than managing drafts. </del>  3.1. consensus MUST NOT be reopened unless new information is presented. For long-running work items, new contributors often raise issues that <del> have already been resolved.  Chairs need to assess whether the arguments offered represent new information or not.  This can require some discussion to determine accurately.  Resolved issues MUST remain closed unless there is consensus to reopen an issue. </del>  4.2. <del> Pull requests are the GitHub feature that allow users to request changes to a repository.  A user does not need to have write access to a repository to create a pull request.  A user can create a "fork", or copy, of any public repository.  The user has write access to their own fork, allowing them to make local changes.  A pull request asks the owner of a repository to merge a specific set of changes from a fork (or any branch) into their copy. </del>  Editors SHOULD make pull requests for all substantial changes rather than committing directly to the "master" branch of the repository. In addition to the features that pull requests share with issues, users can also review the changes in a pull request.  This is a <del> valuable feature, but it has some issues. </del>  Comments in a review other than a summary are attached to specific lines of the proposed change.  Such comments can be hard or are tracked and can be audited.  Within the usual Working Group process it is expected that Internet-Drafts will receive regular review.  Finally, process checkpoints like Working Group Last Call <del> (WGLC; Section 7.4 of RFC2418) provides additional safeguards against </del>  abuse. Working Groups are advised against allowing editors this degree of 6. <del> During the development of a document, individual revisions of a </del>  document can be built and formally submitted as an Internet-Draft. This creates a stable snapshot and makes the content of the in- progress document available to a wider audience.  Documents submitted

Please pay special attention to b872e53 and e74ba45 when reviewing this.
LGTM with some proposed simplifying text.

GitHub is a service operated at https://github.com/ [5].  GitHub provides centralized storage for git repositories.  GitHub is freely  <ins> accessible on the open Internet. </ins>  <ins> GitHub provides a simplified and integrated interface to git, and also provides basic user management, an issue tracker, associated wikis, project hosting, and other features. </ins> There are a large number of projects at GitHub and a very large community of contributors.  One way in which some IETF Working Groups have benefited is through increased numbers of reviews and associated  <ins> issues, along with other improvements that come from facilitating participation by a broader community. </ins> 1.3. 1.5.  <ins> 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. </ins> 2. interest in using GitHub and making a consensus call to determine if the proposed policy and use is acceptable.  <ins> Chairs SHOULD involve Area Directors in any decision to use GitHub, especially where substantive discussion of issues is permitted as described in mode-discuss. </ins> 3.1. consensus MUST NOT be reopened unless new information is presented. For long-running work items, new contributors often raise issues that  <ins> have already been resolved.  Moreover, there could be temptation to reopen contentious issues resolved with rough consensus.  Determining whether arguments presented in favor of reopening an issue represents new information might require some discussion in the Working Group. Chairs are empowered to exercise discretion in determining whether to reopen issues.  For more difficult matters, the chairs MAY insist that the Working Group reach consensus on whether an issue should be reopened.  Note however that any product of this process still needs to have the support of rough consensus in the Working Group, which could justify reopening issues. </ins> 4.2.  <ins> A pull request is a GitHub feature that allows a user to request a change to a repository.  A user does not need to have write access to a repository to create a pull request.  A user can create a "fork", or copy, of any public repository.  The user has write access to their own fork, allowing them to make local changes.  A pull request asks the owner of a repository to merge a specific set of changes from a fork (or any branch) into their copy. </ins> Editors SHOULD make pull requests for all substantial changes rather than committing directly to the "master" branch of the repository. In addition to the features that pull requests share with issues, users can also review the changes in a pull request.  This is a  <ins> valuable feature, but presents some challenges. </ins> Comments in a review other than a summary are attached to specific lines of the proposed change.  Such comments can be hard or are tracked and can be audited.  Within the usual Working Group process it is expected that Internet-Drafts will receive regular review.  Finally, process checkpoints like Working Group Last Call  <ins> (WGLC; Section 7.4 of RFC2418) provide additional safeguards against </ins> abuse. Working Groups are advised against allowing editors this degree of 6.  <ins> During the development of a document, individual revisions of the </ins> document can be built and formally submitted as an Internet-Draft. This creates a stable snapshot and makes the content of the in- progress document available to a wider audience.  Documents submitted


Abstract <del> This document describes best practices for Working Groups that use GitHub for their work. </del>  Note to Readers The main purpose of this document is providing guidelines for how Working Groups might integrate the capabilities provided by GitHub <del> into their processes for developing Internet-Drafts. </del>  This document is meant as a supplement to existing Working Group practices.  It provides guidance to Working Group chairs and

I agreed to change from DISCUSS to Abstain if this change was made - email thread for the curious / archives: URL A PR is close enough to integrated for me...
NAME I'm curious why this change is adequate; it's effectively just a rewording. It doesn't address the issue of the group choosing to adopt the policies.
NAME Yes, it is just a rewording -- but (for me at least) it made it enough clearer that this was optional (WGs can choose to use GH, not WGs are expected to use GH) that I was willing to move to Abstain instead. The WG has consensus, and the charter sent us down the "GH FTW!" path - it isn't appropriate for me to block this just because I don't like it / think there is a better way of using RCS tooling / GH. The process was followed, and the document is valuable - I don't like the tone, I don't like the implication, but it now falls into the "Well, that's just, like, your opinion, man..." territory. (There isn't a technical objection, nor do I think it is specifically dangerous to the IETF / IETF stream, so...)
NAME - OK. This is made moot by the other changes that Martin made to the draft, but to be clear, I don't think that's a good line of argumentation. The WG was charted to an explicit scope - that WGs had to opt into the practices it documented. If it were producing a document that exceeded that scope (which is arguably did before the recent change referenced above), saying that the WG "has consensus" to violate its charter is meaningless, and letting that stand is damaging. That's because charters allow people to decide whether or not they're going to follow a WG. If a WG can violate its charter and justify that with "but we had consensus to do so", charters are meaningless, and the check that requiring IETF consensus places upon WGs is seriously diminished. Thank you -- I would even be OK with just changing to Abstract to be: "This document describes best practices for Working Groups that choose to use GitHub for their work." and leave it as BCP. Would that work better for everyone? It would be enough for me to no longer feel that this is saying that WGs using GitHub is a BCP, but rather that if a WG decided to use GitHub, this is the best way to do so (I'm still not sure that this really is the best way, but that's just my opinion, and I'm OK being in the rough) W I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf

Abstract  <ins> This document describes best practices for Working Groups that choose to use GitHub for their work. </ins> Note to Readers The main purpose of this document is providing guidelines for how Working Groups might integrate the capabilities provided by GitHub  <ins> into their processes for developing Internet-Drafts.  The choices of whether to use GitHub and whether to adopt these practices if they do is at the discretion of the Working Group. </ins> This document is meant as a supplement to existing Working Group practices.  It provides guidance to Working Group chairs and


Discussion of this document takes place on the GitHub@ietf mailing list (ietf-and-github@ietf.org), which is archived at <del> https://mailarchive.ietf.org/arch/search?email_list=ietf-and-github [1]. </del>  Source for this draft and an issue tracker can be found at <del> https://github.com/ietf-gitwg/using-github [2]. </del>  1. The IETF has an open and transparent process for developing <del> standards.  The use of GitHub [3] or similar tools, when used as part </del>  of this process, can have several objectives.  GitHub provides tools that can be helpful in editing documents.  Use of this service has been found to reduce the time that Working Groups need to produce Version control systems are a critical component of software engineering and are also quite useful for document editing. <del> Git [4] is a distributed version control system that can operate </del>  without a central service.  Each instance of a repository contains a number of revisions.  Each revision stores the complete state of a set of files.  Users are able to create new revisions in their copy 1.2. <del> GitHub is a service operated at https://github.com/ [5].  GitHub </del>  provides centralized storage for git repositories.  GitHub is freely accessible on the open Internet. Git is not the only version control system available, nor is GitHub the only possible choice for hosting.  There are other services that host revision control repositories and provide similar additional <del> features to GitHub.  For instance, BitBucket [6] and GitLab [7] </del>  provide similar feature sets.  In addition to a hosted service, software for custom installations exists. CONTRIBUTING file. In addition to Working Group policies, notices on repositories MUST <del> include citations for the IETF Note Well [8]. </del>  3. new repositories for adopted Working Group items, or they might create repositories for individual documents on request. <del> All repositories for Working Group documents within the Working Group organization MUST be public.  Repositories for private documents MAY be kept private, but only where there is a specific reason for doing so.  For instance, a document that details a security vulnerability might be kept private prior to its initial publication as an Internet-Draft.  Once an Internet-Draft is published, repositories SHOULD be made public. </del>  The adoption status of any document MUST be clear from the contents of the repository.  This can be achieved by having the name of the An alternative is to rely on periodic email summaries of activity, such as those produced by a notification tool like github-notify-ml <del> [9].  This tool has been used effectively in several Working Groups, </del>  though it requires server infrastructure. Additionally, clear reporting about the changes that were included in 12.1.  URIs <del> [1] https://mailarchive.ietf.org/arch/search?email_list=ietf-and- github </del>  <del> [2] https://github.com/ietf-gitwg/using-github </del>  <del> [3] https://github.com/ </del>  <del> [4] https://git-scm.com </del>  <del> [5] https://github.com/ </del>  <del> [6] https://bitbucket.org/ [7] https://about.gitlab.com/ [8] https://www.ietf.org/about/note-well/ [9] https://github.com/dontcallmedom/github-notify-ml </del>

From Adam's AD review
Note that the URL fixes here are ineffective. The source is: The resulting XML is: The HTML shows a nice clickable link. xml2rfc produces text output of "URL (URL)". Perhaps this is a case where a small tweak to xml2rfc is in order.
Nice relaxation of the text.

Discussion of this document takes place on the GitHub@ietf mailing list (ietf-and-github@ietf.org), which is archived at  <ins> <https://mailarchive.ietf.org/arch/search?email_list=ietf-and- github>. </ins> Source for this draft and an issue tracker can be found at  <ins> <https://github.com/ietf-gitwg/using-github>. </ins> 1. The IETF has an open and transparent process for developing  <ins> standards.  The use of GitHub [1] or similar tools, when used as part </ins> of this process, can have several objectives.  GitHub provides tools that can be helpful in editing documents.  Use of this service has been found to reduce the time that Working Groups need to produce Version control systems are a critical component of software engineering and are also quite useful for document editing.  <ins> Git [2] is a distributed version control system that can operate </ins> without a central service.  Each instance of a repository contains a number of revisions.  Each revision stores the complete state of a set of files.  Users are able to create new revisions in their copy 1.2.  <ins> GitHub is a service operated at <https://github.com/>.  GitHub </ins> provides centralized storage for git repositories.  GitHub is freely accessible on the open Internet. Git is not the only version control system available, nor is GitHub the only possible choice for hosting.  There are other services that host revision control repositories and provide similar additional  <ins> features to GitHub.  For instance, BitBucket [3] and GitLab [4] </ins> provide similar feature sets.  In addition to a hosted service, software for custom installations exists. CONTRIBUTING file. In addition to Working Group policies, notices on repositories MUST  <ins> include citations for the IETF Note Well [5]. </ins> 3. new repositories for adopted Working Group items, or they might create repositories for individual documents on request.  <ins> Maintaining private repositories for Working Group products is not recommended without specific cause.  For instance, a document that details a security vulnerability might be kept private prior to its initial publication as an Internet-Draft.  Once an Internet-Draft is published, repositories for Working Group documents MUST be made public. </ins> The adoption status of any document MUST be clear from the contents of the repository.  This can be achieved by having the name of the An alternative is to rely on periodic email summaries of activity, such as those produced by a notification tool like github-notify-ml  <ins> [6].  This tool has been used effectively in several Working Groups, </ins> though it requires server infrastructure. Additionally, clear reporting about the changes that were included in 12.1.  URIs  <ins> [1] https://github.com/ </ins>  <ins> [2] https://git-scm.com/ </ins>  <ins> [3] https://bitbucket.org/ </ins>  <ins> [4] https://about.gitlab.com/ </ins>  <ins> [5] https://www.ietf.org/about/note-well/ </ins>  <ins> [6] https://github.com/dontcallmedom/github-notify-ml </ins>


Version compatibility is not symmetric: it is possible for version A to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset <del> of version A. </del>  Note that version compatibility does not mean that every single possible instance of a first flight will succeed in conversion to the

LGTM.
This is a very important section, but I found it to be a little muddy. In particular, the directionality of the phrase A is compatible with B was unclear. An example would help here, I think.

Version compatibility is not symmetric: it is possible for version A to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset  <ins> of version A: if version A includes the concept of streams and STREAM frames, and version B includes the concepts of streams and tubes along with STREAM and TUBE frames, then A would be compatible with B but B would not be compatible with A. </ins> Note that version compatibility does not mean that every single possible instance of a first flight will succeed in conversion to the


2.5. <del> The client's first connection attempt SHOULD be made using the version that the server is most likely to support.  The client selects the version most likely to be supported from the versions that are compatible with the client's most preferred version. Without additional information this could mean selecting the oldest </del>  version that the client supports. 3.

Section 2.5 says unconditionally that the client chooses the most compatible version. This isn't right, because the most compatible version isn't what it is looking to end up on. What the client should choose is probably the most compatible version of those that are compatible (directionality ?) with its most preferred version.
Rereading this, I think the directionality is correct in the existing text. But perhaps we could figure out better wording.
LGTM with the following edits.

2.5.  <ins> When the client picks its original version, it will try to avoid incompatible version negotiation to save a round trip.  Therefore, the client SHOULD pick an original version to maximize the combined probability that both: The server knows how to parse first flights from the original version. The original version is compatible with the client's preferred version. Without additional information, this could mean selecting the oldest </ins> version that the client supports. 3.


QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the <del> version the client offered is unacceptable.  This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version.  Optionally, if the original and negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. </del>  1. The version-invariant properties of QUIC INV define a Version Negotiation packet but do not specify how an endpoint reacts when it receives one.  QUIC version 1 QUIC allows the server to use a Version <del> Negotiation packet to indicate that the version the client offered is </del>  unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually supported version. all versions, and one "compatible" that allows saving the round trip but only applies when the versions are compatible. <del> The client initiates a QUIC connection by sending a first flight of QUIC packets with a long header to the server INV.  We'll refer to the version of those packets as the "original version".  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotation (see compat-vn), and to prevent version downgrade attacks (see downgrade). </del>  Upon receiving this first flight, the server verifies whether it knows how to parse first flights from the original version.  If it does not, then it starts incompatible version negotiation, see <del> incompat-vn.  If the server can parse the first flight, it can either establish the connection using the original version, or it MAY attempt compatible version negotiation, see compat-vn. </del>  Note that it is possible for a server to have the ability to parse the first flight of a given version without fully supporting it, in 2.3. When the server can parse the client's first flight using the <del> original version, it can extract the client's Version Information structure (see vers-info).  This contains the list of versions that the client knows its first flight is compatible with. If the server supports one of the client's compatible versions, and the server also knows that the original version is compatible with this version, and the client's first flight is compatible with this version, then the server converts the client's first flight to that version and replies to the client as if it had received the converted first flight.  Note that this conversion process cannot fail by definition of the first flight being compatible.  The version used by the server in its reply is refered to as the "negotiated version". The server MUST NOT reply with a version that is not present in the client's compatible versions, unless it is the original version. Clients will be made aware of compatible version negotiation by seeing a change in the QUIC long header Version field.  It is possible for the server to initially send packets with the original version before switching to the negotiated version (for example, this can happen when the client's Version Information structured spans multiple packets; in that case the server might acknowledge the first packet in the original version and later switch to a different </del>  negotiated version). Note that, after the first flight is converted to the negotiated by only including the Chosen Version in the Other Versions field of the Version Information Transport Parameter. <del> If the server does not find a compatible version, it will use the original version if it supports it, and if it doesn't then the server will perform incompatible version negotiation instead, see incompat- vn. </del>  2.4. QUIC connections are shared state between a client and a server INV. The compatible version negotiation mechanism defined in this document (see compat-vn) is performed as part of a single QUIC connection; <del> that is, the packets with the original version are part of the same connection as the packets with the negotiated version. </del>  In comparison, the incompatible version negotiation mechanism, which leverages QUIC Version Negotiation packets (see incompat-vn) attempting compatible version negotiation.  If both versions support authenticating Retry packets, the compatibility defition needs to define how to authenticate the Retry in the negotiated version <del> handshake even though the Retry itself was sent using the original version. </del>  7.2.

Original version was defined as the version a client attempts prior to a VN packet. If there is a VN packet, I think that it is still possible to do a compatible upgrade from the version in the client's second attempt. In that case, "original version" isn't the right term to use when talking about compatible upgrades.
We can sidestep this particular issue by removing the "unless..." clause. That clause isn't helping because the client's chosen version MUST already be present in the compatible versions list. However, this issue raises a good point: it's possible for incompatible VN to happen and then be followed by compatible VN. We should clarify that this is allowed, and clearly define what the "original version" is in that scenario.
Consider the case where the client and server both support v1 and v2 and prefer v2. In the current draft, if the client puts v1 in the long header and the server responds with v2, that's called "compatible version negotiation". OTOH, if the client puts v2 in the long header and the server responds with v2, that's called, well, I'm not quite sure what. I guess not negotiation? I think a better way to think about this is that the client is sending an Initial that is compatible with both versions and so both of these cases are compatible version negotiation.
In the scenario where the client starts with v2 and the server responds with v2, I think of that as just "creating a v2 connection" without compatible version negotiation involved. Let's discuss this with the WG at IETF 113.

QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the  <ins> version the client chose is unacceptable.  This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version.  Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. </ins> 1. The version-invariant properties of QUIC INV define a Version Negotiation packet but do not specify how an endpoint reacts when it receives one.  QUIC version 1 QUIC allows the server to use a Version  <ins> Negotiation packet to indicate that the version the client chose is </ins> unacceptable, but doesn't allow the client to safely make use of that information to create a new connection with a mutually supported version. all versions, and one "compatible" that allows saving the round trip but only applies when the versions are compatible.  <ins> The client initiates a QUIC connection by choosing an initial version and sending a first flight of QUIC packets with a long header to the server INV.  The client's first flight includes Version Information (see vers-info) which will be used to optionally enable compatible version negotation (see compat-vn), and to prevent version downgrade attacks (see downgrade).  We'll refer to the version of the very first packets the client sends as the "original version" and the version of the first packets the client sends in a given QUIC connection as the "client's chosen version". </ins> Upon receiving this first flight, the server verifies whether it knows how to parse first flights from the original version.  If it does not, then it starts incompatible version negotiation, see  <ins> incompat-vn, which causes the client to initiate a new connection with a different version.  For instance, if the client initiates a connection with version A and the server starts incompatible version negotiation and the client then initiates a new connection with version B, we say that the first connection's client chosen version is A, the second connection's client chosen version is B, and the original version for the entire sequence is A. If the server can parse the first flight, it can either establish the connection using the client's chosen version, or it MAY select any other compatible version, as described in compat-vn. </ins> Note that it is possible for a server to have the ability to parse the first flight of a given version without fully supporting it, in 2.3. When the server can parse the client's first flight using the  <ins> client's chosen version, it can extract the client's Version Information structure (see vers-info).  This contains the list of versions that the client knows its first flight is compatible with. In order to perform compatible version negotiation, the server MUST select one of these versions that (1) it supports and (2) it knows the client's chosen version to be compatible with.  Once the server has selected a version, termed the "negotiated version", it then attempts to convert the client's first flight into that version, and replies to the client as if it had received the converted first flight. If those formats are identical, as in cases where the negotiated version is the same as the client's chosen version, then this will be the identity transform.  If the first flight is correctly formatted, then this conversion process cannot fail by definition of the first flight being compatible; if the server is unable to convert the first flight, it MUST abort the handshake. Clients can determine the server's negotiated version by examining the QUIC long header Version field.  It is possible for the server to initially send packets with the client's chosen version before switching to the negotiated version (for example, this can happen when the client's Version Information structured spans multiple packets; in that case the server might acknowledge the first packet in the client's chosen version and later switch to a different </ins> negotiated version). Note that, after the first flight is converted to the negotiated by only including the Chosen Version in the Other Versions field of the Version Information Transport Parameter.  <ins> If the server does not find a compatible version (including the client's chosen version), it will perform incompatible version negotiation instead, see incompat-vn. Note that it is possible to have incompatible version negotation followed by compatible version negotiation.  For instance, if A and B are compatible and versions C and D are compatible, the following scenario may occur: In this example, the client selected C from the server's Version Negotiation packet, but the server preferred D and then selected it from the client's offer. </ins> 2.4. QUIC connections are shared state between a client and a server INV. The compatible version negotiation mechanism defined in this document (see compat-vn) is performed as part of a single QUIC connection;  <ins> that is, the packets with the client's chosen version are part of the same connection as the packets with the negotiated version. </ins> In comparison, the incompatible version negotiation mechanism, which leverages QUIC Version Negotiation packets (see incompat-vn) attempting compatible version negotiation.  If both versions support authenticating Retry packets, the compatibility defition needs to define how to authenticate the Retry in the negotiated version  <ins> handshake even though the Retry itself was sent using the client's chosen version. </ins> 7.2.