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

[Joel Halpern <[e-mail]>]

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-4Q9l2USxIAe6P8O4Zc
     
     *  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) :