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