Jari, On 3/26/14 2:31 AM, Jari Arkko wrote: > 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.
As shepherding AD, I agree this should be resolved prior to approval. Regards, Brian > > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
