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.
I thought it polite to mention this before you spend the time and effort to produce a new version. Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of tom petch > Sent: Wednesday, June 23, 2021 1:43 AM > To: Joel M. Halpern <j...@joelhalpern.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 > > From: Joel M. Halpern <j...@joelhalpern.com> > 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 <j...@joelhalpern.com> > > 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 <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
