Hi Rafa, Thank you for the responses; I appreciate the time that you put into them.
I will try to respond to just the "discuss" section now, and cover the "comment" section next week when things have calmed down a bit. On Mon, Nov 16, 2020 at 06:44:35PM +0100, Rafa Marin-Lopez wrote: > Dear Benjamin: > > Thank you very much for your very detailed answer. It is an impressive job > and truly helpful. Please see our comments inline. > > > El 5 nov 2020, a las 5:53, Benjamin Kaduk via Datatracker > > <[email protected]> escribió: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-i2nsf-sdn-ipsec-flow-protection-12: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Let's discuss whether it's appropriate to include vendor-specific > > functionality (e.g., linux NETKEY/XFRM marking) in a standards-track > > protocol/model. > > [Authors] Yes, we tend to think the same. We believe it would be better to > stay away of vendor-specific functionality. In fact, for example, we have > suggested to Erik to remove container spd-mark (where this text appears) > since now its purpose can be replaced by the new dscp-mapping format. Excellent; thank you. > > > > The ASN.1 GeneralName type is an abstract type; in order to represent it > > in a string we must have some discussion of how it is encoded. (A > > similar concern might apply to the other ASN.1 types used, such as > > DistinguishedName, though the latter does have a fairly well-established > > string presentation form, so the concern is of lesser magnitude there. > > That said, RFC 5280 is not a suitable reference for the > > DistinguishedName string presentation form.) > > [Authors] We definitely need your guidance here. We believe this is also > related to the e-mail exchange with Tom Petch about the DistinguisedName. In > the DistinguisedName, it seems we have to wait to know the proper reference > since RFC 2247 is not valid. Okay, I will see if I can pester a couple experts in the "hallway" this week to see if X.520 is really the best/only reference for DistinguishedName. > The rest of places in the I-D where ASN.1 is used has been fixed based on > your comments (e.g. your suggestion about using type binary for the DER > format in ca-data, crl-data) > > However, regarding ASN.1 GeneralName, we must admit we need your guidance > here. What do you advise about the encoding? Is it proper to define it such > as: > > case gnx509 { > leaf gnx509 { > type binary; > description > "ASN.1 X.509 GeneralName structure as > specified in RFC 5280, > encoded using ASN.1 > distinguished encoding rules > (DER), as specified in ITU-T > X.690.”; > reference > “ RFC 5280"; > } > } > > Is this acceptable? That will work, yes. I have a nagging feeling in the back of my head that there should be a better way, but I don't know what it would be, so this will have to do. > > > > > > In a similar vein, the 'id-key' identity representation is listed as > > type 'string' but the description lists it as an "opaque octet string". > > YANG strings are not directly suitable for holding binary content (which > > is what an opaque octet string is), so either a scheme for encoding > > arbitrary binary content as a string is needed, the YANG 'binary' type > > should be used, or this node needs to be documented as only allowing > > valid Unicode (IIUC, in UTF-8 encoding, though > > https://tools.ietf.org/html/rfc6020#section-9.4 is not as clear about > > this as I would like). > > [Authors] Yes, let’s use the binary type. > > > > > > The two 'anti-replay-window' leafs are (1) using different-width types, > > and (2) do not have enough of a description to indicate what content > > they hold, especially whe combined with a default value of 32. > > (I mention both locations in the COMMENT.) > > [Authors] Yes this needs clarification and it is definitely confusing. > > It turns out that in section 4.4.2.1 Data Items in the SAD (RFC 4301) > mentions: > > "Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) > used to determine whether an inbound AH or ESP packet is a replay." > > This is reasonable since it is information associated with a particular SAD > entry. However this woud be the anti-reply window itself. However, our > intention (poorly defined) was to allow the configuration of the window size. > That is why we had default 32 (packets). Nevertheless, though the default > value set to 32 came from this text in RFC 4303: > > "A minimum window size of 32 packets MUST be supported when 32-bit > sequence numbers are employed". > > However it also mentions > > "a window size of 64 is preferred and SHOULD be employed as the default" > > It seems that 32 (packets) MUST be supported but it recommends 64. Taking > into account this, we think we could change both containers as follows: > > leaf anti-replay-window-size { > type uint32; > default 64; > description > "To set the anti-replay window size. > The default value is set > to 64 following RFC 4303 recommendation."; > reference > "Section 3.4.3 in RFC 4303”; > } > > What do you think? That sounds good. Thank you for confirming that it is indeed the size of the window that this leaf holds (the one uint64 made me wonder if it was somehow supposed to be the window itself); this all makes sense now! > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- [comment bits trimmed for now] Thanks again, Ben _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
