Sorry, that didn't come out in a usable form. I used jsonpath.com to validate the expressions against the pre-redacted response in the draft.
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 4/26/23, 12:46 PM, "regext on behalf of Gould, James" <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of jgould=40verisign....@dmarc.ietf.org <mailto:40verisign....@dmarc.ietf.org>> wrote: Andy, I used https://secure-web.cisco.com/1-bWL59tA3_up4WWjpW2qUjacDSlHoa9r9c4MxSmItvffYh6CTxSJ_rs00jhh8RRJeveLDWUhPyLWZlDl0eN-RCIJJuMo_JyF16tjWVNVJqlmTfFTlQN7VErnEXS4zCEKfKwGNnXyf7j3uuLJwfmBwyJL_JYmHw0sPLFb7mdLwrtGBYF7HGXbZDlZVg6ZP28-UWjH2FqVUJ-upXP3HAwyNgaxTmM59n4Nx_3QlAjzEJTilXdwx-gF0A2-qe4f4fB1xyaJTLP8Gfmr7I8zAQ1o2JgzZxtv4sv4uRjWrC5PRcQ/https%3A%2F%2Fjsonpath.com <https://secure-web.cisco.com/1-bWL59tA3_up4WWjpW2qUjacDSlHoa9r9c4MxSmItvffYh6CTxSJ_rs00jhh8RRJeveLDWUhPyLWZlDl0eN-RCIJJuMo_JyF16tjWVNVJqlmTfFTlQN7VErnEXS4zCEKfKwGNnXyf7j3uuLJwfmBwyJL_JYmHw0sPLFb7mdLwrtGBYF7HGXbZDlZVg6ZP28-UWjH2FqVUJ-upXP3HAwyNgaxTmM59n4Nx_3QlAjzEJTilXdwx-gF0A2-qe4f4fB1xyaJTLP8Gfmr7I8zAQ1o2JgzZxtv4sv4uRjWrC5PRcQ/https%3A%2F%2Fjsonpath.com> to validate the expressions against the pre-redacted response in the draft. -- JG James Gould Fellow Engineer jgo...@verisign.com <mailto:jgo...@verisign.com> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com <mailto:jgo...@verisign.com>> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://secure-web.cisco.com/1X1jkCplYd153iyiqaAYULsTgnP8QYntKFXbmhFbFvvB6EdUlr12x50umrzuI8PpWJR7oWj0RpJIPoRqpkuFiNwsjaSJuMUFQnaZLC4vpgw_N4xu0w6YvBsBNCTLcGwihOYCIiKjK0qTY9_ulG5suFoVwVwVC1InxuV6FUT5gASIJnf90yQhCU4WRi46p9HuVw4qJjgPmVzxpBiANnR5PUivbtTS1vrPNia1VUqO3aHlzow0J9Mhll1i30I3fG1OrW8oYVYRtxFUKhxGxjvVcTz9YZXQed4sk8klbyQdSmSA/http%3A%2F%2Fverisigninc.com%2F> <http://secure-web.cisco.com/1X1jkCplYd153iyiqaAYULsTgnP8QYntKFXbmhFbFvvB6EdUlr12x50umrzuI8PpWJR7oWj0RpJIPoRqpkuFiNwsjaSJuMUFQnaZLC4vpgw_N4xu0w6YvBsBNCTLcGwihOYCIiKjK0qTY9_ulG5suFoVwVwVC1InxuV6FUT5gASIJnf90yQhCU4WRi46p9HuVw4qJjgPmVzxpBiANnR5PUivbtTS1vrPNia1VUqO3aHlzow0J9Mhll1i30I3fG1OrW8oYVYRtxFUKhxGxjvVcTz9YZXQed4sk8klbyQdSmSA/http%3A%2F%2Fverisigninc.com%2F>> On 4/26/23, 11:56 AM, "regext on behalf of Andrew Newton" <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> <mailto:regext-boun...@ietf.org <mailto:regext-boun...@ietf.org>> on behalf of a...@hxr.us <mailto:a...@hxr.us> <mailto:a...@hxr.us <mailto:a...@hxr.us>>> wrote: I see in the implementation section of the draft there is a test server that lists the redactions. However, has anybody taken any real output from a DNR and INR server and run some JSONPath expressions on them? Doing so would help to prove out this spec. -andy On Wed, Apr 26, 2023 at 7:39 AM Mario Loffredo <mario.loffr...@iit.cnr.it <mailto:mario.loffr...@iit.cnr.it> <mailto:mario.loffr...@iit.cnr.it <mailto:mario.loffr...@iit.cnr.it>>> wrote: > > > Il 26/04/2023 02:16, Tom Harrison ha scritto: > > On Mon, Apr 17, 2023 at 03:27:23PM +0200, Antoin Verschuren wrote: > >> The document editors have indicated that the following document is > >> ready for submission to the IESG to be considered for publication as > >> a Proposed Standard: > >> > >> Redacted Fields in the Registration Data Access Protocol (RDAP) Response > >> https://secure-web.cisco.com/1iAbLGLPLxLJO8hzh27ViRK4bd-bt0GbQhUPIR2fX6D5EeH2odcVEK_ffmTZkTj0-p2u2un10AG_qkU-2VEGTay2CrfhByh9LG9OyjOd4yNunvYI1mO081jP9odoXhstPWpgFkcNIBlN90l0TZGP8MMDPy8LarElavE224AKk8GoGO-X8IofymkVYZIokMprztLdnTYQZFRZxlmo3drbusAaAR9OJa81pIgusdOR7LAiEyQgfJriJGlrLt7jzh4thYH475NtZctFTSQ8-pufORdjZijb2qK1zVeOtu-qidbs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F11%2F > >> > >> <https://secure-web.cisco.com/1iAbLGLPLxLJO8hzh27ViRK4bd-bt0GbQhUPIR2fX6D5EeH2odcVEK_ffmTZkTj0-p2u2un10AG_qkU-2VEGTay2CrfhByh9LG9OyjOd4yNunvYI1mO081jP9odoXhstPWpgFkcNIBlN90l0TZGP8MMDPy8LarElavE224AKk8GoGO-X8IofymkVYZIokMprztLdnTYQZFRZxlmo3drbusAaAR9OJa81pIgusdOR7LAiEyQgfJriJGlrLt7jzh4thYH475NtZctFTSQ8-pufORdjZijb2qK1zVeOtu-qidbs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F11%2F> > >> > >> <https://secure-web.cisco.com/1iAbLGLPLxLJO8hzh27ViRK4bd-bt0GbQhUPIR2fX6D5EeH2odcVEK_ffmTZkTj0-p2u2un10AG_qkU-2VEGTay2CrfhByh9LG9OyjOd4yNunvYI1mO081jP9odoXhstPWpgFkcNIBlN90l0TZGP8MMDPy8LarElavE224AKk8GoGO-X8IofymkVYZIokMprztLdnTYQZFRZxlmo3drbusAaAR9OJa81pIgusdOR7LAiEyQgfJriJGlrLt7jzh4thYH475NtZctFTSQ8-pufORdjZijb2qK1zVeOtu-qidbs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F11%2F> > >> > >> <https://secure-web.cisco.com/1iAbLGLPLxLJO8hzh27ViRK4bd-bt0GbQhUPIR2fX6D5EeH2odcVEK_ffmTZkTj0-p2u2un10AG_qkU-2VEGTay2CrfhByh9LG9OyjOd4yNunvYI1mO081jP9odoXhstPWpgFkcNIBlN90l0TZGP8MMDPy8LarElavE224AKk8GoGO-X8IofymkVYZIokMprztLdnTYQZFRZxlmo3drbusAaAR9OJa81pIgusdOR7LAiEyQgfJriJGlrLt7jzh4thYH475NtZctFTSQ8-pufORdjZijb2qK1zVeOtu-qidbs/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-redacted%2F11%2F>> > >> > >> Please indicate your support or no objection for the publication of > >> this document by replying to this message on list (a simple “+1” is > >> sufficient). > >> > >> If any working group member has questions regarding the publication > >> of this document please respond on the list with your concerns by > >> close of business everywhere, Monday, 1 May 2023. > >> > >> If there are no objections the document will be submitted to the > >> IESG. > >> > >> The Document Shepherd for this document is Gustavo Lozano Ibarra. > > Looks good overall, some minor comments/suggestions. > > > > Per previous mail from Pawel and Mario, some of the JSON path > > expressions are not quite right for entities that have multiple roles. > > There are some issues with the guidance added to the document to > > account for this, though, and some further updates in this space that > > would be useful. (We rely on entities having multiple roles in our > > server implementation at the moment, for reference, and returning a > > copy of each entity per role as a workaround is not ideal, > > particularly when addressing the comments here shouldn't be > > difficult.) To summarise these issues (mostly along the lines of the > > comments from Pawel and Mario): > > > > - The first example use of prePath has a value of: > > > > $.entities[?(@.roles[0]=='administrative')] > > > > But all that a client can infer from this path is that all entities > > with "administrative" as their first role have been removed. Since > > there are no guarantees around ordering of roles within an entity, > > this doesn't necessarily mean that all entities with > > "administrative" as one of their roles have been removed from the > > resulting object. It would be better to use a more general > > expression in this example (and the others like it) that captured > > the intent more clearly. Per earlier mail from Pawel, something > > like: > > > > $.entities[?(@.roles[*]=='administrative')] > > > > should do the job, though I wasn't able to determine the syntax > > that would be acceptable for draft-ietf-jsonpath-base. > > [ML] Per what is reported in Sections 2.3.5.1 (filter selector syntax) > and 2.3.3.1 (index selector syntax), it seems to me that wildcard is not > accepted. > > The only acceptable values are integers (e.g. 0, 1, -1) > > Neither any of the pre-defined functions seems helpful. > > Looking at the examples in section 2.3.5.3, $.entities[?@.roles[?@ == > 'administrative]] could work maybe. > > > Another solution might be using the indexOf function that is defined by > some JSONPath implementations such as JSONPath.com and should be > registered as Function Extension (see Section 3.2) : > > $.entities[?(@.roles.indexOf('administrative')!=-1)] //tested on > jsonpath.com > > Anyway, the indexOf syntax should be redefined to be compliant with the > jsonpath-base syntax: > > $.entities[?indexOf(@.roles,'administrative')!=-1] > > > Best, > > Mario > > > > > - Section 5.2 at point 4 has: > > > > When an entity has multiple roles, include "redacted" members > > for each role using the role index. This will result in > > duplicate "redacted" members, but will enable the client to > > treat redaction consistently when there is a single role per > > entity or multiple roles per entity. > > > > It's not clear why this advice is present, when compared with e.g. > > having the redacted members be a mapping from the server's > > policies. For example, if the policy is that administrative > > contacts not be returned, then a single "redacted" entry with a > > prePath like "$.entities[?(@.roles[*]=='administrative')]" clearly > > conveys that message to the client, and the client will understand > > that those entities will be removed regardless of any additional > > roles that they might have. How do multiple redacted members > > enable the client to treat redaction consistently? > > > > - Section 5.2 at point 5 has: > > > > When there are multiple entities with the same role, include > > "redacted" members for each entity using the entity index > > instead of the role. A JSONPath can be created that > > identifies the entity based on an index of a role selector > > nodelist, such as "$.entities[?(@.roles[0]=='technical')][0]" > > for the first entity with the "technical" role. Using the > > entity index, such as "$.entities[1]", is simpler and > > recommended. > > > > Similarly to the previous point, removing by index obscures the > > server's intent. To use the example given above, if the server's > > policy is that the first entity with a technical role is omitted, > > then the first expression (though with 'roles[*]' instead of > > 'roles[0]') conveys that message more clearly than removal by way > > of index. (If the server's behaviour can't be conveyed by way of a > > JSON path, e.g. where an entity is omitted because they have opted > > out of being included in responses, then simply omitting the > > prePath and relying on a specific registered redacted name for the > > behaviour would make things clearer for the client than presenting > > an entity index that they can't resolve/use.) > > > > - Section 5.1 at point 1 has: > > > > When the server is using the Redaction By Removal Method > > (Section 3.1) or the Redaction by Replacement Value Method > > (Section 3.4) with an alternate field value, the JSONPath > > expression of the "prePath" member will not resolve > > successfully with the redacted response. The client can > > first key off the "name" member for display logic and > > utilize a template RDAP response overlaid with the redacted > > response to successfully resolve the JSONPath expression. > > > > There is an earlier thread where the "template RDAP response" is > > discussed, but it was noted there that it would likely be difficult > > to construct a one-size-fits-all template response. I think that's > > correct, given the flexibility of the underlying data format, but > > that in turns means that a "template RDAP response" would have to > > be generated on a per-server basis (something that was also flagged > > in that thread). There's no guidance for clients (or servers) on > > this point, though. Omitting the last sentence here will address > > the problem. > > > > - Also on section 5.1 point 1, the prePath expression will sometimes > > resolve 'successfully' when evaluating the redacted response, in > > the sense that it can be applied to the response and will return a > > result. For example, if the first technical-role entity is > > redacted by removal, but the object contains two technical-role > > entities, then the prePath will resolve to the second > > technical-role entity. This could be confusing for implementors, > > particularly given that the other JSONPath expressions will resolve > > correctly when evaluated against the redacted response. Some extra > > text here clarifying that the expression may evaluate > > 'successfully', but not 'correctly', would be useful. > > > > - (Another way of addressing all of the above is to remove prePath > > altogether, given that it's optional, and given that in most cases > > servers should use registered redacted names anyway, the > > descriptions for which can document the associated behaviour > > clearly and unambiguously.) > > > > In the definition for "name" in the "redacted" member, in section 4.2, > > the text has "[t]he logical name is defined using an object with a > > 'type' field denoting a registered redacted name (see Section 6.2)". > > The document uses various names in the examples (e.g. "Administrative > > Contact" in figure 1) without registering them, though. Registering > > those names would address the problem, or alternatively the > > "description" field for unregistered names could be used in the > > examples instead. > > > > Section 6.2 has: > > > > Two new JSON Values Registry Type field values are used to register > > pre-defined redacted name and reason values: > > > > "redacted name": Redacted name being registered. The registered > > redacted name is referenced using the "type" field of the > > redacted "name" field. > > > > "redacted reason": Redacted reason being registered. The registered > > redacted reason is referenced using the "type" field of the > > redacted "reason" field. > > > > "redacted expression language": Redacted expression language being > > registered. The registered redacted expression language is > > referenced using the "pathLang" field. > > > > The following values should be registered by the IANA in the RDAP > > JSON Values Registry described in [RFC7483]: ... > > > > This would read better if the first sentence took account of the > > "redacted expression language" registration as well, or alternatively > > if similar text was added after the "redacted reason" entry. > > > > -Tom > > > > _______________________________________________ > > regext mailing list > > regext@ietf.org <mailto:regext@ietf.org> <mailto:regext@ietf.org > > <mailto:regext@ietf.org>> > > https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > > > <https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> > > > > <https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> > > > > <https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>> > > -- > Dott. Mario Loffredo > Technological Unit “Digital Innovation” > Institute of Informatics and Telematics (IIT) > National Research Council (CNR) > via G. Moruzzi 1, I-56124 PISA, Italy > Phone: +39.0503153497 > Web: > http://secure-web.cisco.com/1tDGEpUaR0qf613wh90Sv48-MMiXo5HY7hY-Skjn6Sx5ua10g5B95XotOA-hkYmhnWMiSEpmuD0D9kAZACVI2HnLnK8BRDcgrH_CfCpTbO9ymDvzgpaXzMnG1vMy4UgEcV5JT7JGQzz_QO3_RwWNOf5-QzcfqJex08L2oC0-d95jV3NtqTP3G2_noEVFpWdtYonPDREv7UN-FznKlFgjYQ2eZrtmJieScDPucXEQtmo8DRjFXB4fKRxPbArB1d9NTapRZVHYMS6pbZDwRHyvx4IU3acgAOndIoxBXmNJIcUc/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo > > <http://secure-web.cisco.com/1tDGEpUaR0qf613wh90Sv48-MMiXo5HY7hY-Skjn6Sx5ua10g5B95XotOA-hkYmhnWMiSEpmuD0D9kAZACVI2HnLnK8BRDcgrH_CfCpTbO9ymDvzgpaXzMnG1vMy4UgEcV5JT7JGQzz_QO3_RwWNOf5-QzcfqJex08L2oC0-d95jV3NtqTP3G2_noEVFpWdtYonPDREv7UN-FznKlFgjYQ2eZrtmJieScDPucXEQtmo8DRjFXB4fKRxPbArB1d9NTapRZVHYMS6pbZDwRHyvx4IU3acgAOndIoxBXmNJIcUc/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> > > <http://secure-web.cisco.com/1tDGEpUaR0qf613wh90Sv48-MMiXo5HY7hY-Skjn6Sx5ua10g5B95XotOA-hkYmhnWMiSEpmuD0D9kAZACVI2HnLnK8BRDcgrH_CfCpTbO9ymDvzgpaXzMnG1vMy4UgEcV5JT7JGQzz_QO3_RwWNOf5-QzcfqJex08L2oC0-d95jV3NtqTP3G2_noEVFpWdtYonPDREv7UN-FznKlFgjYQ2eZrtmJieScDPucXEQtmo8DRjFXB4fKRxPbArB1d9NTapRZVHYMS6pbZDwRHyvx4IU3acgAOndIoxBXmNJIcUc/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> > > <http://secure-web.cisco.com/1tDGEpUaR0qf613wh90Sv48-MMiXo5HY7hY-Skjn6Sx5ua10g5B95XotOA-hkYmhnWMiSEpmuD0D9kAZACVI2HnLnK8BRDcgrH_CfCpTbO9ymDvzgpaXzMnG1vMy4UgEcV5JT7JGQzz_QO3_RwWNOf5-QzcfqJex08L2oC0-d95jV3NtqTP3G2_noEVFpWdtYonPDREv7UN-FznKlFgjYQ2eZrtmJieScDPucXEQtmo8DRjFXB4fKRxPbArB1d9NTapRZVHYMS6pbZDwRHyvx4IU3acgAOndIoxBXmNJIcUc/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>> > > _______________________________________________ > regext mailing list > regext@ietf.org <mailto:regext@ietf.org> <mailto:regext@ietf.org > <mailto:regext@ietf.org>> > https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > > <https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> > > <https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> > > <https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>> _______________________________________________ regext mailing list regext@ietf.org <mailto:regext@ietf.org> <mailto:regext@ietf.org <mailto:regext@ietf.org>> https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> <https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> <https://secure-web.cisco.com/1noqfRTkd7XOrdTnz0B5AgZraEyKiDyC3DL5aMGmWtmpfWix_gLpmtnWD5F1UyE24rQEjktUOyohvyEBACpbQg33KgdeJ4u1a0k8OSR_3h9b30SUzztqwegXRPgOBuiX5l-wum-Fj6vJrfA5sRn3SoDFMPft4VoxsvFKlzp5EF1qX8izzK26vU-J52-Rg44zuaRmQodpFX8QVfW__QT3yMRp7_d-k8dpzYOZYTv39fez8KobCF8zWmnndZJgcYsGUqcGTVW2baXNNf49_DXTfh_Q8sVllvY4qftUGYhlkdN0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>> _______________________________________________ regext mailing list regext@ietf.org <mailto:regext@ietf.org> https://secure-web.cisco.com/1k9uQMqwkX105BZOrBx7LeezVcnSOr6E_sLgpQhxa9x3p3T3SptA2kLOHlCShVVdYSZwoz4Wb1_obo3n6zfM9TzSa_ptx2tywnnAVziobrbIjH31oevuLUyh8FgUvxo0IcMC0Xig_bM1RchyOnLcqFpAllkMpT4DajvtSMxJvwRWf6oRyisIZ-oic21uCE30AXx65_PUX4RrMIRgTD5CUuBLYvSZUBU8k8jjEcDe5tktjtwyqcqMW9owGbFOA3GQXZ4Fj_VkT3-cXzcpR3myq0flL6xzDNMsa_HV3zywLwVY/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1k9uQMqwkX105BZOrBx7LeezVcnSOr6E_sLgpQhxa9x3p3T3SptA2kLOHlCShVVdYSZwoz4Wb1_obo3n6zfM9TzSa_ptx2tywnnAVziobrbIjH31oevuLUyh8FgUvxo0IcMC0Xig_bM1RchyOnLcqFpAllkMpT4DajvtSMxJvwRWf6oRyisIZ-oic21uCE30AXx65_PUX4RrMIRgTD5CUuBLYvSZUBU8k8jjEcDe5tktjtwyqcqMW9owGbFOA3GQXZ4Fj_VkT3-cXzcpR3myq0flL6xzDNMsa_HV3zywLwVY/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
