[16NG] IESG Comments on draft-ietf-16ng-ip-over-ethernet-over-802-dot-16

["Riegel, Maximilian (NSN - DE/Munich)" <[e-mail]>]

When checking the datatracker
https://datatracker.ietf.org/idtracker/draft-ietf-16ng-ip-over-ethernet-
over-802-dot-16/ I found the following open comments from last weeks
IESG discussions.

Meanwhile we have prepared a new revision of the I-D addressing the
issues. We are ready to submit the revised I-D and would like to clarify
that we really solved the issues.

Bye
Max
pls see inline

> Date: 2009-09-10, 04:24:05 
> Document: draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 
> Version: 11 
> Commented by: Jari Arkko 
> Comment: [IESG Evaluation DISCUSS] 
> The document is now in quite good shape -- there's been progress
> since the previous versions! I did have a few issues, though:
> 
> Here the conclusion is right but the rationale needs a bit work:
> 
> > According to [RFC4861], a link is defined as a communication
facility
> > or medium over which IP devices can communicate at the link layer,
> > i.e. the layer immediately below IP.  Ethernet fully satisfies the
> > definition of the link.  IEEE 802.16, however, has limitations on
its
> > transitive connectivity, i.e.  IEEE 802.16 provides point-to-point
> > connections between SSs and the BS but does not enable any direct SS
> > to SS connectivity.  Hence, it is required to bridge each of the
> > point-to-point connections between SSs and the BS so that Ethernet
is
> > realized over IEEE 802.16 access network.
> 
> Here's a piece of Ethernet technology that has the same limitations as
> 802.16:
> 
> - it is point to point
> - it doesn't do multicast
> - it has limitations with regards to host - host connectivity
>   unless your nic supports either straight and twisted cables
> 
> http://www.ccrane.com/images/medium/cat-5e-ethernet-cable.jpg

Great! And congratulation. This is the best explanation of the IEEE
802.16 link 
model which I have ever seen.

> But I do agree, of course, that bridging is required. I would suggest
> however that the paragraph be reworded to:
> 
>    Like in today's wired Ethernet networks, bridging is required to
>    implement connectivity between more than two devices. In 802.16,
the
>    point-to-point connections between SSs and the BS can be bridged
>    so that Ethernet is realized over IEEE 802.16 access network.

Your proposal is much shorter and hits the point. We included the
proposed text
instead of the previous wording.

> > The network-side bridging function SHOULD create a new radio side
> > port whenever a new SS attaches to any of the BSs of the network or
> > SHOULD remove a radio side port when an associated SS detaches from
> > the BSs.
> 
> Wouldn't this be more of a case for a MUST than a SHOULD? This is
basic
> functionality for 802.16 Ethernet.

Agreed. It is the essential behavior of the bridge. MUST is more
appropriate.
We changed SHOULD to MUST in the new revision of the I-D.

> > The generic IP over Ethernet network scenario assumes that all hosts
> > are residing on the same link with trust relationship between all of
> > them.
> 
> I'm not sure why we need to assume a trust relationship here. I would
> suggest deleting everything from word "link" onwards.

We are mentioning here trust relationship, because it is the main
difference to the public access case, where direct communication on the
link layer is prevented to protect other hosts on the same link from
malicious attacks. For the plain Ethernet functionality, trust
relationship is not required. We deleted as you proposed.

> > All multicast and multicast control messages SHOULD be processed in
> > the network-side bridging function according to [RFC4541].
> 
> This is a fine requirement, except for 4541 being an informational
> document and this spec being proposed standard. I would like to change
> this and similar recommendations in Section 7 to a different wording.
> Say, "can" instead of "SHOULD". Alternatively, we could call out this
> downref in a Last Call, but AFAICT this was not done in the last call
> we just had.
> 
> Same for RFC 4562 references.

We changed "SHOULD" to "can". We know about the difficulty to make
normative references to informative specifications. If "can" allows us
to point to the Informational RFCs, we are fine.

> --------------------------
> Date: 2009-09-08, 07:18:44 
> Document: draft-ietf-16ng-ip-over-ethernet-over-802-dot-16 
> Version: 10 
> Commented by: Magnus Westerlund 
> Comment: [IESG Evaluation COMMENT] 
> Section 5.2, 7.1:
> 
> I wonder why these section puts the requirement level on SHOULD and
not a MUST?
> And what are the reasons/motivation for when it is allowable to not do
the
> action?

For Section 5.2 (replicating broadcast messages and sending them unicast
to all hosts) we used 'SHOULD', because later in the document we
describe, when this rule should not be followed.

In section 7.1 hints are given to conserve radio resources by
selectively processing multicast and broadcast messages. The system
still works even when not all of the hints are adopted. Furthermore some
of the hints are from Informational RFCs, which makes it difficult to
use 'MUST' (see Jari's comment above).

I hope we were able to sufficiently address all the remaining issues of
the document. If yes, we will submit the revised I-D to the IETF.

Bye
Max