From: Joel M. Halpern <j...@joelhalpern.com>
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.)

<tp>
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 <j...@joelhalpern.com>
> 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.
>
> <tp>
> 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 <lsr-boun...@ietf.org> on behalf of Joel M. Halpern 
>> <j...@joelhalpern.com>
>> 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.)
>>
>> <tp>
>> 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" 
>>> <lsr-boun...@ietf.org on behalf of j...@joelhalpern.com> wrote:
>>>
>>>        Recently, Ericsson requested and received an IF Type assignment from
>>>        IANA (with expert review) for point-to-point over Ethernet links.
>>>
>>>        It was noted during the discussion around the assignment that a 
>>> document
>>>        (eventually, we hope, an RFC) describing how to use that and why we
>>>        asked for it would be helpful.
>>>
>>>        The below announcement is that draft.  We would like to work with the
>>>        community to improve and clarify teh draft.
>>>
>>>        Thank you,
>>>        Joel
>>>
>>>
>>>        -------- Forwarded Message --------
>>>        Subject: I-D Action: draft-liu-lsr-p2poverlan-00.txt
>>>        Date: Wed, 16 Jun 2021 07:00:04 -0700
>>>        From: internet-dra...@ietf.org
>>>        Reply-To: internet-dra...@ietf.org
>>>        To: i-d-annou...@ietf.org
>>>
>>>
>>>        A New Internet-Draft is available from the on-line Internet-Drafts
>>>        directories.
>>>
>>>
>>>                 Title           : Interface Stack Table Definition for 
>>> Point to
>>>        Point (P2P) Interface over LAN
>>>                 Authors         : Daiying Liu
>>>                                   Joel Halpern
>>>                                   Congjie Zhang
>>>         Filename        : draft-liu-lsr-p2poverlan-00.txt
>>>         Pages           : 7
>>>         Date            : 2021-06-16
>>>
>>>        Abstract:
>>>            The point-to-point circuit type is one of the mainly used circuit
>>>            types in link state routing protocol.  It is important to 
>>> identify
>>>            the correct circuit type when forming adjacencies, flooding link
>>>            state database packets, and monitor the link state.  This 
>>> document
>>>            defines point-to-point interface type and relevant stack tables 
>>> to
>>>            provide benefit for operation, maintenance and statistics.
>>>
>>>
>>>        The IETF datatracker status page for this draft is:
>>>        https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/
>>>
>>>        There is also an htmlized version available at:
>>>        https://datatracker.ietf.org/doc/html/draft-liu-lsr-p2poverlan-00
>>>
>>>
>>>        Internet-Drafts are also available by anonymous FTP at:
>>>        ftp://ftp.ietf.org/internet-drafts/
>>>
>>>
>>>        _______________________________________________
>>>        I-D-Announce mailing list
>>>        i-d-annou...@ietf.org
>>>        https://www.ietf.org/mailman/listinfo/i-d-announce
>>>        Internet-Draft directories: http://www.ietf.org/shadow.html
>>>        or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>>        _______________________________________________
>>>        Lsr mailing list
>>>        Lsr@ietf.org
>>>        https://www.ietf.org/mailman/listinfo/lsr
>>>
>>
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to