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 <[email protected]> On Behalf Of Joel M. Halpern
> Sent: Monday, June 21, 2021 7:13 AM
> To: tom petch <[email protected]>; Harold Liu
> <[email protected]>; [email protected]
> 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 <[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
