-----Original Message-----
From: Lsr <lsr-boun...@ietf.org> On Behalf Of Joel M. Halpern
Sent: Thursday, June 24, 2021 5:52 AM
To: tom petch <ie...@btconnect.com>; lsr@ietf.org
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) <ginsb...@cisco.com>
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 <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
