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

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

On 2008-12-14 15:03, Hesham Soliman wrote:
> Hi Brian,
> 
> 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.

> 
> Also, what do you suggest we do with 2983?

See above - that's Jari's call.

> 
>>    [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
>>               of Explicit Congestion Notification (ECN) to IP",
>>               RFC 3168, September 2001.
> 
>>    [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
>>               for IPv6 Hosts and Routers", RFC 4213, October 2005.
> 
>>    [RFC4459]  Savola, P., "MTU and Fragmentation Issues with In-the-
>>               Network Tunneling", RFC 4459, April 2006.
> 
> => 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.

> 
>>    [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.

> 
>> 5.2.  NAT Detection
> 
> ...
>>    A mobile node MUST always tunnel binding updates in UDP when located
>>    in an IPv4-only network.
> 
> 
> 
> I think this should indicate how the mobile knows that it's in an IPv4-only
> network,
> or maybe it should say 'A mobile node that has not been assigned an IPv6
> address
> by the foreign network...'. Also, there's a missing verb in that sentence.
> 
> => This is explained in section 5.4.4. I forgot to add the verb, will do
> that.

OK

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