From: Joel M. Halpern <[email protected]> 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 <[email protected]> > 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 <[email protected]> on behalf of Harold Liu >> <[email protected]> >> 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: [email protected] <[email protected]> >> Sent: Thursday, June 17, 2021 2:16 PM >> To: Joel M. Halpern <[email protected]>; [email protected] >> 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:[email protected]] De la part de Joel M. Halpern >>> Envoyé : mercredi 16 juin 2021 22:47 À : Acee Lindem (acee) >>> <[email protected]>; [email protected] 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- >>> [email protected] on behalf of [email protected]> 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: [email protected] >>>> Reply-To: [email protected] >>>> To: [email protected] >>>> >>>> >>>> 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 >>>> [email protected] >>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lsr >>>> >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr >> _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
