Thanks for providing this document. 
I do not see any transport-protocol related concerns.
Best wishes, Gorry

# Gunter Van de Velde, RTG AD, comments for draft-ietf-calext-jscontact-profiles-11

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-profiles-11.txt

# Thanks for this document. I am not well skilled within this technology area, but found the document written in a style i could mostly understand. Thank you for the quality write-up.

# COMMENTS
# ========

179	   profile-name = LALPHA *( ["-"] LALPHA / DIGIT )
180	                  ; at most 255 octets in size
181
182	   LALPHA       = %x61-7A ; a-z
183
184	               Figure 1: ABNF Rule for JSContact Profile Name

GV> Is there a reference for what LALPHA means (is it lowercase alphabetic character)? or is this well known in this technology area?

Kind Regards,
Gunter Van de Velde
Routing AD

Thanks to the authors and the WG for their work on this document.

I support the DISCUSS positions of Mike and Med.

Please find below some other comments:

1) I wonder why the section 4 is not moved into the appendix. It is not normative part of this document and seems like would sit well alongside the current Appendix A?

2) I am not familiar with this subject matter, but I am confused with the use of IANA registries for versioned information. I would like to confirm that the desire here is to capture only the latest version of something in the registry and the previous version information is lost. Is that really the intent? I am asking because there is an "escape" clause that allows registration of different versions of a profile as separate entries as well. So, now we will have entries like (Foo,v2) but also entries like (BarV1,v1), (BarV2,v1), (BarV3,v1). Seems odd to me but I don't know enough to turn this into a discussion.

Section 3, paragraph 2
>    The JSContact elements MUST be registered in the IANA JSContact
>    registry.  A JSContact extension MAY define both a new profile and
>    new properties or other elements, as long as they are registered at
>    the same time.  A JSContact profile MUST be registered at IANA (see
>    Section 5).  Section 3.1 defines how to name a JSContact profile,
>    Section 3.2 defines how to version it, Section 3.3 defines how to
>    specify the properties supported by that profile.

Why the requirement that the profile, properties, and elements have to be registered at the same time? Is the implication that once a profile is defined, it cannot be modified?  Why do we have version numbers if the profile cannot be updated?

Section 4, paragraph 6
>    The following table defines the properties of that profile.  This
>    profile does not specify any "Restricted Property Type" and the
>    according column is omitted.

What is "according column"?

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4, paragraph 14
> profile. * The "kind" property of the the NameComponent objects is set to "su
>                                   ^^^^^^^
Possible typo: you repeated a word.

Section 4, paragraph 19
> ions do not incorrectly alter the type of a property, and that the version nu
>                                   ^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

Section 4, paragraph 22
> s profile applies. The reference MUST must include the section number or nam
>                                  ^^^^^^^^^
Possible typo: you repeated a word.

# IESG review of draft-ietf-calext-jscontact-profiles-11

CC @MikeBishop

It was pointed out to me that I was misreading RFC 8126, and Specification Required is stricter than (and includes) Expert Review. That correction addresses my DISCUSS; apologies for the confusion.

## Comments

### Section 3, paragraph 1
```
     properties, value types and values.  These JSContact elements MAY be
     further restricted by the profile, but a profile can not loosen
     restrictions.  For example, a profile can define an originally
     optional property to become mandatory, but it can not make a
     mandatory property become optional.
```
I would suggest framing these differently. A valid element in a conformant
profile MUST be a valid JSContact elemnt, but it is not the case that all valid
JSContact elements will be valid for a given profile.

### Section 3, paragraph 1
```
     The JSContact elements MUST be registered in the IANA JSContact
     registry.  A JSContact extension MAY define both a new profile and
     new properties or other elements, as long as they are registered at
     the same time.  A JSContact profile MUST be registered at IANA (see
```
The 2119 keywords are likely inappropriate here, as they would be difficult to
assess implementation compliance with. There is no way to force all
extant profiles to behave this way. Rather, this document defines a class of
profiles and a registry, and requires these properties before granting
registration.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3, paragraph 1
```
-    further restricted by the profile, but a profile can not loosen
-                                                        -
```

#### Section 3, paragraph 1
```
-    optional property to become mandatory, but it can not make a
-                                                     -
```

#### Section 3, paragraph 4
```
-    profile MUST also be valid (Section 1.7 of [RFC9553]).  Handling
+    profile MUST also be valid (Section 1.7 of [RFC9553]).  Handling of
+                                                                    +++
```

### "Abstract", paragraph 1
```
     which supporting all of JSContact semantics might be inappropriate.
```
Consider "all semantics of JSContact" or "all JSContact semantics"

### Grammar/style

#### Section 4, paragraph 14
```
profile. * The "kind" property of the the NameComponent objects is set to "su
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 5.1, paragraph 1
```
s profile applies. The reference MUST must include the section number or nam
                                 ^^^^^^^^^
```
Possible typo: you repeated a word.

Hi Robert and Mario, 

The changes made in [1] address nicely all the points raised in my previous ballot [2]. Thank you.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-calext-jscontact-profiles-11&url2=draft-ietf-calext-jscontact-profiles-14&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/calsify/sJAdMZ7s7pGMxjs6vAWjNhYBKk0/

Thank you to Behcet Sarikaya for the GENART review.

I support the DISCUSS position of Med Boucadair.