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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Joel -

In addition to the IANA section changes,

1)Please be sure that the text consistently refers to "Point to Point (P2P) Interface over LAN" - not simply "Point to Point"

2)I think the abstract/introduction should make it clear that this draft is specifying the management mappings for the " Point to Point (P2P) Interface over LAN".
It is NOT defining Point to Point (P2P) Interface over LAN operation - that clearly was already done by RFC 5309.

3)I don’t know if Section 3 is really needed. I tend to think not.
But if you do want to keep it, please Reference RFC 8343 Section 4 as this is clearly a copy of the Figure in that document/section.

   Les



> -----Original Message-----
> From: Joel Halpern Direct <[e-mail]>
> Sent: Monday, June 21, 2021 8:47 AM
> To: Les Ginsberg (ginsberg) <[e-mail]>; tom petch
> <[e-mail]>; Harold Liu
> <harold.liu=[e-mail]>; [e-mail]
> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> 
> The change Tom has proposed to the IANA considerations section is fine
> with me.
> 
> If there are other specific changes that will make it clearer, I and my
> co-authors are happy to make those.   I have tried looking at the text.
>   Even before you found it misleading, I did conclude that Tom getting
> the wrong impression meant it needs to be clarified.  But as I am having
> trouble seeing what misled you, I can not suggest wording improvements
> to my co-authors.
> 
> I presume from your phrasing that you want more changes than just to the
> IANA considerations section.  I presume I am just being dense in not
> seeing the rest.  I apologize, but that does not make me less dense.
> Sorry.
> 
> Help?
> Joel
> 
> On 6/21/2021 11:28 AM, Les Ginsberg (ginsberg) wrote:
> > Joel -
> >
> > I am not objecting to the draft.
> > I am simply asking for it to be both clear and accurate in what it is actually
> doing.
> >
> > I think Tom has done an excellent job of pointing out the inaccuracies and
> in some cases providing proposed revised text.
> >
> > I would ask you to reread your own draft in the context that at least two
> people have read it and found it inaccurate and both of us have made very
> explicit points about what language is confusing.
> >
> >     Les
> >
> >> -----Original Message-----
> >> From: Joel Halpern Direct <[e-mail]>
> >> Sent: Monday, June 21, 2021 8:13 AM
> >> To: Les Ginsberg (ginsberg) <[e-mail]>; tom petch
> >> <[e-mail]>; Harold Liu
> >> <harold.liu=[e-mail]>; [e-mail]
> >> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> >>
> >> Les, I am missing something ion both your and Tom's comments.  5309
> >> didn't define the ifType.  If you look at 5309, it has no IANA
> >> considerations at all.
> >>
> >> Yes, this document should talk about 5309 as one of the cases that the
> >> ifType simplifies.  And it does.
> >>
> >> This documents follows the lead of 8343 in defining this specific ifType.
> >>
> >> Let's be clear.  We were asked, quite reasoanbly, by the expert, when we
> >> requested the IANA code point, to please submit a document describing
> >> how the dcode point would be used, rather than merely pointing at 5309
> >> and assuming everyone could guess correctly.  (Guessing is not good for
> >> standards.)
> >> So we are trying to do so.
> >>
> >> You seem to be objecting to our doing so.  Why?
> >>
> >> If the working group really doesn't want a description, we can go away.
> >>    We have the code point we felt was useful.  But it seems much more
> >> useful to actually provide meaningful documentation.
> >>
> >> Yours,
> >> Joel
> >>
> >>
> >>
> >> On 6/21/2021 10:58 AM, Les Ginsberg (ginsberg) wrote:
> >>> I am in complete agreement with the points Tom has made.
> >>>
> >>> AFAICT, the only new content in this draft is Section 4 - the rest is either
> >> boilerplate or a repetition of text already present in RFC 5309 or RFC 8343.
> >>> Neither the Abstract nor the Introduction makes that clear.
> >>> The abstract actually claims to
> >>>
> >>>       "defines point-to-point interface type"
> >>>
> >>> which is both FALSE (already defined in RFC 5309) and incorrectly named
> -
> >> since the document is actually discussing "point-to-point operation over
> >> LAN".
> >>>
> >>> Regarding the IANA section, it is clear that the draft is NOT creating new
> >> entries - rather it is modifying existing entries. And it isn’t modifying the
> code
> >> points, the names, or the descriptions - it only seeks to modify the
> >> references to include "this document".
> >>> But the text in the IANA section states otherwise:
> >>>
> >>> " IANA need to update the "Interface Types(ifType)" registry...with the
> >> following status types"
> >>>
> >>> I don’t know whether the content in Section 4 is sufficient to claim a
> >> reference, but if it is it should only be in addition to the existing reference.
> >>>
> >>>      Les
> >>>
> >>>> -----Original Message-----
> >>>> From: Lsr <[e-mail]> On Behalf Of Joel M. Halpern
> >>>> Sent: Monday, June 21, 2021 7:13 AM
> >>>> To: tom petch <[e-mail]>; Harold Liu
> >>>> <harold.liu=[e-mail]>; [e-mail]
> >>>> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
> >>>>
> >>>> 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.
> >>>>
> >>>> 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