Re: [dhcwg] Review of draft-ietf-dhc-relay-agent-flags-02.txt

Thomas Narten wrote:
>> Since the wg last-call is over, I'm not sure quite what the right thing 
>> to do is. Do you feel that the iesg will not be able to evaluate this 
>> draft without another revision, containing one extra sentence?
> 
> I think they (and the IETF as a whole, as I don't think the IETF LC
> has happened) will probably be able to evaluate it better with the
> extra sentence (btw, what will it be?). But is it critical? No. Also,
> since it only takes 2 minutes to submit a revised ID (once you have
> the text), I think its often less work to just do so than have a
> discussion about whether to. :-)

Yes, submitting a new ID is pretty easy, while people in general
seems to somehow resist this.

Anyway, I suggest that the authors can state what to change/add.
We can see if people are happy with it, and I can also check with
Jari whether we should update now or later.

Not having that extra sentence might possibly delay the IESG
evaluation...

Stig

> 
>>>> 4.  DHCP Relay Agent Behavior
>>>>
>>>>    A DHCP relay agent MUST include this suboption in every Relay Agent
>>>>    Information Option [RFC3046] it adds to a forwarded DHCP request.  In
>>> It seems to me like this MUST is too strong and unenforceable. Relay
>>> Agent options are already defined, and this is a new one, so this
>>> requirement is unenforceable. Moreover, why is this so important?  In
>>> the absence of a compelling justification, SHOULD seems more
>>> appropriate.
>>>
>>>
> 
>> the intention here wasn't to introduce some sort of ... unfunded 
>> mandate. it was just to make it clear what support for the standard 
>> would mean. if an implementation doesn't support the (eventual) 
>> standard, then of course it's not going to be including this suboption. 
>> an implementation that claims compliance needs to obey section 4. an 
>> implementation that isn't compliant ... probably won't. Is there 
>> something here that's different from any of the other suboptions (or 
>> options) that have been developed individually?
> 
> Well, for one thing, the above text makes its sound like a protocol
> violation to implement the spec, but choose not to send the option
> (e.g., even if configured to do so for some reason). That seems a bit
> strong to me.
> 
> Thomas
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg