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

[[e-mail]]

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) :