Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt

[Joel Halpern Direct <[e-mail]>]

"Needed"?  Probably not.  Almost no Informational RFCs are "needed". 
The question is whether the WG considers it useful.

Yours,
Joel

On 6/24/2021 2:51 PM, Les Ginsberg (ginsberg) wrote:
> Joel -
> 
> Thanx for the revised version.
> While I would still have some editorial comments to make, I think you have done a good job of responding to the comments made.
> 
> The bigger question for me is whether the draft is needed at all.
> I am still of the opinion that it is not needed.
> 
>     Les
> 
> 
>> -----Original Message-----
>> From: Lsr <[e-mail]> On Behalf Of Joel M. Halpern
>> Sent: Thursday, June 24, 2021 5:52 AM
>> To: tom petch <[e-mail]>; [e-mail]
>> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
>>
>> Tom, please look at the latest revision and see if that helps.
>>
>> Also note, this document does not assign the ifType. (I.e. it does not
>> "create an ifType".)  That is already done.
>>
>> Yours,
>> Joel
>>
>> On 6/24/2021 7:27 AM, tom petch wrote:
>>> From: Les Ginsberg (ginsberg) <[e-mail]>
>>> Sent: 23 June 2021 17:38
>>>
>>> Joel -
>>>
>>> I have had concerns from the beginning as to whether this draft is really
>> needed.
>>> As I have commented previously, the only content of any significance is
>> Section 4 - and that only provides example settings of the management fields
>> for this interface type.
>>> I question whether a draft is required for this purpose.
>>> I will defer on this matter to folks more expert in this area than I, but, my
>> opinion is that a draft solely for this purpose is not required.
>>>
>>> <tp>
>>> Les has a point.  I see a relevant I-D and dive in and review it and do not
>> stop to think whether or not this work justifies an RFC.  Having reviewed it,
>> and having worked out what is new - as Les says, examples in Section 4 and
>> not much else  - I struggle to see a justification.
>>>
>>> The other thought that this brought to mind is why create an ifType value
>> when the world has been getting on quite happily without it for 13 years?  Is
>> there anything that now needs a value which previously did not?  If so, that
>> might be more suitable for an I-D.
>>>
>>> Tom Petch
>>>
>>>
>>> I thought it polite to mention this before you spend the time and effort to
>> produce a new version.
>>>
>>>      Les
>>>
>>>
>>>> -----Original Message-----
>>>> From: Lsr <[e-mail]> On Behalf Of tom petch
>>>> Sent: Wednesday, June 23, 2021 1:43 AM
>>>> To: Joel M. Halpern <[e-mail]>; Harold Liu
>>>> <harold.liu=[e-mail]>; [e-mail]
>>>> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
>>>>
>>>> From: Joel M. Halpern <[e-mail]>
>>>> Sent: 22 June 2021 09:57
>>>>
>>>> Do Les' suggested edits address your concerns.
>>>> We will apply yor changes to the IANA considerations section.
>>>>
>>>> <tp>
>>>> I would go further than Les as I suggested on Tuesday.  Perhaps it is time
>> for
>>>> a new version to comment on.
>>>>
>>>> Tom Petch
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 6/22/2021 4:34 AM, tom petch wrote:
>>>>> From: Joel M. Halpern <[e-mail]>
>>>>> Sent: 21 June 2021 15:13
>>>>>
>>>>> Tom, 5309 did not define the ifType.  Go read 5309.  You seem to have
>>>>> gotten confused by the fact that the IANA entry given to 303 points to
>>>>> 5309.  That was done to have some reference (with the consent of the
>>>>> experts).   What we are doing now is providing a better reference.  So
>>>>> yes, this document defines how the ifType is defined.  With no criticism
>>>>> of 5309, it does not define that, since it does not define the ifType.
>>>>>
>>>>> <tp>
>>>>> Stepping back a few e-mails,
>>>>> I have read 5309 and did point out previously that there is no IANA
>>>> Considerations in that RFC.  What I have said and repeat here is that 5309
>>>> defines the p2pOverLan type.  That is what the RFC claims and that is what
>> it
>>>> does.  You seem to think that the definition of a type is incomplete
>> without a
>>>> numerical value assigned to it, the SMI ifType  or YANG identity.  The
>> concept
>>>> of the type exists whether or not a value has been assigned to it and this
>> is
>>>> one of the places where this I-D goes wrong..
>>>>>
>>>>> I would say
>>>>> Abstract
>>>>> The p2pOverLan interface type is described in RFC5309.
>>>>> Subsequently, this interface type has been assigned a value of 303 by
>>>> IANA, by Expert Review.
>>>>> This memo ....
>>>>>
>>>>> Well, what does it do?  Gives examples of its use?  I see nothing more.
>>>>>
>>>>> Tom Petch
>>>>>
>>>>> We are explicit in this draft that one of the obvious uses for this
>>>>> ifType is to trigger 5309 behavior.
>>>>>
>>>>> Yours,
>>>>> Joel
>>>>>
>>>>> On 6/21/2021 4:41 AM, tom petch wrote:
>>>>>> From: Lsr <[e-mail]> on behalf of Harold Liu
>>>> <harold.liu=[e-mail]>
>>>>>> Sent: 21 June 2021 02:01
>>>>>>
>>>>>> Hi Med and All:
>>>>>>            Thanks for your helpful comments, I have updated a new version
>> 01
>>>> to follow the comments;
>>>>>>            The main updating is:
>>>>>>            1. More clearly described the intend of this draft in the
>> introduction;
>>>>>>            2. Change the reference style;
>>>>>>            3. Refactor the reference section to make it more reasonable;
>>>>>>            4. I haven't change "IANA Consideration" at the moment given
>> there
>>>> is lots of discussion in this part and it is still up in the air, I will change this
>>>> section next update the document once this part is finalized;
>>>>>>
>>>>>> <tp>
>>>>>> I still think that this is an unsatisfactory I-D and would oppose adoption
>> in
>>>> its present form,
>>>>>>
>>>>>> It is a question of veracity.  It claims to do what others have already
>> done
>>>> and does so without reference, without acknowledgement.  Having the
>>>> same data defined in more than one place can only create confusion, in
>>>> future if not now.
>>>>>>
>>>>>> This is a pattern and starts with the Abstract and continues throughout
>>>> the I-D.
>>>>>>
>>>>>> Thus the Abstract claims 'this defines point-to-point interface type'.
>> No.
>>>> This type was defined in RFC5309 and you need to say that and to say
>> what if
>>>> anything you are changing in that definition.  You should not reproduce
>> text
>>>> from that RFC unless you have to and then you should make it clear you
>> are
>>>> quoting.
>>>>>>
>>>>>> You do the same with Figure 1.  This is a copy, may be accurate may be
>>>> not, it does not matter, from RFC8343 with no mention thereof.  You
>> should
>>>> not be reproducing such text without a good reason and then you should
>>>> make it clear what is reproduced, from where and why.
>>>>>>
>>>>>> And as I have said already, IANA Considerations is yet again claiming to
>> do
>>>> what has already happened which can only confuse.  All that is needed as
>> I
>>>> said in a separate note  is to ask IANA to update two references, nothing
>>>> more.
>>>>>>
>>>>>> Tom Petch
>>>>>>
>>>>>>            And I would like to share more background information for this
>>>> internet draft:
>>>>>>            As Joel mentioned, we requested and received an IF Type
>>>> assignment from IANA (with expert review) for point-to-point over
>> Ethernet
>>>> links several weeks ago and the p2pOverLan type is already added to
>> IANA
>>>> registry now;
>>>>>>            During the discussion around the assignment we noticed a doc
>>>> describing why that is needed and how to use that would be helpful;
>>>>>>            For example, if no entry saying p2pOverLan layer over ethernet,
>> the
>>>> management will suffer since lose the ability to get to the Ethernet-
>> specific
>>>> management properties (Ethernet MIB or YANG model) via many tools;
>> So
>>>> we propose this draft to define a complete p2pOverLan ifStack(Including
>>>> higher layer and lower layer);
>>>>>>
>>>>>> Brs
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [e-mail]
>>>> <[e-mail]>
>>>>>> Sent: Thursday, June 17, 2021 2:16 PM
>>>>>> To: Joel M. Halpern <[e-mail]>; draft-liu-lsr-
>>>> [e-mail]
>>>>>> Subject: RE: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
>>>>>>
>>>>>> Hi Joel, all,
>>>>>>
>>>>>> Please find some quick comments to this draft, fwiw:
>>>>>>
>>>>>> * pdf: https://protect2.fireeye.com/v1/url?k=e8e7d1aa-b77ce948-
>>>> e8e79131-86073b36ea28-edbd778070bbec9a&q=1&e=d4a020c9-b337-
>> 41fd-
>>>> bf1b-
>> 56dcfaef1044&u=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-
>>>> Drafts-Reviews%2Fblob%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00-
>>>> rev%2520Med.pdf
>>>>>> * doc: https://protect2.fireeye.com/v1/url?k=938b5849-cc1060ab-
>>>> 938b18d2-86073b36ea28-e0406a2599fa2a6d&q=1&e=d4a020c9-b337-
>> 41fd-
>>>> bf1b-
>> 56dcfaef1044&u=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-
>>>> Drafts-Reviews%2Fraw%2Fmaster%2Fdraft-liu-lsr-p2poverlan-00-
>>>> rev%2520Med.docx
>>>>>>
>>>>>> Cheers,
>>>>>> Med
>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : Lsr [mailto:[e-mail]] De la part de Joel M. Halpern
>>>>>>> Envoyé : mercredi 16 juin 2021 22:47 À : Acee Lindem (acee)
>>>>>>> <[e-mail]>; [e-mail] Objet : Re: [Lsr] Fwd: I-D Action:
>>>>>>> draft-liu-lsr-p2poverlan-00.txt
>>>>>>>
>>>>>>> This document (and the code point) are intended to be in line with
>>>>>>> 5309.
>>>>>>>       I believe they are.  If we got it wrong, please help us fix it.
>>>>>>>
>>>>>>> A reference would be reasonable to add.  (The IANA entry for the
>> code
>>>>>>> point does reference 5309.)
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Joel
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 6/16/2021 4:41 PM, Acee Lindem (acee) wrote:
>>>>>>>> Hi Joel,
>>>>>>>>
>>>>>>>> At first I wondered where this document should reside and then
>>>>>>> decided that LSR is probably as good as any other place.
>>>>>>>>
>>>>>>>> Can you guys check whether it is mostly in line with
>>>>>>> https://datatracker.ietf.org/doc/rfc5309/ and comment as to whether
>> it
>>>>>>> should be referenced?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Acee
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/16/21, 11:10 AM, "Lsr on behalf of Joel M. Halpern" <lsr-
>>>>>>> [e-mail] on behalf of [e-mail]> wrote:
>>>>>>>>
>>>>>>>>          Recently, Ericsson requested and received an IF Type
>>>>>>> assignment from
>>>>>>>>          IANA (with expert review) for point-to-point over Ethernet
>>>>>>> links.
>>>>>>>>
>>>>>>>>          It was noted during the discussion around the assignment that
>>>>>>> a document
>>>>>>>>          (eventually, we hope, an RFC) describing how to use that and
>>>>>>> why we
>>>>>>>>          asked for it would be helpful.
>>>>>>>>
>>>>>>>>          The below announcement is that draft.  We would like to work
>>>>>>> with the
>>>>>>>>          community to improve and clarify teh draft.
>>>>>>>>
>>>>>>>>          Thank you,
>>>>>>>>          Joel
>>>>>>>>
>>>>>>>>
>>>>>>>>          -------- Forwarded Message --------
>>>>>>>>          Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt
>>>>>>>>          Date: Wed, 16 Jun 2021 07:00:04 -0700
>>>>>>>>          From: [e-mail]
>>>>>>>>          Reply-To: [e-mail]
>>>>>>>>          To: [e-mail]
>>>>>>>>
>>>>>>>>
>>>>>>>>          A New Internet-Draft is available from the on-line Internet-
>>>>>>> Drafts
>>>>>>>>          directories.
>>>>>>>>
>>>>>>>>
>>>>>>>>                   Title           : Interface Stack Table Definition
>>>>>>> for Point to
>>>>>>>>          Point (P2P) Interface over LAN
>>>>>>>>                   Authors         : Daiying Liu
>>>>>>>>                                     Joel Halpern
>>>>>>>>                                     Congjie Zhang
>>>>>>>>                 Filename        : draft-liu-lsr-p2poverlan-00.txt
>>>>>>>>                 Pages           : 7
>>>>>>>>                 Date            : 2021-06-16
>>>>>>>>
>>>>>>>>          Abstract:
>>>>>>>>              The point-to-point circuit type is one of the mainly used
>>>>>>> circuit
>>>>>>>>              types in link state routing protocol.  It is important to
>>>>>>> identify
>>>>>>>>              the correct circuit type when forming adjacencies,
>>>>>>> flooding link
>>>>>>>>              state database packets, and monitor the link state.  This
>>>>>>> document
>>>>>>>>              defines point-to-point interface type and relevant stack
>>>>>>> tables to
>>>>>>>>              provide benefit for operation, maintenance and
>>>>>>> statistics.
>>>>>>>>
>>>>>>>>
>>>>>>>>          The IETF datatracker status page for this draft is:
>>>>>>>>          https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/
>>>>>>>>
>>>>>>>>          There is also an htmlized version available at:
>>>>>>>>          https://datatracker.ietf.org/doc/html/draft-liu-lsr-
>>>>>>> p2poverlan-00
>>>>>>>>
>>>>>>>>
>>>>>>>>          Internet-Drafts are also available by anonymous FTP at:
>>>>>>>>          ftp://ftp.ietf.org/internet-drafts/
>>>>>>>>
>>>>>>>>
>>>>>>>>          _______________________________________________
>>>>>>>>          I-D-Announce mailing list
>>>>>>>>          [e-mail]
>>>>>>>>          https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>>>>>          Internet-Draft directories: http://www.ietf.org/shadow.html
>>>>>>>>          or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>>>>
>>>>>>>>          _______________________________________________
>>>>>>>>          Lsr mailing list
>>>>>>>>          [e-mail]
>>>>>>>>          https://www.ietf.org/mailman/listinfo/lsr
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Lsr mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>>>>
>>>>>>
>>>>
>> __________________________________________________________
>>>>
>> __________________________________________________________
>>>> _____
>>>>>>
>>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
>> exploites
>>>> ou copies sans autorisation. Si vous avez recu ce message par erreur,
>> veuillez
>>>> le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
>>>> messages electroniques etant susceptibles d'alteration, Orange decline
>> toute
>>>> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>>>>>
>>>>>> This message and its attachments may contain confidential or privileged
>>>> information that may be protected by law; they should not be distributed,
>>>> used or copied without authorisation.
>>>>>> If you have received this email in error, please notify the sender and
>>>> delete this message and its attachments.
>>>>>> As emails may be altered, Orange is not liable for messages that have
>>>> been modified, changed or falsified.
>>>>>> Thank you.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Lsr mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>>>> _______________________________________________
>>>>>> Lsr mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/lsr
>>>>>>
>>>> _______________________________________________
>>>> Lsr mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lsr
>>
>> _______________________________________________
>> Lsr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lsr