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

Reply via email to