Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Les Ginsberg (ginsberg) Sent: 24 June 2021 19:51 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. Again, I am in broad agreement with Les. As I suggested before, I would still add to the Introduction or - probably - Abstract the fact that the assignment of a value to ifType was made by Expert Review. Those who know nothing of IETF procedures will not find it odd that RFC5309 does not contain IANA Considerations. Those that know a little, and see that omission, may think that the correct procedures have not been followed, for assignment. Those who know the spectrum of possibilities will look at the assignment policy, see it is Expert Review and deduce that that is how the assignment was made. And even if there is a more recent RFC to be pointed to, I think it clearer to spell out that Expert Review was how the value was assigned and so not to look for further documentation. Tom Petch. Les > -Original Message- > From: Lsr On Behalf Of Joel M. Halpern > Sent: Thursday, June 24, 2021 5:52 AM > To: tom petch ; 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) > > 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. > > > > > > 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 On Behalf Of tom petch > >> Sent: Wednesday, June 23, 2021 1:43 AM > >> To: Joel M. Halpern ; Harold Liu > >> ; lsr@ietf.org > >> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > >> > >> From: Joel M. Halpern > >> Sent: 22 June 2021 09:57 > >> > >> Do Les' suggested edits address your concerns. > >> We will apply yor changes to the IANA considerations section. > >> > >> > >> 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 > >>> 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. > >>> > >>> > >>> 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 a
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Joel >From my experience and vendor best practice as well as operators deployments as well have always configure ethernet interfaces with P2P subnet /31 or /127 as network type P2P for ospf to bypass DR election immediate converge to Full state and ISIS to avoid DIS election and more efficient. This basic IGP optimization has been done for many decades as a standard for all operators. As Les stated as this has been a best practice for operators I guess forever Day 1 I would call an optimization, I am not sure the draft is necessary as well. There are so many configuration knob type best practices for IGP and EGP as that also digs into vendor implementations aspects and not protocol design or even network architecture or design, I am not sure IETF is the place for this informational documentation. Kind Regards Gyan On Thu, Jun 24, 2021 at 4:25 PM Joel Halpern Direct < jmh.dir...@joelhalpern.com> wrote: > "Needed"? Probably not. Almost no Informational RFCs are "needed". > The question is whether the WG considers it useful. > > Yours, > Joel > > On 6/24/2021 2:51 PM, Les Ginsberg (ginsberg) wrote: > > 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 On Behalf Of Joel M. Halpern > >> Sent: Thursday, June 24, 2021 5:52 AM > >> To: tom petch ; 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) > >>> 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. > >>> > >>> > >>> 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 On Behalf Of tom petch > >>>> Sent: Wednesday, June 23, 2021 1:43 AM > >>>> To: Joel M. Halpern ; Harold Liu > >>>> ; lsr@ietf.org > >>>> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > >>>> > >>>> From: Joel M. Halpern > >>>> Sent: 22 June 2021 09:57 > >>>> > >>>> Do Les' suggested edits address your concerns. > >>>> We will apply yor changes to the IANA considerations section. > >>>> > >>>> > >>>> 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, >
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) 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. 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 On Behalf Of tom petch Sent: Wednesday, June 23, 2021 1:43 AM To: Joel M. Halpern ; Harold Liu ; lsr@ietf.org Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt From: Joel M. Halpern Sent: 22 June 2021 09:57 Do Les' suggested edits address your concerns. We will apply yor changes to the IANA considerations section. 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 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. 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 on behalf of Harold Liu 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; 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
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Les Ginsberg (ginsberg) 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. 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 On Behalf Of tom petch > Sent: Wednesday, June 23, 2021 1:43 AM > To: Joel M. Halpern ; Harold Liu > ; lsr@ietf.org > Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > > From: Joel M. Halpern > Sent: 22 June 2021 09:57 > > Do Les' suggested edits address your concerns. > We will apply yor changes to the IANA considerations section. > > > 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 > > 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. > > > > > > 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 on behalf of Harold Liu > > >> 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; > >> > >> > >> 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
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
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 On Behalf Of tom petch > Sent: Wednesday, June 23, 2021 1:43 AM > To: Joel M. Halpern ; Harold Liu > ; lsr@ietf.org > Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > > From: Joel M. Halpern > Sent: 22 June 2021 09:57 > > Do Les' suggested edits address your concerns. > We will apply yor changes to the IANA considerations section. > > > 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 > > 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. > > > > > > 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 on behalf of Harold Liu > > >> 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; > >> > >> > >> 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 t
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Joel M. Halpern Sent: 22 June 2021 09:57 Do Les' suggested edits address your concerns. We will apply yor changes to the IANA considerations section. 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 > 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. > > > 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 on behalf of Harold Liu >> >> 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; >> >> >> 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 prope
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Do Les' suggested edits address your concerns. We will apply yor changes to the IANA considerations section. Yours, Joel On 6/22/2021 4:34 AM, tom petch wrote: From: Joel M. Halpern 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. 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 on behalf of Harold Liu 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; 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 Sent: Thursday, June 17, 2021 2:16 PM To: Joel M. Halpern ; 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=1=d4a020c9-b337-41fd-bf1b-56dcfaef1044=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=1=d4a020c9-b337-41fd-bf1b-56dcfaef104
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Les Ginsberg (ginsberg) Sent: 21 June 2021 20:06 inline (sorry that my web browser messes up e-mail) Joel - In addition to the IANA section changes, 1)Please be sure that the text consistently refers to "Point to Point (P2P) Interface over LAN" - not simply "Point to Point" 2)I think the abstract/introduction should make it clear that this draft is specifying the management mappings for the " Point to Point (P2P) Interface over LAN". It is NOT defining Point to Point (P2P) Interface over LAN operation - that clearly was already done by RFC 5309. As previously, I suggest Abstract The p2pOverLan interface type is described in RFC 5309. 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? That is what I see. 3)I don’t know if Section 3 is really needed. I tend to think not. But if you do want to keep it, please Reference RFC 8343 Section 4 as this is clearly a copy of the Figure in that document/section. I agree, not needed. I would also moderate the claim that this is the predominant circuit type for OSPF. That may be true for IX or PE-CE but not for the Enterprise LAN that I see. Widely used by ISP perhaps. I do not see this type enabling routing protocols to select the right mode automatically; theoretically possible but ospf-yang requires explicit configuration thereof. Requirements language should use RFC8174. With the revised IANA Considerations, there is no need for Security Considerations to make any mention of YANG. Tom Petch Les > -Original Message- > From: Joel Halpern Direct > Sent: Monday, June 21, 2021 8:47 AM > To: Les Ginsberg (ginsberg) ; tom petch > ; Harold Liu > ; lsr@ietf.org > Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > > The change Tom has proposed to the IANA considerations section is fine > with me. > > If there are other specific changes that will make it clearer, I and my > co-authors are happy to make those. I have tried looking at the text. > Even before you found it misleading, I did conclude that Tom getting > the wrong impression meant it needs to be clarified. But as I am having > trouble seeing what misled you, I can not suggest wording improvements > to my co-authors. > > I presume from your phrasing that you want more changes than just to the > IANA considerations section. I presume I am just being dense in not > seeing the rest. I apologize, but that does not make me less dense. > Sorry. > > Help? > Joel > > On 6/21/2021 11:28 AM, Les Ginsberg (ginsberg) wrote: > > Joel - > > > > I am not objecting to the draft. > > I am simply asking for it to be both clear and accurate in what it is > > actually > doing. > > > > I think Tom has done an excellent job of pointing out the inaccuracies and > in some cases providing proposed revised text. > > > > I would ask you to reread your own draft in the context that at least two > people have read it and found it inaccurate and both of us have made very > explicit points about what language is confusing. > > > > Les > > > >> -----Original Message- > >> From: Joel Halpern Direct > >> Sent: Monday, June 21, 2021 8:13 AM > >> To: Les Ginsberg (ginsberg) ; tom petch > >> ; Harold Liu > >> ; lsr@ietf.org > >> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > >> > >> Les, I am missing something ion both your and Tom's comments. 5309 > >> didn't define the ifType. If you look at 5309, it has no IANA > >> considerations at all. > >> > >> Yes, this document should talk about 5309 as one of the cases that the > >> ifType simplifies. And it does. > >> > >> This documents follows the lead of 8343 in defining this specific ifType. > >> > >> Let's be clear. We were asked, quite reasoanbly, by the expert, when we > >> requested the IANA code point, to please submit a document describing > >> how the dcode point would be used, rather than merely pointing at 5309 > >> and assuming everyone could guess correctly. (Guessing is not good for > >> standards.) > >> So we are trying to do so. > >> > >> You seem to be objecting to our doing so. Why? > >> > >> If the working group really doesn't want a description, we can go away. > >>We have the code point we felt was useful. But it seems much more > >> useful to actually provide meaningful documentation. > >> > >> Yours, > >> Joel > >> > >> > >> > >> On 6
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Joel M. Halpern 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. 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 on behalf of Harold Liu > > 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; > > > 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 > Sent: Thursday, June 17, 2021 2:16 PM > To: Joel M. Halpern ; 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=1=d4a020c9-b337-41fd-bf1b-56dcfaef1044=https%3A%2F%2Fgithub.com%2Fboucadair%2FIETF-Drafts-Reviews%2Fblob%2Fmaster
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Okay. We will make those changes. Thank you, Joel On 6/21/2021 3:06 PM, Les Ginsberg (ginsberg) wrote: Joel - In addition to the IANA section changes, 1)Please be sure that the text consistently refers to "Point to Point (P2P) Interface over LAN" - not simply "Point to Point" 2)I think the abstract/introduction should make it clear that this draft is specifying the management mappings for the " Point to Point (P2P) Interface over LAN". It is NOT defining Point to Point (P2P) Interface over LAN operation - that clearly was already done by RFC 5309. 3)I don’t know if Section 3 is really needed. I tend to think not. But if you do want to keep it, please Reference RFC 8343 Section 4 as this is clearly a copy of the Figure in that document/section. Les -Original Message- From: Joel Halpern Direct Sent: Monday, June 21, 2021 8:47 AM To: Les Ginsberg (ginsberg) ; tom petch ; Harold Liu ; lsr@ietf.org Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt The change Tom has proposed to the IANA considerations section is fine with me. If there are other specific changes that will make it clearer, I and my co-authors are happy to make those. I have tried looking at the text. Even before you found it misleading, I did conclude that Tom getting the wrong impression meant it needs to be clarified. But as I am having trouble seeing what misled you, I can not suggest wording improvements to my co-authors. I presume from your phrasing that you want more changes than just to the IANA considerations section. I presume I am just being dense in not seeing the rest. I apologize, but that does not make me less dense. Sorry. Help? Joel On 6/21/2021 11:28 AM, Les Ginsberg (ginsberg) wrote: Joel - I am not objecting to the draft. I am simply asking for it to be both clear and accurate in what it is actually doing. I think Tom has done an excellent job of pointing out the inaccuracies and in some cases providing proposed revised text. I would ask you to reread your own draft in the context that at least two people have read it and found it inaccurate and both of us have made very explicit points about what language is confusing. Les -Original Message- From: Joel Halpern Direct Sent: Monday, June 21, 2021 8:13 AM To: Les Ginsberg (ginsberg) ; tom petch ; Harold Liu ; lsr@ietf.org Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt Les, I am missing something ion both your and Tom's comments. 5309 didn't define the ifType. If you look at 5309, it has no IANA considerations at all. Yes, this document should talk about 5309 as one of the cases that the ifType simplifies. And it does. This documents follows the lead of 8343 in defining this specific ifType. Let's be clear. We were asked, quite reasoanbly, by the expert, when we requested the IANA code point, to please submit a document describing how the dcode point would be used, rather than merely pointing at 5309 and assuming everyone could guess correctly. (Guessing is not good for standards.) So we are trying to do so. You seem to be objecting to our doing so. Why? If the working group really doesn't want a description, we can go away. We have the code point we felt was useful. But it seems much more useful to actually provide meaningful documentation. Yours, Joel On 6/21/2021 10:58 AM, Les Ginsberg (ginsberg) wrote: 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 On Behalf Of Joel M. Halpern Sent: Monday, June 21, 2021 7:13 AM To: tom petch ; Harold Liu ; lsr@ietf.org 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 r
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Joel - In addition to the IANA section changes, 1)Please be sure that the text consistently refers to "Point to Point (P2P) Interface over LAN" - not simply "Point to Point" 2)I think the abstract/introduction should make it clear that this draft is specifying the management mappings for the " Point to Point (P2P) Interface over LAN". It is NOT defining Point to Point (P2P) Interface over LAN operation - that clearly was already done by RFC 5309. 3)I don’t know if Section 3 is really needed. I tend to think not. But if you do want to keep it, please Reference RFC 8343 Section 4 as this is clearly a copy of the Figure in that document/section. Les > -Original Message- > From: Joel Halpern Direct > Sent: Monday, June 21, 2021 8:47 AM > To: Les Ginsberg (ginsberg) ; tom petch > ; Harold Liu > ; lsr@ietf.org > Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > > The change Tom has proposed to the IANA considerations section is fine > with me. > > If there are other specific changes that will make it clearer, I and my > co-authors are happy to make those. I have tried looking at the text. > Even before you found it misleading, I did conclude that Tom getting > the wrong impression meant it needs to be clarified. But as I am having > trouble seeing what misled you, I can not suggest wording improvements > to my co-authors. > > I presume from your phrasing that you want more changes than just to the > IANA considerations section. I presume I am just being dense in not > seeing the rest. I apologize, but that does not make me less dense. > Sorry. > > Help? > Joel > > On 6/21/2021 11:28 AM, Les Ginsberg (ginsberg) wrote: > > Joel - > > > > I am not objecting to the draft. > > I am simply asking for it to be both clear and accurate in what it is > > actually > doing. > > > > I think Tom has done an excellent job of pointing out the inaccuracies and > in some cases providing proposed revised text. > > > > I would ask you to reread your own draft in the context that at least two > people have read it and found it inaccurate and both of us have made very > explicit points about what language is confusing. > > > > Les > > > >> -----Original Message- > >> From: Joel Halpern Direct > >> Sent: Monday, June 21, 2021 8:13 AM > >> To: Les Ginsberg (ginsberg) ; tom petch > >> ; Harold Liu > >> ; lsr@ietf.org > >> Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > >> > >> Les, I am missing something ion both your and Tom's comments. 5309 > >> didn't define the ifType. If you look at 5309, it has no IANA > >> considerations at all. > >> > >> Yes, this document should talk about 5309 as one of the cases that the > >> ifType simplifies. And it does. > >> > >> This documents follows the lead of 8343 in defining this specific ifType. > >> > >> Let's be clear. We were asked, quite reasoanbly, by the expert, when we > >> requested the IANA code point, to please submit a document describing > >> how the dcode point would be used, rather than merely pointing at 5309 > >> and assuming everyone could guess correctly. (Guessing is not good for > >> standards.) > >> So we are trying to do so. > >> > >> You seem to be objecting to our doing so. Why? > >> > >> If the working group really doesn't want a description, we can go away. > >>We have the code point we felt was useful. But it seems much more > >> useful to actually provide meaningful documentation. > >> > >> Yours, > >> Joel > >> > >> > >> > >> On 6/21/2021 10:58 AM, Les Ginsberg (ginsberg) wrote: > >>> 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
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
The change Tom has proposed to the IANA considerations section is fine with me. If there are other specific changes that will make it clearer, I and my co-authors are happy to make those. I have tried looking at the text. Even before you found it misleading, I did conclude that Tom getting the wrong impression meant it needs to be clarified. But as I am having trouble seeing what misled you, I can not suggest wording improvements to my co-authors. I presume from your phrasing that you want more changes than just to the IANA considerations section. I presume I am just being dense in not seeing the rest. I apologize, but that does not make me less dense. Sorry. Help? Joel On 6/21/2021 11:28 AM, Les Ginsberg (ginsberg) wrote: Joel - I am not objecting to the draft. I am simply asking for it to be both clear and accurate in what it is actually doing. I think Tom has done an excellent job of pointing out the inaccuracies and in some cases providing proposed revised text. I would ask you to reread your own draft in the context that at least two people have read it and found it inaccurate and both of us have made very explicit points about what language is confusing. Les -Original Message- From: Joel Halpern Direct Sent: Monday, June 21, 2021 8:13 AM To: Les Ginsberg (ginsberg) ; tom petch ; Harold Liu ; lsr@ietf.org Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt Les, I am missing something ion both your and Tom's comments. 5309 didn't define the ifType. If you look at 5309, it has no IANA considerations at all. Yes, this document should talk about 5309 as one of the cases that the ifType simplifies. And it does. This documents follows the lead of 8343 in defining this specific ifType. Let's be clear. We were asked, quite reasoanbly, by the expert, when we requested the IANA code point, to please submit a document describing how the dcode point would be used, rather than merely pointing at 5309 and assuming everyone could guess correctly. (Guessing is not good for standards.) So we are trying to do so. You seem to be objecting to our doing so. Why? If the working group really doesn't want a description, we can go away. We have the code point we felt was useful. But it seems much more useful to actually provide meaningful documentation. Yours, Joel On 6/21/2021 10:58 AM, Les Ginsberg (ginsberg) wrote: 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 On Behalf Of Joel M. Halpern Sent: Monday, June 21, 2021 7:13 AM To: tom petch ; Harold Liu ; lsr@ietf.org 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 on behalf of Harold Liu 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 updat
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Joel - I am not objecting to the draft. I am simply asking for it to be both clear and accurate in what it is actually doing. I think Tom has done an excellent job of pointing out the inaccuracies and in some cases providing proposed revised text. I would ask you to reread your own draft in the context that at least two people have read it and found it inaccurate and both of us have made very explicit points about what language is confusing. Les > -Original Message- > From: Joel Halpern Direct > Sent: Monday, June 21, 2021 8:13 AM > To: Les Ginsberg (ginsberg) ; tom petch > ; Harold Liu > ; lsr@ietf.org > Subject: Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt > > Les, I am missing something ion both your and Tom's comments. 5309 > didn't define the ifType. If you look at 5309, it has no IANA > considerations at all. > > Yes, this document should talk about 5309 as one of the cases that the > ifType simplifies. And it does. > > This documents follows the lead of 8343 in defining this specific ifType. > > Let's be clear. We were asked, quite reasoanbly, by the expert, when we > requested the IANA code point, to please submit a document describing > how the dcode point would be used, rather than merely pointing at 5309 > and assuming everyone could guess correctly. (Guessing is not good for > standards.) > So we are trying to do so. > > You seem to be objecting to our doing so. Why? > > If the working group really doesn't want a description, we can go away. > We have the code point we felt was useful. But it seems much more > useful to actually provide meaningful documentation. > > Yours, > Joel > > > > On 6/21/2021 10:58 AM, Les Ginsberg (ginsberg) wrote: > > 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 On Behalf Of Joel M. Halpern > >> Sent: Monday, June 21, 2021 7:13 AM > >> To: tom petch ; Harold Liu > >> ; lsr@ietf.org > >> 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 on behalf of Harold Liu > >> > >>> 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 mo
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Les, I am missing something ion both your and Tom's comments. 5309 didn't define the ifType. If you look at 5309, it has no IANA considerations at all. Yes, this document should talk about 5309 as one of the cases that the ifType simplifies. And it does. This documents follows the lead of 8343 in defining this specific ifType. Let's be clear. We were asked, quite reasoanbly, by the expert, when we requested the IANA code point, to please submit a document describing how the dcode point would be used, rather than merely pointing at 5309 and assuming everyone could guess correctly. (Guessing is not good for standards.) So we are trying to do so. You seem to be objecting to our doing so. Why? If the working group really doesn't want a description, we can go away. We have the code point we felt was useful. But it seems much more useful to actually provide meaningful documentation. Yours, Joel On 6/21/2021 10:58 AM, Les Ginsberg (ginsberg) wrote: 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 On Behalf Of Joel M. Halpern Sent: Monday, June 21, 2021 7:13 AM To: tom petch ; Harold Liu ; lsr@ietf.org 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 on behalf of Harold Liu 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; 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 fro
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
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 On Behalf Of Joel M. Halpern > Sent: Monday, June 21, 2021 7:13 AM > To: tom petch ; Harold Liu > ; lsr@ietf.org > 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 on behalf of Harold Liu > > > 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; > > > > > > 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
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 on behalf of Harold Liu 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; 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 Sent: Thursday, June 17, 2021 2:16 PM To: Joel M. Halpern ; 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=1=d4a020c9-b337-41fd-bf1b-56dcfaef1044=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=1=d4a020c9-b337-41fd-bf1b-56dcfaef1044=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) ; 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 b
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Lsr on behalf of Harold Liu 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; 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 Sent: Thursday, June 17, 2021 2:16 PM To: Joel M. Halpern ; 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=1=d4a020c9-b337-41fd-bf1b-56dcfaef1044=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=1=d4a020c9-b337-41fd-bf1b-56dcfaef1044=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) > ; 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" 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 documen
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
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; 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 Sent: Thursday, June 17, 2021 2:16 PM To: Joel M. Halpern ; 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=1=d4a020c9-b337-41fd-bf1b-56dcfaef1044=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=1=d4a020c9-b337-41fd-bf1b-56dcfaef1044=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) > ; 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" 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 > > > >
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Joel M. Halpern Sent: 18 June 2021 17:41 How can we clarify the wording. If it is misleading you, we need to improve it. The text is not asking to create an entry (i.e. it does not "ask for an assignment"), but rather to change an entry that already exists. (And obviously, it won't do so until and if the document becomes an RFC.) NEW "IANA Considerations In the Interface Types registry, IANA has previously assigned a value of 303 for p2pOverLan with a reference of RFC5309. IANA is requested to amend the reference to point to this document and to make a similar amendment in the YANG iana-if-type module which currently points to RFC8561." I see no need for any more action by IANA; it is the sort of request that has been made many times before when one RFC obsoletes another The body of the document might say more, e.g. that value 303 was assigned for interface type ap2pOverLan by Expert review which caused IANA to add the entries to the MIB module and the YANG module but IANA do not need to be told that - they did it! Tom Petch Yours, Joel On 6/18/2021 12:20 PM, tom petch wrote: > From: Joel M. Halpern > Sent: 18 June 2021 16:29 > > Tom, I am not sure what you mean by "the update has happened"> The code > point has been assigned. Assuming this document becomes an RFC, it will > be significantly clearer if the 303 code point IANA entry points at this > for information instead of 5309. So this document requests that update. > > > I mean that the IANA Registry has been updated to include 303 with a > reference to 5309 so I think it wrong of this I-D to ask for assignment which > is what I see it doing with > > IANA need to update the "Interface Types(ifType)" with the following status > types: > >| 303| p2pOverLan |Point to Point over LAN interface | > > It should only ask for the reference to be changed and should also spell > out that the assignment was made by Expert Review since that may otherwise be > unclear to users.. > > Likewise the update to the YANG module is automatic, has happened and so > specifying it here can only confuse IMHO. > > And elsewhere I find the flavour misleading. The abstract and introduction > should IMHO reference RFC5309 as the source of p2pOverLan, add that the > values have been assigned by Expert Review and that this I-D ... well I am > not clear what it does except lay claim to things that others have already > done with RFC5309 and expert review :-) > > I think too that camel case is problematic. SMI uses it, YANG does not but > we are now likely stuck with identity p2pOverLan . > > Tom Petch > > Yours, > Joel > > On 6/18/2021 7:47 AM, tom petch wrote: >> From: Lsr on behalf of Joel M. Halpern >> >> Sent: 16 June 2021 21:46 >> >> 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.) >> >> >> which confused me as RFC5309 has no IANA considerations and no reference to >> 303. I understand how this is so but think that this I-D could explain >> this. I think that the I-D is wrong to ask IANA to perform an update - the >> update has happened. >> >> What would help would be for this I-D to explain that the allocation was >> made by Expert Review and to ask that IANA update the reference to point to >> this I-D and then this I-D can point back to RFC5309. This is almost an >> updates to 5309 as it give a value to the specification - I can see the IESG >> having fun with that concept but I would go for it. >> >> I think too that this I-D should reference and build on RFC5309. At present >> it looks like an Unused Ref. >> >> Tom Petch >> >> >> >> 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" >>> 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 >>>
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
How can we clarify the wording. If it is misleading you, we need to
improve it. The text is not asking to create an entry (i.e. it does
not "ask for an assignment"), but rather to change an entry that already
exists. (And obviously, it won't do so until and if the document
becomes an RFC.)
Yours,
Joel
On 6/18/2021 12:20 PM, tom petch wrote:
From: Joel M. Halpern
Sent: 18 June 2021 16:29
Tom, I am not sure what you mean by "the update has happened"> The code
point has been assigned. Assuming this document becomes an RFC, it will
be significantly clearer if the 303 code point IANA entry points at this
for information instead of 5309. So this document requests that update.
I mean that the IANA Registry has been updated to include 303 with a reference
to 5309 so I think it wrong of this I-D to ask for assignment which is what I
see it doing with
IANA need to update the "Interface Types(ifType)" with the following status
types:
| 303| p2pOverLan |Point to Point over LAN interface |
It should only ask for the reference to be changed and should also spell out
that the assignment was made by Expert Review since that may otherwise be
unclear to users..
Likewise the update to the YANG module is automatic, has happened and so
specifying it here can only confuse IMHO.
And elsewhere I find the flavour misleading. The abstract and introduction
should IMHO reference RFC5309 as the source of p2pOverLan, add that the values
have been assigned by Expert Review and that this I-D ... well I am not clear
what it does except lay claim to things that others have already done with
RFC5309 and expert review :-)
I think too that camel case is problematic. SMI uses it, YANG does not but we
are now likely stuck with identity p2pOverLan .
Tom Petch
Yours,
Joel
On 6/18/2021 7:47 AM, tom petch wrote:
From: Lsr on behalf of Joel M. Halpern
Sent: 16 June 2021 21:46
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.)
which confused me as RFC5309 has no IANA considerations and no reference to
303. I understand how this is so but think that this I-D could explain this.
I think that the I-D is wrong to ask IANA to perform an update - the update has
happened.
What would help would be for this I-D to explain that the allocation was made
by Expert Review and to ask that IANA update the reference to point to this I-D
and then this I-D can point back to RFC5309. This is almost an updates to 5309
as it give a value to the specification - I can see the IESG having fun with
that concept but I would go for it.
I think too that this I-D should reference and build on RFC5309. At present it
looks like an Unused Ref.
Tom Petch
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" 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
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Joel M. Halpern Sent: 18 June 2021 16:29 Tom, I am not sure what you mean by "the update has happened"> The code point has been assigned. Assuming this document becomes an RFC, it will be significantly clearer if the 303 code point IANA entry points at this for information instead of 5309. So this document requests that update. I mean that the IANA Registry has been updated to include 303 with a reference to 5309 so I think it wrong of this I-D to ask for assignment which is what I see it doing with IANA need to update the "Interface Types(ifType)" with the following status types: | 303| p2pOverLan |Point to Point over LAN interface | It should only ask for the reference to be changed and should also spell out that the assignment was made by Expert Review since that may otherwise be unclear to users.. Likewise the update to the YANG module is automatic, has happened and so specifying it here can only confuse IMHO. And elsewhere I find the flavour misleading. The abstract and introduction should IMHO reference RFC5309 as the source of p2pOverLan, add that the values have been assigned by Expert Review and that this I-D ... well I am not clear what it does except lay claim to things that others have already done with RFC5309 and expert review :-) I think too that camel case is problematic. SMI uses it, YANG does not but we are now likely stuck with identity p2pOverLan . Tom Petch Yours, Joel On 6/18/2021 7:47 AM, tom petch wrote: > From: Lsr on behalf of Joel M. Halpern > > Sent: 16 June 2021 21:46 > > 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.) > > > which confused me as RFC5309 has no IANA considerations and no reference to > 303. I understand how this is so but think that this I-D could explain this. > I think that the I-D is wrong to ask IANA to perform an update - the update > has happened. > > What would help would be for this I-D to explain that the allocation was made > by Expert Review and to ask that IANA update the reference to point to this > I-D and then this I-D can point back to RFC5309. This is almost an updates > to 5309 as it give a value to the specification - I can see the IESG having > fun with that concept but I would go for it. > > I think too that this I-D should reference and build on RFC5309. At present > it looks like an Unused Ref. > > Tom Petch > > > > 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" >> 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: >>
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
Tom, I am not sure what you mean by "the update has happened"> The code point has been assigned. Assuming this document becomes an RFC, it will be significantly clearer if the 303 code point IANA entry points at this for information instead of 5309. So this document requests that update. Yours, Joel On 6/18/2021 7:47 AM, tom petch wrote: From: Lsr on behalf of Joel M. Halpern Sent: 16 June 2021 21:46 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.) which confused me as RFC5309 has no IANA considerations and no reference to 303. I understand how this is so but think that this I-D could explain this. I think that the I-D is wrong to ask IANA to perform an update - the update has happened. What would help would be for this I-D to explain that the allocation was made by Expert Review and to ask that IANA update the reference to point to this I-D and then this I-D can point back to RFC5309. This is almost an updates to 5309 as it give a value to the specification - I can see the IESG having fun with that concept but I would go for it. I think too that this I-D should reference and build on RFC5309. At present it looks like an Unused Ref. Tom Petch 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" 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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
From: Lsr on behalf of Joel M. Halpern Sent: 16 June 2021 21:46 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.) which confused me as RFC5309 has no IANA considerations and no reference to 303. I understand how this is so but think that this I-D could explain this. I think that the I-D is wrong to ask IANA to perform an update - the update has happened. What would help would be for this I-D to explain that the allocation was made by Expert Review and to ask that IANA update the reference to point to this I-D and then this I-D can point back to RFC5309. This is almost an updates to 5309 as it give a value to the specification - I can see the IESG having fun with that concept but I would go for it. I think too that this I-D should reference and build on RFC5309. At present it looks like an Unused Ref. Tom Petch 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" > 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 ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
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" 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
Re: [Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
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" 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
[Lsr] Fwd: I-D Action: draft-liu-lsr-p2poverlan-00.txt
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
