Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.txt

[Kathleen Moriarty <[e-mail]>]

I went back to the email thread as I wanted to look at the consensus and
don't see it the way Paul does.
Here is the end of the thread:
http://www.ietf.org/mail-archive/web/ipsec/current/msg09668.html

It reads as confusion with the term updates and most being ok with going in
either direction, Paul against and Yaron more in favor.

Updates can update very specific text in a draft.  Since this just applies
in this special case, the updates text needs to be clearly worded to
reflect that or you copy in all the text that applies from the other draft.

I'm at a day long conference tomorrow and will be slow to respond.

Thanks.

On Wed, Apr 1, 2015 at 3:11 PM, Kathleen Moriarty <
[e-mail]> wrote:

> Hi Paul,
>
> On Mon, Mar 30, 2015 at 8:51 PM, Paul Hoffman <[e-mail]>
> wrote:
>
>> On Mar 30, 2015, at 1:56 PM, Kathleen Moriarty <
>> [e-mail]> wrote:
>>
>> > Thanks for making most of the suggested changes to the draft.  I see
>> nothing happened in section 2.4 with the 'updates' text.  Since this
>> requires changes to the referenced draft, it's easier to just state what is
>> being updated in the previous RFC with this draft.  Could we work on that
>> change and have it ready soon?  I'd rather do this before IETF last call or
>> in IESG review as I think it pretty clearly should be done.
>>
>> My interpretation from the WG discussion was that there was consensus
>> that this document doesn't need to be marked as "updates RFC 4301". I
>> updated the shepherd report to indicate that the WG defers to the IESG on
>> judgement about this.
>>
>
> In looking back at this, the email lists, and talking to a couple of
> fellow ADs, I think it's important to tweak some text as it will get held
> up otherwise.  This text was not present in RFC4322.
>
> The last sentence of this paragraph is the mail issue:
>
>      When using NULL Authentication, the peer identity is not
>
>    authenticated and cannot be trusted.  If ID_NULL is used with NULL
>
>       Authentication, there is no ID at all.  The processing of PAD
>    described in Section 4.4.3.4 of [RFC4301] must be updated.
>
>
> The only change that would be required here is to reword that last
> sentence and mark the draft appropriately so it "updates" 4301 for this
> case. New text could be something like:
>
>
>      When using NULL Authentication, the peer identity is not
>
>    authenticated and cannot be trusted.  If ID_NULL is used with NULL
>
>       Authentication, there is no ID at all.  The processing of PAD
>    described in Section 4.4.3.4 of [RFC4301] is updated for NULL Authentication.
>
>
> Then you can add a few sentences specific to what is updated and where
> that text goes in 4.4.3.4. This keeps the update very specific and we see
> this in drafts pretty regularly when just a bit of text is needed.
>
> The other sentence that is problematic in this section is:
>
> To add support for ID_NULL, it needs to be included into the
>    list of ID types, specified in Section 4.4.3.1 of [RFC4301].
>
>
> As such, Section 4.4.3.1 of [RFC4301] is updated as follows:
>
>
> Old:
>
>
> New:
>
>
>
> You could simply then add a sentence that provides the text to update the list of ID types, showing where it is added in that section with surrounding text in the old/new.  The way it is written now leaves you wondering if that list will get updated at some point in the future.
>
>
> One AD wasn't too fused and the other agreed (provided an alternative)
>
>      Given the wording in 2.4, this draft most certainly needs to update
> RFC 4301.  If it does not update 4301, it needs to subsume the necessary
> text from 4301 to make this spec standalone.  From a quick read of 4301,
> I think section 2.4 would be augmented with 3-4 blocks indicating what
> text in 4301 is updated.
>
>
> I'm fine with the alternative as well.
>
>
>
> Does this draft update RFC4322 at all?  I do see that it wasn't referenced, so maybe not, but figured I would check to be safe.
>
>
> Thanks.
>
>
>
>> > The next telechat is April 9th and this won't make it on it, so there
>> is time to get this update ready without holding up the draft.
>>
>> Unless you want us to make more changes to the draft, you might as well
>> put this into IETF Last Call now, even though it will miss the next
>> telechat.
>>
>> --Paul Hoffman
>
>
>
>
> --
>
> Best regards,
> Kathleen
>



-- 

Best regards,
Kathleen