Thanks for the review and suggested changes. Suresh, would you be OK with Ted's proposed change?
We need to resolve this before the document can be approved, I think. Jari On Mar 26, 2014, at 6:46 AM, Ted Lemon <[email protected]> wrote: > On Mar 25, 2014, at 5:20 PM, Suresh Krishnan <[email protected]> > wrote: >> * Section 4.1 (b) >> >> The following text is unclear. >> >> "if the relay agent receives the message for which it is not the target >> according to the message type." >> >> The text that follows talks about new server-to-relay messages sent to the >> relay agent being forwarded back to the server. Such a message will not meet >> either of the conditions laid out in Section 4.1. > > It might be better to make point (b) this way: > > (b) if the relay agent receives the message for which it does > not identify itself as the target. > > At present the only DHCP message that could be intended for a relay > agent would be a LEASEQUERY-REPLY message [RFC5007]. Such messages > are only correctly generated in response to LEASEQUERY messages sent > by a relay agent acting as a leasequery requestor. It is therefore > expected that such messages will be able to be identified by relay > agents. > > The text that follows is intended to address the case where a new message > type is defined that is intended to be sent, unsolicited, to a relay agent. > It might be made clearer as follows: > > New DHCP message types may be defined in future that are sent, > unsolicited, to relay agents. Relay agents > that do not implement these messages will not recognize such > messages as being intended for them. A relay agent that implements this > specification will therefore forward such messages to the DHCP > servers to which it is configured to relay client messages. > > At this time, no such message types have been specified. If > such a message is specified in the future, it is possible that this > would result in needless load on DHCP servers. If such a message > type is defined in a future specification, authors may need to > consider some strategy for identifying non-conforming relays and > not sending such messages to them. > > However, since DHCP servers do not respond to unknown messages, > this is unlikely to create significant load, and therefore is > likely to be unnecessary. > >> The following text seems extraneous >> >> " However, this is not strictly necessary, since DHCP does not provide >> a signaling message for rejecting unexpected message types, and >> therefore DHCP servers are not expected to respond to such messages." >> >> What exactly is "this" referring to? The DHCP server is not responding >> anyway to such messages. > > The reason for not just deleting this text is that it _is_ possible to define > an unsolicited relay message in such a way that it could cause problems, so > the author really does need to think about it, and it's reasonably likely > that they will read this advice before doing so, or at least that someone who > reviews the document will be aware of this advice. > > >> * Section 4.2 >> >> The prescribed behavior here is contradicts the text in section 4.1 defining >> a valid message. Specifically, what happens when a relay receives an unknown >> message type for which it is the intended target. According to 4.1, the >> relay does nothing. According to 4.2 the relay forwards. > > No, according to 4.1 it forwards as well, unless it's the intended recipient > of the message. And it can only tell that it's the intended recipient if it > understands that type of message. So the two sections do not contradict > each other. Hopefully this is more clear with the new text. Stephen > Farrell raised some related questions; updating the text as I've suggested > should address his concerns as well. > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
