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

[Karen Moore <[e-mail]>]

Hi Amanda,

Thank you for the clarifications. Since the IANA action message was vague, we were questioning what additional actions may be needed (aside from the reference changes) as the message noted that the actions would be done after publication.

Since the registrations have been made and the document accurately describes the updates, we will notify you once the document is published, which is the usual process.

Thanks!

RFC Editor/Karen

> On Aug 18, 2022, at 12:38 PM, Amanda Baber via RT <[e-mail]> wrote:
> 
> Hi Karen,
> 
>> 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).
> 
> These assignments have already been made. We would just be updating a pair of references, as follows:
> 
> In https://www.iana.org/assignments/smi-numbers:
> 
> OLD:
> 
> 303	p2pOverLan	Point to Point over LAN interface	[RFC5309]
> 
> NEW:
> 
> 303	p2pOverLan	Point to Point over LAN interface	[this document]
> 
> In the iana-if-type module reachable from iana.org/assignments/yang-parameters:
> 
> OLD:
> 
>    reference
>      "RFC 5309 - Point-to-Point Operation over LAN in Link State Routing Protocols";
> 
> NEW:
> 
>    reference
>      "this document - IfStackTable for P2poverLAN interface";
> 
> We've been advised to hold off on making reference updates to YANG modules before RFC publication on the grounds that doing so earlier would mean generating two new versions of the file (and two new revision statements) instead of one: the first for RFC-liu-lsr-p2poverlan-12, and the second for the reference change to RFC 9296. (For each change to a YANG module, we replace our links to the existing version of the file with links to an updated version has that day's date in the filename. The current version of this file, for instance, is [e-mail].)
> 
> The corresponding reference update in https://www.iana.org/assignments/smi-numbers was postponed on the grounds that it could be confusing to have different references appear in the registry and the module.
> 
> The issue here is that we have a strong preference for not listing RFC numbers in the registries until the RFC is publicly available. Can you clarify the reason for making these two changes before publication? 
> 
> I should add that we have a seven-day SLE for implementing reference updates upon RFC publication, and last month, half of those tickets were completed within a day. We can expedite this one after we receive the publication notice.
> 
> thanks,
> Amanda
> 
> On Wed Aug 17 20:12:56 2022, [e-mail] wrote:
>> 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 <drafts-
>>> [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/iana-if-
>>>>>>> [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/iana-if-
>>>>>>> [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/iana-if-
>>>>>>> [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/iana-if-
>>>>>>> [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/iana-if-
>>>>>>> [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/iana-if-
>>>>>>> [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) :
>>>>>>> 
>>>> 
>>> 
>>> 
>>> 
> 
>