IETF conflict review for draft-liu-lsr-p2poverlan
conflict-review-liu-lsr-p2poverlan-01

The following approval message was sent
From: The IESG
To: Adrian Farrel ,
    draft-liu-lsr-p2poverlan@ietf.org,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-liu-lsr-p2poverlan-08

The IESG has completed a review of draft-liu-lsr-p2poverlan-08 consistent
with RFC5742.

The IESG has no problem with the publication of 'Interface Stack Table
Definition and Example for Point-to-Point (P2P) Interface over LAN'
as an Informational RFC.

The IESG has concluded that this work is related to IETF work done in the LSR
WG, but this relationship does not prevent publishing.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-liu-lsr-p2poverlan/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-liu-lsr-p2poverlan/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
We discussed this in the telechat and agreed from an IETF conflict review perspective that the IESG should not prevent this from being published, but with a desire to agree some scope disclaimer text with the authors/ISE and hopefully discussion/resolution of the other issues/questions that I raised.

Previous discuss comments:

Hi,

I've put a discuss on this conflict review because I think that it would be helpful to have some level of discussion to check that the IESG is okay with the ISE publishing this draft.

My specific concern is that this document is defining a management interface for an IETF specified property (i.e., that an Ethernet interface is only carrying point-to-point traffic as defined in RFC5309), and if the IETF were to standardize such a property I'm doubtful that there would be consensus for the property to be modelled this way, given that it seems a complex way to model a management attribute of an interface.

However, as a counter point in favour of publishing this, it is only describing an iftype, many such types are defined, and such types are allowed to be defined by expert review (subject to the guidance in RFC 8892), and having a document that explains how an iftype is used, and its associated properties, is generally helpful and aids interoperability.

A possible compromise, if the document is to be published, is to have some very clear declaimer that this document explains how implementations may represent the P2P traffic as a separate interface in the interface stack but makes it clear that modelling it this way it an implementation decision and other implementations may choose to implement it without creating a separate interface in the ifStack. 

It is worth noting that I also had a verbal discussion with the ISE today and invited him to join/discuss this in today's telechat but he is unavailable.

Regards,
Rob

---

I have other questions and comments with how this is defined, but I will post the comments to the authors/ISE/IESG separately so that they do not get confused with the conflict review.

[Ballot discuss]
Hi,

I've put a discuss on this conflict review because I think that it would be helpful to have some level of discussion to check that the IESG is okay with the ISE publishing this draft.

My specific concern is that this document is defining a management interface for an IETF specified property (i.e., that an Ethernet interface is only carrying point-to-point traffic as defined in RFC5309), and if the IETF were to standardize such a property I'm doubtful that there would be consensus for the property to be modelled this way, given that it seems a complex way to model a management attribute of an interface.

However, as a counter point in favour of publishing this, it is only describing an iftype, many such types are defined, and such types are allowed to be defined by expert review (subject to the guidance in RFC 8892), and having a document that explains how an iftype is used, and its associated properties, is generally helpful and aids interoperability.

A possible compromise, if the document is to be published, is to have some very clear declaimer that this document explains how implementations may represent the P2P traffic as a separate interface in the interface stack but makes it clear that modelling it this way it an implementation decision and other implementations may choose to implement it without creating a separate interface in the ifStack. 

It is worth noting that I also had a verbal discussion with the ISE today and invited him to join/discuss this in today's telechat but he is unavailable.

Regards,
Rob

[Ballot comment]
I have other questions and comments with how this is defined, but I will post the comments to the authors/ISE/IESG separately so that they do not get confused with the conflict review.

[Ballot comment]
Alvaro’s comment seems right. Which, I suppose means my (or his) ballot should really be a discuss? But if he can’t be bothered, neither can I. :-)

[Ballot comment]
I agree that there is no conflict that prevents publication.  However, given rfc5309, it seems to me that this work is related to the work in the lsr WG.