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 <[email protected]> On Behalf Of Joel M. Halpern > Sent: Thursday, June 24, 2021 5:52 AM > To: tom petch <[email protected]>; [email protected] > 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) <[email protected]> > > 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 <[email protected]> On Behalf Of tom petch > >> Sent: Wednesday, June 23, 2021 1:43 AM > >> To: Joel M. Halpern <[email protected]>; Harold Liu > >> <[email protected]>; [email protected] > >> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > >> > >> 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]>; draft-liu-lsr- > >> [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 > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
