Re: [6lo] AP-ND 22

Abdussalam Baryun <> Sun, 26 April 2020 07:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 331413A0F07; Sun, 26 Apr 2020 00:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lJeaGs6Et7cq; Sun, 26 Apr 2020 00:10:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::c2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79ECF3A0F05; Sun, 26 Apr 2020 00:10:47 -0700 (PDT)
Received: by with SMTP id g14so3133501ooa.4; Sun, 26 Apr 2020 00:10:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tX8fjXVUivdL1jGkUmAls8bBWxOe3U72ILB2nFhQv2Q=; b=h8gp6tcFnIuhQBb2+Kn5/7H25nBvxe/Bz426GKtHK6NjzWKeGFP65aAL1tH//ndfma wKnNJViNcC3jKnBUIRYRX8bfl1GqwZEM4wXaSJGC3RQLdIAlcyhWbOmIeGietc+iXyGi tjaZP2UVCFyIgWKjRVgZmL0L9XqJMNIFd9tVpPe92OlK8A5Kr7aVY0pgX68STz+17xW4 IaKK3a0NPCkhdXrE+ez6lbYEQnc5RTZhM15tBuwuaUavJpU7eaFrEmBcG98h80yTu4og 77KJUhS4eLu/xdbC+hIbqueD5XhI5HvW3W+VsFybJ8i+bTccuMPvolN5bqY2S11bvvFV 6kjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tX8fjXVUivdL1jGkUmAls8bBWxOe3U72ILB2nFhQv2Q=; b=ZhbP2h4GOAuxpmIMFIGzr0Yl5SMsOxoSTZOgTiOBVVcuUHb0nn64yCs5oCqaGvP7h3 OBcwdhxKeWnJz4q2Kazi0WLxN9wgKf5evOBcGwx8tVU6knR2JN35Ta8ukNYVICLpsZjC clArFyi6tthFAaYcqlef0TbkFkZlIcOAjMwE6J5DVWm2VKNfuuBhBfqPMfV9337+nE8m 99+BBj+9V7/km3HXmqdgLe7RFd09armETIE2QOMXeFoQ5JFF01YJs0SqyAocbYNE3lBc OWLPoxCTmJSnQZWU+0y8k0Kpjx3qBb7n0vc8GaEMSQ7xSCUwwraYyFtQZQoKFdbZUU7V Gc7g==
X-Gm-Message-State: AGi0PuahTa5Kvbb1Bk93IXLCqfN4oO71pJwsHKDPcv3vM1l/6uXSWjN0 j2JRjlQ7HmcRf8m2woHBfBNnwUXWM3XIDJAimZc=
X-Google-Smtp-Source: APiQypLN4Ckg+U9p+IzFJzyONj9XWaalwySdI42YN5yyNFf6Hpk21z/dkYHcI3pXiWX+uaKKsbYbFX4brkllMp08C78=
X-Received: by 2002:a4a:4348:: with SMTP id l8mr14311650ooj.49.1587885046593; Sun, 26 Apr 2020 00:10:46 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Abdussalam Baryun <>
Date: Sun, 26 Apr 2020 09:10:33 +0200
Message-ID: <>
To: "Pascal Thubert (pthubert)" <>
Cc: Benjamin Kaduk <>, Rene Struik <>, Mohit Sethi <>, Jim Schaad <>, "" <>, Erik Kline <>, "Shwetha Bhandari (shwethab)" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000257bfb05a42c4c16"
Archived-At: <>
Subject: Re: [6lo] AP-ND 22
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Apr 2020 07:10:49 -0000

  The draft should indicated on top first page that it updates RFC6775,
7400, and 8505, it only shows updating RFC8505.

On Fri, Apr 24, 2020 at 3:54 PM Pascal Thubert (pthubert) <pthubert=> wrote:

> Hello Benjamin (and 6lo)
> We are soliciting your help on AP ND for hopefully the last time, about
> the last step, that was supposed to be the IANA section that was missing
> for JOSE and Crypto Type 2.
> Rene worked quite a bit with Jim and the conclusion that I made from that
> is that the formats that we already discussed in appendix B (SEC1) were
> better suited than JOSE (or COSE) and avoided both the registry issue and
> gaps in the existing specifications.
> We had a conversation yesterday with our AD (Erik) and Shepherd (Shwetha)
> and we agreed to give a try at using those formats for -22. The conclusion
> that it looked OK but we need a validation that the new key and signature
> formats do not alter the security of the spec.

IMHO it can be more clear to define in options a security policy name
defined by the 6LR, so the security cases of this draft can be attached to
per policy.

On Fri, Apr 24, 2020 at 4:26 PM Pascal Thubert (pthubert) <pthubert=> wrote:

> On the side, It appears that the key representations are typically of
> length 8n +1. Considering that IPv6 ND aligns its options at 8n bytes, it
> would make sense to start a byte ahead like this, don’t you think?

Yes makes sense when the reserved1 is not fully used or zeros, but if used
then having another reserved is ok also,

Best regards,