Re: [C431] AUTH48 [LB]: RFC 9174 <draft-ietf-dtn-tcpclv4-28.txt> NOW AVAILABLE

[Michael Demmer <[e-mail]>]

Nope that is definitely not a current address.

At the same time, I don't have a current relevant academic
affiliation, and I'm not sure I want to have my personal home address
listed in this public forum as that also seems irrelevant.

Is it possible to just omit the mailing address altogether? If not,
given how long it's been since I've been involved with this effort at
all, could I simply be removed from the authors list so I stop adding
extra burden to this process?

-mi

On Wed, Jan 19, 2022 at 8:44 AM Lynne Bartholomew <[e-mail]> wrote:
>
> Hi, Michael.
>
> We have updated your email address in this document and in our corresponding database record.
>
> Because you mentioned that you haven't been affiliated with Berkeley for some time, should your listing under Authors' Addresses be updated, or should it stay as is?  Currently:
>
>    Michael Demmer
>    University of California, Berkeley
>    Computer Science Division
>    445 Soda Hall
>    Berkeley, CA 94720-1776
>    United States of America
>
>    Email: [e-mail]
>
> The latest files are posted here:
>
>    https://www.rfc-editor.org/authors/rfc9174.txt
>    https://www.rfc-editor.org/authors/rfc9174.pdf
>    https://www.rfc-editor.org/authors/rfc9174.html
>    https://www.rfc-editor.org/authors/rfc9174.xml
>    https://www.rfc-editor.org/authors/rfc9174-diff.html
>    https://www.rfc-editor.org/authors/rfc9174-rfcdiff.html
>    https://www.rfc-editor.org/authors/rfc9174-auth48diff.html
>    https://www.rfc-editor.org/authors/rfc9174-lastdiff.html
>    https://www.rfc-editor.org/authors/rfc9174-lastrfcdiff.html
>
>    https://www.rfc-editor.org/authors/rfc9174-xmldiff1.html
>    https://www.rfc-editor.org/authors/rfc9174-xmldiff2.html
>
> Thank you!
>
> RFC Editor/lb
>
>
> > On Jan 18, 2022, at 10:34 AM, Michael Demmer <[e-mail]> wrote:
> >
> > Hi Lynne,
> >
> > I haven't been affiliated with Berkeley in many years -- the old email
> > address was forwarding to my gmail address, but perhaps something
> > changed there.
> >
> > That said, [e-mail] is a good email to reach me so you can
> > update accordingly.
> >
> > -m
> >
> > On Mon, Jan 3, 2022 at 10:39 AM Lynne Bartholomew <[e-mail]> wrote:
> >>
> >> Hi, Kevin and Michael.
> >>
> >> Kevin, thank you for the gmail address.
> >>
> >> Michael, if you receive this email, please advise regarding which email address we should use for you; if the berkeley.edu address is no longer valid, we would need to update this document, our corresponding database record, and the C431 mailing list.
> >>
> >> Thanks again!
> >>
> >> RFC Editor/lb
> >>
> >>> On Jan 3, 2022, at 10:27 AM, Kevin Fall <[e-mail]> wrote:
> >>>
> >>>
> >>> perhaps [e-mail] will work I think...
> >>> - Kevin
> >>>
> >>>
> >>>
> >>> On Mon, Jan 3, 2022 at 10:25 AM Lynne Bartholomew via C431 <[e-mail]> wrote:
> >>> Hello, authors, and Happy New Year!
> >>>
> >>> We are having difficulty reaching Michael Demmer at <[e-mail]> (we've received some bounces related to the C431 mailing list).  Do any of you have an alternative and functional email address for him?
> >>>
> >>> Thank you!
> >>>
> >>> RFC Editor/lb
> >>>
> >>>> On Dec 10, 2021, at 4:39 PM, Lynne Bartholomew via C431 <[e-mail]> wrote:
> >>>>
> >>>> Hi, Brian.
> >>>>
> >>>> We have noted your approval for publication on the AUTH48 status page:
> >>>>
> >>>>  https://www.rfc-editor.org/auth48/rfc9174
> >>>>
> >>>> If additional updates are needed for this document, we might check in with you again to confirm your approval.
> >>>>
> >>>> Thank you!
> >>>>
> >>>> RFC Editor/lb
> >>>>
> >>>>
> >>>>> On Dec 8, 2021, at 7:06 PM, Brian Sipos <[e-mail]> wrote:
> >>>>>
> >>>>> All,
> >>>>> I am satisfied with all of the last edits and the current state of the document. There has been some clarifying discussion in the cluster with some of the other documents, but I believe that no related changes are needed in this document.
> >>>>>
> >>>>> On Fri, Dec 3, 2021, 17:58 Lynne Bartholomew <[e-mail]> wrote:
> >>>>> Hi, Brian and Zahed.
> >>>>>
> >>>>> Thank you for the emails.  We have updated this document per your notes below.
> >>>>>
> >>>>> The latest files are here:
> >>>>>
> >>>>>  https://www.rfc-editor.org/authors/rfc9174.txt
> >>>>>  https://www.rfc-editor.org/authors/rfc9174.pdf
> >>>>>  https://www.rfc-editor.org/authors/rfc9174.html
> >>>>>  https://www.rfc-editor.org/authors/rfc9174.xml
> >>>>>  https://www.rfc-editor.org/authors/rfc9174-diff.html
> >>>>>  https://www.rfc-editor.org/authors/rfc9174-rfcdiff.html
> >>>>>  https://www.rfc-editor.org/authors/rfc9174-auth48diff.html
> >>>>>  https://www.rfc-editor.org/authors/rfc9174-lastdiff.html
> >>>>>  https://www.rfc-editor.org/authors/rfc9174-lastrfcdiff.html
> >>>>>
> >>>>>  https://www.rfc-editor.org/authors/rfc9174-xmldiff1.html
> >>>>>  https://www.rfc-editor.org/authors/rfc9174-xmldiff2.html
> >>>>>
> >>>>> Zahed, we have noted your approval re. the current text in Section 5.1.1:
> >>>>>
> >>>>>  https://www.rfc-editor.org/auth48/rfc9174
> >>>>>
> >>>>> Thanks again!
> >>>>>
> >>>>> RFC Editor/lb
> >>>>>
> >>>>>
> >>>>>> From: Zaheduzzaman Sarker via C431 <[e-mail]>
> >>>>>> Subject: Re: [C431] *[AD] (Martin Duke or Zaheduzzaman Sarker) Re: AUTH48 [LB]: RFC 9174 <draft-ietf-dtn-tcpclv4-28.txt> NOW AVAILABLE
> >>>>>> Date: December 3, 2021 at 12:26:41 AM PST
> >>>>>> To: Brian Sipos <[e-mail]>
> >>>>>> Cc: "[e-mail]" <[e-mail]>
> >>>>>>
> >>>>>> In that case, lets stick to “may”. With my very little knowledge in English language, I understand “may” provides kind of more certainty than “can” regarding the retransmission which fits better to the TCP recipe :-).
> >>>>>>
> >>>>>> BR
> >>>>>> Zahed
> >>>>>
> >>>>>
> >>>>>
> >>>>>>> From: Brian Sipos <[e-mail]>
> >>>>>>> Subject: Re: *[AD] (Martin Duke or Zaheduzzaman Sarker) Re: [C431] AUTH48 [LB]: RFC 9174 <draft-ietf-dtn-tcpclv4-28.txt> NOW AVAILABLE
> >>>>>>> Date: December 2, 2021 at 8:28:29 PM PST
> >>>>>>> To: Lynne Bartholomew <[e-mail]>
> >>>>>>> Cc: Martin Duke <[e-mail]>, Zaheduzzaman Sarker <[e-mail]>, RFC System <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
> >>>>>>>
> >>>>>>> Editors,
> >>>>>>> All of these last edits look good to me.
> >>>>>>>
> >>>>>>> Per Scott's earlier review message, the informative text in Section 8.10 can be clarified as
> >>>>>>> OLD:
> >>>>>>> ... identifying DTN endpoint IDs
> >>>>>>> NEW:
> >>>>>>> ... identifying bundle endpoint IDs
> >>>>>>>
> >>>>>>> And in Section 4.4.5 and Section 7.9 the related phrase can be clarified as
> >>>>>>> OLD:
> >>>>>>> ... DTN node ...
> >>>>>>> NEW:
> >>>>>>> ... bundle node ...
> >>>>>>>
> >>>>>>> I don't think the originals are particularly ambiguous but this new text is more consistent with Section 3.1 definitions of RFC 9171.
> >>>>>>>
> >>>>>>> Thanks for all of the work in cleaning up this document and the others in the cluster.
> >>>>>>> Brian S.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> From: Brian Sipos via C431 <[e-mail]>
> >>>>>>>> Subject: Re: [C431] *[AD] (Martin Duke or Zaheduzzaman Sarker) Re: AUTH48 [LB]: RFC 9174 <draft-ietf-dtn-tcpclv4-28.txt> NOW AVAILABLE
> >>>>>>>> Date: December 2, 2021 at 4:47:17 PM PST
> >>>>>>>> To: Zaheduzzaman Sarker <[e-mail]>
> >>>>>>>> Cc: [e-mail]
> >>>>>>>>
> >>>>>>>> Zahed,
> >>>>>>>> Only to avoid the word even in a non normative sense. I don't feel strongly about it though and leave it to your judgment.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>> From: Zaheduzzaman Sarker <[e-mail]>
> >>>>>>>>> Subject: Re: [C431] *[AD] (Martin Duke or Zaheduzzaman Sarker) Re: AUTH48 [LB]: RFC 9174 <draft-ietf-dtn-tcpclv4-28.txt> NOW AVAILABLE
> >>>>>>>>> Date: December 2, 2021 at 4:22:24 PM PST
> >>>>>>>>> To: Brian Sipos <[e-mail]>, Lynne Bartholomew <[e-mail]>
> >>>>>>>>> Cc: Martin Duke <[e-mail]>, "[e-mail]" <[e-mail]>
> >>>>>>>>>
> >>>>>>>>> Hi Brian,
> >>>>>>>>>
> >>>>>>>>> Yes, it should have not been a normative MAY in the first place but why not change it to “may “instead of “can”?
> >>>>>>>>>
> >>>>>>>>> BR
> >>>>>>>>> Zahed
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Dec 2, 2021, at 3:30 PM, Brian Sipos <[e-mail]> wrote:
> >>>>>>>>>
> >>>>>>>>> Editors,
> >>>>>>>>> Thank you, I will review this evening and get back to you.
> >>>>>>>>>
> >>>>>>>>> ADs,
> >>>>>>>>> The reason for removing the MAY is that is a preexisting TCP behavior and not one that we are prescribing here just describing. The requirement is on how the TCPCL entity can avoid bad interactions.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, Dec 2, 2021, 16:40 Lynne Bartholomew via C431 <[e-mail]> wrote:
> >>>>>>>>> Hi, Brian and *AD (Martin or Zahed).
> >>>>>>>>>
> >>>>>>>>> * Martin or Zahed, please let us know if you approve the change from "MAY" to "can" in Section 5.1.1.
> >>>>>>>>>
> >>>>>>>>> Brian, thank you for the updated XML file!  We have further updated it to (1) replace the "TBD"s with the correct IANA values and (2) incorporate the cluster updates as indicated in the cluster questions and replies pasted at the bottom of this thread.
> >>>>>>>>>
> >>>>>>>>> The latest files are posted here.  Please review the updates carefully, and let us know if we missed anything:
> >>>>>>>>>
> >>>>>>>>>  https://www.rfc-editor.org/authors/rfc9174.txt
> >>>>>>>>>  https://www.rfc-editor.org/authors/rfc9174.pdf
> >>>>>>>>>  https://www.rfc-editor.org/authors/rfc9174.html
> >>>>>>>>>  https://www.rfc-editor.org/authors/rfc9174.xml
> >>>>>>>>>  https://www.rfc-editor.org/authors/rfc9174-diff.html
> >>>>>>>>>  https://www.rfc-editor.org/authors/rfc9174-rfcdiff.html
> >>>>>>>>>  https://www.rfc-editor.org/authors/rfc9174-auth48diff.html
> >>>>>>>>>
> >>>>>>>>>  https://www.rfc-editor.org/authors/rfc9174-xmldiff1.html
> >>>>>>>>>  https://www.rfc-editor.org/authors/rfc9174-xmldiff2.html
> >>>>>>>>>
> >>>>>>>>> Thanks again!
> >>>>>>>>>
> >>>>>>>>> RFC Editor/lb
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Nov 29, 2021, at 9:47 AM, Brian Sipos via C431 <[e-mail]> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Editors,
> >>>>>>>>>> Attached is an updated XML document sourced from [1] with in-line comment responses prefixed with "BS:" and edits in the document itself (including some rephrasing from the editor's earlier changes). I've also attached an explicit "diff" from the editor's earlier XML document to make identifying these changes easier.
> >>>>>>>>>>
> >>>>>>>>>> Please let me know if these edits/responses are acceptable or if there are further comments,
> >>>>>>>>>> Brian S.
> >>>>>>>>>>
> >>>>>>>>>> [1] https://www.rfc-editor.org/authors/rfc9174.xml
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Mon, Nov 29, 2021 at 9:44 AM Brian Sipos <[e-mail]> wrote:
> >>>>>>>>>> Editors,
> >>>>>>>>>> Please be aware that my email address, which is currently accurate in the document, the datatracker <https://datatracker.ietf.org/doc/draft-ietf-dtn-tcpclv4/email/> and is the source of this message, is not on the Editor's original email distribution. Can this be updated for future correspondence?
> >>>>>>>>>>
> >>>>>>>>>> I will be responding to the editor's detailed comments shortly along with some additional clarifying edits in XML form.
> >>>>>>>>>> Thank you,
> >>>>>>>>>> Brian S.
> >>>>>>>>>> <rfc9174.xml><rfc9174-sipos-edits.diff>--
> >>>>>>>>>> C431 mailing list
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://www.rfc-editor.org/mailman/listinfo/c431
> >>>>>>>>>
> >>>>>>>>> = = = = = = = =
> >>>>>>>>>
> >>>>>>>>> Cluster emails:
> >>>>>>>>>
> >>>>>>>>>> From: "sburleig.sb--- via C431" <[e-mail]>
> >>>>>>>>>> Subject: Re: [C431] AUTH48 Questions for C431
> >>>>>>>>>> Date: November 24, 2021 at 7:31:44 PM PST
> >>>>>>>>>> To: <[e-mail]>
> >>>>>>>>>>
> >>>>>>>>>> Hi, all.  I've inserted my perspective on these questions in-line below.
> >>>>>>>>>>
> >>>>>>>>>> Scott
> >>>>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: C431 <[e-mail]> On Behalf Of Jean Mahoney via C431
> >>>>>>>>>> Sent: Wednesday, November 24, 2021 7:47 AM
> >>>>>>>>>> To: [e-mail]
> >>>>>>>>>> Subject: [C431] AUTH48 Questions for C431
> >>>>>>>>>>
> >>>>>>>>>> Authors,
> >>>>>>>>>>
> >>>>>>>>>> While reviewing this cluster of documents*, please reply to the questions below regarding consistency across the cluster. These questions are in addition to the document-specific questions that have been sent. Your reply will impact both of the documents in the cluster, so please discuss as necessary, and let us know the group decision. (You have the option of updating the edited XML files accordingly, if you are so inclined.) We will wait to hear from you before continuing with the publication process.
> >>>>>>>>>>
> >>>>>>>>>> * Currently in AUTH48 state:
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9171.txt
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9172.txt
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9173.txt
> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9174.txt
> >>>>>>>>>>
> >>>>>>>>>> You may track the progress of all documents in this cluster through
> >>>>>>>>>> AUTH48 at <https://www.rfc-editor.org/auth48/C431>.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 1)  Would you like to use "BPv7" as the acronym for Bundle Protocol version 7? "BPv7" is currently used in RFC 9173 and RFC 9174. "BP version 7" is used in RFC 9172.  RFC 9171 does not use a versioned acronym.
> >>>>>>>>>>
> >>>>>>>>>>     My preference would be for BPv7.
> >>>>>>>>>>
> >>>>>>>>>> 2)  Although RFC 9172 defines the security protocol for the Bundle Protocol, it does not expand the acronym "BPSec", and the name of the security protocol itself is inconsistent throughout the cluster (for example, "Bundle Protocol Security", "Bundle Protocol Security Protocol", "Bundle Security Protocol",  "bundle security"). We suggest the name "Bundle Protocol Security" with the acronym "BPSec".
> >>>>>>>>>>
> >>>>>>>>>>     I agree.  Labeling BPSec a "protocol" might actually be slightly misleading, as BPSec comprises a pair of extensions to the Bundle Protocol.  While the definition of "protocol" may well be open to constructive discussion, I think we would not similarly label the Hop Count extension a protocol, for example.
> >>>>>>>>>>
> >>>>>>>>>> 3)  The term "Bundle Protocol agent" is inconsistently capitalized and abbreviated. Please let us know how to make this consistent. We suggest using "BPA" after the initial expansion of the acronym.
> >>>>>>>>>>
> >>>>>>>>>> bundle protocol agent / Bundle Protocol Agent / Bundle Protocol agent BP Agent / BPA
> >>>>>>>>>>
> >>>>>>>>>>     I think the term should be in initial capitals when introduced and abbreviated to "BPA" thereafter.
> >>>>>>>>>>
> >>>>>>>>>> 4)  We note that earlier entries in the "Bundle Block Types" IANA registry capitalize the beginning of each word in the description and also end the description with the word "Block".
> >>>>>>>>>> <https://www.iana.org/assignments/bundle/bundle.xhtml#block-types>
> >>>>>>>>>>
> >>>>>>>>>> Should entries added by this cluster follow the same pattern? For instance, should "Bundle age (in milliseconds)" be "Bundle Age Block"?
> >>>>>>>>>> Or should newer entries drop "Block" from the description because it leads to redundancy in text? For instance, "BIB block" expands to "Block Integrity Block block".
> >>>>>>>>>>
> >>>>>>>>>> For any changes, we will update the documents and ask IANA to update the registry accordingly.
> >>>>>>>>>>
> >>>>>>>>>>     I think "Block" is in reality the final word in the description of each entry in this table, whether implicit or explicit.  For example, we would always refer to a block of block type 7 as a "Bundle Age Block".  But because it applies to every entry in the table, the token "Block" conveys no information and could profitably be omitted altogether.  So my preference would be to omit the terminal "Block" from the description of every entry in the table rather than append it where it is missing.  That is, I would propose that the description for block type 11 be changed from "Block Integrity Block" to "Block Integrity" while the formulations "Block Integrity Block" and "BIB" are retained wherever they currently appear in the BPSec specification.
> >>>>>>>>>>
> >>>>>>>>>> 5)  Should the expansion of the acronym "DTN" be "Delay-Tolerant
> >>>>>>>>>> Networking" or "Delay-Tolerant Networks"?  We note that the title of RFC
> >>>>>>>>>> 4838 is "Delay-Tolerant Networking Architecture", the expansion of the
> >>>>>>>>>> WG name is "Delay/Disruption Tolerant Networking", and the expansion of
> >>>>>>>>>> the RG name is "Delay-Tolerant Networking".
> >>>>>>>>>>
> >>>>>>>>>>     I know this is a controversial topic.  Without expecting to prevail, I will state my preference for "Delay-Tolerant Networking".  My reasoning is that (a) it's cleaner and simpler and (b) I think it's actually more accurate.  As has been pointed out from time to time, an IP router could fairly readily be modified to simply cache outbound datagrams pending repair of a network partition, instead of simply discarding them; that sort of disruption tolerance is relatively trivial.  The reason that DTN initially drew the attention of DARPA, I think, was that it addressed the less trivially managed effects of disruption, i.e., large increases in round-trip time.  Tolerance of large and variable round-trip times is fundamental to the concept of DTN, regardless of whether those long round-trip times are attributable to transient link outages or to large signal propagation latencies.  The essence of DTN is ditching the client/server, query/response model of communications - because the roun
> >>>>>>>>> d-
> >>>>>>>>>> trip delays can be too large to make that model workable - and turning instead to an asynchronous model as implemented by "bundling", AMA, LTP, etc.  Its ability to function successfully over interplanetary signal propagation latencies is what enables DTN to function successfully over disrupted terrestrial links as well; disruption is only one of the possible circumstances in which the client/server model fails.
> >>>>>>>>>>
> >>>>>>>>>> 6)  We see inconsistency in hyphenation when "convergence layer" is used
> >>>>>>>>>> as an adjective. For example, "convergence layer service" and
> >>>>>>>>>> "covergence-layer adapter". Please let us know how to make this
> >>>>>>>>>> consistent. We suggest the hyphenated form be used when
> >>>>>>>>>> "convergence-layer" is modifying a noun.
> >>>>>>>>>>
> >>>>>>>>>>     I agree.
> >>>>>>>>>>
> >>>>>>>>>> 7)  We also see inconsistent hyphenation with "block-type-specific
> >>>>>>>>>> data". For example, "block-type-specific-data field" and
> >>>>>>>>>> "block-type-specific data field". Please let us know how to make this
> >>>>>>>>>> consistent. We note that RFC 5050 uses "block-type-specific data field"
> >>>>>>>>>> consistently.
> >>>>>>>>>>
> >>>>>>>>>>     I prefer that RFC 5050 usage.
> >>>>>>>>>>
> >>>>>>>>>> 8)  The capitalization of "Node ID" and "Endpoint ID" is inconsistent
> >>>>>>>>>> across the cluster, although RFC 9171, which defines these terms,
> >>>>>>>>>> consistently uses "node ID" and "endpoint ID". Please let us know how
> >>>>>>>>>> you prefer these terms to be capitalized.
> >>>>>>>>>>
> >>>>>>>>>>     Not surprisingly, I prefer the usage in RFC 9171.
> >>>>>>>>>>
> >>>>>>>>>> Please review the use of the terms "node ID", "endpoint ID", and "EID"
> >>>>>>>>>> in your documents to ensure that their usages are correct.
> >>>>>>>>>>
> >>>>>>>>>> We note that RFC 9172 defines and uses the term "waypoint", which is
> >>>>>>>>>> "any node that receives a bundle from a forwarder that is not the bundle
> >>>>>>>>>> destination." The term seems more broadly applicable to the cluster, but
> >>>>>>>>>> it is not used in the other documents. Please let us know if and how
> >>>>>>>>>> this may be made consistent.
> >>>>>>>>>>
> >>>>>>>>>>     I like the term "waypoint" and would be in favor of using it wherever that concept bears on our specifications.
> >>>>>>>>>>
> >>>>>>>>>> If you chose to make changes to these terms, please make your changes to
> >>>>>>>>>> the XML files and send those changes to us.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 9)  Please let us know how to make the capitalization of "block
> >>>>>>>>>> processing control flags" and "bundle processing control flags"
> >>>>>>>>>> consistent across the cluster. Although more instances are lowercase,
> >>>>>>>>>> there is a mix of capitalization styles.
> >>>>>>>>>>
> >>>>>>>>>> Should shortened versions of the term (i.e., "processing flags") be
> >>>>>>>>>> corrected to "processing control flags"?
> >>>>>>>>>>
> >>>>>>>>>>     I think the lower-case usage is appropriate, and unfortunately I think in both cases it is clearer to write out the entire term wherever it appears: block processing control flags, bundle processing control flags.
> >>>>>>>>>>
> >>>>>>>>>> 10) Edward, we have added the "III" suffix to your name across the
> >>>>>>>>>> cluster documents to make them consistent. Please let us know if any
> >>>>>>>>>> changes are necessary.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Thank you,
> >>>>>>>>>> RFC Editor
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> C431 mailing list
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://www.rfc-editor.org/mailman/listinfo/c431
> >>>>>>>>>
> >>>>>>>>
> >>>>
> >>>> --
> >>>> C431 mailing list
> >>>> [e-mail]
> >>>> https://www.rfc-editor.org/mailman/listinfo/c431
> >>>
> >>> --
> >>> C431 mailing list
> >>> [e-mail]
> >>> https://www.rfc-editor.org/mailman/listinfo/c431
> >>
> >
>