Re: [Gen-art] Genart last call review of draft-ietf-6man-sids-03

[Reese Enghardt]

Hi Suresh,

Thank you for the replies.

Please see inline:

On 10/27/23 11:30, Suresh Krishnan wrote:

[…]


Section 1:
"SR segment endpoint nodes process a local segment present the Destination
Address of an IPv6 header." I have a hard time parsing this phrase, and I think
adding a preposition or an "-ing" somewhere would make it easier. Is this "SR
segment endpoint nodes processing a local segment present the Destination
Address of an IPv6 header." or "SR segment endpoint nodes process a local
segment which presents the Destination Address of an IPv6 header." or something
else?

I will reword this to

"SR segment endpoint nodes process a local segment present in the Destination
Address of an IPv6 header”

Does that clarify the intent?


Yes, thank you.





Section 3:
Are all SIDs IPv6 addresses? This section sounds like it implies that they are,
while the abstract says that they merely "resemble" IPv6 addresses. I suggest
clarifying this point in the document.

I had attempted to address this with the following text in Section 3.

   Some of these elements may represent a local interface as described
in Section 4.3 of [RFC8754] as "A FIB entry that represents a local
interface, not locally instantiated as an SRv6 SID".  From this it
follows that not all the SIDs that appear in the SRH are SRv6 SIDs as
defined by [RFC8402].

Does that clarify further?


I did see this text, but I could not get an answer to my question from 
this text, being a general reviewer without a lot of context on SRv6.


In my reading, either all SIDs are IPv6 addresses (which is what Section 
3 seems to imply), or all SIDs resemble IPv6 addresses but are not 
necessarily IPv6 addresses (which is what the Abstract seems to imply). 
Is it possible to make a direct statement saying which of the two is 
true, or am I making the wrong distinction?


If all SIDs are in fact IPv6 addresses, then I suggest changing text in 
the abstract such as:
OLD: "Segment Identifiers (SIDs) used by SRv6 can resemble IPv6 
addresses and behave like them while exhibiting slightly different 
behaviors in some situations"
NEW: "Segment Identifiers (SIDs) used by SRv6 are IPv6 addresses which 
may exhibiting slightly different behaviors than specified in the IPv6 
Addressing architecture [RFC4291] in some situations"


If not all SIDs are IPv6 addresses, then I suggest changing text in 
Section 3 such as:
OLD: "[RFC8754] defines the Segment List of the SRH as a contiguous 
array of 128-bit IPv6 addresses"
NEW: "[RFC8754] defines the Segment List of the SRH as a contiguous 
array of 128-bit identifiers which resemble IPv6 addresses"


Of course, if the text is quoting from RFC8754, it might not be possible 
to make this change. My comment is not blocking, it's just a point of 
confusion for me.




"Such a SID is assigned to a node within a prefix defined as a Locator of
length L." Does "Such a SID" refer to the previous sentence, which talks about
SIDs with L+F+A < 128? If not, what is meant by "Such a SID"?

"Such as SID" refers to the "Section 3.1. of [RFC8986] describes the format of 
an SRv6 SID…”. The padding piece you mentioned is still part of the definition from RFC8986 
and was added to the draft since it was brought up as a question in 6man.


I see. In this case, maybe it helps to simply remove the "Such" from the 
sentence, as it appears the sentence is talking about SIDs in general?




IANA Considerations:
This document asks IANA to allocate a Global Unicast Prefix for SIDs. According
to Section 5.1 of RFC 5226, I suggest that this document explicitly identify
the namespace in which a value is to be allocated - The "Internet Protocol
Version 6 Address Space" registry has multiple prefixes marked as "Reserved by
IETF". According to RFC 3513, I assume this will be under the 1000::/4 prefix,
but I may be missing context here.

There is a separate discussion ongoing with IANA on this and it appears to tend 
towards an allocation of the
fbff::/16 block. I will update this in the next version of the draft.


Sounds good, thanks!


Best,
Reese

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

[Gen-art] Genart last call review of draft-ietf-opsawg-rfc7125-update-05

[Elwyn Davies via Datatracker]

Reviewer: Elwyn Davies
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-opsawg-rfc7125-update-??
Reviewer: Elwyn Davies
Review Date: 2023-10-27
IETF LC End Date: 2023-10-26
IESG Telechat date: 2023-11-30

Summary:

The data specification is good to go, but there are some difficulties (in my
view) with status and the nature of some text that is intended to be a data
description but actually provides normative rules for a protocol using the
data.  Looking at the IPFIX IANA record, it may be worth checking that there
are not additional entries that could be vulnerable in a similar way to the
Control Flags.  I also noted that there are some references to RFCs in the
record that could do with added RFC numbers.

Major issues:

Status of documents:  I note that this is intended to be a standards track
document that obsoletes an informational document (RFC 7125)  which in turn
updated a standards track document (RFC 5102) which has in turn been sort of
'obsoleted'  by RFC 7012.  Since RFC 5102 remains as a historic reference and
is mentioned in RFC 7012, I think this draft should specify that it updates RFC
7012 since someone using the IPFIX data structures etc should be aware of this.
 Also I would say that this draft goes further than making RFC 7125 obsolete -
RFC 7125 should become Historic.  I take it this could be specifed in this
document.

S3: In essence this document contains a data description intended to update a
part of the data description in the IANA record of "IP Flow Information Export
(IPFIX) Entities".   However, the four paragraphs of Description in S3 starting
 at para 4 ("As the most significant...") contain prescriptive normative 
language that purports to affect the behaviour of the protocol that is
intending to use this data description (e.g., para 5 says

All TCP control bits (including those unassigned) MUST be exported
  as observed in the TCP headers of the packets of this Flow. )

Is this a legitimate usage?   I note that this language is (I think) the
'stronger requirement language' mentioned in s5, para 1.  This issue is closely
tied to the document status issue above.

Minor issues: None

Nits/Editorial comments:

s1, para 3
OLD:
   However, that update is still problematic for interoperability
   because a value was deprecated since then (Section 7 of [RFC8311])
   and, therefore, [RFC7125] risks to deviate from the authoritative TCP
   registry [TCP-FLAGS].
NEW:
   However, that update may still be problematic for interoperability
   because a flag value was added prior to the release of [RFC9293] for
   experimental purposes but has since been deprecated (see Section 7 of
   [RFC8311]). [RFC7125] pre-dates this deprecation and explicitly mentions the
   deprecated flag hence deviating from the authoritative TCP registry
   [TCP-FLAGS].  Any future changes to the control flags would risk additional
   deviations unless [RFC7125] were updated in the same way.
END

s4: IANA should also add a reference to this document.



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

Re: [Gen-art] Genart last call review of draft-ietf-6man-sids-03

[Suresh Krishnan]

Hi Reece,
 Thanks a lot for your review. Please find responses inline.

> On Oct 26, 2023, at 3:46 PM, Reese Enghardt via Datatracker 
>  wrote:
> 
> Reviewer: Reese Enghardt
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-6man-sids-03
> Reviewer: Reese Enghardt
> Review Date: 2023-10-26
> IETF LC End Date: 2023-10-27
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: The document is almost ready for publication as an Informational RFC,
> pending some clarifications in the IANA Considerations and some text tweaks.
> 
> Major issues: None.
> 
> Minor issues:
> 
> Abstract:
> The abstract does not mention that the document allocates a Global Unicast
> Prefix for SIDs, which seems like a major contribution of this document. I
> suggest mentioning this contribution in the abstract.

Will do.

> 
> Section 1:
> "SR segment endpoint nodes process a local segment present the Destination
> Address of an IPv6 header." I have a hard time parsing this phrase, and I 
> think
> adding a preposition or an "-ing" somewhere would make it easier. Is this "SR
> segment endpoint nodes processing a local segment present the Destination
> Address of an IPv6 header." or "SR segment endpoint nodes process a local
> segment which presents the Destination Address of an IPv6 header." or 
> something
> else?

I will reword this to 

"SR segment endpoint nodes process a local segment present in the Destination
Address of an IPv6 header”

Does that clarify the intent?

> 
> Section 3:
> Are all SIDs IPv6 addresses? This section sounds like it implies that they 
> are,
> while the abstract says that they merely "resemble" IPv6 addresses. I suggest
> clarifying this point in the document.

I had attempted to address this with the following text in Section 3.

  Some of these elements may represent a local interface as described
   in Section 4.3 of [RFC8754] as "A FIB entry that represents a local
   interface, not locally instantiated as an SRv6 SID".  From this it
   follows that not all the SIDs that appear in the SRH are SRv6 SIDs as
   defined by [RFC8402].

Does that clarify further?

> 
> "Such a SID is assigned to a node within a prefix defined as a Locator of
> length L." Does "Such a SID" refer to the previous sentence, which talks about
> SIDs with L+F+A < 128? If not, what is meant by "Such a SID"?

"Such as SID" refers to the "Section 3.1. of [RFC8986] describes the format of 
an SRv6 SID…”. The padding piece you mentioned is still part of the definition 
from RFC8986 and was added to the draft since it was brought up as a question 
in 6man.

> 
> IANA Considerations:
> This document asks IANA to allocate a Global Unicast Prefix for SIDs. 
> According
> to Section 5.1 of RFC 5226, I suggest that this document explicitly identify
> the namespace in which a value is to be allocated - The "Internet Protocol
> Version 6 Address Space" registry has multiple prefixes marked as "Reserved by
> IETF". According to RFC 3513, I assume this will be under the 1000::/4 prefix,
> but I may be missing context here.

There is a separate discussion ongoing with IANA on this and it appears to tend 
towards an allocation of the
fbff::/16 block. I will update this in the next version of the draft.

> 
> Nits/editorial comments:
> 
> Section 3:
> "Please note that [BCP198] does not override the rules in [RFC4291], but 
> merely
> limits where their impact is observed" Missing full stop at the end.

Will fix.

Thanks
Suresh

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