Re: [Gen-art] Gen-ART review of draft-ietf-mext-nemo-v4traversal-07.txt

Hi Brian,

> Hi Hesham, why are we both working at the weekend?

=> Good question :) At least we seem to be in the same time zone!

>> 
>> The following appear to me to be used normatively; the absence of an
>> upper case keyword doesn't prove the absence of a normative reference:
>> 
>>>    [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
>>>               Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
>>>               March 2000.
>> 
>>>    [RFC2983]  Black, D., "Differentiated Services and Tunnels",
>>>               RFC 2983, October 2000.
>> 
>> 
>> 
>> (Sorry about this, it was added at my suggestion and is a downref.)
>> 
>> 
>> => I don't understand how the reference to GRE is a downref. There is no
>> requirement language for it, it's simply supported if someone needs it.
>> If you could tell me that then I will understand some of the other downrefs
>> you refer to.
> 
> No, I only meant 2983 is a downref, because it's Informational.
> See http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
> There's a procedure for handling downrefs, which Jari can perform if
> people agree it's necessary. I can't even remember why 2983 went as
> Informational (I should do, since I was the WG co-chair).
> 
> I think you're confusing two issues, so I must have been unclear
> in my review, sorry:
> 
> 1. A normative reference to an Informational RFC needs to be handled
> by the downref procedure. That only concerns RFC2983 and RFC4459 here.
> 
> 2. I believe that you have several normative references listed
> as informative. That's a matter of judgement and consensus, so the
> WG and the IESG are free to disagree with me. The fact that GRE
> is only an optional feature doesn't prevent it being a normative
> reference, however; the question is whether an implementer can
> implement that option without reading RFC2784. The same applies
> to all the other cases I've suggested should be normative.
> My best guess is that they are required reading; but I'm quite
> ready to be told I'm wrong.

=> Thank you for the clarification. Yes I think I lumped both issues and
perhaps read your email too quickly. I agree that 2983 and 4459 are downrefs
I this case. I'll defer to Jari here for sugestions on how to handle this.

>> 
>> => Again, I don't see it for 3168, 4213 or 4459. Can you please explain it
>> for at least a couple of those so I know what you mean? For example, why is
>> 3168 a downref?
> 
> To take that example, you say
>  "it is RECOMMENDED that the ECN and DSCP information is copied
>    between the inner and outer header as defined in [RFC3168] and
>    [RFC2983]."
> How can I write code to do that except by reading those two RFCs?
> So they are both normative IMHO, but only 2983 is a downref.

=> Agreed. I think you can definitely write the code without reading GRE or
MOBKIE (4555). But you do need 3168 and 2983, although, they are most likely
already supported by the tunnelling code that an implementer will reuse.

> 
>> 
>>>    [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
>>>               (MOBIKE)", RFC 4555, June 2006.
>> 
>> => How can this be a downref??
> 
> It's not, but I think it's normative.

=> I can add that.

Thanks,
Hesham

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art