[auth48] [IANA] Re: AUTH48: RFC-to-be 9296 <draft-liu-lsr-p2poverlan-12> for your review

[Karen Moore <[e-mail]>]

Hello IANA,

We are close to publishing RFC-to-be 9296 and would like to request that you make the assignments now so we can ensure that the text matches your assignments (as we felt that the needed updates were not straightforward). 

> On May 25, 2022, at 6:07 PM, Sabrina Tanamal via RT <[e-mail]> wrote:
> 
> RFC Editor, 
> 
> In accordance with instructions from the YANG doctors, we will not complete the IANA action in Section 5 until the document has been published.
> 
> Please reply to acknowledge receipt of this message. 
> 
> Thanks,
> 
> Sabrina Tanamal
> Lead IANA Services Specialist

Thank you in advance,

RFC Editor/kc


> On Aug 17, 2022, at 12:28 PM, Karen Moore <[e-mail]> wrote:
> 
> Hi Eliot,
> 
> We have noted your approval on the AUTH48 status page for this document (https://www.rfc-editor.org/auth48/rfc9296).  We will now ask IANA to update their registries accordingly; we will inform everyone when the actions are complete.
> 
> Best regards,
> 
> RFC Editor/kc
> 
>> On Aug 17, 2022, at 12:05 PM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>> 
>> Approved!
>> 
>> On 17.08.22 20:53, Karen Moore wrote:
>>> Congjie, Harold, and Eliot,
>>> 
>>> Thank you for your replies.  We have noted approvals for Congjie and Harold on the AUTH48 status page for this document.
>>> 
>>> Eliot, we agree that a definite article should be added for consistency to the instance you pointed out as “the ifStackTable” was used elsewhere in the document (3 instances); thanks for catching this. (Note that we do not have specific guidance on this in the style guide as we evaluate the need for articles on a case-by-case basis as there can be exceptions.)  The update is now reflected in our files; please let us know if you approve the document with this change.
>>> 
>>> (Please refresh)
>>> The updated XML file is here:
>>> https://www.rfc-editor.org/authors/rfc9296.xml
>>> 
>>> The updated output files are here:
>>> https://www.rfc-editor.org/authors/rfc9296.txt
>>> https://www.rfc-editor.org/authors/rfc9296.pdf
>>> https://www.rfc-editor.org/authors/rfc9296.html
>>> 
>>> This diff file shows all changes made during AUTH48:
>>> https://www.rfc-editor.org/authors/rfc9296-auth48diff.html
>>> 
>>> This diff file shows all changes made to date:
>>> https://www.rfc-editor.org/authors/rfc9296-diff.html
>>> 
>>> Please contact us with any further updates or with your approval of the document in its current form.  We now await approval from Eliot (ISE) prior to moving forward in the publication process.
>>> 
>>> For the AUTH48 status of this document, please see:
>>> https://www.rfc-editor.org/auth48/rfc9296
>>> 
>>> Thank you,
>>> 
>>> RFC Editor/kc
>>> 
>>>> On Aug 16, 2022, at 11:47 PM, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
>>>> 
>>>> Hi Karen,
>>>> 
>>>> I just have one question.
>>>> 
>>>> In Section 3.1, 2nd para, beginning of the first (only) sentence:
>>>> 
>>>>> In ifStackTable, the higher layer
>>>> This "sounds" wrong to me.
>>>> 
>>>> We do tend to refer SNMP tables with definite articles.  It is true that it is a proper noun, in that it is not in the dictionary, but how do we address this in the context of technical documentation?
>>>> 
>>>> Eliot
>>> 
>>> 
>>>> On Aug 16, 2022, at 6:02 PM, Harold Liu <[e-mail]> wrote:
>>>> 
>>>> Thanks Karen, I have reviewed the revised final version in its entirety and I believe it has improved the quality of the document without changing any of the original purpose of the document. So it looks good to me as well, this is my approval of this document.
>>>> 
>>>> Brs
>>>> 
>>>> On Aug 16, 2022, at 5:54 PM, Congjie Zhang <[e-mail]> wrote:
>>>> 
>>>> Thanks Harold, Karen and Joel.
>>>> Fine with me as well.
>>>> 
>>>> 
>>>> Thanks,
>>>> Congjie
>>>> 
>>>> -----Original Message-----
>>>> From: Joel Halpern <[e-mail]>
>>>> Sent: Tuesday, August 16, 2022 8:46 PM
>>>> To: Harold Liu <harold.liu=[e-mail]>; Karen Moore <[e-mail]>; Congjie Zhang <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>>> Subject: RE: AUTH48: RFC-to-be 9296 <draft-liu-lsr-p2poverlan-12> for your review
>>>> 
>>>> Thank you Harold and Karen.  Looks good to me.
>>>> Yours,
>>>> Joel
>>>> 
>>>> -----Original Message-----
>>>> From: Harold Liu <harold.liu=[e-mail]>
>>>> Sent: Monday, August 15, 2022 9:19 PM
>>>> To: Karen Moore <[e-mail]>; Joel Halpern <[e-mail]>; Congjie Zhang <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>>> Subject: RE: AUTH48: RFC-to-be 9296 <draft-liu-lsr-p2poverlan-12> for your review
>>>> 
>>>> Hello Karen, thanks for your response, I answered the questions following and please let me know if you or your team have any further question:
>>>> 
>>>> <!--1) Should a reference to the IANA registry (https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml) be added to the end of this sentence? If so, we will add the corresponding entry under the Informative References section.
>>>> 
>>>> <Harold>
>>>> I thought "defined in the Iana-if-type YANG module" was a clear description before, but after thinking about your suggestion,  I think your suggestion is right - adding a reference to the IANA registry is a better description because we cannot assume that all readers have a strong background and know where to get the "IANA -if-type YANG Module", so please modify it as follows:
>>>> 
>>>> In ifStackTable, the higher layer of the P2P interface over LAN type
>>>> SHALL be network layer "ipForward" to enable IP routing, and the
>>>> lower layer of the P2P interface over LAN type SHOULD be any link-
>>>> data layer that can be bound to "ipForward", including
>>>> "ethernetCsmacd", "ieee8023adLag", "l2vlan", and so on (defined in
>>>> the iana-if-type YANG module [IANA-ifTYPE]).
>>>> 
>>>> Informative Ref Entry:
>>>> [IANA-ifTYPE]
>>>>             IANA, “YANG Module Names",
>>>>             <https://www.iana.org/assignments/yang-parameters>.
>>>> </Harold>
>>>> -->
>>>> 
>>>> <!--2) In the following, “SHOULD always be” is a bit confusing. For clarity, would it make sense to update as “SHOULD be” or “MUST always be”?
>>>> 
>>>> <Harold>
>>>> I believe "SHOULD be" is better to make the description clear, so please:
>>>> 
>>>>  In general, the higher layer of a P2P over a LAN type SHOULD
>>>>  be "ipForward" (value 142 in [Assignment]), and the lower layer of
>>>>  P2P over a LAN type SHOULD be any appropriate link-data layer of
>>>>  "ipForward".
>>>> </Harold>
>>>> -->
>>>> 
>>>> <!--3) We updated the text in the IANA section (see Section 5). Please review and let us know if any further changes are needed.
>>>> <Harold>
>>>> I saw the current text of Section 5 is:
>>>> 
>>>> In the "Interface Types (ifType)" registry, value 303 is assigned to
>>>> p2pOverLan [Assignment]. As this document explains how the
>>>> p2pOverLan (303) ifType is to be used, IANA has amended the reference
>>>> for p2pOverLan (303) to point to this document (instead of [RFC5309])
>>>> and made a similar amendment in the YANG iana-if-type module
>>>> [IANA-ifTYPE] (originally specified in [RFC7224]).
>>>> 
>>>> Thank you very much for your update, I think there is no problem with such text because it presents our original intention.
>>>> </Harold>
>>>> -->
>>>> 
>>>> Brs
>>>> 
>>>> -----Original Message-----
>>>> From: Karen Moore <[e-mail]>
>>>> Sent: Tuesday, August 16, 2022 5:09 AM
>>>> To: Joel Halpern <joel.halpern=[e-mail]>; Harold Liu <[e-mail]>; Congjie Zhang <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>>> Subject: Re: AUTH48: RFC-to-be 9296 <draft-liu-lsr-p2poverlan-12> for your review
>>>> 
>>>> Hello Harold and Joel,
>>>> 
>>>> Thank you for your replies.  Apologies for the delayed response - we were discussing some of the updates internally before replying to the authors.
>>>> 
>>>> We have updated our files based on Harold's replies, and we have some additional questions.
>>>> 
>>>> 1) Should a reference to the IANA registry (https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml) be added to the end of this sentence? If so, we will add the corresponding entry under the Informative References section.
>>>> 
>>>> Current:
>>>> In ifStackTable, the higher layer of the P2P interface over LAN type
>>>> SHALL be network layer "ipForward" to enable IP routing, and the
>>>> lower layer of the P2P interface over LAN type SHOULD be any link-
>>>> data layer that can be bound to "ipForward", including
>>>> "ethernetCsmacd", "ieee8023adLag", "l2vlan", and so on (defined in
>>>> the iana-if-type YANG module.
>>>> 
>>>> Perhaps:
>>>> In ifStackTable, the higher layer of the P2P interface over LAN type
>>>> SHALL be network layer "ipForward" to enable IP routing, and the
>>>> lower layer of the P2P interface over LAN type SHOULD be any link-
>>>> data layer that can be bound to "ipForward", including
>>>> "ethernetCsmacd", "ieee8023adLag", "l2vlan", and so on (defined in
>>>> the iana-if-type YANG module [IANA-ifTYPE]).
>>>> 
>>>> Informative Ref Entry:
>>>> [IANA-ifTYPE]
>>>>             IANA, “YANG Module Names",
>>>>             <https://www.iana.org/assignments/yang-parameters>.
>>>> 
>>>> 2) In the following, “SHOULD always be” is a bit confusing. For clarity, would it make sense to update as “SHOULD be” or “MUST always be”?
>>>> 
>>>> Current:
>>>>  In general, the higher layer of a P2P over a LAN type SHOULD always
>>>>  be "ipForward" (value 142 in [Assignment]), and the lower layer of
>>>>  P2P over a LAN type SHOULD be any appropriate link-data layer of
>>>>  "ipForward”.
>>>> 
>>>> Perhaps:
>>>>  In general, the higher layer of a P2P over a LAN type SHOULD
>>>>  be "ipForward" (value 142 in [Assignment]), and the lower layer of
>>>>  P2P over a LAN type SHOULD be any appropriate link-data layer of
>>>>  "ipForward".
>>>> 
>>>> 3) We updated the text in the IANA section (see Section 5). Please review and let us know if any further changes are needed.
>>>> 
>>>> 
>>>> The updated XML file is here:
>>>> https://www.rfc-editor.org/authors/rfc9296.xml
>>>> 
>>>> The updated output files are here:
>>>> https://www.rfc-editor.org/authors/rfc9296.txt
>>>> https://www.rfc-editor.org/authors/rfc9296.pdf
>>>> https://www.rfc-editor.org/authors/rfc9296.html
>>>> 
>>>> This diff file shows all changes made during AUTH48:
>>>> https://www.rfc-editor.org/authors/rfc9296-auth48diff.html
>>>> 
>>>> This diff file shows all changes made to date:
>>>> https://www.rfc-editor.org/authors/rfc9296-diff.html
>>>> 
>>>> Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC.
>>>> 
>>>> Please contact us with any further updates or with your approval of the document in its current form.  We will await approvals from each author, in addition to Eliot (ISE), prior to moving forward in the publication process.
>>>> 
>>>> For the AUTH48 status of this document, please see:
>>>> https://www.rfc-editor.org/auth48/rfc9296
>>>> 
>>>> Thank you,
>>>> 
>>>> RFC Editor/kc
>>>> 
>>>>> On Aug 15, 2022, at 6:36 AM, Joel Halpern <joel.halpern=[e-mail]> wrote:
>>>>> 
>>>>> Editors, it is unclear from the status page what the current status is.
>>>>> Harold submitted replies to the questions (below).  I do not recall seeing an acknowledgment of those replies.  Are you waiting before confirming to hear from myself and Congie?  If you are waiting for me, this is to confirm that I agree with his resolutions.  I had assumed we would see a reply from you indicating whether those resolutions were sufficient, so Congie and I (and the ISE?) could sign off?
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> -----Original Message-----
>>>>> From: Harold Liu <[e-mail]>
>>>>> Sent: Tuesday, August 9, 2022 11:07 AM
>>>>> To: [e-mail]; Joel Halpern
>>>>> <[e-mail]>; Congjie Zhang
>>>>> <[e-mail]>
>>>>> Cc: [e-mail]; [e-mail];
>>>>> [e-mail]
>>>>> Subject: RE: AUTH48: RFC-to-be 9296 <draft-liu-lsr-p2poverlan-12> for
>>>>> your review
>>>>> 
>>>>> Thanks a lot editors, this mail is to resolve your questions:
>>>>> 
>>>>> 1) <!-- [rfced] The document's title creates some hyphenation questions, and we are curious if we could get a better matchup between the title and the rest of the document's stated purpose (see the final line of the Introduction's penultimate paragraph).  Please review this suggested update and let us know if this, or another title of your suggestion, might work.
>>>>> 
>>>>> <Authors>
>>>>> It is good to change the title as your suggestion, please change the title to:
>>>>> ifStackTable for the Point-to-Point (P2P) Interface over a LAN Type:
>>>>> Definition and Example </Authors>
>>>>> -->
>>>>> 
>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search.
>>>>> <Authors>
>>>>> "ifType", "ifStack", and "point-to-point" would seem the good candidates.
>>>>> </Authors>
>>>>> -->
>>>>> 
>>>>> 3) <!--[rfced] There appears to be a slight mismatch in these two very similar phrases from the Abstract and Introduction.  Please review and let us know if/how they should be made uniform.  Specifically, see the difference between "the P2P interface over LAN ifType" vs. "a P2P interface over LAN type".
>>>>> 
>>>>> <Authors>
>>>>> In general, "ifType" is a specific description in ifStackTable, and "type" is a generic description, where the use of "ifType" and "type" in Abstract and Introduction does introduce ambiguity.
>>>>> So the suggested approach here is to use " ifType" when presented with a "p2pOverLan" or "IANA" or "value 303", and "type" when presented with a "P2P Interface over LAN".
>>>>> In other words, please change "for the P2P interface over a LAN ifType" to "for the P2P interface over a LAN Type" in Abstract.
>>>>> The other descriptions of "type" in Abstract and Introduction are fine.
>>>>> </Authors>
>>>>> -->
>>>>> 
>>>>> 4) <!-- [rfced] May we update "P2P interface lower layer" to "lower layer of the P2P interface"?
>>>>> 
>>>>> <Authors>
>>>>> Yes, " lower layer of the P2P interface" is more clear, please help to update.
>>>>> </Authors>
>>>>> -->
>>>>> 
>>>>> 5) <!--[rfced] The following paragraph is basically a single sentence that uses back-to-back clauses beginning with the relative pronoun "that".
>>>>> Please review our suggested update and check whether your intended meaning has been preserved.
>>>>> 
>>>>> In addition, is to what does "LAN type higher layer" refer and "LAN type lower layer" refer?  Perhaps "P2P over higher/lower-layer LAN protocols"
>>>>> or "higher/lower-layer P2P interface over LAN", or "higher/lower-layer-if"?
>>>>> Please let us know how this text may be clarified and that we may want to apply a similar update where these phrases are used throughout the document.
>>>>> 
>>>>> <Authors>
>>>>> P2P over a LAN type is interlayer, the upper layer of P2P over a LAN type is "ipForward", and the lower layer is any link-data layer applicable to "ipForward".  The original description of this paragraph does need to be clear, perhaps it could be amended in this way.
>>>>> 
>>>>> Perhaps:
>>>>> In standard network management protocols that make use of
>>>>> ifStackTables, the P2P interface over a LAN type is intended to be used
>>>>> solely as a means to signal that the upper-layer interface of link-data layer is a P2P
>>>>> interface. Thus, the upper and lower layers of P2P over a LAN type are
>>>>> expected to apply appropriate semantics.  In general, the higher layer of a P2P over a
>>>>> LAN type SHOULD always be "ipForward" (value 142 in
>>>>> [Assignment]), and the lower layer of P2P over a LAN type SHOULD be any
>>>>> appropriate link-data layer of "ipForward".
>>>>> </Authors>
>>>>> -->
>>>>> 
>>>>> 6) <!-- [rfced] Would it make sense to udpate this text as follows:
>>>>> 
>>>>> <Authors>
>>>>> Your suggestion is good, please update the text as:
>>>>> 
>>>>> "
>>>>> The purpose of this document is to serve as a reference
>>>>> for ifType 303 by suggesting how the ifStackTable for the P2P interface
>>>>> over a LAN type is to be used and providing examples.
>>>>> "
>>>>> </Authors>
>>>>> -->
>>>>> 
>>>>> 7) <!-- [rfced] What is 'in "Interface Management YANG"' referring to?
>>>>> Is it the IETF interfaces YANG module?  The title of RFC 8343?  How can we update?
>>>>> 
>>>>> <Authors>
>>>>> Yes, the "Interface Management YANG" refer to RFC 8343, " A YANG Data Model for Interface Management". The following text is better for me:
>>>>> 
>>>>> "
>>>>> If a device implements the IF-MIB [RFC2863], then each entry in the
>>>>> "/interfaces/interface" list (see "A YANG Data Model for Interface
>>>>> Management" [RFC8343]) in the operational state is typically mapped
>>>>> to one ifEntry as required in [RFC8343].
>>>>> "
>>>>> </Authors>
>>>>> -->
>>>>> 
>>>>> 8) <!-- [rfced] Please be more specific regarding the text "defined in IANA".
>>>>> Is this meant to point the reader to the iana-if-type YANG Module <https://www.iana.org/assignments/yang-parameters/[e-mail]>?
>>>>> Also note that we are having a tough time parsing "LAN type higher layer"
>>>>> and "LAN type lower layer" here.
>>>>> 
>>>>> <Authors>
>>>>> Yes, "defined in IANA" means to point the reader to the iana-if-type YANG Module <https://www.iana.org/assignments/yang-parameters/[e-mail]>, and also < https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-5>.
>>>>> Again P2P over a LAN type is interlayer, the upper layer of P2P over a LAN type is "ipForward" (one ifType defined https://www.iana.org/assignments/yang-parameters/[e-mail] or ), and the lower layer is any link-data layer applicable to "ipForward" (also, the applicable lower link-data layer types are from https://www.iana.org/assignments/yang-parameters/[e-mail] and https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-5).
>>>>> 
>>>>> The preferred text is:
>>>>> "
>>>>> In ifStackTable the higher layer of the P2P interface over LAN type SHALL be
>>>>> network layer "ipForward" to enable IP routing, and the lower layer of the P2P interface
>>>>> over LAN type SHOULD be any link data layer that can be
>>>>> bound to "ipForward" including "ethernetCsmacd", "ieee8023adLag",
>>>>> "l2vlan", and so on (defined in iana-if-type YANG Module)."
>>>>> </Authors>
>>>>> -->
>>>>> 
>>>>> 9) <!-- [rfced] IANA indicates that they will complete these actions closer to the time of publication per instructions from the YANG doctors.
>>>>> For our clarity, does "YANG iana-if-type module" refer to https://www.iana.org/assignments/yang-parameters/[e-mail]?
>>>>> If yes, is the reference to RFC 8561 correct?  We only see the following that refer to RFC 8561:
>>>>> 
>>>>> identity microwaveCarrierTermination {
>>>>>  base iana-interface-type;
>>>>>  description
>>>>>    "air interface of a single microwave carrier.";
>>>>>  reference
>>>>>    "RFC 8561 - A YANG Data Model for Microwave Radio Link";  }
>>>>> identity microwaveRadioLinkTerminal {
>>>>>  base iana-interface-type;
>>>>>  description
>>>>>    "radio link interface for one or several aggregated microwave carriers.";
>>>>>  reference
>>>>>    "RFC 8561 - A YANG Data Model for Microwave Radio Link";
>>>>> 
>>>>> <Authors>
>>>>> Yes, "YANG iana-if-type module" refer to https://www.iana.org/assignments/yang-parameters/[e-mail].
>>>>> 
>>>>> We expect to update the one:
>>>>> identity p2pOverLan {
>>>>>  base iana-interface-type;
>>>>>  description
>>>>>    "Point to Point over LAN interface.";
>>>>>  reference
>>>>>    "RFC 5309 - Point-to-Point Operation over LAN in Link State
>>>>> Routing Protocols";  } Change the reference from "RFC 5309" to this
>>>>> RFC.
>>>>> 
>>>>> I checked the latest iana-if-type (version 2022-03-07), now "identity p2pOverLan" does refer to "RFC 5309" but in last version of "YANG iana-if-type module" "identity p2pOverLan" refers to "RFC 8561" that's why we wrote it in this draft, so now we should correct the content as below:
>>>>> "
>>>>> IANA is
>>>>> requested to amend the reference for that code point to be to this
>>>>> document and to make a similar amendment in the YANG iana-if-type
>>>>> module (originally specified in [RFC7224]) which currently points to
>>>>> [RFC5309], as this document explains how the ifType is to be used.
>>>>> "
>>>>> 
>>>>> And also remove the reference RFC8561 from "Normative References" list of section 6.1.
>>>>> </Authors>
>>>>> -->
>>>>> 
>>>>> 10) <!-- [rfced] Should "LAG" be expanded as Link Aggregation Group or something else?
>>>>> 
>>>>> <Authors>
>>>>> Yes, "LAG" means Link Aggregation Group.
>>>>> </Authors>
>>>>> -->
>>>>> 
>>>>> Brs
>>>>> 
>>>>> -----Original Message-----
>>>>> From: [e-mail] <[e-mail]>
>>>>> Sent: Tuesday, August 9, 2022 5:10 AM
>>>>> To: Harold Liu <[e-mail]>; Joel Halpern
>>>>> <[e-mail]>; Congjie Zhang
>>>>> <[e-mail]>
>>>>> Cc: [e-mail]; [e-mail];
>>>>> [e-mail]; [e-mail]
>>>>> Subject: Re: AUTH48: RFC-to-be 9296 <draft-liu-lsr-p2poverlan-12> for
>>>>> your review
>>>>> 
>>>>> Authors,
>>>>> 
>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>>>>> 
>>>>> 1) <!-- [rfced] The document's title creates some hyphenation questions, and we are curious if we could get a better matchup between the title and the rest of the document's stated purpose (see the final line of the Introduction's penultimate paragraph).  Please review this suggested update and let us know if this, or another title of your suggestion, might work.
>>>>> 
>>>>> Original:
>>>>> Interface Stack Table Definition and Example for Point-to-Point (P2P)
>>>>> Interface over LAN
>>>>> 
>>>>> Perhaps:
>>>>> ifStackTable for the Point-to-Point (P2P) Interface over a LAN Type:
>>>>> Definition and Examples
>>>>> 
>>>>> Original from the penultimate paragraph of the introduction:
>>>>> So the purpose of this document is to
>>>>> request IANA to add this document as a reference to ifType 303, as
>>>>> well as suggest how to use ifStackTable for the P2P interface over
>>>>> LAN type, and provide examples.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 3) <!--[rfced] There appears to be a slight mismatch in these two very similar phrases from the Abstract and Introduction.  Please review and let us know if/how they should be made uniform.  Specifically, see the difference between "the P2P interface over LAN ifType" vs. "a P2P interface over LAN type".
>>>>> 
>>>>> Original Abstract:
>>>>> This document provides advice about the ifStack for the P2P interface
>>>>> over LAN ifType to facilitate operational control, maintenance and
>>>>> statistics.
>>>>> 
>>>>> Original Introduction:
>>>>> ... an interface is to be considered a P2P
>>>>> interface over LAN type explicitly in the interface stack.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 4) <!-- [rfced] May we update "P2P interface lower layer" to "lower layer of the P2P interface"?
>>>>> 
>>>>> Original:
>>>>> If no entry specifies the P2P interface
>>>>> lower layer, management tools lose the ability to retrieve and
>>>>> measure properties specific to lower layers.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 5) <!--[rfced] The following paragraph is basically a single sentence that uses back-to-back clauses beginning with the relative pronoun "that".
>>>>> Please review our suggested update and check whether your intended
>>>>> meaning has been preserved.  I
>>>>> 
>>>>> In addition, is to what does "LAN type higher layer" refer and "LAN type lower layer" refer?  Perhaps "P2P over higher/lower-layer LAN protocols"
>>>>> or "higher/lower-layer P2P interface over LAN", or "higher/lower-layer-if"?
>>>>> Please let us know how this text may be clarified and that we may want to apply a similar update where these phrases are used throughout the document.
>>>>> 
>>>>> Original:
>>>>> The P2P interface over LAN type is intended to be used solely as a
>>>>> means to signal in standard network management protocols that make
>>>>> use of ifStackTables that the upper layer interface is P2P interface,
>>>>> and thus the upper and lower layers of P2P over LAN type will be
>>>>> expected to apply appropriate semantics: In general, P2P over LAN
>>>>> type higher layer SHOULD always be "ipForward" (Value 142,
>>>>> [Assignment]), and the P2P over LAN type lower layer SHOULD be any
>>>>> appropriate link data layer of "ipForward".
>>>>> 
>>>>> Perhaps:
>>>>> In standard network management protocols that make use of
>>>>> ifStackTables, the P2P interface over a LAN type is intended to be used
>>>>> solely as a means to signal that the upper-layer interface is a P2P
>>>>> interface.  Thus, the upper and lower layers of P2P over a LAN type are
>>>>> expected to apply appropriate semantics.  In general, a P2P over a
>>>>> LAN type higher layer SHOULD always be "ipForward" (value 142 in
>>>>> [Assignment]), and the P2P over a LAN type lower layer SHOULD be any
>>>>> appropriate link-data layer of "ipForward".
>>>>> -->
>>>>> 
>>>>> 
>>>>> 6) <!-- [rfced] Would it make sense to udpate this text as follows:
>>>>> 
>>>>> Original:
>>>>> So the purpose of this document is to
>>>>> request IANA to add this document as a reference to ifType 303, as
>>>>> well as suggest how to use ifStackTable for the P2P interface over
>>>>> LAN type, and provide examples.
>>>>> 
>>>>> Perhaps:
>>>>> The purpose of this document is to serve as a reference
>>>>> for ifType 303 by suggesting how the ifStackTable for the P2P interface
>>>>> over a LAN type is to be used and providing examples.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 7) <!-- [rfced] What is 'in "Interface Management YANG"' referring to?
>>>>> Is it the IETF interfaces YANG module?  The title of RFC 8343?  How can we update?
>>>>> 
>>>>> Original:
>>>>> If a device implements the IF-MIB [RFC2863], each entry in the
>>>>> "/interfaces/interface" list (in "Interface Management YANG") in the
>>>>> operational state is typically mapped to one ifEntry as required in
>>>>> [RFC8343].
>>>>> 
>>>>> Perhaps A:
>>>>> If a device implements the IF-MIB [RFC2863], then each entry in the
>>>>> "/interfaces/interface" list (see the ietf-interfaces YANG
>>>>> module [RFC8343]) in the operational state is typically mapped
>>>>> to one ifEntry as required in [RFC8343].
>>>>> 
>>>>> Perhaps B:
>>>>> If a device implements the IF-MIB [RFC2863], then each entry in the
>>>>> "/interfaces/interface" list (see "A YANG Data Model for Interface
>>>>> Management" [RFC8343]) in the operational state is typically mapped
>>>>> to one ifEntry as required in [RFC8343].
>>>>> -->
>>>>> 
>>>>> 
>>>>> 8) <!-- [rfced] Please be more specific regarding the text "defined in IANA".
>>>>> Is this meant to point the reader to the iana-if-type YANG Module <https://www.iana.org/assignments/yang-parameters/[e-mail]>?
>>>>> Also note that we are having a tough time parsing "LAN type higher layer"
>>>>> and "LAN type lower layer" here.
>>>>> 
>>>>> Original:
>>>>> In ifStackTable the P2P interface over LAN type higher layer SHALL be
>>>>> network layer "ipForward" to enable IP routing, and the P2P interface
>>>>> over LAN type lower layer SHOULD be any link data layer that can be
>>>>> bound to "ipForward" including "ethernetCsmacd", "ieee8023adLag",
>>>>> "l2vlan", and so on (defined in IANA).
>>>>> -->
>>>>> 
>>>>> 
>>>>> 9) <!-- [rfced] IANA indicates that they will complete these actions closer to the time of publication per instructions from the YANG doctors.
>>>>> For our clarity, does "YANG iana-if-type module" refer to https://www.iana.org/assignments/yang-parameters/[e-mail]?
>>>>> If yes, is the reference to RFC 8561 correct?  We only see the following that refer to RFC 8561:
>>>>> 
>>>>> identity microwaveCarrierTermination {
>>>>>  base iana-interface-type;
>>>>>  description
>>>>>    "air interface of a single microwave carrier.";
>>>>>  reference
>>>>>    "RFC 8561 - A YANG Data Model for Microwave Radio Link";  }
>>>>> identity microwaveRadioLinkTerminal {
>>>>>  base iana-interface-type;
>>>>>  description
>>>>>    "radio link interface for one or several aggregated microwave carriers.";
>>>>>  reference
>>>>>    "RFC 8561 - A YANG Data Model for Microwave Radio Link";
>>>>> 
>>>>> Original:
>>>>> IANA is
>>>>> requested to amend the reference for that code point to be to this
>>>>> document and to make a similar amendment in the YANG iana-if-type
>>>>> module (originally specified in [RFC7224]) which currently points to
>>>>> [RFC8561], as this document explains how the ifType is to be used.
>>>>> -->
>>>>> 
>>>>> 
>>>>> 10) <!-- [rfced] Should "LAG" be expanded as Link Aggregation Group or something else?
>>>>> 
>>>>> Original:
>>>>> In the case of underlying interface is LAG, the ifStackTable should
>>>>> be defined as:
>>>>> -->
>>>>> 
>>>>> 
>>>>> Thank you.
>>>>> 
>>>>> RFC Editor
>>>>> 
>>>>> 
>>>>> 
>>>>> On Aug 8, 2022, at 2:06 PM, [e-mail] wrote:
>>>>> 
>>>>> *****IMPORTANT*****
>>>>> 
>>>>> Updated 2022/08/08
>>>>> 
>>>>> RFC Author(s):
>>>>> --------------
>>>>> 
>>>>> Instructions for Completing AUTH48
>>>>> 
>>>>> Your document has now entered AUTH48.  Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC.
>>>>> If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>>> 
>>>>> You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval.
>>>>> 
>>>>> Planning your review
>>>>> ---------------------
>>>>> 
>>>>> Please review the following aspects of your document:
>>>>> 
>>>>> *  RFC Editor questions
>>>>> 
>>>>> Please review and resolve any questions raised by the RFC Editor
>>>>> that have been included in the XML file as comments marked as
>>>>> follows:
>>>>> 
>>>>> <!-- [rfced] ... -->
>>>>> 
>>>>> These questions will also be sent in a subsequent email.
>>>>> 
>>>>> *  Changes submitted by coauthors
>>>>> 
>>>>> Please ensure that you review any changes submitted by your
>>>>> coauthors.  We assume that if you do not speak up that you
>>>>> agree to changes submitted by your coauthors.
>>>>> 
>>>>> *  Content
>>>>> 
>>>>> Please review the full content of the document, as this cannot
>>>>> change once the RFC is published.  Please pay particular attention to:
>>>>> - IANA considerations updates (if applicable)
>>>>> - contact information
>>>>> - references
>>>>> 
>>>>> *  Copyright notices and legends
>>>>> 
>>>>> Please review the copyright notice and legends as defined in
>>>>> RFC 5378 and the Trust Legal Provisions
>>>>> (TLP – https://trustee.ietf.org/license-info/).
>>>>> 
>>>>> *  Semantic markup
>>>>> 
>>>>> Please review the markup in the XML file to ensure that elements of
>>>>> content are correctly tagged.  For example, ensure that <sourcecode>
>>>>> and <artwork> are set correctly.  See details at
>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>> 
>>>>> *  Formatted output
>>>>> 
>>>>> Please review the PDF, HTML, and TXT files to ensure that the
>>>>> formatted output, as generated from the markup in the XML file, is
>>>>> reasonable.  Please note that the TXT will have formatting
>>>>> limitations compared to the PDF and HTML.
>>>>> 
>>>>> 
>>>>> Submitting changes
>>>>> ------------------
>>>>> 
>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all
>>>>> the parties CCed on this message need to see your changes. The parties
>>>>> include:
>>>>> 
>>>>> *  your coauthors
>>>>> 
>>>>> *  [e-mail] (the RPC team)
>>>>> 
>>>>> *  other document participants, depending on the stream (e.g.,
>>>>>    IETF Stream participants are your working group chairs, the
>>>>>    responsible ADs, and the document shepherd).
>>>>> 
>>>>> *  [e-mail], which is a new archival mailing list
>>>>>    to preserve AUTH48 conversations; it is not an active discussion
>>>>>    list:
>>>>> 
>>>>>   *  More info:
>>>>> 
>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxI
>>>>> Ae6P8O4Zc
>>>>> 
>>>>>   *  The archive itself:
>>>>>      https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>> 
>>>>>   *  Note: If only absolutely necessary, you may temporarily opt out
>>>>>      of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>      If needed, please add a note at the top of the message that you
>>>>>      have dropped the address. When the discussion is concluded,
>>>>>      [e-mail] will be re-added to the CC list and
>>>>>      its addition will be noted at the top of the message.
>>>>> 
>>>>> You may submit your changes in one of two ways:
>>>>> 
>>>>> An update to the provided XML file
>>>>> — OR —
>>>>> An explicit list of changes in this format
>>>>> 
>>>>> Section # (or indicate Global)
>>>>> 
>>>>> OLD:
>>>>> old text
>>>>> 
>>>>> NEW:
>>>>> new text
>>>>> 
>>>>> You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient.
>>>>> 
>>>>> We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes.  Information about stream managers can be found in the FAQ.  Editorial changes do not require approval from a stream manager.
>>>>> 
>>>>> 
>>>>> Approving for publication
>>>>> --------------------------
>>>>> 
>>>>> To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication.  Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval.
>>>>> 
>>>>> 
>>>>> Files
>>>>> -----
>>>>> 
>>>>> The files are available here:
>>>>> https://www.rfc-editor.org/authors/rfc9296.xml
>>>>> https://www.rfc-editor.org/authors/rfc9296.html
>>>>> https://www.rfc-editor.org/authors/rfc9296.pdf
>>>>> https://www.rfc-editor.org/authors/rfc9296.txt
>>>>> 
>>>>> Diff file of the text:
>>>>> https://www.rfc-editor.org/authors/rfc9296-diff.html
>>>>> https://www.rfc-editor.org/authors/rfc9296-rfcdiff.html (side by
>>>>> side)
>>>>> 
>>>>> Diff of the XML:
>>>>> https://www.rfc-editor.org/authors/rfc9296-xmldiff1.html
>>>>> 
>>>>> The following files are provided to facilitate creation of your own diff files of the XML.
>>>>> 
>>>>> Initial XMLv3 created using XMLv2 as input:
>>>>> https://www.rfc-editor.org/authors/rfc9296.original.v2v3.xml
>>>>> 
>>>>> XMLv3 file that is a best effort to capture v3-related format updates
>>>>> only:
>>>>> https://www.rfc-editor.org/authors/rfc9296.form.xml
>>>>> 
>>>>> 
>>>>> Tracking progress
>>>>> -----------------
>>>>> 
>>>>> The details of the AUTH48 status of your document are here:
>>>>> https://www.rfc-editor.org/auth48/rfc9296
>>>>> 
>>>>> Please let us know if you have any questions.
>>>>> 
>>>>> Thank you for your cooperation,
>>>>> 
>>>>> RFC Editor
>>>>> 
>>>>> --------------------------------------
>>>>> RFC9296 (draft-liu-lsr-p2poverlan-12)
>>>>> 
>>>>> Title            : Interface Stack Table Definition and Example for Point-to-Point (P2P) Interface over LAN
>>>>> Author(s)        : D. Liu, J. Halpern, C. Zhang
>>>>> WG Chair(s)      :
>>>>> Area Director(s) :
>>>>> 
>> 
> 
> 
>