Hi Russ, Thanks for confirming!
We should be all set now. I appreciate the responsiveness. Sincerely, Sarah Tarrant RFC Production Center > On Mar 17, 2026, at 9:34 AM, Russ Housley <[email protected]> wrote: > > > >> On Mar 17, 2026, at 10:11 AM, Sarah Tarrant <[email protected]> >> wrote: >> >> Hi Corey, Mike, and Russ, >> >> Thank you for working with me on this. >> >> Corey - I figured out that the sourcecode (in markdown) requires three >> tildes "~~~" instead of two. Kramdown-rfc was having trouble with the >> sourcecode in Section 6, specifically line "MACAddress ::= OCTET STRING >> (SIZE (6 | 8 | 12 | 16))", which it was trying to convert to an incomplete >> table. After updating to the three tildes, the file now works! I don't >> believe you need to change anything on your end. >> >> All - I'm happy to update the <tt> tagging to single quotation marks for >> consistency, if that is the consensus. Please just let me know. > > That works for me. > >> All - Between the submitted -07 version and this new file, I noticed one >> update to a word that I wanted to verify before moving forward: >> "excluded_trees" was updated to "excluded_subtrees". Is this correct? > > Yes, "excluded_subtrees" is the correct term. It aligns with Section 6 of > RFC 5280. > > Russ > >> >> Original: >> 3.4.2.3. Union Operation >> ... >> Starting with an >> an excluded_trees empty set, with each level add to that set any >> constraints from the CA certificates that are not already in the set, >> or that are not covered by a constraint already in the set. >> >> Current: >> Starting with an >> excluded_subtrees empty set, with each level add to that set any >> constraints from the CA certificates that are not already in the set, >> or that are not covered by a constraint already in the set. >> >> >> Again, thank you for your patience with me. >> >> Sincerely, >> Sarah Tarrant >> RFC Production Center >> >>> On Mar 16, 2026, at 9:07 PM, Corey Bonnell <[email protected]> >>> wrote: >>> >>> Hi Sarah, >>> https://github.com/CBonnell/draft-housley-lamps-macaddress-on/blob/eabe72abfd2af40aa7c34192bf45ae5cea99cf6e/draft-ietf-lamps-macaddress-on.md?plain=1 >>> now contains the latest, including the changes that Mike made to the >>> formatting. >>> >>> Does this file work with your tooling? If not, please let me know the >>> specific error you're encountering so I can troubleshoot from this side. >>> >>> Thanks, >>> CoreyFrom: Russ Housley <[email protected]> >>> Sent: Monday, March 16, 2026 9:33 PM >>> To: Sarah Tarrant <[email protected]> >>> Cc: Corey Bonnell <[email protected]>; Joe Mandel >>> <[email protected]>; [email protected] >>> <[email protected]>; Mike StJohns <[email protected]>; >>> Tim Hollebeek <[email protected]>; Deb Cooley >>> <[email protected]>; RFC Editor <[email protected]>; >>> [email protected] <[email protected]> >>> Subject: Re: Document intake questions about >>> <draft-ietf-lamps-macaddress-on-07> >>> Sarah: >>> >>> Corey will work with you on the kramdown issues. He is making the final >>> edits that were included in -07 now. >>> >>> Russ >>> >>> >>>> On Mar 16, 2026, at 5:49 PM, Sarah Tarrant <[email protected]> >>>> wrote: >>>> >>>> Hi Russ, >>>> >>>> Thank you for the speedy response! >>>> >>>> 1) I don't have any recommendations for <tt> tags -- perhaps a coauthor >>>> has a suggestion/preference? >>>> >>>> 2) I've tried to make the markdown file work with kramdown-rfc, but I'm >>>> running into issues. Could you please attach the self-contained >>>> kramdown-rfc file in your response? >>>> >>>> 3) Thank you for the usernames!! >>>> >>>> Sincerely, >>>> Sarah Tarrant >>>> RFC Production Center >>>> >>>>> On Mar 16, 2026, at 4:17 PM, Russ Housley <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>>> On Mar 16, 2026, at 4:54 PM, Sarah Tarrant >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi Russ, >>>>>> >>>>>> Thank you for your reply. We have three remaining questions: >>>>>> >>>>>> 1) Regarding text styling, we did find <tt>1.3.6.1.5.5.7.8.12</tt> in >>>>>> Section 3: >>>>>> >>>>>> In this document "otherName", "OtherName" and "GeneralName.otherName" >>>>>> all refer to a GeneralName.otherName field included in a SAN or IAN. >>>>>> The new name form is identified by the OBJECT IDENTIFIER (OID) >>>>>> id-on-MACAddress (1.3.6.1.5.5.7.8.12) and declared below using the >>>>>> OTHER-NAME class declaration syntax. >>>>>> >>>>>> This is the only instance. Are these tags correct? >>>>> >>>>> I am fine with whatever styling you suggest. >>>>> >>>>>> 2) Regarding the markdown experiment, is the following markdown code up >>>>>> to date? If not, please attach the self-contained kramdown-rfc file in >>>>>> your response. >>>>>> >>>>>> https://github.com/CBonnell/draft-housley-lamps-macaddress-on/blob/main/draft-ietf-lamps-macaddress-on.md?plain=1 >>>>> >>>>> I believe so. Since the Internet-Draft repository was closed for IETF >>>>> 125 when -07 was posted, the "-latest" was changed to "-07" by hand so >>>>> that the Secretariat could post the draft with AD approval. >>>>> >>>>>> 3) Regarding the GitHub experiment, please provide all author, AD, >>>>>> and/or document shepherd GitHub usernames. >>>>> >>>>> Russ Housley = russhousley >>>>> Corey Bonnell = CBonnell >>>>> Joe Mandel = mandelj7 >>>>> Tomofumi Okubo = tomofumiokubo >>>>> Michael StJohns = mstjohns >>>>> >>>>> Tim Hollebeek = timfromdigicert >>>>> >>>>> Deb Cooley = debcooley >>>>> >>>>>> >>>>>> Sincerely, >>>>>> Sarah Tarrant >>>>>> RFC Production Center >>>>>> >>>>>>> On Mar 16, 2026, at 3:38 PM, Russ Housley <[email protected]> wrote: >>>>>>> >>>>>>> Hi Sarah. >>>>>>> >>>>>>>> 1) As there may have been multiple updates made to the document during >>>>>>>> Last Call, >>>>>>>> please review the current version of the document: >>>>>>>> >>>>>>>> * Is the text in the Abstract still accurate? >>>>>>>> * Are the Authors' Addresses, Contributors, and Acknowledgments >>>>>>>> sections current? >>>>>>> >>>>>>> The -07 version addresses the changes that were needed to complete IESG >>>>>>> Evaluation. >>>>>>> >>>>>>>> 2) Please share any style information that could help us with editing >>>>>>>> your >>>>>>>> document. For example: >>>>>>>> >>>>>>>> * Is your document's format or its terminology based on another >>>>>>>> document, >>>>>>>> WG style guide, etc.? If so, please provide a pointer to that >>>>>>>> information >>>>>>>> (e.g., "This document's terminology should match DNS terminology in >>>>>>>> RFC 9499." or "This document uses the style info at >>>>>>>> <https://httpwg.org/admin/editors/style-guide>."). >>>>>>>> * Is there a general pattern of capitalization or formatting of terms >>>>>>>> that >>>>>>>> editors can follow (e.g., "Field names should have initial >>>>>>>> capitalization." >>>>>>>> or "Parameter names should be in double quotes." or "<tt/> should be >>>>>>>> used >>>>>>>> for token names." etc.)? >>>>>>> >>>>>>> It is related to RFC 5280, which defines GeneralName. This document >>>>>>> defines a new otherName form of GeneralName. >>>>>>> >>>>>>>> 3) Please carefully review the entries and their URLs in the >>>>>>>> References section with the following in mind. Note that we will >>>>>>>> update as follows unless we hear otherwise at this time: >>>>>>>> >>>>>>>> * References to obsoleted RFCs will be updated to point to the current >>>>>>>> RFC on the topic in accordance with Section 4.8.6 of RFC 7322 >>>>>>>> (RFC Style Guide). >>>>>>>> >>>>>>>> * References to I-Ds that have been replaced by another I-D will be >>>>>>>> updated to point to the replacement I-D. >>>>>>>> >>>>>>>> * References to documents from other organizations that have been >>>>>>>> superseded will be updated to their superseding version. >>>>>>>> >>>>>>>> Note: To check for outdated RFC and I-D references, you can use >>>>>>>> idnits <https://author-tools.ietf.org/idnits>. You can also help the >>>>>>>> IETF Tools Team by testing idnits3 >>>>>>>> <https://author-tools.ietf.org/idnits3/> >>>>>>>> with your document and reporting any issues to them. >>>>>>> >>>>>>> All references are already final. >>>>>>> >>>>>>>> 4) Is there any text that requires special handling? For example: >>>>>>>> * Are there any sections that were contentious when the document was >>>>>>>> drafted? >>>>>>>> * Are any sections that need to be removed before publication marked >>>>>>>> as such >>>>>>>> (e.g., Implementation Status sections (per RFC 7942)). >>>>>>>> * Are there any instances of repeated text/sections that should be >>>>>>>> edited >>>>>>>> the same way? >>>>>>> >>>>>>> The handling of name constraints was carefully crafted to align with >>>>>>> the Section 4.2.1.10 of RFC 5280. >>>>>>> >>>>>>>> 5) This document uses one or more of the following text styles. >>>>>>>> Are these elements used consistently? >>>>>>>> >>>>>>>> * fixed width font (<tt/> or `) >>>>>>>> * italics (<em/> or *) >>>>>>>> * bold (<strong/> or **) >>>>>>> >>>>>>> These are not used. >>>>>>> >>>>>>>> 6) This document contains sourcecode: >>>>>>>> >>>>>>>> * Does the sourcecode validate? >>>>>>>> * Some sourcecode types (e.g., YANG) require certain references and/or >>>>>>>> text >>>>>>>> in the Security Considerations section. Is this information correct? >>>>>>>> * Is the sourcecode type indicated in the XML? (See information about >>>>>>>> types: >>>>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types.) >>>>>>> >>>>>>> Yes, the ASN.1 compiles without errors. >>>>>>> >>>>>>> There is pseudocode in Section 3.4 of the document. >>>>>>> >>>>>>>> 7) Would you like to participate in the RPC Pilot Test for editing in >>>>>>>> kramdown-rfc? >>>>>>>> If so, please let us know and provide a self-contained kramdown-rfc >>>>>>>> file. For more >>>>>>>> information about this experiment, see: >>>>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. >>>>>>> >>>>>>> We used kramdown-rfc, and we will gladly participate in the experiment. >>>>>>> >>>>>>>> 8) Would you like to participate in the RPC Pilot Test for completing >>>>>>>> AUTH48 in >>>>>>>> GitHub? If so, please let us know and provide all author, AD, and/or >>>>>>>> document >>>>>>>> shepherd GitHub usernames. For more information about this experiment, >>>>>>>> see: >>>>>>>> https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test. >>>>>>> >>>>>>> We are willing. >>>>>>> >>>>>>>> 9) Is there anything else that the RPC should be aware of while >>>>>>>> editing this >>>>>>>> document? >>>>>>> >>>>>>> No. >>>>>>> >>>>>>> Russ -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
