Tom,
Tunnels seem to be ubiquitous in the IETF, as in the Internet.
IMO:
A over B, which is typically more like A over X over B (requiring a
shim), belongs where A belongs.
The point is that this tunnel is trying to create a new version of service A
that needs to behave exactly like A. It typically isn’t changing B.
That said, if there are extensions to B required, then they need ALSO be
reviewed where B belongs, but IMO only in concert with A being where A belongs.
I.e., that’s why the IP over * tunnels draft (draft-ietf-intarea-tunnels) is in
intarea.
Joe
> On Oct 26, 2018, at 5:05 AM, tom petch <[email protected]> wrote:
>
> I am not sure where tunnels have a home in the IETF but for anyone with
> an interest in them, draft-ietf-softwire-yang, having completed IETF
> Last Call two weeks ago, has since acquired a YANG module for tunnel
> types, based on the Tunnel MIB, RFC4087, which seems not to have been
> turned into a YANG module before.
>
> I am unsure where the place to discuss such a topic is; softwires, which
> owns the I-D containing the module, would be the place for aplusp but
> perhaps not for the others. I have forwarded this to 6man thinking that
> they would have an interest.
>
> The I-D has been revised five times since Last Call completed and I have
> suggested that it needs to go back to softwires for them to agree this
> is really what they want before the I-D goes any further.
>
> Tom Petch
>
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
