FYI: draft-barnes-mimi-identity-arch-02 has been submitted
Thanks,
-rohan
On Tue, Feb 4, 2025 at 2:44 PM Rohan Mahy <rohan.m...@gmail.com> wrote:
> Hi,
> Attached is my revised XML file with some minor changes.
>
> 1) I am updating draft-barnes-mimi-identity-arch so it will no longer be
> an expired draft. I already submitted a PR for my intended changes. My
> co-author should review it today or tomorrow. Once it is submitted, I will
> let you know
>
> 2) The XML, HTML, and TXT versions look good. The PDF version has the
> section headings for References and Normative References at the end of one
> page with the references starting on the next one. If it is straightforward
> to start Section 6 on the next page, that seems desirable.
>
> Many thanks,
> -rohan
>
> On Tue, Feb 4, 2025 at 7:46 AM Megan Ferguson <
> mfergu...@staff.rfc-editor.org> wrote:
>
>> Thanks for the guidance, Rohan and Russ!
>>
>> We will await Rohan’s updated XML file with further changes.
>>
>> Thank you.
>>
>> RFC Editor/mf
>>
>> > On Feb 4, 2025, at 8:16 AM, Russ Housley <hous...@vigilsec.com> wrote:
>> >
>> > Rohan and RFC Editor:
>> >
>> > 1) <!--[rfced] We note a small discrepancy between the ASN.1 snippet in
>> >> Section 3 and the ASN.1 in Appendix A: the { character at the end
>> >> of the "id-kp" line in Section 3 is on the following line in the
>> >> Appendix. Please review and let us know if/how to make these
>> >> consistent. Might it be possible to simply point the reader to
>> >> Appendix A instead of repeating the code?
>> >>
>> >> Original (Section 3):
>> >> id-kp OBJECT IDENTIFIER ::= {
>> >> iso(1) identified-organization(3) dod(6) internet(1)
>> >> security(5) mechanisms(5) pkix(7) kp(3) }
>> >>
>> >> id-kp-imUri OBJECT IDENTIFIER ::= { id-kp TBD1 }
>> >>
>> >> Original (Appendix A):
>> >> id-kp OBJECT IDENTIFIER ::=
>> >> { iso(1) identified-organization(3) dod(6) internet(1)
>> >> security(5) mechanisms(5) pkix(7) kp(3) }
>> >>
>> >>
>> >> id-kp-imUri OBJECT IDENTIFIER ::= { id-kp TBD1 }
>> >>
>> >> -->
>> >> I followed the formatting conventions of other similar registrations,
>> including RFC9509, which is the most recent registration of an Extended Key
>> Purpose. It also places the opening curly brace in a different location in
>> the textual definition than it does in the MIB. I would tend to keep the
>> status quo unless there is consensus otherwise from the chairs and ADs.
>> >
>> > Both formats will work. ASN.1 compilers will be fine with either one.
>> >
>> > Russ
>>
>>
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
