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

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

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