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

[tom petch <[e-mail]>]

From: Les Ginsberg (ginsberg) <[e-mail]>
Sent: 21 June 2021 20:06

inline <tp> 
(sorry that my web browser messes up 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.

<tp>
As previously, I suggest

 Abstract
 The p2pOverLan interface type is described in RFC 5309.
 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?  That is what I see.
 
</tp>

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.

<tp>
I agree, not needed.

I would also moderate the claim that this is the predominant circuit type for OSPF.  That may be true for IX or PE-CE but not for the Enterprise LAN that I see.  Widely used by ISP perhaps.

I do not see this type enabling routing protocols to select the right mode automatically; theoretically possible but ospf-yang requires explicit configuration thereof.

Requirements language should use RFC8174.

With the revised IANA Considerations, there is no need for Security Considerations to make any mention of YANG.

Tom Petch



   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