Subject: RE: [Mip4] draft-ietf-mip4-rfc3012bis-04.txt review

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 15 Sep 2005 14:27:58 -0500

Hi Jari,

Looks like we just have one open issue regarding IANA section. For that
also, I think it makes sense in cloning information from RFC3012 since
the intent of this draft is to obsolete RFC3012. So I will go ahead and
make that change as well.

Thanks again for all your comments.

Regards,
Jayshree

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2005 5:54 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]
Cc: Charlie P; [email-masked]
Subject: Re: [Mip4] draft-ietf-mip4-rfc3012bis-04.txt review

Hi Jayshree,

>The challenge rules are almost the same for all error cases, except the

>last one. I realize that the last one is a serious error, and there's 
>little that the mobile node can do about it. However, the rules appear 
>to imply that a new challenge value is required in all cases, except if

>you retry after HA_WRONG_CHALLENGE. Is there a reason for this? 
>Presumably if you want to retry the registration just in case the 
>system now works correctly, you would want to use a new, fresh 
>Challenge.
>
>If there is no reason for this difference, I would suggest deleting 
>some of the case-specific rules above and replacing them with generic 
>text at the bottom of the section, saying something like:
>
>  "In any case, if the mobile node attempts to register again
>   after such an error, it MUST use a new Challenge value
>   in such a registration, obtained either from an Agent Advertisement,
>   or from a Challenge extension to the Registration Reply containing
>   the error."
>
>(And even this may be unnecessary, given that there is also a 
>requirement close to this in Section 4.)
>
>[JB] Agree. Since the section is related to processing at the mobile 
>node, I will go ahead and include generic text and remove corresponding

>text from each of those error definitions.
>  
>
Ok.

>Are IANA considerations & rules needed for the Subtype field and SPI 
>0-255 range defined in Section 5?
>
>[JB] As you know, the sub-type defined in section 5 is same as RFC3012 
>and there was no change made in the format in this bis draft. In the 
>IANA Considerations section, we have statement mentioning dependency on

>RFC3012. Do you think we still need to have rules defined in this 
>document?
>  
>
Hmm. Good question, I didn't notice the reference.
Let see, I need to go and read RFC 3012 section
first...  OK, there's some more information about the rules
in there. Then the nature of your bis document is that it obsoletes
3012... but you have the reference. I don't know.

The IANA rules serve really two purposes (1) a command to
IANA to allocate new numbers or name spaces and (2)
documenting the rules through which further allocations
should be made.

Its a judgement call what to do here. All the information is there if
you considered the reference, we're not really missing anything. But
given that your document obsoletes 3012, it might seem natural to copy
the information to the new document, as you presumably have done for
everything else as well. I'm not even sure if a normative reference to
an obsoleted document is possible in a standards track spec, even if
this is admittedly a special case :-)

>>      Preceding Mobile IP data || Type, Subtype, Length, SPI
>>    
>>
>
>"Preceding Mobile IP data" is not explained. All bytes preceding the 
>start of the option in question, presumably? But starting from the IP, 
>UDP, or Mobile IP header or something else?
>
>[JB] Let me know if the following changes are acceptable for defining 
>Preceding Mobile IP data.
>
>From:
>The default algorithm for computation of the authenticator is HMAC- 
>Preceding Mobile IP data || Type, Subtype, Length, SPI where the Type, 
>Length, Subtype, and SPI are as shown in Section 5.
>
>To:
>The default algorithm for computation of the authenticator is HMAC- 
>Preceding Mobile IP data || Type, Subtype, Length, SPI where the Type, 
>Length, Subtype, and SPI are as shown in Section 5. The Preceding 
>Mobile IP data refers to the UDP payload (the Registration Request or 
>Registration Reply data) and all prior Extensions in their entirety.
>  
>
Sounds good to me.

>Might be an idea to clean this up to a "What's New vs. RFC3012" 
>section. Right now its hard to see if all the changes are true 
>technical changes from 3012, editorial modifications, or just 
>back-and-forth modifications between draft revisions.
>
>[JB] Currently we have noted modifications between draft revisions. I 
>don't have any issue summarizing just technical changes in short list 
>if there are no further objections from the group.
>  
>
Ok.

>Other editorial issues:
>
>I spent quite a bit of time trying to understand all the "MUST precede"

>rules relating to the order of the options (Sect 3, Sect 6, etc). Its 
>still hard to get an overview, and its also hard to convince yourself 
>that the specification of these rules is complete and unambiguous. But 
>I don't have a good suggestion for a better way to describe the rules.
>
>[JB] My suggestion is to keep the text as it is.
>  
>
Ok.

--Jari

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/