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 <jmh.dir...@joelhalpern.com> > Sent: Monday, June 21, 2021 8:47 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; tom petch > <ie...@btconnect.com>; Harold Liu > <harold.liu=40ericsson....@dmarc.ietf.org>; lsr@ietf.org > 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 <jmh.dir...@joelhalpern.com> > >> Sent: Monday, June 21, 2021 8:13 AM > >> To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; tom petch > >> <ie...@btconnect.com>; Harold Liu > >> <harold.liu=40ericsson....@dmarc.ietf.org>; lsr@ietf.org > >> 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 <lsr-boun...@ietf.org> On Behalf Of Joel M. Halpern > >>>> Sent: Monday, June 21, 2021 7:13 AM > >>>> To: tom petch <ie...@btconnect.com>; Harold Liu > >>>> <harold.liu=40ericsson....@dmarc.ietf.org>; lsr@ietf.org > >>>> 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 <lsr-boun...@ietf.org> on behalf of Harold Liu > >>>> <harold.liu=40ericsson....@dmarc.ietf.org> > >>>>> 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: mohamed.boucad...@orange.com > >>>> <mohamed.boucad...@orange.com> > >>>>> Sent: Thursday, June 17, 2021 2:16 PM > >>>>> To: Joel M. Halpern <j...@joelhalpern.com>; draft-liu-lsr- > >>>> p2pover...@ietf.org > >>>>> 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:lsr-boun...@ietf.org] De la part de Joel M. Halpern > >>>>>> Envoyé : mercredi 16 juin 2021 22:47 À : Acee Lindem (acee) > >>>>>> <a...@cisco.com>; lsr@ietf.org 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- > >>>>>> boun...@ietf.org on behalf of j...@joelhalpern.com> 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: internet-dra...@ietf.org > >>>>>>> Reply-To: internet-dra...@ietf.org > >>>>>>> To: i-d-annou...@ietf.org > >>>>>>> > >>>>>>> > >>>>>>> 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 > >>>>>>> i-d-annou...@ietf.org > >>>>>>> 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 > >>>>>>> Lsr@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/lsr > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Lsr mailing list > >>>>>> Lsr@ietf.org > >>>>>> 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 > >>>>> Lsr@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/lsr > >>>>> _______________________________________________ > >>>>> Lsr mailing list > >>>>> Lsr@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/lsr > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Lsr mailing list > >>>> Lsr@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
