> 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]
